I have often had to manage risks in a project and have also written about managing risks in projects but reading a project management newsletter recently made me think that for all the information, methodologies, tips and techniques we can read about, talk about and discuss concerning risks in projects, we rarely discuss the effect of simply making mistakes. A very fact of our humanity.
Many mistakes are trivial and do not affect the overall outcome of a project. For example, a new software development project will always have some mistakes, in fact plenty of mistakes. But there is an expectation of these kinds of mistakes and there are processes and tools available for debugging software. After these mistakes, or bugs, have been corrected the software will go through testing for technical faults as well as user testing to ensure that it actually does what it was supposed to do. So no-one would ever expect a software development project to be without these types of mistakes and they would be anticipated and planned for. They would probably not even be considered risks as they are so likely to happen.
There are other types of mistakes that could not be anticipated and would also have been unlikely to appear on a list of risks. For example, the manufacture of a component for a new prototype engine where the machinery was incorrectly calibrated. This would cause a problem at the prototype stage but would be corrected well before the production stage to prevent it from becoming a serious problem.
These are human mistakes, not risks, so it is important to distinguish them from risks. But the most dangerous mistake of all in projects is when all the data for the project have been gathered but then the data are incorrectly analysed. The data could have been gathered by any number of methods such brainstorming, storyboarding, interviewing or prototyping or whatever method is most appropriate to the project or preferred by the project manager.
This is the most dangerous type of mistake because that data form the foundation of the project. The project planning, schedules, budget, risk management etc are all built on the assumption that the data analysis is correct.
How many projects would list as a risk the fact that the information on which the whole project is founded is faulty? Very few, if any, I imagine and yet this could mean that the whole project is doomed from the start. And for once it might not be the fault of the project manager.
Imagine that new software development project – the company developing it has been looking for a niche area which they can dominate. So a number of marketing professionals are assigned to investigate gaps in the market. And they come up with, let’s say, a new system that integrates data from a number of existing 3rd party applications into one database that can then display and analyse several different datasets in a way that has never been easily possible before. The business analysts get to work in the buzz of the exciting new project – all that data in one place. But they neglect to realise that the newly integrated data cannot actually be used for any worthwhile business advantage.
And there you have it – the project doomed from the start down to fundamental research and analysis mistakes that did not reveal that the integrated data wouldn’t actually provide something useful that somebody wanted.
Everyone hates a project failure but I have to say I get some satisfaction out of it not being the project manager’s fault all the time.
But on a serious note, my point is that mistakes are not always trivial and yet they are not risks that can be managed as part of a formal project management plan. A project manager cannot predict human mistakes but should be on the look out for them and question decisions that fundamentally affect each project.