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.
Caroline Pepa is a senior software engineer with Tybrin Corp. Contact her at email@example.com.