All projects run the risk of getting into trouble along the way. Here are three pitfalls and how you can avoid them.
“Let’s do it all now”
It’s not possible to deliver everything in one go. Part of the role of a project manager is analysing the best way to get to the desired solution. That might be through rolling out a piece of software to 100 sites in one go, or ten million users, and if that genuinely is the best approach for whatever reason, then go with it. But most often you will have the choice of several different deployment solutions and it is a prudent project manager who chooses not to do it all in one go.
A pilot will give you the chance to learn from development, delivery and implementation mistakes across the full range of technology and business change. It will help you identify who are key supporters and where you may have issues with stakeholders in the future. Reviewing your pilot with real-life customers or end users will also give you the confidence that you are delivering what they want. They will hopefully go on to become champions of the project and able to support you and your team during the complex later stages.
“Let’s break it down”
Breaking down a large project into manageable chunks is a good thing. However, those chunks don’t always fit back together again. The risk here is that by decomposing the project into stages, phases, small projects or even work packages you end up with lots of small pieces that individually do a good job, but that overall don’t actually fit into the whole you were after. This creates problems like:
- The inability to effectively realize benefits
- Separate teams or team members working on the same integration exercises
- A ‘whole’ that is less than the sum of its parts
- Rework
- Successful unit testing but unsuccessful integration or smoke testing, which results in extensions to the project schedule while these errors are resolved
- Different project approaches or standards used for individual elements
- Confusion at the time of project handover into support as there may be multiple ways of doing things being handed over instead of a standardised approach
- Increased costs
This is particularly relevant in software development projects where a large software release is broken into components for ease of development. They need to be joined back together – and this joining needs to be planned. This was one of the key messages at the prestigious BCS Lovelace lecture given by Maurice Perks this month.
If integration of components – whether they are software elements or smaller parts of a large programme of business change – are not designed with fitting together in mind, chances are they will not fit.
“Let’s fix the scope”
You have to start with a view of what you want to achieve. After all, if you don’t know where you are going you will certainly end up somewhere else. However, fixing the scope forever is not practical and not desirable. Scope is a fluid concept.
At the end of the requirements phase and at the beginning of the development or delivery phase, you have to know what it is you are trying to do. In this sense, you do need a fix on the scope. But that isn’t to say the scope is permanently fixed.
Business needs change, the economy and the environment change, and a PESTLE analysis* will flag any items that are at risk of influencing your well-defined scope.
Your change control process should include a method by which people can raise potential scope changes for analysis and recommendation. You may choose not to implement them, but if there is a valid reason, then the changes could (should) be adopted. If you choose to ignore or refuse sensible changes there is every likelihood that the project you deliver will no longer be fit for purpose. You could spend months working on something that essentially will never be used by the end customer as it has failed to meet the changing business need.
It’s much better the manage scope change as a constructive and formal process, instead of organically, which leads to confusion in the team as no one knows what the latest position in and scope creep.