Chapter 2. Project Management Good Practices[2]
Note
Consultant and author John Boddie once said that, too often, new software project managers are appointed to the technical ranks with less task-specific training than McDonald’s gives someone moving from French fries to hamburgers. Many novice project managers look back on their first project and wish that they knew at the beginning what they know now. This chapter introduces 21 valuable practices that can help both rookie and veteran project managers do a better job. Some of these practices are obvious, but others typically are learned only through painful experience. Perhaps this chapter can help you avoid some of that pain.
Managing software projects is difficult under the best circumstances. The project manager must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing technologies, and unachievable demands from unreasonable people. Project management is a juggling act, with too many balls in the air at once.
Unfortunately, many new project managers receive little training in how to do the job. Anyone can learn to draw a Gantt chart, but effective project managers also rely on the savvy that comes from experience. Learning survival tips from people who’ve already done their tour of duty in the project management trenches can save you from learning such lessons the hard way. Here are 21 such tips for success—good practices—that I’ve learned from both well-managed and challenged projects. Many of these practices are elaborated in subsequent chapters in this book. The practices are organized into five categories:
Together, the practices in these five categories define a project management control tool kit that can help your project deliver on expectations. When initiating a new project, study this list of practices to see which ones would be valuable contributors to that project. Build the corresponding activities into your thinking and plans. Recognize, though, none of these practices will be silver bullets for your project management problems.
At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too often, meeting a predetermined schedule is the only apparent success factor but there are certainly others. Begin by identifying your stakeholders and their interests and expectations. Next, define some clear and measurable business goals. Some examples are:
Increasing market share by a certain amount by a specified date.
Reaching a specified sales volume or revenue.
Achieving certain customer satisfaction measures.
Saving money by retiring a high-maintenance legacy system.
Achieving a particular transaction processing volume and correctness.
These business goals should imply specific project success criteria, which should again be measurable and trackable. They could include achieving schedule and budget targets, delivering committed functionality in a form that satisfies customer acceptance tests, complying with industry standards or government regulations, or achieving specific technology milestones. Also, keep your eye on team member job satisfaction, sometimes indicated by staff turnover rate and the willingness of team members to do what it takes to make the project succeed. The business objectives define the overarching goal, though. It doesn’t matter if you deliver to the specification on schedule and budget if those factors don’t clearly align with business success.
Remember that not all of these defined success criteria can be your top priority. You’ll have to make some thoughtful tradeoff decisions to ensure that you satisfy your most important priorities. If you don’t define clear priorities for success, team members can work at cross-purposes, leading to frustration, stress, and reduced teamwork effectiveness. See Chapter 4, for more information about defining success criteria.
Every project must balance its functionality, staffing, cost, schedule, and quality objectives (Wiegers 1996). Define each of these five project dimensions as either a constraint within which you must operate, a driver strongly aligned with project success, or a degree of freedom you can adjust within some stated bounds. I’m afraid I have bad news: Not all factors can be constraints and not all can be drivers. The project manager must have some flexibility to react to schedule slips, demands for more functionality, staff turnover, and other realities. See Chapter 4 for more on how to apply these five dimensions.
I once heard a senior manager and a project leader debate how long it would take to deliver a planned new large software system. The project leader’s top-of-the-head guess was four times as long as the senior manager’s stated goal of six months. The project leader’s response to the senior manager’s pressure for the short schedule was simply, "Okay." A better response would have been to negotiate a realistic outcome through a dialogue:
How critical is the six-month goal? Does something drastic happen if we don’t deliver in six months (schedule is a constraint), or is that just a desirable target date (schedule is a driver)?
If the six months is a firm constraint, what subset of the requested functionality do you absolutely need delivered by then? (Features are a degree of freedom.)
Can I get more people to work on it? (Staff is a degree of freedom.)
Do you care how well it works? (Quality is a degree of freedom.)
Can I get more funding to outsource part of the project work? (Cost is a degree of freedom.)
While I was teaching a course on project management best practices recently, a student told me that all five dimensions were constraints on her project. She had a defined feature set that had to be delivered with zero defects by a specific date by a fixed team size working on a fixed budget. She will most likely fail. An overconstrained project has no way to deal with requirement changes, staff turnover, illness, risks that materialize, or any other unexpected occurrences.
Early in the project, decide what criteria will indicate whether the product is ready for release (Rothman 2002). Examples of possible release criteria are:
There are no open high-priority defects.
The number of open defects has decreased for X weeks and the estimated number of residual defects is acceptable.
Performance goals are achieved on all target platforms.
Specific required functionality is fully operational.
Quantitative reliability goals are satisfied.
X% of system tests have been passed.
The optimum marketplace time to release has arrived.
Customer acceptance criteria are satisfied.
Whatever criteria you choose should be realistic, objectively measurable, documented, and aligned with what "quality" means to your customers. Decide early on how you will tell when you’re done, track progress toward your goals, and stick to your guns if confronted with pressure to ship before the product is ready for prime time.
Consider your target market segments when selecting release criteria (Rothman 1999). The technology enthusiasts and early adopters have a higher tolerance for defects than do the pragmatic early majority of customers or the conservative late majority. In contrast, time to market and innovative features or technology usage are most important to the early adopters. See Chapter 5 for more recommendations regarding release criteria.
Despite pressure to promise the impossible, never make a commitment you know you can’t keep. Engage in good-faith negotiations with customers, managers, and team members to agree on goals that are realistically achievable. Negotiation is required whenever there’s a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates. Principled negotiation involves four precepts (Fisher, Ury, and Patton 1991):
Separate the people from the problem.
Focus on interests, not positions.
Invent options for mutual gain.
Insist on using objective criteria.
Any data you have from previous projects will strengthen your arguments, especially because the person with whom you’re negotiating likely has no data at all. However, there’s no real defense against truly unreasonable people.
Plan to renegotiate commitments when project realities (such as staff, budget, or deadlines) change, unanticipated problems arise, risks materialize, or new requirements are added. No one likes to have to modify his commitments. However, if the reality is that the initial commitments won’t be achieved, let’s not pretend that they will right up until the moment of disappointing truth. See Chapter 9, for more about this delicate area.
[2] This chapter was originally published as "21 Project Management Success Tips" in Reifer, Donald J. (ed.), Software Management, Sixth Edition, Los Alamitos, Calif.: IEEE Computer Society Press, 2002. It is reprinted here, with modifications, with permission of IEEE.