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.
Assumptions.
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.
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
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.
Leaving building the deployment setup until crunch time.
Solution: Having an automated build should mean that you can deploy quickly and easily, and often.
Opaqueness: not sharing information that affects schedules, deliverables, resources, etc.
Causes include:
Fixes:
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.
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.
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.
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.
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.
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.
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
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.
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.
Sometimes they do not fire the engineer(s) that should be fired.
Destroy the team's morale a lot.
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.
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.
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: http://www.construx.com/Page.aspx?hid=2537 (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:
Each mistake is defined more verbosely in the document.
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.
its a toss up between two things for me:
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
--LM
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.
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.