Products over Projects

hh 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.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>