Seven deadly sins of project management.

Everyone has heard of the seven deadly sins: pride, greed, envy, anger, lust, gluttony, and sloth. The list was supposedly developed by a 6th century pope, Saint Gregory the Great, and another man who became a saint, John Cassian. These sins are religion-based, of course, but there are also seven deadly sins in project management.

[ILLUSTRATION OMITTED]

The sins of project management don't necessarily correspond to the original sins, but they do meet the criteria of the Roman Catholic Catechism, which explains that "sin creates an inclination to sin; it engenders vice by repetition of the same acts. This results in perverse inclinations which cloud conscience and corrupt the concrete judgment.... Thus sin tends to reproduce itself and reinforce itself."

To put it in blunt terms, when you start screwing up and making bad decisions, you have a tendency to screw up more in the same vein, and that ruins your management judgment and can have a serious impact on the project. We in the project management field aren't saints--or at least most of us aren't--but we need to learn not to be sinners in the field either. So let's look at the seven deadly sins of project management and how you can avoid them.

Sin #1: Failing to have good, stable requirements

Good requirements are the underpinning of any project. Bad requirements are one of a PM's worst nightmares. Without good requirements, you don't know if you are building the product that a user or client needs. Usually there are hundreds or even thousands of requirements for a project. With bad requirements, you are stuck with an impossible task. You end up guessing what is needed.

Requirements should be well written (see "Mission Possible ... With Good Requirements," Defense AT & L September-October, 2005), quantifiable, testable, and all the other adjectives that describe good requirements. Starting with good requirements and using a good requirements management system are critical for project success (see "Requirements Management ... A Template for Success," Defense AT & L, March-April, 2005).

Requirements stability is a recurring dream for project managers. It is not going to happen for most projects; requirements change, but that change can be controlled, at least to a certain extent. As a PM, it is incumbent on you to minimize the changes to only those that are necessary. And when changes come, and they will, make sure that funding to pay for the changes comes also. Scope creep is the serpent that goes with the sin and will get you thrown out of the Garden of Success.

Sin #2: Trying to do the job without enough resources or a good schedule

This is directly akin to the sin of pride in the original seven sins. It may be an ego problem or it may be forced on the PM by outside agencies. If it is an ego problem, learn to be realistic. Talk to your team and find out what they believe can be done with the resources available and in the time available. Meeting the schedule and staying within budget are how the PM is graded as to real and perceived success. If you don't meet the schedule, even through no fault of yours or your team's, the project is deemed a failure. The same is true of over-running the budget.

Many projects are given a completion date by an outside agency or higher headquarters. You can achieve a better chance of success by developing a schedule using the completion date and working backwards to include all of the necessary actions. Decide if the schedule is realistic and can be made. If not, develop a realistic schedule. It then becomes the PM's job to sell the new schedule. Throwing money or resources at the project may help to resolve some schedule problems, but even that won't always help. With money tight, the chances of getting the extra funding are slim or none. (And as they say, Slim is on vacation.)

If you have a schedule that looks impossible, there might be ways to help to compress the work during the time available. One way is to make as many of the tasks as possible parallel rather than sequential. For example, it is sometimes possible in the software world to develop the software in modules. Admittedly, it is difficult and requires good coordination among the module developers, but work can proceed on multiple modules at one time with each module tested as it comes ready, and final integration testing at the end. This is just one example. Finding ways to compress a schedule is a challenge for your whole team. Ask their help and listen to their ideas.

Do your planning! Set up a posted schedule and track progress against that schedule. Use Earned Value Management to compare budget and schedule. Whatever the schedule and budget--plan, monitor, and replan.

Sin #3: No good, repeatable processes (a.k.a. continually reinventing the wheel)

Processes are the key to the puzzle. Knowing that things are done the same way every time gives the team and customer confidence that nothing is missed and that the results are trustworthy, useful, and usable. Don't reinvent when you can leverage on previously developed and proven work.

Begin with established standards and processes from your own organization. They are a good baseline. Look at other public and private sector processes. The Government Accountability Office can be a great source of information on government best practices. Which processes and products that you use will depend upon your project. Don't hesitate to talk to others with more experience. Get them to share their successes and what didn't work for them.

The Carnegie Mellon Software Engineering Institute has developed Capability Maturity Models and ratings for organizations. Their Web site is full of good information on processes and is worth reviewing: <www.sei.cmu.edu>.

There is a caveat: Processes are a good thing, but they are the roadmap, not the destination. Processes are based on history and don't always apply to present circumstances. There are always the unexpected and the unplanned. Innovation and original thinking are needed to resolve problems. But don't stray from the processes as a habit. That can get you in trouble.

There's another problem with processes. Some people and organizations get so caught up in the processes that they forget about results. Results are what PMs are paid for. So don't get so caught up in the processes that you forget your job--to end up with a specific product.

Sin #4: Not identifying risks and working to mitigate them

Risk management is a discipline for living with the possibility that future events may cause adverse effects. A good risk management process to identify and mitigate risks is a necessity. Risk management should be used to continuously assess what can go wrong in the project, determine which of the risks are most important, identify the potential effects or outcomes, and implement mitigation strategies to deal with them. Don't make it an exercise just to check the blocks. Use risk management to find those risks that could have a negative impact on the project, and diligently work to find strategies to overcome, bypass, resolve, or mitigate the risks. Schedule reviews on a regular basis as a tool for communication and review of risks. Otherwise unpleasant surprises are in your future.

Here is one simple method of risk management.

Begin with risk assessment:

* Identify all (or as many as possible) of the potential dangers that will affect the project

* Assign specific responsibility for each risk to an individual or team

* Put the risks in a database or spreadsheet

* Assess the probability of occurrence and potential impact of each

* Rank/prioritize the risks.

Progress to risk control/mitigation:

* Identify techniques and strategies to mitigate the risks

* Implement the strategies

* Monitor the effectiveness of the strategies and update risk levels

* Report on the success/status on a periodic basis.

Sin #5: Wanting the latest and greatest

Here is another PM sin that directly parallels one of the original sins: Lust. PMs (and their customers) love technology and shiny new toys. They lust after them. Too often, an important project is started using a technology with no proven capability or with which no one on the team has had experience. People get sold on the new toys and technologies by vendors or by what they read of others' successes. This is prevalent throughout DoD and the government. It can be summed up with the sigh of despair that I have heard from my wife so often: "Boys and their toys!" (Though it's not just the boys who fall victim to the lust for the latest bells and whistles.) Look at new technologies, but remember that the leading edge of technology can often be described as the "bleeding edge."

At the other end of the spectrum are those who won't try anything new because of the risks and the fact that "we've always done it this way." It is the other side of the latest-and-greatest coin and just as much a deadly sin. Being totally risk averse and/or closed to new technology or new ways of doing things leads to stagnation and little or no progress.

Sin #6: Poor communication

Lack of communication can ruin a project. If the whole team doesn't know what is going on, they can be moving in opposite directions. That leads to wasted effort and rework. It is not just communication with the team, though. Make sure everyone who needs to know is aware of what is going on. Communicate up the chain, with your peers, and with your team. Your boss: Let him or her know what is happening with the project on a regular basis. Your team: Give them feedback on their work and on the project status and plans. Keep them informed about what is happening, what changes are occurring, and why. Others outside your organization: Keep them in the know.

One good way of sharing information is the interim (or internal) project review. Think about it before you groan, "Oh no! Not another meeting or report!" IPRs can be a wonderful tool. There are two types. One is the internal IPR for the team to share information with each other and the PM. The other is for the PM to share information with management and/or the customer(s). Make sure that you are prepared for the questions that will come up; otherwise you can look pretty foolish or lose your credibility.

Sin #7: Bad people management practices

Good project management requires good people management skills. New managers (and not-so-new ones) frequently have few, if any, people management skills and usually aren't trained in managing. Too often upper management believe that if people have great technical skills, then they can manage. Many projects fail because of the poor management skills of the PM. There is no need to go into bad management practices in detail. Everyone has seen them.

The things that make a manager good are evident. He cares about the job and the people. She is honest, sensitive, knowledgeable, patient, and self-disciplined. A good manager is an inspiration to those under her. He praises in public and corrects in private. Good managers get the mission accomplished without abusing their people. They don't ask others to do what they wouldn't do themselves. They're good communicators and listeners. All of these attributes should be common sense, but they are sometimes lost in practice by managers.

All is not lost for new or inexperienced managers, though. People management skills can be learned. DoD and other government agencies have training courses. Mentors are available. There are many books and articles on the subject. Take advantage of what's available. Learn both the technical and people side of project management. Then put theory into practice.

Don't Abandon Hope, All Ye ...

According to religious beliefs, violating the original seven deadly sins can send you to hell. Dante described the extremely appropriate and very nasty punishments for those sins in the Inferno. In the world of project management, committing any of the seven sins can put you in a different kind of hell with nasty punishments of its own. It's no place to be, and you can escape it. Avoid the seven deadly sins of project management, and you'll be on your way to PM heaven, not the fiery pit.

The author welcomes comments and questions and can be contacted at [e-mail].

Turk is a retired Air Force lieutenant colonel and a manager with SRA International supporting National Guard Bureau information technology projects and distance learning classrooms. He has managed projects for DoD, other federal agencies, and non-profit organizations, and he is a frequent contributor to Defense AT & L.

RELATED ARTICLE: Former DoD Transformation Head Dies at Age 63

Gerry J. Gilmore

American Forces Press Service 

[ILLUSTRATION OMITTED]

WASHINGTON, Nov. 14, 2005--Retired Navy Vice Adm. Arthur K. Cebrowski, former director of DoD's Office of Force Transformation, died Nov. 12 at age 63.

Cebrowski had already experienced a highly successful military career when he was appointed by Defense Secretary Donald H. Rumsfeld on Nov. 26, 2001, to lead DoD's transformation efforts.

"Art Cebrowski is the perfect guy to promote and analyze our transformation efforts," Rumsfeld said in a DoD news release announcing Cebrowski's appointment.

Cebrowski was chosen for the position, Rumsfeld said, due to the admiral's vast military experience, strong credentials in joint operations and information technology, and grasp of cultural and technical issues involved in transformation.

"All of society is moving from the Industrial Age to the Information Age," Cebrowski said during an interview conducted shortly before he retired Feb. 1, 2005, as director of DoD's Office of Force Transformation. "Now the military is as well."

Transformation has taken hold across DoD and is here to stay, Cebrowski said in luncheon remarks to American Institute of Aeronautics and Astror autics members just before he stepped down as transformation chief.

For example, Cebrowski pointed out, the U.S. Army isn't going to jettisor its new combat-brigade structure centered on the Stryker armored vehicle and go back to an old-style, division-based tactical force structure. Smaller, lighter military units like Stryker brigades pack a powerful punch and can be more quickly transported to global hot spots than heavy "legacy" armored divisions.

The armed services also have thousands of noncommissioned officers and junior- and mid-level commissioned officers who have combat experience under the new transformational doctrine, the admiral said.

"That changes the force," Cebrowski said. The department also has harnessed new technologies, he said, to greatly improve and expand its communications capabilities.

Cebrowski was born in Passiac, N.J., on Aug. 13, 1942. He graduated from Villanova University, located just outside Philadelphia, Pa., in 1964. He also secured a master's degree in computer systems management from the Naval Postgraduate School.

The admiral was a naval aviator who'd had combat experience in Vietnam and Operation Deser. Storm and had commanded Fighter Squadron 41 and Carrier Air Wing 8. Cebrowski also commanded the assault ship USS Guam, the aircraft carrier USS Midway, and the USS America battle group. His joint assignments included service as the director for command, control and communications on the Joint Staff.

Cebrowski had also served in the Office of the Chief of Naval Operations as director of space, information warfare, and command and control. He retired from the U.S. Navy in October 2001 after serving as president of the Naval War College, in Newport, R.I.

The Office of Force Transformation works with other DoD office elements involved with policy, acquisition, technology and logistics to develop strategies and processes for force structure transformation.

Defense AT & L interviewed Cebrowski in the March-April 2004 issue. The interview can be found at <www.dau.mil/pubs/dam/dam_issues04.asp>.

DoD photograph.