Yesterday, I wrote about a Computerworld article, entitled “The Ten Commandments of Project Management,” which proposed a number of “commandments” to ensure project management success. I thought it was a good start, but I’ve got an alternative list. Here it is:

1. Don’t fail to identify the key “players” who will ultimately declare “success” or “failure” for your project — you can deliver the required functionality, and you can do so on time, under budget, and with good technical quality, and still have your project declared a failure by a powerful stakeholder who has decided he doesn’t want your project to succeed for some reason. Similarly, you can deliver a subset of the required functionality, with lots of bugs, months behind schedule, and way over budget — and still have your project declared a success, if a key stakeholder is satisfied with the results. If you haven’t identified the key stakeholders and sources of power, your chances of success with anything other than a trivial project are minimal.
2. Don’t fail to clearly identify (preferably in writing!) what constitutes “success” for your project — everyone wants to deliver a defect-free system, with all of the features and functions requested by the user, on time and under budget. But which of these really matters to the person/persons who have the power to declare success? Sometimes it’s okay to be a week or two behind schedule; sometimes it’s not. Sometimes you can exceed the budget by a few million dollars; sometimes you can’t exceed it by a penny. You’d better figure out which of the criteria for success are “hard” and non-negotiable, and which ones are soft and/or negotiable at the last moment.
3. Don’t confuse “estimating” project schedules and budgets with “guessing” or “negotiating” — much of what we call “estimating” is a farce: even if we had adequate historical data with which to develop a “rational” estimate of the time, money, and people required to develop a system, that estimate would not be acceptable to the end-user or key stakeholder(s). What usually takes place is a form of negotiating, based on inadequate and incomplete information; unfortunately, what really takes place in many projects is a form of bullying, where the project manager is ultimately forced to accept a schedule, budget, and staff that he knows, deep in his heart, won’t be sufficient to get the job done.
4. Don’t ignore the non-linear nature of tradeoffs between people, time, money, and quality when negotiating key project parameters — if you tell the end-user, or key project stakeholders, that it will take 12 months and 10 people to develop a system, what happens when they respond by saying the system must be delivered in 6 months? In most cases, their initial negotiating position is to offer zero additional people; the implicit assumption is that your initial estimate was a bluff, or that it included a 100% “safety factor,” or that your staff should be willing to work 16 hours a day instead of 8 hours a day. Even if your end-user/stakeholders are generous, they’ll normally assume that the tradeoff between time and people (or any of the other project parameters) is linear: if they want the system finished in half the time, they have some vague notion that you’ll need twice as many people. But it doesn’t work that way; the tradeoffs are non-linear in nature, and you really need a sophisticated estimating tool (of which several are available in the marketplace) to calculate the details of the third-order polynomial equations that are involved. Meanwhile, tell your end-user/stakeholders to skim through Fred Brooks‘ The Mythical Man-Month for an explanation of this concept.
5. Don’t attempt to “freeze” user requirements; do expect “scope creep,” but don’t accept “requirements churn” — Anyone with experience developing a non-trivial system knows how unrealistic it is to expect end-users to freeze their requirements in the early stages of development. But the other extreme is just as bad: chaotic, uncontrolled “requirements churn” virtually guarantees that the system will never be sufficient stable that it can be used. You should assume that user requirements will continue changing at the rate of approximately 1% per months throughout the project; and you need to have some mechanism in place to acknowledge those changes, manage them (which means, among other things, prioritizing them), and incorporate them into the evolving system.
6. Don’t allow developers and key end-users to stop communicating with each other — one of the key elements of most XP/agile development methodologies is to encourage ongoing, intensive interactions between the developers and the end-users who will eventually be stuck with the system. Everyone understands this point, and most projects begin with a reasonable degree of interaction between the end-users and developers. But for a variety of reasons, there’s a common tendency for the two groups to start drifting apart as the project continues — the end-users are busy doing their “regular” jobs, and the developers often believe that they’ve learned enough about the end-user requirements to go off in a corner and start coding furiously. This is almost always a disaster, if only because the two groups typically fail to come back together again to participate in acceptance testing in a cooperative fashion. Keep them together, joined at the hip, throughout the entire project.
7. Don’t commit teamicide — most non-trivial projects require a team of developers and related specialists; the success or failure of the project depends, to some extent, on how well the team works together. But in many cases, any chances for successful teamwork is killed by idiotic managerial and bureaucratic rules and procedures. For details, see Peopleware, by Tom DeMarco and Tim Lister; for a more recent update, see “Teamicide Revisited,” by the same two authors.
8. Don’t ignore whatever software processes the project team has committed to — it’s hard to endorse a waterfall life-cycle and its associated processes these days; but aside from that, it doesn’t matter too much whether your project team decides to use XP, scrum, RAD, RUP, agile development processes, or whatever else strikes their fancy. The most important thing is that the team should agree, at the beginning of the project, which of the “standard” process activities will be eliminated, which ones will be followed on a cursory basis, and which ones will be followed with religious fervor (e.g., pair programming, writing acceptance test criteria before writing code, etc.). And once those details have been agreed upon, don’t abandon the process in the heat of battle, simply because everyone is “too busy” to follow the process. The result of such abandonment is usually anarchy, and it doesn’t end well.
9. Don’t skimp on risk management — trivial projects may not have any risks, but any interesting, non-trivial project is inevitably saddled with risks. You can’t make them go away; but you also can’t ignore them. I’m amazed by how many managers pound their fist on the table, and exclaim loudly, “I don’t want to hear about any problems unless you’ve got a solution!” … and then wonders why nobody on the project team tells the managers about such problems. Duh! The serious risks are the ones for which the project team members can’t figure out a solution — that’s why they want to bring it to the attention of the manager!
10. Don’t forget the importance of a “daily build” approach — project status indicators that consist of delivering piles of paper (test plans, requirements documents, architecture diagrams, use-case models, etc.) are better than nothing, but they don’t really show tangible evidence of progress. As (former) Microsoft Visual C++ manager Jim McCarthy likes to say, “The daily build is the heartbeat of the project — it’s how you know you’re alive.” If you don’t know what this is all about, check out the Wikipedia article here.

Project managers who follow these commandments may not deliver a “perfect” system, but my own experience indicates that they will have eliminated the major causes of project collapse and failure.

Let me know if you have your own list of “ten commandments.” We can use as much wisdom as we can get in this area!