Managing software projects is difficult under the best of circumstances. The project manager must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing requirements and technologies, and unachievable demands from unreasonable people.
I don’t think there really is such a discrete thing as project management. Project management is a combination of people management, requirements management, technology management, opportunity management, business management, risk management, expectation management, and more. It’s a juggling act, with 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 wisdom they earn from painful experience. Coaching and survival tips from people who have already done their tour of duty in the project management trenches can save you from learning such lessons the hard way.
This is the first in a series of four articles that presents twenty-one such tips for success, which I’ve learned from both well-managed and challenged projects. The tips are organized into five categories:
- Laying the foundation for success
- Planning the project
- Estimating the work
- Tracking your progress
- Learning for the future
Thoughtfully applied and adapted, the practices in these categories can help your project deliver on expectations. Keep these suggestions in mind on your next project, recognizing that none of them is a silver bullet for your project management problems. More information on many of these topics is available in my book Practical Project Initiation: A Handbook with Tools.
Tip #1: Define project success criteria.
At the beginning of the project, make sure the key stakeholders share a common understanding of how they’ll 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 accuracy
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 criteria, complying with industry standards or government regulations, or achieving specific technological milestones.
Besides these goals, keep your eye on team member job satisfaction. This is 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 objective, 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 effectiveness.
Tip #2: Identify project drivers, constraints, and degrees of freedom.
Every project must balance its functionality, staffing, cost, 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 have bad news: not all factors can be constraints, and they cannot all be drivers. The project manager must have some flexibility to react to schedule slips, demands for increased functionality, staff turnover, and other realities.
A “flexibility diagram” such as that shown in Figure 1 visually depicts your constraints, drivers, and degrees of freedom. A constraint gives the project manager no flexibility in that dimension, so it is plotted at the zero value on its axis. A driver yields a small amount of flexibility, so its point is plotted a bit higher than zero. Degrees of freedom provide varying degrees of latitude. They represent parameters the project manager can adjust to achieve the project’s success drivers within the limits imposed by its constraints. Connecting the five plotted points creates an irregular pentagon. The smaller the area inside the pentagon, the more constrained the project is.
I once heard a senior manager ask a project leader how long it would take to deliver a planned new large software system. The project leader replied, “Two years.” The senior manager said, “No, that’s too long. I need it in six months.” The project leader’s response was simply, “Okay,” despite the fact that nothing had changed in the few seconds of that conversation to make the six-month target achievable. A better response would have been to negotiate a realistic outcome through a series of questions:
- How critical is the six-month target? 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 firm, what subset of the requested functionality do you absolutely need delivered by then? (schedule is a constraint, functionality is a driver)
- 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)
For more information on this topic, see “Rethinking the Triple Constraint: Five Project Dimensions.”
Tip #3: Define product release criteria.
Early in the project, decide what criteria will indicate whether the product is ready for release. Here are some examples of release criteria:
- 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.
- Specified customer acceptance criteria are satisfied.
- The optimum marketplace time to release has arrived.
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 when confronted with pressure to ship before the product is ready for prime time.
Carefully consider your target market segments when deciding on release criteria. The early adopters and enthusiasts 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.
Tip #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 about goals that are realistically achievable. Negotiation is required whenever there is a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates. See my cleverly-titled article “Negotiating Achievable Commitments” for more on this topic.
Principled negotiation involves four precepts:
- 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 help you make persuasive arguments, although there is no real defense against truly unreasonable people.
I once met with an aggressive and intimidating senior manager to discuss our large software engineering department’s software process improvement plans. Jack was eager to see our department achieve a specific — and highly ambitious — goal in just a few months. My process improvement group had carefully studied the problem and estimated that the earliest date that was even remotely feasible was a year longer than Jack had in mind. After some debate, Jack grudgingly agreed to give us a few more months, but I regarded even that goal as pure fantasy. After additional discussion, I finally said, “Jack, I’m not going to commit to that goal.”
I don’t think anyone had ever told Jack he wouldn’t make a commitment that Jack had demanded. He wasn’t sure what to say next. Jack eventually agreed to the target date to which I was willing to commit, and my team strove mightily to achieve it.
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 they will up until the moment of unfortunate truth. That just pisses everyone off.
Part 2 of this series describes several good practices for effective project planning. Part 3 will address estimation, and the final part offers suggestions for tracking status and learning for the future.
If you’re interested in software requirements, business analysis, project management, or software quality, Process Impact provides numerous useful publications and other resources.