Project Management

Definition ProjectManagement is nothing more (or less!) than knowing what the status of a project is: when it should be done, how much (and if :-) it has slipped from the original schedule, what the bottlenecks are, what you might drop to save some time. But it's hard, and it's supported by the (im)moral equivalent of CaseTools, so there are some AntiPatterns.

That describes a Project Administrator. A project manager uses that information to marshal resources and apply them to meet the goal of the project.

It is fundamentally important for an individual charged with ProjectManagement responsibilities to have the ImpressionOfControl.


BottleNeck or constraint management (EliyahuGoldratt's TheoryOfConstraints, especially his third business novel CriticalChain) offer an approach that may reduce the frustrations of project management. -- GeorgeBrower


ProjectManagement is as easy as keeping your checkbook constantly in balance. This is Bad News for some of us. (Plus, you have to keep asking your checks how they're doing, and figuring what to do when they say they're 90% cashed.)

When they say they're 90% cashed, mark it as "not cashed yet". See BinaryMilestone and TaskCompleteDefinition.

About the manager Professional Project Manager: Project management is a role (see MappingRolesToStaff?), and a critical one. Who carries out that role?

My least favorite statement from a Professional Project Manager: "If you don't (do this, tell me that), I can't get my job done!" Excuse me; gathering information is important, but since when did it become more important that the thing itself? Oh, right, since the rise of a new attitude:

Project Management Top Ten

See IainMacleanOnProjectManagement.

Patterns or Anti-Patterns in ProjectManagement

The Schedule Is The Project: Since management has become too busy to do project management, but since knowing the status of a project is important, managers now refer to the Holy Project Management Document to find out what's happening. So, managers refer to the schedule, which is created by the professional project manager, who actually talks to the people doing the work (or to someone who talks to them).

The Tool Is The Schedule: Even just part of project management, the part about estimating what happens when and tracking progress (that is, the schedule) is hard. Good tools can be very valuable. But even good tools can lead to an illusion that the maps (the Pert charts and Gantt charts and such) are the territory (the actual work being done, the communications at the staff level, the agreements about what needs to be done and how to do it). Is failing to report success as bad as actual failure? (Neither is good.)

Schedule Churn: It's easy to take status information, plug it into the tool, and create a new schedule every day. It's destructive, confusing, and demoralizing, but by golly, it's easy. Happily, there's a pattern that deals with this: Take No Small Slips (see Jim Coplien's organization patterns in the PLoP 94 proceedings).

Schedule Backwards From The Completion Date: This is the classic project management anti-pattern: Deciding when something needs to be done, and then trying to build a schedule that shows how the date will be met. If the job takes as long as it takes, you're going to be in trouble. MicrosoftProject encourages this with automated ScheduleCompression?.

Micro Project Management: I know of someone who was told his small group had seven hundred and sixty-eight milestones to meet. He answered: "It's January, and project's due in June. There aren't seven hundred and sixty-eight days left!" At forty hours per week, there were barely that many hours left. (On the calendar, anyway; who knows how many were in the schedule.)

Positive rule of thumb: Staff, and first level management, should generally be tracking tasks that take from one day (maybe half a day) to one week (maybe two weeks) to accomplish. Anything bigger should be broken down. Anything smaller should be lumped with other small things, or (if nothing depends on it) not even tracked. Maybe each higher level of management should (at least) double the granularity? Maybe the line manager's view of the schedule should have about the same number of items on it as the vice president's view, with the details of the items varying greatly?

MythicalManMonth, a.k.a. BrooksLaw: Adding staff to a late project makes it later. (Combined with Micro Project Management, this leads to what I call the Mythical Staff Second.)

Ant's-Eye View: Project management is usually done in a divide-and-conquer style. That has the same problem in project management as it does for software development: Attention is focused at the sub-problem being considered, not the overall goal. One project I've heard about had two groups, each with a different project manager. The first group needed simple something done, but it was in the second group's domain. The second group scheduled it according to their own priorities, and announced that the work would be finished in eighteen months. That was way too late for the first group, whose project was canceled. More generally, it's very hard to justify reuse or education when you never look up from your schedule and your short-term milestones.

Constant hounding: Things are bad when you spend more time telling people what you're doing than actually doing something. Bad project managers can make things bad. What can make things even worse is having to give status to multiple people: a supervisor, one or more project managers, a team leader, etc. My wife says, "I've been in places where everyone waits for the project managers to go home so they can get some work done."

Positive rule of thumb: Never bug an individual more than once a day. In a crisis, for urgent, short duration tasks, maybe twice a day. Ask how things are doing. Ask if there's anything you, or anyone else, can do to help. (Accept "no" for an answer ... but don't forget to ask, and if you ask, be willing to make something happen!) Ask when the task will be accomplished. Don't ask again until around the completion date (or time). When I need to bug someone, I try to decide up front when I'll need more status, put it in my Day Planner, and don't worry about it again until then. I often let people know when I'll ask them again for status. That gives them the opportunity to get back to me at our mutual convenience.

One of my boss's favorite variations on this: When you have to bug someone, make sure they're doing the right thing. If a task is in the critical path, can it be done more simply, less generally (for now); is it time for a workaround? This has the potential to decrease quality, so it needs to be applied carefully. (A nightmare I've run into several times from several perspectives: What happens when the reusable software is late?)

Simpler positive rule of thumb: Don't Panic!

StatusMeeting: I know status meetings are one way of collecting status information, getting people to (finally) really talk about their dependencies ("Hey, if that's going to be late, that's going to impact these other three things."), and generally communicate about what's going on. But in almost every status meeting I've been in, each member spends most of his or her time waiting for something relevant to be discussed.

ScrumProcess advocates having very short and focused daily status meetings (ScrumMeetings) where members answer three very specific questions. A StandUpMeeting also helps keep meetings short and focused.

Consistent Estimation Error: I've heard that every person is pretty consistent about how he or she botches schedule estimates. Person A always underestimates by 50%; Person B overestimates by a factor of three. If you can compare estimates to actual durations, you can start to munge the estimates to get more accurate figures.

This tasks sounds easier than it is. Say that, on Friday afternoon, Person A expects to spend one day on task 1 and one day on task 2; both should be done by Tuesday afternoon. The following Friday, Person A reports both tasks have just been finished, but nothing else has gotten worked on. What happened? Did A underestimate both tasks by 60%? Did he or she guess right for task 1 but missed the task 2 estimate by a factor of 4? Was he or she just sick for three days?

Unfortunately, answering these questions can lead to TooMuchMeasurementDetail? (antidote: NotTooMuchMeasurementDetail).

Why am I telling you all this? Have I fallen under the influence of an incompetent professional project manager? Nope. I've gotten something like a promotion, and guess what I need to do lots more of? -- PaulChisholm P.S.: I've just stumbled across ("ProjectNet? - Project Management Information Resource") but haven't had time to browse it yet.

Project leadership and Project management

Quote from a writer in a UK e-paper

As I write this, I have on my desk a marketing flyer for a project management two-day course happening next month. It is a sad document. Before I share with you my thoughts on this, please do me a favour. Close your eyes and think about someone in your team and department who delivers on projects, every time. Think about a person who you always call in times of crisis, someone you know who will never let you down, ever.

Now think about the skills they have, the attitudes and behaviour they display consistently. I imagine you are thinking of communication, leadership, persistence, inspiration, motivation, focus and action.

Now I glance at the flyer on my left. It talks about process, Prince2 project management methodology, bar charts, reporting, management meetings and software skills.

And there's the rub - the reason we are in the state we are in. To me it comes down to one thing above all others - the need for project leadership, not project management.


I'm not a PM, and don't want to be a PM. But I have strong opinions about project management. I'll touch on some of your points:

Professional Project Manager Depending on the size of this project, it could be one person's sole responsibility, or it could be delegated to one of the programmers. I don't have enough experience to say how big the project should be to determine this, though.

The Schedule Is The Project That's what our boss here thought. She was fired a few weeks ago. The VP pulled out the Gantt chart the ex-boss had for my project. I said "Throw it away; it's junk." She said "What part?" "See Item #1? Everything from there to the end." So she threw it in the trash. The point is that the ex-boss thought that the schedule always was an accurate status of the project, and that by putting tasks and timelines on there, she could control the project. Of course, her wishes and reality were worlds apart, but she was "blinded by the Gantt charts..." The Tool was Her Schedule, and she loved to Churn.

Schedule Backwards From the Completion Date I watched this happen too. Another scenario: Boss: "How long will this take?" Me: "4 people, 9 months to Beta, 12 to version 1.0" Boss: "Well, I want it in 6 months, and only 2 people can work on it. I'll make a Gantt chart..." Total garbage.

Ant's-Eye View Decent projects need someone to MaintainTheVision. Every project needs an Architect Role, even if it's divided among several people. I believe that Architects and PMs should work "at the same level" to get the project done right. The Architect provides technical input to the PM, and the PM provides schedule and business input to the Architect. Neither is the sole "boss" - they must work together to move forward. If the two roles are shared by the same person, he's going to work l--o--n--g days! The Architect Owns the Product, the PM Owns the Project. Two sides to the same coin.

StatusMeeting Good if they are concise, bad if too long. I hate StatusMeetings where I have no dependencies on others' work, and I have a 5 minute status update to give, then sit for 2 hours listening to irrelevant information. Email is probably much better for this. Well, that's my $2.00. 8-)

-- DavidHooker

The bit about spending more time in meetings talking about what you're doing than you are actually doing it has got to be some sort of strange attractor for chaotic project systems. So many organizations seem to drift into that as a stable state. I was there a few years back, and blew my stack when I realized we were having to spend ever more time in meetings explaining why we were falling further behind. Slip? Call a meeting! Bug count not coming down? Call a meeting! Not getting anything done besides spending time in meetings? Let's have a meeting to brainstorm on that.

This was one of the inspirations behind CorrectiveAction, and the observation that many AntiPatterns are CorrectiveAction gone awry. The sad part is that many of the middle management involved are trying to do the right thing with the tools they have at hand. Sadly, one of the tools that many managers lack is SystemsThinking.

A good dose of one of GeraldWeinberg's books might help. "QualitySoftwareManagement Volume 1: SystemsThinking" is a worthwhile read. Weinberg spends a couple of chapters on misapplied CorrectiveAction.

"Poorly managed pressure can lead to collapse, but it's not always clear how the system will actually break down. In software projects, time pressure is almost universal, and time does wound all heels. Time pressure finds the Achilles Heel of any culture. In Pattern 2 cultures, what usually collapses first under time pressure is the manager's ability to make meaningful control interventions." -- GeraldWeinberg, op cit, Intro to chapter 17.

"No project can succeed without management support. The best sort of management support is the kind in which management doesn't find out about the project until it's a market success." -- ScottAdams, TheDilbertPrinciple

-- DaveSmith

Please add your comments about ProjectManagement here (I need the help!) See ExtremeProjectReview, LoadFactor and ReusableSoftwareHah. -- RonJeffries

I've been managing a project of 15 people over the last year and a half and it is going well. Here's what works for me:

By the way, the opening paragraph of this page describes project scheduling. Managing a project is much, much, more. If all you do is scheduling, then your team will probably get pretty darned annoyed (rightfully so).

-- DaveVanBuren


I am beginning to form the opinion that ProjectManagement is made of hundreds of little tricks, rather than one large technique. I have been trying my hand at project management, interviewing PMs, and researching, and can't find a Thing out there to stare at. Instead, I find that under many varying circumstances, a PM will apply a little trick. Each little trick avoids a little danger or makes a tiny correction. They all add up to a project that keeps from landing in the ditch and keeps moving forward.

NotTooMuchMeasurementDetail is one such trick. Other ones would be Short Meetings (I try always to ask, even in meetings not my own, "What are the exit criteria for this meeting? How soon can we reach it?"), Give Developers Think Time, Don't Bug Developers (also described above), Uncover The Risks, Get People To Talk To Each Other. All kinds of little things you apply or invent moment to moment. -- AlistairCockburn

Shouldn't project management be seen as a service to a team? There are a whole bunch of things to do with tracking, resourcing, infrastructure, expectations, and so on that a lot (most?) software developers just aren't adept at handling, but nonetheless are crucial to the success of a project. It seems that what good project managers do falls into three categories:

-- KeithBraithwaite

StatusMeeting - Here are some patterns I've noticed with Status Meetings. -- DavidSchmaltz (Not to mention ProblemSolvingMeetings...)

See DeathByScheduling for one story of project management gone sour.

See Also ProjectManager, DilbertMomentsAvoided, TypesOfProjects, BestProjectOrganization, AbstractionsInProjectManagement,ProjectPlanningSoftware


Please help RefactorProjectManagementPage. -- DavidSaff Yes! I am with you and just started it.

Why? it looks quite condensed already

I seek articles about InternationalProjectManagement? (managing projects in other countries - as opposed to distributive teams working in different countries). Help?

''What kind of issues are you looking for information about? I believe the fundementals don't change, but people do vary in ways that will affect ProjectManagement - you may find Hofstede's work on this interesting? From the man himself at

Managing an AtAllCostsProject

Often after a project has started, the project develop a life of its own, and even "senior management" do not seem to have ability to tame the unleashed beast. Have you got that experience? And would you like to share your stories at AtAllCostsProjectDiscussion??

BTW according to a 2001 OECD report, as little as 28 percent of IT projects undertaken in the US were successful in relation to budget, functionality and timeliness. --;670617869;fp;4;fpid;21

The above article also shared much "explanations/excuses" on why RefactoringGovernment is particularly hard, in the case of ProjectManagement. It quoted Rob Thomsett who said:

Project Management is About Communication

I get the impression that much of this page has been written by people who have not managed a project. Tracking status is not the purpose of project management and often times the time producing status reports actually detracts from project management. Most of the time spent by a project manager is keeping expectations inline with the current understanding of reality both inside and outside of the project team. It is also about laying the groundwork for future enhancements and projects, and developing new skills and capabilities in the team.


History of ProjectManagement see

ProjectManagementBodyOfKnowledge? - a publication by ProjectManagementInstitute. Link at

School of Project Management - unsure of its use to us at

Sep05 interview with PMI chief at,7208,16554183%5E24172%5E%5Enbv%5E24169,00.html

Differences between ProjectManagement and ProgramManagement? at dated 2004

See also:

CategoryEnterpriseComputingConcerns CategoryProjectManagement

EditText of this page (last edited August 14, 2010) or FindPage with title or text search