Johanna Rothman starts out by stating that there is no “One True Way” to manage every project. I was relieved that the book wasn’t going to be a treatise on a particular management method—a cure-all, if you will. Rothman does emphasize one point throughout the book: the crucial importance of knowing when the project is “done.” This implies the need for release criteria that all relevant stakeholders clearly understand. I’ve been involved with some projects over the years that suffered from ambiguity in the notion of “done,” so I can appreciate this emphasis. What she offers here is helpful practices for each project life cycle and guidance for making good decisions about how to guide and plan your project.

Establishing success criteria

On the way to defining release criteria, a project manager must consider constraints such as cost, schedule, features, and quality levels. Rothman explains how to balance these constraints according to stakeholder expectations. This balance requires project managers to determine what areas they can control and how to fit requirements to the constraints. It also requires assisting stakeholders in setting priorities and distinguishing real requirements from a wish list.

Eventually, you need a requirements list that defines success criteria to fit within the constraints established with stakeholders. The release criteria established at this point should flow through to your testing documentation and reporting to show that your project has met the release criteria.

Planning the project

When the development team has fewer than 10 people, Rothman proposes group planning. She also proposes limiting the amount of planning to what’s required to get started. Regardless of the life cycle your project is following, she advises you to assume you’ll be replanning at some point. Trying to plan the entire project in detail at the beginning is a waste of time and effort.

Rothman provides a project-plan template and suggests that project managers create a template for their plans before they begin planning. Some companies (including my employer) have libraries of templates and document samples available for projects. This gives inexperienced managers a starting point for creating project documentation. This option is especially important if the company adheres to a particular development standard because the template outlines the content required for compliance.

Rothman also cautions against providing schedule detail too early in the project lest the stakeholders believe it’s set in stone and without risk. Rather, project managers should provide details as they become clearer and more certainly attainable.

Project life cycles

Project managers are lucky if they can make a life-cycle choice without pressure from the sponsor or stakeholders. Each situation is unique, and Rothman provides information on several life-cycle types, discussing when one type might be more appropriate than another. It’s apparent throughout the book that she favors the agile life cycle for its more immediate feedback to the project team.

In the overview of life cycles, she discusses the association of life-cycle type with managing risk. She includes a high-level table of life-cycle examples, strengths of each type, project priorities, and what it takes to succeed using each type.

It’s good to remember here, too, that you can combine features from different life cycles when it’s appropriate for managing risk on a particular project type.

Schedules and schedule games

Rothman describes four scheduling techniques: top-down, bottom-up, inside-out, and Hudson Bay Start. I’m sure most project managers would agree that the initial schedule is basically a best guess—one that’s certain to change as the project resolves more uncertainties.

I found the discussion of scheduling with “yellow stickies”—instead of a project-scheduling tool—particularly interesting. The stickies offer a low-tech tool (no special training required) that lets the project manager involve all team members in the scheduling activity. An obvious advantage of the team approach is the increased possibility of having more detailed knowledge of the effort involved in accomplishing specific technical tasks. It can also save project managers time they might otherwise spend creating schedules that the team can’t agree with and that must therefore be rewritten—often many times—before planning can proceed.

Broadening the base of technical experts involved with the schedule also tends to reveal aspects of task dependencies, constraints, and risks that the project manager might not see when working alone with an automated scheduling tool. Finally, as Rothman points out, a project team that owns the schedule will stay committed to it.

Estimating tasks for project scheduling might involve one of the well-known methods such as Delphi. In my current project, we haven’t quite mastered using anything other than historical data. Luckily, Rothman sees this as a good thing—even if you’re using one or more of the more formal methods. The historical estimates should come from efforts similar to the current one performed by similarly experienced teams. Ideally, the historical estimates would include comparisons to actual results. In our case, our project has been ongoing for several years, so we have ample historical data to develop the initial estimates. Rothman offers tips that should make estimation easier.

Once the project manager has carefully planned, estimated, and scheduled the project, beware of individuals—especially sponsors and managers—who try to play schedule games. Rothman describes several of these games, explaining how to recognize and respond to them to keep the project moving along. I’ve witnessed several of them as a project team member—for example, “Bring me a rock” can indicate requirements so vague that no revision will ever be good enough; “90% done” can signal wishful thinking about how much of a task is completed and how much remains to be done; and “Schedule equals commitment” can reflect a project sponsor’s thinking about initial schedules—essentially guesses.

Project manager and the team

Finding and keeping the right technical talent for the team is another important project management function. Once the right people are assigned to the team, the manager should help the individuals get acquainted, develop trust in each other, and become a high-performing team. Project managers must make sure team members have access to the tools they need, such as configuration-management and defect-tracking tools. They must also know when the project requires more people to ensure its success.

One section of the book deals with being a great project manager. It includes lists of interpersonal and functional skills as well as discussions of domain and technology expertise and development tools. Rothman speaks candidly about knowing when to consider leaving an organization. There are times when a project manager must recognize that he or she is not right for an organization, a team, or a product and must prepare to move on. This decision isn’t often an easy decision to make!

Project managers must keep a finger on the project’s pulse by measuring qualitative and quantitative factors and by discovering and managing risks. Rothman suggests ways to perform these tasks and reminds project managers that they must decide which practices to use, according to the problems or issues encountered. She has good suggestions for reporting measurements and the caveat that you should use data as “a tool for your use, not an end in itself.” Measurements can help managers in tracking project progress, but they must be presented to sponsors and senior management in a way that ensures their correct interpretation. Often sponsors and stakeholders think they want to measure according to the latest and greatest measurement method, such as earned-value management or balanced scorecard. (I could go on!)

Rothman also suggests practices for project teams to consider. At the same time, she reminds project managers to carefully review any resistances to change in the existing culture before deciding to exert pressure on a team. When project teams consist of members from various geographical locations, the challenges to keeping them working in concert—with you and with each other—can be interesting. Rothman provides insight into what a project manager might expect to encounter in various scenarios and concludes, “If you can’t build trust with remote teams, your project cannot succeed.” The need for trust would seem to hold true of any team, regardless of its members’ geographical locations.

Manage It! has a website at http://pragmaticprogrammer.com/titles/jrpm. The site includes the templates advertised in the book’s preface. It also offers a PDF version of the book for sale. Many other Web sites are sprinkled throughout the book as references. I verified all the URLs and found several that I will visit again.

Every manager should read the chapter, “Managing Meetings.” I also found that the appendixes—one describing life cycles and another defining various terms—provided useful information about the book’s topics.

Rothman provides her view from the trenches on real-world projects and has good advice and some interesting observations to share. Anyone wanting to learn project management should consult various sources, and I recommend including this book among them; experienced project managers would benefit from the tips and techniques provided as well.

IEEE Annals of the History of Computing covers computer history with scholarly articles by leading computer scientists and historians, as well as first-hand accounts.

Cloud Computing magazine is committed to the timely publication of peer-reviewed articles that provide innovative research ideas, applications results, and case studies in all areas of cloud computing.

IEEE Computer Graphics and Applications magazine bridges the theory and practice of computer graphics, from specific algorithms to full system implementations.

Computing in Science & Engineering addresses the need for efficient algorithms, system software, and computer architecture to address large computational problems in the hard sciences.