A few days ago, I came across this excellent blog entry about many of the project management misconceptions, bad ideas, overused buzzwords that I ran into in my professional career.
For instance, the author defines “backwards causality” by the example, “let’s adopt the Spotify model!” Yes, of course. While you are at it, also ask a lottery winner what he did that led to his winfall, and make sure you follow those steps exactly, as it will surely guarantee a win.
Or how about the “big bang”, as in “we can’t afford to keep up two systems at the same time”? Even in my teeny-weeny home office environment, I run things in parallel. When I set up a new workstation, it runs parallel with the old for weeks. Same goes for a new server. When I last did a planned transition to a new Internet service provider, I ran things in parallel for a month, too. Sure, it costs money. But it costs a lot less money in the long run than a botched, irreversible transition.
Then there is “buy vs. build”, or the mythical commercial-off-the-shelf (COTS) beast. I have seen this so often, especially in this blessed government town! Sure, don’t develop your own word processing software, specifically designed for Her Majesty’s Canadian Government, as that would be foolish nonsense. But many government applications are unique to the government, and may also be unique to the country or jurisdiction. Yet I have seen this happen, in fact I have lost business as a result, when a government department somehow got it in their head that COTS is the way to go.
Closely related is the concept of a “platform”. As in, we’re not just selling a product… we are selling a platform! Yeah, right. Add an API to your software, perhaps bundle two or three remotely related applications with a common installer, and suddenly, you are a platform vendor. To would-be buyers out there: The word “platform” has no technical meaning. It is a marketing buzzword designed to serve one purpose and one purpose only: to suck more money out of your budget.
Speaking of money, how about “enterprise”? You know, it’s government, we cannot just go with some low grade consumer product, we need an “enterprise solution”! You know what makes a product “enterprise”? Mostly it’s the price, nothing more. So-called “enterprise-ready” software is usually the same solution you get elsewhere, just packaged differently.
Another lovely buzzword is the “roadmap”. OK, I plead guilty: in my misguided youth, I both talked about, and contributed to the development of “roadmaps”. And to some extent, they may even make sense: as in a vague, strategic overview of where an IT system is expected to be heading in the long run. But the moment you shoehorn that roadmap into Microsoft Project and start attaching numbers (dollars, dates) to it, it becomes a work of pure fiction. Don’t build roadmaps, do research, do planning, do analysis, do design.
And for goodness’s sake, don’t buy a “turn-key solution”. That is perhaps the greatest deception of all: the idea that an outside vendor can come in, study your business, analyze the requirements, design and implement a solution so that on the agreed-upon delivery date, a nice, shiny new system is ready, just waiting for you to turn the ignition key. That *never* happens. Every experienced system architect can tell you that successful systems don’t happen without customer/user involvement at all stages; that the best adoption strategy is often gradual (see also the “big bang” approach above); and that even the best system needs adjustments and tinkering as its shortcomings only become evident once it is tested through daily use.
Anyhow, these are good lessons. The original article is well worth the read, as it talks about many other points, too.