Month: August 2016

I generally stay away from buzzword topics. They are typically marketing oriented and serve only the advertising for which they are intended. It is sort of like presidential campaigns and polls. Have you ever thought about the reason for their existence? The candidates really do not benefit from the polls outright as one’s mercurial behavior can increase the polls just to see them fall later. The public most definitely does not benefit from the polls as they represent disinformation as opposed to any fact-based reality. The polls are created by and substantiated by the media in order to benefit the media. It gives them something to report on – “Breaking News – George Washington Up in the Polls by 7%.” Kind of like ESPN when sports gets boring the Lebron versus Kobe debate starts all over again.

But this particular piece of marketing spin, designed like all others to sell something shiny to an otherwise unwilling participant in the dance, is perhaps the most convoluted piece of disinformation ever (yes, I typically am not a fan of hyperbole but I do engage every now and then).

There are three vastly different business frameworks interwoven into this shiny fabric. The first covers procurement vehicles followed by technical debt finished up by business process evolution.

The business process evolution incorporates one of three basic approaches in making your business perform better over time.
1. Do more with less; 2. Do things differently and 3. Do different things.

A project makes a singular leap through one of these approaches through one iteration. For example, Cisco had multiple “projects” that re-engineered their expense reporting process enabling the “do more with less” approach. These iterations reduced the transaction costs each time and resulted in an significant overall reduction by the final iteration. A product (software product) is designed to encapsulate a business process and enable that process through automation making functional enhancements over time (thinking of my iPhone 6 upgrade of late). So the product approach helps with approach (1) but not in approach (2) and (3). Actually, it could be argued that the product and project are pretty much the same in regards to approach (1).

Procurement is how we buy and their are three ways to buy technological solutions: (1) staff aug, (2) Project Deliverables and (3) Package Software. A product over project discussion embeds a hidden assumption surrounding the procurement vehicle that is both not accurate and not fact-based. The assumption is this: a product approach includes a “package” purchase and a project approach concludes a deliverable purchase.

Finally, there is technical debt. This aspect has many perspectives but the short version includes the debt curve is different for many different industries and verticals. The public sector carries a large debt structure by necessity and this normal and standard model works in direct opposition to most product over project rhetoric. Manufacturing comes in a close second with their well managed technical debt and a host of other industries and verticals manage technical debt as a strategic maneuver that weighs more heavily than product versus project considerations.
Product over project gives a topic and product over project gets a meeting and may even get a speaking engagement at a conference near you. But a wholistic decision leading to a corporate strategy is a little tough for me to imagine.

If I never get to see the northern lights I won’t be happy. The sheer scope and scale of this naturally occurring phenomenon overwhelms and inspires me. I enjoy challenges – the harder the better.

I find some of my experience in this tech-space has been straight-forward but rarely easy. I remember tough projects spending a lot of their time in the “valley of despair”. Large scale and small and highly complex to low-tech – all IT projects have their own particular flavor of “hard”.

The client always enjoys the “luxury of being unreasonable”. There are difficult and arrogant “heads of operations” who “built this same solution at my last shop” (bless their hearts). There is the head of sales who does not see the need for predictive modeling in the solution set and the guy that says he is not sure “mobile” is a viable solution in the healthcare space.  And those that insist that you “respect the title” and those that hold “court”.  There is “kissing the ring” and re-writing that email 30 times versus the short version.

There is the developer who thinks he is the best BA in the room; the BA who took a couple of coding classes; the QA whose next project should include a project manager title and who could forget the aloof and distant architect (not to mention the know-it-all CIO).  As a CIO I sometimes laugh at all of our dysfunction as few of us can actually admit these failures out loud for fear of looking bad – and of course we can not look bad!

But when they come calling … searching for an actual result … who do we hire?  Who do we hire to do the hard stuff?  I call them the IT Seal Team.

Members of the seal team are an elite crew devoid of excuses and blame with nothing but demonstrable results in the wake.  They make mistakes often as they are not afraid to take risk yet avoid recklessness.  And they are ok with mistakes because they know image is nowhere near as marketable as results.  Only in a presidential election are facts completely irrelevant.  In our world, success breeds inheritance and everyone watching knows when IT succeeds and when it fails.