Project issues, challenges, mistakes…they happen. It’s a way of life. No project in the history of projects has ever gone perfectly throughout the engagement without bumps and issues along the way. As project managers, most of us are learning along the way – I know I am and I have about 25 years of experience managing projects. One thing I have learned is this…there are a few key things we must make sure that we – as project leaders – avoid repeating on our projects time and time again as they only lead to difficulty, confusion, customer frustration, and sometimes project meltdown. The list can be longer – much longer – but I’ve narrowed it down to these four key items:
1) Treat risk management as an optional item. Risk is risk. There is a reason things are called risks. And on most projects at least some of that risk you identify at the beginning of the project becomes a reality. Conduct risk planning and identification sessions up front on the project and ready yourself and your team to react to that risk. You won’t catch everything, but you may end up saving a project you would have otherwise lost had it not been for some proactive risk planning on the project.
2) Overlook small scope changes as small. No scope changes are too small to just let pass through. You can keep some in your hip pocket as negotiating points on larger project issues, but you and your team must always be aware of the scope of the requirements and alert each other and the customer of work that is being done or requested that falls outside of that scope. It isn’t always easy to do or to recognize, that’s why it requires managing. By overlooking several ‘changes’ to the project scope, you can easily find yourself falling outside of the project budget and you may not know why and you’ll have no documentation or additional customer revenue from the changes to save yourself when you have to answer to the budget overrun at deployment time.
3) Treating the project budget as a casual financial yardstick. The project manager is handed the project with a price tag on the project. Period. There is always a price tag. Whether it’s an internal estimate or price on an internal project, or it’s a price quoted to your project customer. Yes, that may be the only price your customer – internal or external – is going to see and pay. Or they may be getting billed for the ‘real price’ – the actual cost of the work you and your team is doing. Either way, the budget is yours to manage…even if you were never really given it to manage. If you weren’t given the budget to manage, then seek it out and manage it. Because at the end of the day, you’ll be expected to answer to it – either by your senior management if you’re leading a ‘fixed price’ engagement or by your customer if they are getting billed the real cost of the project work you’re doing. If it’s higher than was originally quoted or planned, you’ll be answering to it – so know it and manage to it.
4) Assume the project customer knows what they need. The customer almost always comes into an engagement with their own ideas of how to solve their problem. And our mistake as a project team can be two fold in those cases…first we believe that the customer knows what their real problem is and, second, we believe that they know how to solve it. If we’re busy and take them at their word, we are the ones who will get blamed for the project failure later on when we implement the wrong technology or a solution that doesn’t meet their needs. Take what the customer comes to you with and set it on a shelf, then do your own discovery work. Go to the end users and subject matter experts (SMEs) in the customer organization. Don’t assume the sponsor has gathered all of the necessary info or even asked the right people the right questions.
Summary / call for input
If we don’t plan for risks and watch out for mistakes and use project management best practices, we are destined to repeat our failures. Paying attention to what has going wrong and striving for better future performance, is what makes us better project managers with higher future project success rates.
What about our readers? Do you agree with what I have listed here? What would you add or change? Please share and discuss. Thanks!