Nobody is perfect, no matter how highly we regard ourselves and our skills. And as project managers, most of us are learning along the way – I know I am, and I’m 20+ years into this profession. 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:
Assume the project budget is meant as a guideline
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.
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.
Treat risk management as an optional item
Risk is risk. It’s called that for a reason – 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.
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.
Lessons learned are optional
I understand that it is hard to regroup at the end of the project for a lessons learned session to involve most or all of the project team and customer team and other stakeholders. Everyone has moved on to other projects and if things went poorly well… who likes to dwell on the bad stuff right? Tomorrow is another day. Wrong. No matter how hard it is, it’s important to get as much of the team back together – even if it’s a 30 minute conference call. Don’t skip it even if it’s only a partial project team in attendance. You never know when something very important may come up – even something that may need fixed on this current project.
Summary
What we fail to correct or observe are the very mistakes that we are destined to repeat time and time again. ‘Too busy’ is never a good excuse, because expensive re-work later in a project will kill the budget and the project manager and team are the ones who will be on the hook. Do it right from the beginning. These key issues are just the start of a list of common mistakes to avoid. What’s on your list? What have you learned along the way in your PM career as mistakes we all are prone to make from time to time and should try to avoid at all costs if we hope to achieve success on our projects?
Photo by Sarah Kilian on Unsplash
