Manage It! Your Guide to Modern, Pragmatic Project Management
Johanna Rothman. 2007. Pragmatic Bookshelf. [ISBN: 978-0-9787392-4-9. 365 pages. $34.95 USD.]
Review by Robert Delwood, Senior Programmer-Writer
Every company has their own life cycle model. This is the set of procedures guiding them toward a product release. In practice, it’s not long before they have to vary from the model. General Eisenhower understood this when he said, “Plans are useless, planning is indispensable.” In addition to the inevitable problems that come up, the model won’t even be appropriate for all groups. Considering the diversity of a release (for software, this includes developers, testers, program managers, writers, and evangelists), no single model meets everyone’s needs. What do you do in those cases?
Manage It! by Johanna Rothman, takes a detailed approach toward “pragmatic project management.” Written mostly for the project manager, the ideas apply equally to other groups, if only in a smaller way. Given the few project management books specifically for documentation teams, these approaches adapt easily. Its 365 pages define issues such as starting a project, life cycles, estimating and scheduling along with their pitfalls, statusing and keeping a project on the right path, through to managing the release.
“Pragmatic” is a good term. The book introduces the idea that modern project management has to be a flexible system, using creative approaches and selections from among established models. It discusses a dozen broad topics in a format of problem description, solution, and something that is not always mentioned in books; how you can implement the solutions. The following are three issues discussed in detail: project management, managing managers, and scheduling.
Project Management
There is no “One True Way” for all projects. For example, an initial product release, a point release, and a bug fix version are all very different projects, just as is an initial documentation release, a maintenance update, and a Web-based How To suite. Slavishly following an inadequate model introduces more risks than it solves. Understand that project management is really risk management. Here, a risk is any condition that threatens to interfere with the plan. That means knowing the strengths and weaknesses of different systems and taking the useful features to meet your goals. For example, the project as a whole may be using the serial model, but your documents need an incremental approach for the added feedback and technical inputs. There are four basic types.
- Serial. Also called waterfall, this is the classic model. Milestones are clearly scheduled and follow a sequential approach, and expectations are easily managed, but useful scheduling is next to impossible since the serial nature of the process hides delays and risks, and limits feedback. A common variation is called rolling wave scheduling, and it allows for additional planning at each milestone.
- Iterative. This breaks down processes into smaller serial processes. The product prototypes evolve each cycle. This handles technical risk better, and the smaller timeboxes allow for better feedback. But the finishing schedule can be difficult if the prototype takes too much time and costs can be larger since the riskiest parts are worked on first.
- Incremental. This works best when you don’t have constant contact with the customer or component or cross-functional teams work independently to complete their tasks. The results are then rolled up in the next milestone. Schedules are more accurate as feedback is from multiple team members. Workers can be added or small teams can be used (useful when resources are scarce). Requirement changes can be accommodated, but keep in mind that changes in the architectural foundation affect the entire product.
- Iterative/Incremental (now known as agile). This breaks down each cycle to even smaller parts, as short as a week. Scheduling is the most flexible since you never plan in excess of what you need for the cycle. Team members may be reassigned after each short period. Requirements change less during a short period. Cost can be managed since priorities can be re-ranked. Project leaders must make strong decisions up front since significant re-ranking of priorities can cause extra work. The work environment must support flexibility.
Managing Managers
Project management boils down to management. The classic view is of a person directing the time and efforts of subordinates. You also manage your own time. While some amount of pushback (such as on a schedule or proposed feature list) is normal, recognizing risks introduced by your management is important. Sixteen types of risks are identified. Among them are:
- Bring Me a Rock. The boss insists on results but is vague about what is needed. The team, therefore, always brings the wrong rock. The pragmatic manager (you) has options for asking for explicit details, explaining why you brought that rock, trying to get an explanation, and then solving the underlying problem.
- Queen of Denial. The boss doesn’t face up to reality and has the attitude of “if you work hard, you’ll meet the goals.” The key is that you are not in denial. Be clear about the costs and results, or try to have managers explain the problems and suggest solutions.
- Split Focus. These managers schedule more than 100% of your time or set tasks that are too divergent. They say yes to all projects, thinking doing more than one task is always good. Try approaching the team to point out time/resource limitations, setting up shorter iterations, or using ranking requirements.
Planning and Scheduling
The pragmatic manager plans enough only to get the project started. It doesn’t have to be perfect. Know that things change quickly. Planning should be empirical (shorter-term goals and using feedback to gauge process), rather than the commonly used predictive approach. Scheduling is the hardest part of the process since it’s the most subjective, least defined, and within hours, will be out of date anyway. Expect to iterate schedules after milestones. The following can be used in any combination:
- Top Down. Use firm dates as the milestones and fill downwards.
- Bottom Up. Use individual component goals and fill upwards.
- Hudson Bay. Use this if the tasks are completely new to the team. The term refers to fur outfitters of the Hudson Bay Company. The trapper was required to set up camp several miles away from the store for a few days. This ensured they didn’t forget anything later. Start with small tasks and work up to more complicated ones.
