Make no mistake... And no pun intended there...I fully realize that there are hundreds of mistakes waiting out there for project managers to make. I've probably made many of them somewhere along the way in my 25 year IT career. One thing I like to believe is that I've learned from my mistakes and from those mistakes that I've witnessed others making. I've tried to make mental notes during and after projects as well as document those PM mistakes physically in post-deployment lessons learned sessions with my teams and my project clients. Through all the professional writing that I've done I try to bring these experiences and observations to light to help other project managers, team members, IT executives and even project customers be aware and plan to avoid such actions on their own projects.
For this article I would like to discuss what I consider ten of the most common mistakes that project managers make or allow on their projects. These are in no particular order – they are all important and all can lead to extreme budget overruns, failed schedules and frustrated project clients. Basically, they can all lead to project failure. My top ten are:
Failure to ask enough questions to get clear enough direction before starting the project (also known as: Taking the customer’s need at face value without digging deeper)
Our project clients come to us with problems. Big problems. And they are almost always certain that they know their need and they may even be telling us how to solve it including what technology to use. Sounds easy, right? The problem is, we’re the project experts and it’s our job to ask questions – the right questions – to uncover the real need of the client. What they are presenting as the problem may only be a symptom of what really needs to be addressed. It’s the responsibility of the project manager and team to ask the tough questions to get to the real requirements and the real problem. Then, and only then, can we understand the need, price the effort and map out a solution. If we act on the customer’s initial concerns without digging deeper we may end up solving the wrong problem and spending a lot of the customer’s project dollars on a solution that won’t work for them.
Failure to ask enough questions to get clear enough direction before starting the project (also known as: Taking the customer’s need at face value without digging deeper)
Our project clients come to us with problems. Big problems. And they are almost always certain that they know their need and they may even be telling us how to solve it including what technology to use. Sounds easy, right? The problem is, we’re the project experts and it’s our job to ask questions – the right questions – to uncover the real need of the client. What they are presenting as the problem may only be a symptom of what really needs to be addressed. It’s the responsibility of the project manager and team to ask the tough questions to get to the real requirements and the real problem. Then, and only then, can we understand the need, price the effort and map out a solution. If we act on the customer’s initial concerns without digging deeper we may end up solving the wrong problem and spending a lot of the customer’s project dollars on a solution that won’t work for them.
Involving too many people in key decision-making activities due to lack of confidence and experience
It’s ok – even wise – to seek out the advice of colleagues, peers, senior management, and more experienced project professionals who may have already encountered issues similar to what you’re facing. Project managers who lack experience with a given situation should do this – especially if the project has reached a critical point and needs quick action. However, more is not always better. Involving too many ‘subject matter experts’ in a decision process can lead to a significant delay in the actual making of the decision, meaning you may miss the boat on responding to the issue or at least cause the project to suffer severe damage in the process.
Not communicating openly enough with the project customer
The project manager who thinks they are ‘protecting the customer’ by keeping things from them runs the extreme risk of alienating the customer or worse – causing the customer to loose all trust, faith, and confidence in the integrity and ability of the project manager and team. I like to work on the assumption that the customer will always find out. I always do with my kids. My parents always did with me. My wife always does. It’s just that way. Sooner or later you’re going to have to give the customer the bad news so do it quickly and get them on your side as you work to correct the problem situation. Never go it alone. Only keep it from them long enough – if you keep it from them at all – to think up some possible courses of action to present to them…and that better be quick.
Putting too much trust in the self-management of the project team
No one likes to be micro-managed. But allowing your very talented and egocentric team too much leeway can cause your project to veer off course. Give them an inch and they’ll take a mile. Seriously…these are skilled individuals who already don’t like to be told what to do – especially by someone less technical then they are. Assign them their tasks and hold them accountable for them and keep abreast of what they are doing by communicating frequently with them. You must assume that if you haven’t heard from a project team member in awhile that they might be working on some tasks that are slightly to significantly off course. And with that extra effort there goes your project budget. Stay on top and keep them focused.
Micro-managing the project team
I already said that no one likes to be micro-managed. And sometimes new project managers will feel that they have to do that. A skilled project team with big egos will resent this behavior immediately and make life miserable for the new project manager. For the experienced project manager they may become confrontational or passive aggressive. At any rate, their behavior may become detrimental to the rest of the team and the progress of the project. Allow them the proper freedom to do their job. They’re experts. Recognize that and treat and trust them accordingly.
Relying too heavily on senior management direction
You need senior management. And they need you. But they have their own jobs to do. Make them interested in your project and have them at the ready if you need them to knock down barriers your project may encounter. Do this by sending them weekly status reports and schedule updates. But that’s just informing them and that’s a good thing. The flipside is being far too needy and running to them with every issue and decision that needs to be made. Your project will suffer from your lack of decision ownership and your career will suffer greatly when you show your senior leadership that you’re really not a leader at all. At least not a very confident one.
Failure to carefully manage project scope
Project scope is like the lid on a shopvac. Leave it on and it successfully manages all the dust and grime in the shopvac. Take it off while it’s running and chaos and a significant mess ensues…and you get to clean it up. The project manager and team must be in control of the project scope throughout the engagement. If it looks like it might be out of scope, something has to happen. The work or issue must be assessed and a change order must be presented. If scope isn’t managed and change orders aren’t created then the project budget and timeline will take repeated beatings throughout the engagement and the end result will be a project that is either canceled or deployed way over budget and way off schedule.
Failure to continually monitor the budget
I make it a habit to check the project forecast every week as I update the project budget with actuals that I get from accounting. By doing this I know I’m never far off budget. A 10% budget overrun is far easier to fix as you discover it than a 50% budget overrun is to fix three months later when it rears its ugly head. And it’s much easier to break the news to the customer or your senior management that the project is going to come in 10% over budget – assuming you can’t fix the overrun – than it is to tell your CFO that a $1 million project is coming in $500,000 over budget. Ouch.
Signoff on requirements that are not detailed enough
I always say that requirements are the lifeblood of the project. Documenting requirements is never easy and getting good, detailed requirements from the project customer that mean something to the delivery team who will be creating the solution is a very difficult task. What the customer considers good and what your solution architects consider good are usually two very entirely different things. The experienced project manager anticipates this gap and plans for enough time in the schedule to sit down with the customer and hammer out real requirements…no matter how much the customer contends that they already have done that on their own. They haven’t. At least I’ve never seen it in 20 years of managing IT projects so far.
Don’t plan enough planning time – Plans the project schedule too tightly
Being overly optimistic with the project schedule and task durations is never a wise move. It’s noble to say, “We’re going to get this done in two weeks instead of the usual three weeks.” But it’s also stupid. If there’s an extreme crunch, that’s one thing – and even then you need to let whoever is putting the thumbscrews on you that the date is not likely to be met. But if you’re just trying to look good…don’t do it. I’m not saying you should ever pad. I’ve been a developer and I know how much estimates can get padded anyway…that’s why I’m glad I was once a developer and I’m still and excellent technical estimator. Don’t pad, but be real. Your project needs a good leader, not a superhero who thinks he can accomplish the impossible.
It’s ok – even wise – to seek out the advice of colleagues, peers, senior management, and more experienced project professionals who may have already encountered issues similar to what you’re facing. Project managers who lack experience with a given situation should do this – especially if the project has reached a critical point and needs quick action. However, more is not always better. Involving too many ‘subject matter experts’ in a decision process can lead to a significant delay in the actual making of the decision, meaning you may miss the boat on responding to the issue or at least cause the project to suffer severe damage in the process.
Not communicating openly enough with the project customer
The project manager who thinks they are ‘protecting the customer’ by keeping things from them runs the extreme risk of alienating the customer or worse – causing the customer to loose all trust, faith, and confidence in the integrity and ability of the project manager and team. I like to work on the assumption that the customer will always find out. I always do with my kids. My parents always did with me. My wife always does. It’s just that way. Sooner or later you’re going to have to give the customer the bad news so do it quickly and get them on your side as you work to correct the problem situation. Never go it alone. Only keep it from them long enough – if you keep it from them at all – to think up some possible courses of action to present to them…and that better be quick.
Putting too much trust in the self-management of the project team
No one likes to be micro-managed. But allowing your very talented and egocentric team too much leeway can cause your project to veer off course. Give them an inch and they’ll take a mile. Seriously…these are skilled individuals who already don’t like to be told what to do – especially by someone less technical then they are. Assign them their tasks and hold them accountable for them and keep abreast of what they are doing by communicating frequently with them. You must assume that if you haven’t heard from a project team member in awhile that they might be working on some tasks that are slightly to significantly off course. And with that extra effort there goes your project budget. Stay on top and keep them focused.
Micro-managing the project team
I already said that no one likes to be micro-managed. And sometimes new project managers will feel that they have to do that. A skilled project team with big egos will resent this behavior immediately and make life miserable for the new project manager. For the experienced project manager they may become confrontational or passive aggressive. At any rate, their behavior may become detrimental to the rest of the team and the progress of the project. Allow them the proper freedom to do their job. They’re experts. Recognize that and treat and trust them accordingly.
Relying too heavily on senior management direction
You need senior management. And they need you. But they have their own jobs to do. Make them interested in your project and have them at the ready if you need them to knock down barriers your project may encounter. Do this by sending them weekly status reports and schedule updates. But that’s just informing them and that’s a good thing. The flipside is being far too needy and running to them with every issue and decision that needs to be made. Your project will suffer from your lack of decision ownership and your career will suffer greatly when you show your senior leadership that you’re really not a leader at all. At least not a very confident one.
Failure to carefully manage project scope
Project scope is like the lid on a shopvac. Leave it on and it successfully manages all the dust and grime in the shopvac. Take it off while it’s running and chaos and a significant mess ensues…and you get to clean it up. The project manager and team must be in control of the project scope throughout the engagement. If it looks like it might be out of scope, something has to happen. The work or issue must be assessed and a change order must be presented. If scope isn’t managed and change orders aren’t created then the project budget and timeline will take repeated beatings throughout the engagement and the end result will be a project that is either canceled or deployed way over budget and way off schedule.
Failure to continually monitor the budget
I make it a habit to check the project forecast every week as I update the project budget with actuals that I get from accounting. By doing this I know I’m never far off budget. A 10% budget overrun is far easier to fix as you discover it than a 50% budget overrun is to fix three months later when it rears its ugly head. And it’s much easier to break the news to the customer or your senior management that the project is going to come in 10% over budget – assuming you can’t fix the overrun – than it is to tell your CFO that a $1 million project is coming in $500,000 over budget. Ouch.
Signoff on requirements that are not detailed enough
I always say that requirements are the lifeblood of the project. Documenting requirements is never easy and getting good, detailed requirements from the project customer that mean something to the delivery team who will be creating the solution is a very difficult task. What the customer considers good and what your solution architects consider good are usually two very entirely different things. The experienced project manager anticipates this gap and plans for enough time in the schedule to sit down with the customer and hammer out real requirements…no matter how much the customer contends that they already have done that on their own. They haven’t. At least I’ve never seen it in 20 years of managing IT projects so far.
Don’t plan enough planning time – Plans the project schedule too tightly
Being overly optimistic with the project schedule and task durations is never a wise move. It’s noble to say, “We’re going to get this done in two weeks instead of the usual three weeks.” But it’s also stupid. If there’s an extreme crunch, that’s one thing – and even then you need to let whoever is putting the thumbscrews on you that the date is not likely to be met. But if you’re just trying to look good…don’t do it. I’m not saying you should ever pad. I’ve been a developer and I know how much estimates can get padded anyway…that’s why I’m glad I was once a developer and I’m still and excellent technical estimator. Don’t pad, but be real. Your project needs a good leader, not a superhero who thinks he can accomplish the impossible.
RSS Feed
