This often applies to IT projects often, but not exclusively - rushing into it without proper planning, biting off more than they can chew. That might sound glaringly obvious, but it happens all the time . . .
There's a large project and everyone wants to get on with it because "time is money!". But what happens next is that everyone is in such a hurry that they don't think it through properly:
- They don't consider the risks that could impact the project
- They don't ensure they have the requirements properly documented
- They've thought about what they do today, not what they will need tomorrow
- They try to do too much in one go
Some examples:
- Spain's tallest residential skyscraper (47 floors) with no elevators
- Surrey police crime management system scrapped after spending £14.8m
- UK £12bn National Health Service computer system scrapped
- Healthcare.gov and a history of failed projects
I believe a lot of it ultimately comes down to ego and bravado, few people would admit to this, but that's what it is. Everyone is eager to get going, show progress, make it happen, justify their existence and position in the project and this, in turn, causes the team (as a whole) to underestimate the complexities and over-estimate their abilities because they don't actually understand what it's going to take to make this thing happen and think they can solve issues as they arise - maybe they can, but the costs will go up and time scales will slip!
Clearly, nobody goes into a project hoping to fail, so where does it so often go wrong?
There used to be a generally accepted rule of thumb that whatever the software licenses cost, it would cost between two and five times as much to get it properly implemented. The advent of Open Source and Software as a Service (SaaS) or "Cloud" or "Hosted" applications has changed this model, but it still holds true that the cost of implementation will almost always be more than the software itself - but now we could be talking 100 times as much! The important thing to realise is that trying to save money in the wrong areas is going to cost you dearly!
The really key thing here is that if you don't have a VERY clear set of requirements, then you don't know what you're building. You wouldn't start building a family home (or bigger) without a set of architect's drawings, would you? Or start without a clear idea of the manpower, time-scales, materials, budgets, timings for each of the different jobs and when the trades would come on site. . ? Well, would you? Yet we are tempted to do this in IT projects.
Then, just like every project of every type, there's the good old, "CYJ Factor" - "Can you just . . . .?" Move this? Do that? Add this? Change that . . . It would be great if . . . You know, stuff that wasn't considered when the job was being scoped, but now it is important and can be miraculously added without impacting budgets or timescales.
So, for me the most important part of a project, from 25+ years of experience, is actually gathering accurate requirements and doing the Business Analysis to establish what's absolutely critical, what's important, what would be "nice to have" etc. Because, without this information you're flying blind and you don't even know where you're heading for.
HOWEVER, the real challenge here is that you're going to ask the people who do their job every day what they want, aren't you? And, guess what, chances are they're going to describe what they have today as what they need tomorrow. If you had asked a typist in 1990 for the perfect specification of a word processing package, there's a good chance they would have described a blue screen with white text, because WordPerfect 5.1 was the de facto standard then. The colour of the screen wasn't a CRITICAL requirement, it was just what they were used to - and that's the danger of getting people who do the job every day to provide requirements for a new system - you're going to end up with a detailed description of what you have right now, with a few minor tweaks.
So, here you are, with the best opportunity in years to change the way your organisation operates and the ability to revolutionise your business, decrease costs, improve efficiency, surge ahead of your competitors, make money, save money, etc. and the specification you are likely to be given by your people is a slightly updated version of what you already have! The opportunity to leverage technologies, radically improve processes, integrate systems, become leaner and more efficient and you end up with your current system on new hardware, because that's what your people just told you they NEED.
The really bad news is that's just the start of your issues, because now a team of people who don't know your business are going to start cutting code based on the specification you just gave them! Moreover, they probably don't speak English as a first language and they're not going to question what you meant by XYZ because that would be disrespectful - they're just going to code it and hope for the best!!
And when user requirements are translated by software guys, it all goes horribly wrong . . . . have you heard this joke:
A wife asks her husband, a software engineer...
"Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6!"
A short time later the husband comes back with 6 cartons of milk.
The wife asks him, "Why the hell did you buy 6 cartons of milk?"
He replied, "They had eggs."
The next article will be on Requirements Gathering . . .