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 challenging demands from high-pressure 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 tours of duty in the project management trenches can save you from learning such lessons the hard way.

This four-part series introduces twenty-one valuable practices that can help both rookie and veteran project managers do a better job. Perhaps these articles, which are adapted from my book Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007), can help you avoid some project pain.

The practices are organized into five categories:

1. Laying the foundation
2. Planning the project
3. Estimating the work
4. Tracking your progress
5. Learning for the future

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. Also, remember that even “best” practices are situational. They need to be selectively and thoughtfully applied only where they will add value to the project.

Practice #1: Define project success criteria.
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 particular 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 again should be measurable and trackable. These goals could include achieving schedule and budget targets, delivering committed functionality that satisfies acceptance tests, complying with industry standards or government regulations, or achieving specific technology milestones. The business objectives define the overarching goal. It doesn’t matter if you deliver to the specification on schedule and budget if those factors don’t clearly align with business success.

Not all of these defined success criteria can be your top priority. You’ll have to make some thoughtful tradeoff decisions to be sure that you satisfy your most important priorities. If you don’t define clear priorities for success, team members can work at cross-purposes, which leads to frustration, stress, and reduced effectiveness. Chapter 4 of Practical Project Initiation presents a tutorial on defining project success criteria.

 Practice #2: Identify project drivers, constraints, and degrees of freedom.
Every project must balance its functionality, staffing, budget, schedule, and quality objectives. 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 explain this idea more fully in my book Creating a Software Engineering Culture (Dorset House, 1996).

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.

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 much shorter 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 teaching a project management course once, a student insisted 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. The likely outcome? She will most likely fail. An overconstrained project has no way to deal with requirement changes, staff turnover or illness, risks that materialize, or any other unexpected occurrences.

Practice #3: Define product release criteria.
Early in the project, decide what criteria will indicate whether the product is ready for release. Some 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.
• Specified legal, contractual, or regulatory goals are met.
• 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. See Chapter 5 of Practical Project Initiation for more about defining product release criteria.

Practice #4: Negotiate achievable commitments.
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, as described in Getting to Yes by Roger Fisher, William Ury, and Bruce Patton (Penguin USA, 1991):

1. Separate the people from the problem.
2. Focus on interests, not positions.
3. Invent options for mutual gain.
4. Insist on using objective criteria.

Any data you have from previous projects will strengthen your negotiating position, 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. But 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. I discuss the importance of negotiating achievable commitments in Chapter 9 of Practical Project Initiation.

These four practices can help you get your project off to a solid start, with a clear idea of where you’re headed. In Part 2 of this series we’ll take a look at eleven best practices for planning the project.

Don't forget to leave your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.