What would you say are the most significant mistakes made by a typical project manager?

By "most significant", I mean with a large negative impact on the project. And the context is line-of-business projects, where software isn't the main product of the organization.

For each mistake you discuss, it would be great if you could note the most likely cause and best solution related to that mistake.

+4  A: 


Causes range from inexperience to arrogance.

Fixes include listing all assumptions explicitly and quantifying the impact on the project if they're wrong; collaborating with team members; and learning from the previous project's mistakes.

Adam Liss
+43  A: 

Brow-beating developers to reduce estimates to fit the budget.

Solution: Break all tasks down to a granularity of around 4 hours. Play planning poker:

The idea behind planning poker is simple. Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again.

A great resource for estimating is Steve McConnell's: Software Estimation: Demystifying the Black Art

Mitch Wheat
Do you have a likely cause and the best solution?
The likely cause is that the project has a fixed budget, or short deadline. Solution is start with an accurate as possible estimate.
Mitch Wheat
If the most likely cause is a fixed budget or deadline, perhaps another good solution is to drop scope?
Mitch - if you're experiencing a lot of this, try a shift in perspective: When a PM asks for an estimate, you give them an estimate. If they set a limit to the estimate, or want to reduce it, they've now set you a TARGET. Removing features, reducing extensibility, shrinking scope are acceptable!
Ben McEvoy
@Ben McEvoy: not currently where I work, but I have experienced it firsthand in the past.
Mitch Wheat
+1 I have seen this annihilate so many software projects.
Chris Ballance
Totally agree. Another key point when estimating with stories/planning poker is to minimize or eliminate assignment of time units to tasks.
Ashley Tate
+6  A: 

Not having Version Control from day 1.

Mitch Wheat
Do you have a likely cause of this? Is is deliberate or just plan "couldn't care", or something else?
It's often cultural: "We didn't have source control when I was a developer!" !! ;) (I hasten to add this is not how it is where I work!)
Mitch Wheat
As a developer, you can and should still use a VCS, even if the PM doesn't think so. I always use a VCS!
Jonathan Leffler
Ditto: You shouldn't be developing software without SCC
Mitch Wheat
SCC helps but I don't think not having it would cause the project to fail. Just look at Linux kernel development, how long they didn't have any SCC? first 10 years or so?
lubos hasko
SCC Helps? NO, SCC is vital. I've heard of teams getting into money losing situations because they didn't have SCC. You should not develop software without SCC. Period (Either as a lone dev or large shop)
Mitch Wheat
+3  A: 

Take sides between users and developers. This can happen when the PM lets the role of referee overcome the role as mediator.

It helps to consciously remember that facilitating good things happening is more important than preventing bad things.

The best way to prevent bad things (otherwise known as surprises) is to identify and prioritize the project risk factors, and resolve those first.

le dorfier
Do you have a likely cause and the best solution?
+5  A: 

Leaving building the deployment setup until crunch time.

Solution: Having an automated build should mean that you can deploy quickly and easily, and often.

Mitch Wheat
+16  A: 

Opaqueness: not sharing information that affects schedules, deliverables, resources, etc.

Causes include:

  • Arrogance
  • Fear of repercussions
  • "We'll make up for it later"


  • Publish current schedule and progress reports.
  • Agile-style daily meetings highlighting progress, plans, and roadblocks.
  • Tenacious team members who pester for the info they need to get their jobs done.
Adam Liss
A better word might be opacity.
"Opacity" usually refers to the blockage of radiation. IMO, "Opaqueness" connotes the intentional blockage of information. There's a vague connection somewhere to the idea that arguments with PMs often generate more heat than light. :-)
Adam Liss
+10  A: 

Not understanding the truth of The Mythical Man Month. I work in an enterprise environment for a living and it still continually amazes me to see many PMs try to shoehorn an impossible project scope into a small time frame by "throwing resources" -- i.e. programmers -- at it. It just. Doesn't. Work. And the proof is one delayed project, or one project not delivering the desired functionality, after another.

The best solution for this is the use of lean or agile software practices with buy-in from all parties.

Peter Meyer
Wait, how does an agile software process fix the problem of the Mythical Man Month.
Jonathan Arkell
Honestly, there is no silver-bullet. I feel agile/lean practices provide the required empirical data and feedback loops that support both planning and change and better results than "throwing more resources at the problem." Proof that "adding resources" does *not* work are the trail of failures.
Peter Meyer
+11  A: 

Robbing Peter to work on Paul's project, and expecting everything to just work itself out.

"We need every developer on project Ecks-Que."

"But in doing so, we will impact project Four-Sea!"

"That's okay, Four-Sea isn't due until 3 weeks from now."


The other big mistake I've seen is building out schedules, and not allowing for vacations, sickness, and when (for instance) project Four-Sea goes over, or has bugs, because all of its resources got pulled to work on Ecks-Que.

The Cause seems to be chasing after too many projects without enough resources to staff them, and a lack of breathing room.

I don't really know the solution to the problem of Robbing Peter to work on Pauls Project problem. One of the things you can try is to constantly communicate how this will impact the projects. Specific examples will work better ones.

"You know, if we use Peter to work on Project Ecks-Que, we won't have his badly needed expertise on Four-Sea. Because his piece is the lynchpin of Four Sea, he neexs his work done before anyone else can start."

Would clearly communicate the problem.

The problem then, is making sure your audience is receptive.

Jonathan Arkell
Do you have good solution for the "robbing Peter to pay Paul" mistake?
I think the only solution is only take on the amount of work you can reasonably staff.
Doug T.
Which works, if you are the guy taking on the work.
Jonathan Arkell
+10  A: 

Poor Project Communication, I think that effective communication among all project levels its one of the major factors leading to the success of a project.

Do you have a likely cause and a good solution?
+3  A: 

Not being technical enough.

The most likely cause is a lack of appreciation of how important being technical is. The best solution is self-education (talking to other PMs and reading books) and experience,

EDIT: Why is it important to be technical? Partly because it prevents developers and other techies feeding you with nisleading information. And partly because many developers feel that non-technical PMs don't add value to a project.

In my oppinion, it is important to understand the underlying technique. However, this is not the "most likely cause". If You establish a culture of trust with Your developers, they will honestly explain all the important technical stuff to You.
+24  A: 

Starting a project after estimates have shown that the project is not possible within the given constraints of time and/or budget.

Likely Cause: Project Manager/Team Lead being pressured from above to accept an impossible deadline.

Solution: Tell management the truth, not what they want to hear.

Mitch Wheat
<synical>What if Management can't / won't hear any criticism, since they **know** what is real, despite evidence to the contrary (aka reality distortion by EGO), would you ask the PM to lose his job now .. or earn some good money before losing the job anyhow? </synical>
+1 absolutely correct. "lying to your supervisor" is a huge cause of project failures
Steven A. Lowe
+15  A: 

Playing "let's pretend".

You know, like "let's pretend that we can make a schedule for a two year project, in which we assign effort down to a half day, and imagine that we'll be doing what was predicted on any particular day."

Or like "let's pretend that it doesn't take any additional effort to maintain the system, administer user accounts, manage the SVN repository, write build scripts, and organize the hardware; after all, we didn't get the headcount we needed for a system admin."

Or "let's pretend that even though we don't know what the requirements are, we can make a cost estimate now."

Project management requires being in touch with reality.

Charlie Martin
We call this the Think Method, with apologies to the Music Man.
Adam Liss
+22  A: 

Dictating a technical solution without input from developers.

Likely cause: they read about some new technology (or old technology) that promises to solve a problem similar to yours

Solution: make decisions as a team, be open and honest about technical issues, prototype/experiment/spike to explore options

a fellow dev at a past company used to call this "Managing by Magazine" because it was whatever was on the cover of eWeek that seemed to percolate into the requirements
+1  A: 

Likely cause: Accepting scope extensions and changes from upper management or customers without understanding the impact on the schedule or talking to the developers.

Solution: Clear specifications and a change process which includes consultation of the developers and re-scheduling (maybe even re-budgeting).

No Solution: Not accepting changes at all and forcing the customer to accept and pay exactly according to the specification. This results in a loss of the customer and Your developers will realize that they are developing a "bookshelf" version.

+4  A: 

Planning milestones on friday afternoon. It quickly devolves into the actual technical staff being told at 4 pm that they need to come in over the weekend. Yes you can often meet a particular milestone without a schedule slip. But moral and employee retention goes down the tubes, fast.

+7  A: 

Sometimes they do not fire the engineer(s) that should be fired.

Destroy the team's morale a lot.

s/engineer(s) that/employees who/Engineers are only a subset of the problem, which often affects the entire organization.
Adam Liss
@Adam indeed...
Hurts morale even more when the PMs who muck things up don't get fired. Somehow, since the devs are at the end of the process, it is alawys their fault for not meeting the deadline, not delivering the right thing, etc and never the guy who provided bad requirements, didn't tell the client that a delay was needed, accepted more work without more money and hours for the project. Usually he gets promoted instead.
+29  A: 

Continual reprioritization decimates productivity.

We've all been told, "Stop whatever you're doing. This is more important -- do it right away"

Often caused by:

  • Knee-jerk reactions to crises or "forest fires" that have high visibility and/or serious consequences, combined with an edict from above to fix them immediately.

  • Opportunities that are "too good" to ignore or have "brief windows of opportunity."

Let's face it: unexpected situations arise, often, and we need to address them. But they need to be competently managed. How?

  • Assess the true priority of the crisis. Can it wait for a day or two? For a few hours?

  • Consider the cost of the added stress, scheduling impact, and any ripple effects that will be incurred by the interruption. Ask the people who are doing the work for their input on this.

  • If you must reprioritize, let the developer choose an intelligent place to pause the current task. This may seem obvious, yet non-technical managers often do not understand that it is difficult, time-consuming, and sometimes impossible to return to an interrupted train of thought.

  • Perhaps the best solution is the oxymoron of scheduled interruptions: tell developers to expect to be interrupted, perhaps first thing in the morning and upon returning from lunch, for fire-fighting. Very few crises can't wait an hour or two, and these are natural times to expect interruptions.

  • In an environment that is rampant with crises, train the developers to schedule work in small chunks as much as possible, so that any interruption will affect only one chunk, rather than a long, thought-intensive activity. Worst case, if a task is dropped altogether, perhaps the completed chunks can be used elsewhere instead of wasted.

  • Communicate with the entire team, so everyone knows whether it's a relatively good or bad time to multitask or deal with crises.

Adam Liss
+6  A: 

Think they can just buy the developers pizza and soda to get the project finished, expecting them then to stay late to finish. During this the PM still continues to leave at 5pm daily.

+11  A: 

Construx published a white paper "Software Development's Classic Mistakes 2008" which covers this topic comprehensively and with the added benefit of actual real-world sample data.

You can download from: (Free registration required).

When you say 'most significant' mistakes, you may mean a few things. The document breaks this down into 'most frequent' and 'most severe'.

Their summary table combines most frequent with most severe, to give:

  1. Unrealistic expectations
  2. Overly optimistic schedules
  3. Shortchanged quality assurance
  4. Wishful thinking
  5. Confusing estimates with targets
  6. Excessive multi-tasking
  7. Feature creep
  8. Noisy, crowded offices
  9. Abandoning planning under pressure
  10. Insufficient risk management

Each mistake is defined more verbosely in the document.

Ben McEvoy
I have that paper, thanks.
+3  A: 

Bonus-driven management.

Project Manager tries to hide the possible problems or missed schedules, often accepting only programmer’s word on the progress and marking the progress as on-time in his Gantt Chart. Then he presents the same Gantt to the Head of Department who takes his Gantt for granted and incorporates it into his Gantt. This Gantt is presented to CTO and the CTO makes the ppt with “Executive Overview” since CIO can no muster anything more complicated.

If the development is in-house, users will be kept quiet even if the software is making their lives impossible. This is often coupled with PowerPoint programming, where instead of the Demo, ppt is used to present the progress.

Finally, everyone gets bonus, no matter what really happened to the software.


The dreaded "One Shot".

SOLUTION: Access the original data instead of copying it.

Not sure I understand this. Can you explain it a bit more?
In big companies, i've seen too many times companies synchronize data with a "One Shot". i.e. Instead of both using the same data one department will find a way to copy it a midnight into a duplicate database.
+1  A: 

its a toss up between two things for me:

  • not having a method for controlling scope-creep
  • drastically under-estimating the complexity of a technical task

protocols for controlling scope-creep arent that hard to come by (i.e. change control) - but getting the client to understand and accept it can be an uphill battle

drastically under-estimating a tech task is more a failing of the business analyst to understand a clients requirement. i have seen this happen to disastrous effect on a project. a paper-based process the client took for granted was a nightmare to implement in code


+4  A: 

Failure to pass on bad news to the client. Compounded by making stupid choices to avoid having to pass the bad news onto the client in hopes the bad news will go away.

For example, developers report there is a show-stopper bug, cannot deploy until it is fixed. It will take a week to fix and test. PM insists we deploy on schedule with bug unfixed because the client is insistent that the schedule be met. First day out, the bug is hit and the client is screaming because we didn't find and fix it before deploying. The pain gets worse when you avoid telling the client.

We often know a long time ahead that we won't meet the schedule. Developers often tell their managers who tell the PM that. PM fails to tell the client that until the deadline is already passed making things worse. Especially when it won't be missed by a few hours or a day but by several weeks.

Clients will remember deploying a buggy bad project far more than they will remember slipping the schedule.

Another one that gets me is the "we must fix the process attitude" that means every little tiny error no matter how unlikely it is to be repeated must have new process steps added to avoid ever having it in the future. Of course every new step added to the process adds to the time to complete work (which we did not add to the schedule) and adds new different possible errors. Just accept that human error will happen and no system can be made so that no errors will ever happen. Change the process when there are major flaws int it not every little minor issue that comes up.

Finally not pushing back to the client to insist on more time and a slip to the deadline when features are added or when the client causes the delay. If client must deliver something before you can do your work (hard to design a data import without the file in hand for instance), they need to be told that every day they slip their deadline to us, we slip ours the same amount of time.

Solution: Pass on the bad news as soon as you know about it, delaying will only make things worse. If you can't handle dealing with telling people bad news, you are in the wrong profession.

Yeah, especially the process thing: If the process doesn't allow for errors being made, making the process more complex will only compound the problems!
David Schmitt
+6  A: 

When writing a system to replace an old system (even a paper one) I would say that "Phase 11: Import Old Data" is the critical project management mistake. Usually the devs and PMs want to have some UI in place to work with the data before they do the import. But only after the import do the end users and stakeholders really understand what they've agreed to, and only after the import do the devs spot the perf or usability issues that can arise from having 1000 of something you thought there would be 10 of. Related to this is believing users who tell you there will be 10 of something, or that each X has one Y, when you have their old data that would tell you the truth.

Phase 2: Import Old Data. It's the path to happiness.

Kate Gregory
They also seem to think the import will somehow happen instantly and doesn't need to be scheduled to start work until the day before going live. Hello, that's dev work too and often quite complicated and time consuming. It needs to start months ahead.