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 Case Tools, so there are some Anti Patterns.
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 Project Management responsibilities to have the Impression Of Control.
Bottle Neck or constraint management (Eliyahu Goldratt's Theory Of Constraints, especially his third business novel Critical Chain) offer an approach that may reduce the frustrations of project management. -- George Brower
Discussion
Project Management 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 Binary Milestone and Task Complete Definition.
About the manager Professional Project Manager: Project management is a role (see Mapping Roles To Staff), and a critical one. Who carries out that role?
During the good parts of my career, project management was just part of what management was and what managers did. The person who did project management (the boss) was responsible for what was being done, how well it was being done, how fast it was being done, and making sure everyone (staff and upper management) was happy.
During the very best part of my career, I was in a leaderless team. One of us was really good at coding, and did most of it. One of us was very good at project management, and did most of it. (I'm still not sure what, if anything, I was really good at....)
During the less good parts of my career, managers were given so much other (allegedly important) stuff to do, they didn't have time to do project management. So, project management became a full-time job for professional project managers. Some of them are very good at it. Some of them are not. A bad project manager is a serious source of negative productivity. (It sure seems that way at the staff level, anyway. Should project managers only be providing value to management? Project managers consume a lot of time from people at the staff level; wouldn't they be more welcome if they made the staff's lives better? Maybe there's an anti-pattern: Project Manager Perceived As Leech.)
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
Patterns or Anti-Patterns in Project Management
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. Microsoft Project encourages this with automated Schedule Compression.
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?
Mythical Man Month, a.k.a. Brooks Law: 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!
Status Meeting: 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.
Scrum Process advocates having very short and focused daily status meetings (Scrum Meetings) where members answer three very specific questions. A Stand Up Meeting 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 Too Much Measurement Detail (antidote: Not Too Much Measurement Detail).
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? -- Paul Chisholm P.S.: I've just stumbled across www.projectnet.co.uk 
("Project Net - 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 Maintain The Vision. 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.
Status Meeting Good if they are concise, bad if too long. I hate Status Meetings 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-)
-- David Hooker
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 Corrective Action, and the observation that many Anti Patterns are Corrective Action 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 Systems Thinking.
A good dose of one of Gerald Weinberg's books might help. "Quality Software Management Volume 1: Systems Thinking" is a worthwhile read. Weinberg spends a couple of chapters on misapplied Corrective Action.
"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." -- Gerald Weinberg, 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." -- Scott Adams, The Dilbert Principle
-- Dave Smith
Please add your comments about Project Management here (I need the help!) See Extreme Project Review, Load Factor and Reusable Software Hah.
-- Ron Jeffries
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:
get comfortable with the customer - you should be talking to them almost daily
be sure your team is well exposed to the domain, and by multiple routes
find out what people need to do their jobs and get it for them
delegate, delegate, delegate
engage in technical discussions, but let a consensus emerge instead of imposing a solution
focus on quality
negotiate scope first
work at solving problems that are 3-6 months out (so there are far fewer ones on your doorstep)
have celebrations and spontaneous fun
the team is more important than the product (it's a zen thing)
become expert in the big picture and the technology flow; communicate these things simply
be able to drill way down from time to time
become comfortable with scheduling and accounting systems so you can make them work for you
spend enough time managing upwards
meetings should deal with the future, not the past
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).
I am beginning to form the opinion that Project Management 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.
Not Too Much Measurement Detail 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.
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:
clearly communicate the requirements for the project (not the product)
ensure the team has the resources available to meet the requirements
ensure that everyone not useful to them keeps out of the team's way
Status Meeting - Here are some patterns I've noticed with Status Meetings. -- David Schmaltz
(Not to mention Problem Solving Meetings...)
See Death By Scheduling for one story of project management gone sour.
See Also Project Manager, Dilbert Moments Avoided, Types Of Projects, Best Project Organization, Abstractions In Project Management,Project Planning Software
Please help Refactor Project Management Page. -- David Saff Yes! I am with you and just started it.
Why? it looks quite condensed already
I seek articles about International Project Management (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 Project Management - you may find Hofstede's work on this interesting? From the man himself at web.archive.org
Managing an At All Costs Project
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 At All Costs Project Discussion?
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. -- www.cio.com.au
The above article also shared much "explanations/excuses" on why Refactoring Government is particularly hard, in the case of Project Management. It quoted Rob Thomsett who said:
(Governments have) higher demands because of size, stakeholder engagement, political imperatives, relatively poor levels of project governance, excessive dependence on outsourcers, complex contract and tendering processes, difficult HR practice and relatively immature financial management...
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.
Resources
History of Project Management see en.wikipedia.org
Project Management Body Of Knowledge - a publication by ProjectManagementInstitute. Link at www.pmibookstore.org
I have borrowed a copy from a colleague, looked good, but unsure of the price though
School of Project Management - unsure of its use to us at en.wikibooks.org
Sep05 interview with PMI chief at australianit.news.com.au
Differences between Project Management and Program Management at www-128.ibm.com dated 2004
See also:
See original on c2.com