Strategy to Optimize Project Management

8/25/99 - Jack Harich - Go Back

Our strategic recommendations are:

  1. Use a Defined Process on all non-trivial and non-skunkwork projects.
  2. Create the role of Process Manager to ensure Defined Process success.
  3. Buy, don't build your process.
  4. None are perfect, but the Unified Process seems to be the "best".
  5. Use the Mini Process for small work, but in the context of the Unified Process.
  6. Understand the major Project Elements.
  7. Learn from the experience of others by lots of reading about process.
  8. Engage in strong Risk Management from day one.
  9. Use weekly project review meetings regardless of what process you use.

1. First off we must agree that anything as complex and unpredictable as a non-trivial software project requires a Defined Process to manage well. A Defined Process is merely a documented set of activities and work products that can be fairly uniformly applied. A good Defined Process works so well those using it love it, and the team succeeds wildly. Such processes exist, but take serious committement to use. They are not simple, because the problem they are solving is not simple.

Your Defined Process becomes the live repository of all the best practices you borrow from others and invent yourself. Over the years it becomes one of your greatest assets.

2. Second, any use of a Defined Process on a project is really an instance of a standard but flexible process used at that company. Thus a Process Manager is needed to manage process definition, training, use monitoring and improvement. When a Project Manager needs to initiate a project, the Process Manager helps them get started with an instance of the Defined Process, and continues to help them as the project proceeds. Without the help of the Process Manager, the Project Manager has to become way too much of a process expert themself, and is forced to put lots of time into process definition, training, use monitoring and improvement. They will be too distracted to put much time into their primary responsibilities. A Process Manager is especially crucial if multiple project are underway.

3. Buy, don't build your process. Good news! Recently software process and supporting literature/tools have matured. We have plenty to pick from.

4. We have selected Rational's Unified Process as by far the most appropriate. The best literature on it for managers is "Software Project Management - A Unified Framework" by Walker Royce, 1998. (SPM) Believe it or not, the author is a second generation process expert. The book treats process from a flexible framework strategic viewpoint, not a cookbook or dogmatic viewpoint. It uses the highest level abstractional thinking on a workable process I've ever seen. It's state-of-the-art process treatment. (This is a rave review! :-)

5. The Unified Process is for process in the large. For process in the small, you can still use tried and true procedures like the Mini Process. However, even that will live in a larger context.

6. Don't get cornfused (sic) by all this process mumbo jumbo. One way to avoid that is by thinking of the major project elements this way:

Project Element

Primary Driver

Main Mechanism

Oversight Role

Time Consumption Risk and Dependencies Successive Iterations, Schedule Scheduler
Project Process A particular Defined Process Process Mgr (a)
Software Architecture Models Architect
People Clear Goals Schedules and Work Products Project Mgr
Economics ROI Reduction of unnecessary work Process Mgr

(a) This is a little controversial. Most would think the Project Manager is the main oversight role for project success. We are saying that projects are process driven, and so the Process Manager (aka Process Evangelist) secretly plays the main role in project success. The Project Manager merely runs the process, making their job much easier. As a bonus they are more likely to well manage more than one project at a time because the process is so efficient. BTW, according to Fred Brooks in "The Mythical Man Month", page 256, the most important role on a project is the Architect.

7. Additional related required reading is "Software Project Survival Guide" (SPSG)and especially "Rapid Development" (RD), both by Steve McConnell. There's also "The Rational Unified Process" (TRUP) by Philippe Kruchten which has coverage different from the Royce book (SPM). And then there's "The Unified Software Development Process"(TUSDP) by Ivar Jacobson et al. It's not as high level as SPM, getting into lots of Use Case and OOAD stuff, but Ivar is one who knows.... See Scott Ambler's software process book reviews. If you're a knowledge worker, be sure to read the best books you can find at least 2 hours per day.

8. Engage in strong Risk Management from day one. This is the single most important Best Practice one can follow. Even a ?Defined Process is just a repeatable approach to Risk Management. Since most developers and some managers don't know what Risk Management really means in practice, get a mentor for this. Always know your top risks and how each is being successfully resolved. Remember, "If you don't manage your risks, they will manage you." :-)

9. Unless you have a flawless record of highly successful Project Management, engage in weekly project review meetings. (except for small or well running projects, but always for crucial projects) The meeting purpose is to maximize project success through joint ownership of common goals and regular groupthink about achieving those goals. Translation - great teamwork makes all the difference!!! A typical agenda includes project status review, risk list review, action item review, special topics and new business.