Chapter 4. Lessons About Project Management

The Project Management Institute defines a project as “a temporary endeavor undertaken to create a unique product, service or result” (PMI, n.d.). It defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”

These definitions sound reasonable, but I don’t think project management is a discrete discipline. Instead, project management involves managing many activities that—in the aggregate—contribute to project success. These activities could be performed by a single individual, a group or hierarchy of managers on a large project, or collaboratively by partitioning activities among multiple team members. For instance, on a project following Scrum, various project management responsibilities are distributed among the Scrum Master, product owner, and other team members. When I say project manager in this book, I refer to whoever is involved with the activities of guiding projects from inception to successful completion, regardless of their job titles or other project responsibilities.

This introduction describes some of the dimensions included in project management; several of these are addressed in more detail in this chapter’s lessons. Even if you aren’t a specialist project manager, you manage your own work and have project delivery responsibilities. Much of this chapter’s contents applies to individuals as well as two project teams.

People Management

Projects are carried out by people, ranging from a single individual through a small colocated team to a cast of hundreds working on multiple subprojects in numerous locations. Managing a project involves identifying what must be done and when, determining the mix of skills needed to do it, identifying individuals to fill the various project roles, and then bringing them in at the right time. Once people are on board, they need to be managed, led, and perhaps trained appropriately. Occasionally, it might be necessary to replace certain individuals because of their performance or an improper fit to the work.

Requirements Management

As we saw in Chapter 2, all projects have requirements. Most requirements describe the product itself; others describe related project work, such as developing training materials or transitioning to a replacement system. Some projects launch with an already completed baseline set of requirements. On others, developing requirements is an ongoing part of the project work. For the latter, the team must have both people who are skilled in requirements activities and the time needed to do the requirements work. Adjusting project plans to keep the team focused on delivering the necessary system capabilities and characteristics is a core project management activity.

Expectation Management

An essential part of managing a project is to set realistic expectations that stakeholders understand and accept. Those expectations include the properties of the solution that the project team will deliver and the delivery parameters. Delivery parameters include the schedule for interim and final deliveries, cost, quality, resources required, and limitations—things the solution will not include. Frank discussions help ensure that the project participants know what others expect from them, which facilitates negotiating mutually acceptable—and achievable—commitments (Karten, 1994).

Some stakeholders might not be happy with particular expectations. However, project managers must deal with reality, not with fantasies of ideal but unachievable outcomes. When project situations change, project managers need to negotiate adjusted expectations with the affected stakeholders.

Task Management

Delivering the expected value from a project requires that many tasks be completed correctly in the right sequence. Some tasks can’t begin (or complete) until others are either begun or completed. Participants need to identify tasks at an appropriate level of granularity, allocate resources to each task, and roll up sets of tasks into milestones that show progress to defined checkpoints. The project manager needs to sequence the work to achieve the project’s objectives in the shortest time and at the lowest cost, avoiding unnecessary wait states and delays. Task management is a continuous juggling act.

Commitment Management

Project managers make commitments to their customers, their own managers, and their team members. Similarly, those other participants make commitments to the project manager and each other. Commitments often are based on estimates, which have intrinsic uncertainty. As one experienced project manager pointed out, “Estimates are not actuals in advance.” Everyone must make commitments in good faith based on the best available information. They should track progress toward those commitments, honestly adjust them as realities change, and take action when a commitment isn’t fulfilled.

Risk Management

All projects contain unknowns and risks. A vital success factor is anticipating potential risks, assessing their likely impact on the project, and controlling them to the extent possible. Failure to manage risks actively is an invitation to let the resulting problems surprise—and perhaps derail—the project. The project manager is focused on enabling success, but they also have to keep an eye open for trouble ahead. Risk management is worrying about the what-ifs before they become the what-do-we-do-nows.

Communication Management

Communication is at the core of project management. Projects generate information regarding status, issues, resource needs, changes, expectations, and the like. Project management encompasses acquiring this information, storing it appropriately, and sharing it with the right people at the right time. Large projects that involve multiple teams in numerous locations, sometimes speaking different languages and with diverse cultures and communication preferences, pose particular communication challenges.

Change Management

It’s safe to assume that a project’s final product won’t be precisely what people anticipated at the outset. The project manager must cope with changes in requirements, priorities, resources, technologies, processes, and regulations. Each team should establish mechanisms at the beginning to help them anticipate and accommodate change with as little disruption as possible. Agile projects are explicitly structured to accommodate change, dynamically adjusting the backlog of remaining work to ensure the team is always working on the top priority activities.

Resource Management

I don’t like to hear managers refer to human beings as “resources,” but people do constitute the largest—and most costly—project resource. Besides assembling the right staff, managers need to provide physical facilities, computer systems, communications infrastructures, testing laboratories, and access privileges for contractors. Managing the project’s budget is another critical activity.

Dependency Management

Many projects have dependencies on outside factors beyond their control. They might be awaiting delivery of software or hardware components from a third party before they can proceed. One project that built a new printer was delayed because the international standard for the new hardware interface protocol was not yet finalized. Tasks and activities can have internal dependencies within the project, also. A project manager must identify such dependencies, incorporate appropriate lead times into the project schedule, and monitor status to see if each dependency will be fulfilled. It’s also a good idea to create contingency plans in case a dependency fails.

Dependencies can run the other way, too. If the current project is itself a dependency for another one, the project manager should communicate status frequently to the other project team so they know what to expect.

Contract Management

Contracts constitute legally binding agreements among parties. Not all projects involve formal contracts, but someone must attentively manage those that do. Failing to deliver on a contract can have significant consequences. A developing organization might have contracts with customers, vendors of goods, and subcontractors who perform portions of the project work. Contracts should include such details as who will pay for customer-requested scope changes and the consequences of failing to meet contractual commitments.

Even on projects with no formal contracts, agreements reached among the participants imply some level of “contract.” These tacit contracts can be more difficult and critical to manage, simply because they’re not negotiated and documented explicitly. It would be unwise for a project manager to ignore implicit agreements, expectations, or commitments simply because “we don’t have a written contract.”

Supplier Management

Software projects often involve outsourcing. The entire body of development work could be outsourced to a third-party company, possibly offshore. Some projects outsource only certain activities, such as system testing. Building partnerships with these suppliers involves establishing contractual agreements, communication mechanisms, common tools, quality expectations, and dispute resolution processes. Third-party supplier arrangements introduce risks and dependencies over which the project manager might have little influence.

Managing Away the Barriers

Based on this lengthy list of subdisciplines, project management clearly is an extensive and challenging process on any sizable project. The people responsible for each project’s success should assess which of these domains apply to their project and ensure that they have the appropriate experience, skills, and time available, either in themselves or in other team members.

The project manager’s primary responsibility is to clear out obstacles that impede the team’s progress. I like to think of the project manager as working for the team, not the reverse. Someone has to provide resources, resolve conflicts, negotiate outcomes, coordinate activities, run interference, and keep the team running smoothly. By any title, on any project, that’s a big responsibility. This chapter presents twelve lessons that can make the project manager’s job easier.

First Steps: Project Management

I suggest you spend a few minutes on the following activities before reading the project management-related lessons in this chapter. As you read the lessons, contemplate to what extent each of them applies to your organization or project team.

1. List project management practices that your organization is especially good at. Is information about those practices documented to remind team members about them and make it easy to apply them?

2. Identify any problems—points of pain—that you can attribute to shortcomings in how project teams estimate, plan, coordinate, and track their work.

3. State the impacts that each problem has on your ability to complete projects successfully. How do the problems impede achieving business success for both the development organization and its customers? Common problems include:

• Inadequate visibility into the necessary work and its status

• Communication gaps

• Collaboration shortcomings

• Unrealistic estimates and plans

• Unfulfilled commitments

• Unexpected risks that materialize into problems

• Failed dependencies

4. For each problem from Step #2, identify the root causes that trigger the problem or make it worse. Some root causes are internal to the project team or organization; others arise from sources outside the team that are beyond your control. Problems, impacts, and root causes can blur together, so try to tease them apart and see their connections. You might find multiple root causes that contribute to the same problem, as well as several problems that arise from a single root cause.

5. As you read this chapter, list any practices that would be useful to your team.

Lesson #23. Work plans must account for friction.

I overheard this conversation at work one day:

Manager Shannon: “Jamie, I know you’re doing the usability assessments on the Canary project right now. Several other projects are also interested in usability assessments. How much time do you spend on that?”

Team Member Jamie: “About eight hours a week.”

Manager Shannon: “Okay, so you could work with five projects at a time then.”

Do you see any flaws in Shannon’s thinking? Five times eight is forty, the nominal hours in a work week, so this discussion seems reasonable on the surface. But Shannon hasn’t considered the many factors that reduce the time that individuals have available each day for project work: project friction (as opposed to interpersonal friction, which I’m not discussing here).

There’s a difference between elapsed hours on the job and effective available hours. This difference is just one factor that both project planners and individuals must keep in mind as they translate size or effort estimates into calendar time. If people don’t incorporate these friction factors into their planning, they’ll forever underestimate how long it will take to get work done.

Task Switching and Flow

People do not multitask—they task switch. When multitasking computers switch from one job to another, there’s a period of unproductive time during the switch. The same is true of people, only it’s far worse. It takes a little while to gather all the materials you need to work on a different activity, access the right files, and reload your brain with the pertinent information. You need to change your mental context to focus on the new problem and remember where you were the last time you worked on it.

Some people are better at task switching than others. Maybe I have a short attention span, but I’m pretty good at diverting my focus to something different and then resuming right where I left off. For many people, though, excessive task switching destroys productivity. Programmers are particularly susceptible to the time-sucking impact of multitasking, as Joel Spolsky (2001) explained:

When you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once.

When I was a manager, a developer named Jordan said he was flailing. Jordan didn’t understand the priorities of items in his work backlog. He would work on task A for a while, then feel guilty that he was neglecting task B, so he’d switch to that one. He was getting little done as a result. Jordan and I worked out his priorities and a plan for allocating time to tasks in turn. His productivity went up, and Jordan felt much better about his progress. Jordan’s task-switching overhead and priority confusion affected both his productivity and his state of mind.

When you’re deeply immersed in some work, focused on the activity, and free from distractions, you enter a mental state called flow. Creative knowledge work like software development (or writing a book) requires flow to be productive (DeMarco and Lister, 2013). You understand what you’re working on, the information you need is in your working memory, and you know where you’re headed. You can tell you’ve been in a state of flow when you lose track of time as you’re making great progress and having fun. Then your phone pings with a text message, an email notification pops up, your computer reminds you that a meeting starts in five minutes, or someone stops by to talk. Boom—there goes your flow.

Interruptions are flow-killers. It takes several minutes to get your brain back into that highly productive state and pick up where you were before the interruption. Some reports suggest that interruptions and task switching can impose a penalty of at least 15 percent of a knowledge worker’s time, amounting to more than one hour per day (DeMarco, 2001). A realistic measure of your effective work capacity is based not on how many hours you’re at work or even how many hours you’re on task, but how many uninterrupted hours you’re on task (DeMarco and Lister, 2013).

To achieve the high productivity and satisfaction that come from an extended state of flow, you need to manage your work time actively. The potential for distractions and interruptions is ever-present unless you take steps to block them out. Jory MacKay (2021) offered several recommendations for reducing context switching and its accompanying productivity destruction:

• Timeblock your schedule to create clearer focus boundaries. Planning how you will spend your day, with dedicated blocks of time allocated to specific activities, carves out opportunities for extended deep concentration. If the nature of your work permits, devote certain full days each week to focus on your most important individual tasks, to more actively collaborate with others, or to catch up on busywork.

• Build a habit of single-tasking throughout the day. One of my talented but less productive team members was able to get more work done when we agreed that he would set aside half-day blocks of time during which he didn’t answer the phone, texts, or emails—at all.

• Employ routines to remove attention residue as you migrate from one task to the next. Physically moving on to the next activity doesn’t immediately unplug your brain from the previous one, which can be a distraction. A small transition ritual—a cup of coffee, an amusing video—can help you make that mental break into a new work mode.

• Take regular breaks to recharge. The intense concentration of a state of flow is great—up to a point. You must come up for air occasionally. Stretch your tired neck, arms, and shoulders. To minimize eyestrain, periodically focus your eyes on something in the distance for a few seconds instead of staring at the screen endlessly. Short mental breaks are refreshing before you dive back into that flow.

Effective Hours

At-work hours seep away through many channels. You attend meetings and video chats, respond to emails, look things up on the web, participate in retrospectives, and review your teammates’ code. Time gets lost to unexpected bug fixes, kicking around ideas with your coworkers, and administrative activities. Working from home offers myriad other distractions, many of them more fun than project work. Even if you work forty hours a week, you don’t spend anywhere near that many on your project.

One software group of mine measured how we devoted our time on projects for several years (Wiegers, 1996). Individuals tracked the hours they spent working on each project in ten activity categories: planning, requirements, design, implementation, testing, documentation, and four types of maintenance. We didn’t try to make the weekly numbers add up to any total. We just wanted to know how we really spent our time, compared to how we thought we spent our time, compared to how we were supposed to spend our time.

The results were eye-opening. In the first year we collected data, we devoted an average of just 26 hours per week to project work. The time tracking made us all more conscious of finding ways to focus our time more productively. However, we never exceeded an average of 31 hours per week of project time.

Several of my colleagues have obtained similar results, averaging five to six hours per day on project work. Other sources also suggest that a typical average of ideal work hours—”uninterrupted attentive time for project tasks”— is about five hours per day (Larman, 2004). Rather than relying on published figures to estimate your effective project time, collect your own data. Recording how you work for a few typical weeks will provide a good idea of how many hours per week you can expect to devote to project tasks, which affects the team’s projected productivity or velocity.

The intent of this time tracking is not so that managers can see who’s working hard. Managers shouldn’t even see the data for individuals, just aggregated data. Knowing the team’s average effective weekly work hours helps everyone make realistic estimates, plans, and commitments.

Other Sources of Project Friction

Besides the daily frittering away of time on myriad activities, project teams lose time to other sources of friction. For instance, most corporate IT organizations are responsible for both new development and enhancing and repairing current production systems. Since you can’t predict when something will break or a change request will come along, these sporadic maintenance demands usurp team members’ time with unplanned work.

Distance between project participants can retard information exchanges and decision-making. (See Lesson #39, “It takes little physical separation to inhibit communication and collaboration.”) Even with the many collaboration tools available, projects with people in multiple locations and time zones should expect some slowdown from communication friction. Sometimes you can’t reach an individual, such as a key customer representative who has the answer you need. You have to either wait until they’re available or make your best guess so you can proceed. That slows you down, especially when an incorrect guess leads to rework.

The team composition can further impose friction if project participants speak different native languages and working diverse cultures. Unclear and volatile requirement priorities can chew up hours as people spend time researching, debating, and adjusting priorities. The team might have to temporarily shelve some incomplete work if a new, higher-priority task inserts itself into the schedule. Unplanned rework is yet another time diversion.

I know of a contract project that involved a customer in the eastern United States and a vendor in western Canada (Wiegers, 2003). Their project plan included some peer reviews of certain deliverables. However, the long-distance reviews took longer than expected, as did follow-up to verify the corrections made. Slow decision-making across the distance further reduced the project’s pace. Sluggish iteration to resolve requirements questions and ambiguity about who the right contact people were for each issue were further impediments. These—and other—factors put the project behind schedule after just the first week and eventually contributed to its failure.

Planning Implications

Project friction has a profound impact on estimation, so both individuals and teams must keep it in mind. I estimate how long individual tasks will take as though I will have no distractions or interruptions, just focused and productive time. Next, I convert that ideal effort estimate into calendar time based on my effective work hour percentage. I also consider whether any of the other sources of friction discussed above could affect my estimates. Then I try to arrange my work so I can focus on a single task at a time until it’s complete or I hit a blocking point.

My colleague Dave described what happens on his current project, whose manager doesn’t consider the impacts of time lost to excessive multitasking:

The manager likes to split people up between teams, 50 percent here and 50 percent there, or 50, 25, and 25. But when this happens, it seems like they forget the percentages and think the team has all full-time people. Then they seem surprised at how long things take. Also, being on multiple teams means more overhead in meetings and less coding time.

If people always create estimates without accounting for the many ways that time-splitting and project conditions can slow down the work, they’re destined to overrun their estimates every time.

Lesson #24. Don’t give anyone an estimate off the top of your head.

You’re a business analyst (BA) or product owner. As you walk down the hall in your workplace, you bump into Melody, one of your project’s customer representatives. “I’d like to add something to that project we’re working on,” Melody says. You stop and listen to her description of the new feature. “How much work you think it would take to put that in?” she asks.

You ponder for a moment. “About three days,” you reply.

Melody says, “Great, thanks. Let’s do it.” You both resume your journeys down the hallway.

You return to your desk and think about Melody’s new feature some more. The more you look into it, the larger it appears. You realize that there’s no way the team can implement it with just three days of effort, as you had told Melody earlier. There’s a lot more to it than you thought. As you understand the feature better, you’re also concerned that it might conflict with another feature the team has planned for the next development cycle. Is it too late to change your reply to Melody?

Hasty Predictions

The best response to a request for an estimate is, “Let me get back to you on that.” An estimate you provide in passing based on limited information and superficial analysis could be terribly inaccurate, yet it sounds a lot like a commitment to the other person. Melody took you at your word, so now you have to explain that her request is bigger than you initially appreciated. Some negotiation and replanning will be needed before the team can commit to adding this new feature. That can be an awkward conversation. As Mike Cohn (2010) pointed out:

“We estimate this will take seven months” was translated into “We commit to finishing in seven months.” Estimating and committing are both important, but they should be viewed as separate activities.

It’s tempting to give someone a quick estimate off the top of your head, but try to suppress that temptation until you’ve studied the request more. Those quick responses aren’t analytically-derived estimates but rather guesses pulled out of thin air. Before you provide an estimate, make sure you know just what the request encompasses. Then assess what it realistically would take to deliver on that request.

Quick—and maybe not very accurate—estimates are a common problem when dealing with new requirements and change requests. Impact analysis often reveals that the problem is larger than you appreciated based on your initial information. If you provide a realistic estimate, the requester might elect to drop the whole thing because it’s not worth the time or cost required. It’s better to know that before you begin implementing the new functionality instead of getting partway done and then abandoning it when the change turns out to be unjustifiably large.

When you study the problem and derive your best estimate for a piece of work, consider the following factors and include the answers when you deliver the estimate.

• What assumptions influenced your estimate? How can you verify their validity?

• Do you know who will be doing the work? Different team members have different skill sets; some are more productive than others. If you don’t know who would handle it, you have to assume some average performance level.

• Someone will have to write and execute tests for new functionality. You might need a code review and regression testing to make sure the change didn’t break anything else. Make it clear whether your estimate encompasses this full scope of work or just the coding part.

• Have you considered unobvious impacts and extra work that might be required beyond simply implementing the new functionality? It could affect other functionality or negatively impact some quality attribute. It might require design modifications, interface changes, or user documentation updates.

• Can you think of any risks that might affect your sunny-day, everything-goes-fine estimate?

Fear of Fuzz

Sometimes the people who receive estimates don’t realize how much uncertainty even a carefully crafted estimate can have. The fuzzier the problem and the less certain the assumptions, the fuzzier the estimate will be. If customers hear a single number like “three days,” that’s what they’re going to remember and count on. Providing an estimate in the form of a range—best case to worst case—instead of a single-point value is a reminder that an estimate is an approximate prediction of the future, not a guarantee (McConnell, 2006). The listener might still choose to focus on the lower number of the range: “So it’s possible you’ll be done in three days, right?” It’s important to communicate expectations clearly when you present an estimate.

A significant problem when providing a bald, unsupported estimate is that the people who receive the estimate have little understanding of how you formulated it. You can do a thorough job of analyzing, planning, and allowing for contingencies, yet the response could still be, “That’s ridiculous. It can’t take you that long to get it done.” A superficial guess that lacks careful analysis will be more optimistic and hence better received, but that just sets everyone up for more disappointment when reality sets in.

We all like to provide instant gratification when someone asks something of us. However, if you take the time to reflect on a problem before you offer an estimate for solving it, you’ll paint yourself into fewer commitment corners.

Lesson #25. Icebergs are always larger than they first appear.

My manager once called me and asked, “Got an hour?” He’d been approached by a scientist who’d written a simple BASIC program on his PC to calculate formulas for chemical solutions he used in his research. The scientist wanted one of us software people to port his program to our mainframe so others could use it.

This seemed like a quick job on the surface. My manager’s initial request really would have taken only a couple of hours. However, I realized that there was much more to the problem. The program needed to include more calculations than this scientist had addressed because different researchers worked with different chemicals. The calculations had to be more accurate than his simple homegrown approach considered. We also needed a flexible interface that would work for a large user group and generate reports suitable for use in the lab.

I explored the full spectrum of requirements and researched how to improve the computational accuracy. Then I designed a solution, coded the software, and tested the application. This project consumed just over 100 hours of my time. It was a good investment, though, as the application was heavily used for years.

Most software projects don’t turn out to be 100 times larger than initially estimated. However, projects tend to balloon from their initial conception from more thorough problem analysis and change requests during development. The longer the project takes, the more you can expect it to grow. Software industry analyst Capers Jones (2006) found that the requirements set on large projects typically grows between 1 and 3 percent per calendar month during development. If you don’t anticipate some growth and plan to accommodate it, you’re certain to fall behind plan.

You’ve probably heard that a large fraction of an iceberg is hidden below the water’s surface. Similarly, a lot of the work needed to execute a software project might not be visible initially. Iterative development approaches acknowledge that the iceberg’s size isn’t fully understood at the outset. As software is delivered in chunks, stakeholders will think of more functionality to add. That is, the more they see, the more they’ll want (Davis 1995). The iceberg is always bigger than you thought it was initially, and it just keeps growing.

Contingency Buffers

One way to deal with requirements growth is to build contingency buffers into project schedules. Buffers provide a margin for error, a way to handle uncertainty. When you plan a development cycle, you’re basing your estimates on limited information about the project’s scope, assumptions that might not be true, and other variables. Because of these unknowns, it’s a good idea to add some slack to the schedule in the form of contingency buffers. Otherwise, the first new requirement that comes along, the first estimate that turns out to be low, or the first unanticipated task will wreck the schedule.

A contingency buffer isn’t an arbitrary fudge factor pasted into the schedule, nor arbitrary inflation of all the individual estimates. You can calculate sensible buffers based on your previous experience with schedule overruns and requirements growth. Quantitative risk analysis is another method, letting you think through the potential risks facing your project, their likelihood of occurrence, and how they could harm the schedule. Critical chain project management is a technique for incorporating well thought-out buffers (Goldratt, 1997). They can go at the end of a sequence of dependent tasks—feeding buffers—and also at the end of the overall project—a project buffer. Figure 4.1 illustrates how to position both types of buffers in a Gantt chart schedule representation.

On an agile project, consider incorporating a modest contingency buffer into each iteration to account for project uncertainties. This buffer will help keep your iteration cycle on track and reduce the need to defer uncompleted work to later iterations. You might also plan an extra iteration at the end of the project as a buffer to accommodate deferred and added user stories and other lingering work, as Figure 4.2 illustrates (Thomas, 2008b).

Let’s see one way to incorporate buffers into an agile project (Cohn, 2006). User stories (or, more generally, backlog items) come in different sizes, which many teams estimate in units of story points. Agile projects measure the team’s velocity on each development iteration of a few weeks’ duration. Velocity is a measure of how many story points the team can deliver per iteration.

Suppose your product backlog contains 150 story points of work. Your velocity measurements indicate that the team can deliver an average of 30 points per iteration, suggesting a project duration of 5 iterations. You might base your overall delivery plan on a slightly more conservative velocity of 25 points per iteration, for a total of 6 planned iterations (150 divided by 25). Your committed delivery plan now includes an average of 5 points of contingency in each iteration.

The team still plans iterations as though they’ll deliver 30 points in each. That is, they work toward an internal goal that’s more ambitious than their external commitment. The difference constitutes slack that can account for items that turn out to be bigger than estimated, unanticipated work, bug fixes, refactoring, and other activities that consume time. The team’s velocity measurements might already include the impact of ongoing bug fixes and refactoring, but surprises can happen at any time on any project (Cohn, 2014).

Risky Assumptions

Incorporating contingency buffers does increase the expected delivery schedule, so managers and customers might push back against them. “That’s just padding,” they protest. “If you take that padding out, you’ll be done earlier, right?” Probably not.

A contingency buffer doesn’t change the future. It provides a safety margin to account for unknowns, the unexpected, and estimation inaccuracies. Yanking out the buffer doesn’t eliminate those variables; it just reduces your ability to cope with them and still meet commitments. A manager who excises contingency buffers is making several assumptions:

• The scope information you have in hand today is well understood, accurate, and stable.

• All estimates are accurate, or at least any inaccuracies will balance each other out.

• You know who will be working on the project, and the team will remain intact throughout the project.

• Team members won’t be interrupted by performing support work on a previous product or other diversions.

• No one will get sick, go on vacation, or leave the company.

• No risks will turn into problems, and no new risks will raise their ugly heads.

• All dependencies the project has on external factors will come through on time.

Those assumptions paint the development team into a corner that’s just about guaranteed to cause an overrun. If you encounter resistance to your contingency buffers, point out some unexpected experiences from previous projects. Ask if there’s any reason to believe that the new project will be different, that none of those unpleasant experiences will recur. If not, the buffers should stay.

The best way to justify your contingency buffers is to show how you calculated them based on previous project experience in the organization. Historical data that indicates how much requirements growth your projects typically experience helps you defend a buffer to accommodate such growth.

I once spoke with a senior manager at one of my consulting clients about a project they expected to take five years to complete. I told him about the industry data that suggested a requirements growth rate of perhaps 2 percent per month for a project of that size. That growth rate could make the ultimate product of a sixty-month project more than twice as large as initially estimated. “That sounds plausible,” he replied.

Then I asked, “Do your project plans include any contingency buffers to accommodate that growth?” His predictable answer was, “No.” I suspect that project took a lot longer than five years.

Contracting on Icebergs

The iceberg phenomenon also affects contracting projects. If you’re a contractor who wants to get the job, you might be tempted to exclude contingency buffers from your bid to keep the price low. But what happens when you discover the true size of the iceberg? Or what if the customer requests a scope increase and won’t agree to postpone any of the other committed requirements?

If your plans included contingency buffers, you could accommodate some modest growth without trashing the budget or schedule. When the customer asks, “Can you add this one little requirement or make this one extra change? You’ll still be done on time, right?” the buffer might let you answer in the affirmative. The customer would view your “yes” answer as a sign of your flexibility and desire to satisfy. Without some planned slack capacity, though, a growing project could force you to eat the cost overrun and perhaps miss a schedule commitment.

I’ve heard the practice of presenting an unrealistically low bid to land the contract described as “the best liar wins” syndrome. You’ll have to decide whether you want to do business based on your best assessment of the future or on fantasies that might come back to bite you. Incremental development approaches help to cope with size uncertainty, acknowledging up front that there’s much you don’t know yet that could affect the project’s outcome. Some customers will balk at an open-ended project, though.

The Benefits of Buffers

Planning for possible future occurrences doesn’t change what will happen in the future. It does improve your ability to roll with reality without wrecking your plans. If you don’t know the iceberg’s full size, expect it to be larger than it appears and plan accordingly. Building some flexibility into any commitment helps to keep deliveries on schedule.

Suppose all goes well on the project and you don’t fully consume the allocated contingency buffers. You might deliver ahead of time—everybody wins.

Lesson #26. You’re in a stronger negotiating position when you have data to build your case.

When you meet with a salesperson at a car dealership to negotiate the price, you’re at a disadvantage. Salespeople have a lot of data at their fingertips, including:

• The manufacturer’s suggested retail price for the vehicle you want.

• What the dealer paid for the car (invoice price).

• The minimum profit the dealer will accept.

• The dealer cost and markup on any accessories.

• Any special promotions or incentives available to either the dealer or the customer.

• What your trade-in is worth.

• What the last people who bought the same car paid.

You probably have only one piece of data available: the sticker price on the window. However, if you’ve done some homework, you might have inside price information from a source like Consumer Reports. That preparation has worked well for me. Otherwise, though, the salesperson is in a far stronger negotiating position than you because of the extra information they have at hand.

Where Did You Get That Number?

A software project doesn’t come with a preset sticker price to use as a starting point, but an analogous data imbalance can influence negotiations among key stakeholders. Suppose I’m a project manager. The project sponsor—some senior manager or my primary customer—asks me how long it will take to complete a new project and what it will cost. Based on my understanding of the project and my experience, I develop and present an estimate. If the sponsor doesn’t like the estimate, two possible outcomes can ensue. In one, I try to defend my estimate—without data—while the sponsor insists on a more aggressive target. That’s not so much a negotiation as a debate that I’m likely to lose.

An alternative outcome is based on data, not on emotion, pressure, or political power. I describe to the sponsor how I came up with my estimate, perhaps something like this:

• I worked with knowledgeable and experienced team members who understand the kind of work the new project involves.

• We estimated the project’s size based on the information we had about it at the time, including a factor for uncertainties and anticipated growth based on our previous experiences. We used a group estimation technique like Wideband Delphi (Wiegers, 2007) or one of several agile estimation methods (Sliger, 2012).

• We made certain assumptions that influenced our estimate.

• We referred to our previous experience on similar projects, from which we had recorded data regarding the project size, our estimates, the actual results, risks and surprises we encountered, and so forth.

• We assessed the extent to which the reference projects were good models for the new one to judge how different characteristics of the new project would affect our estimates.

• Based on our previous productivity measurements, we calculated most likely, pessimistic, and optimistic estimates of duration and cost.

In the second scenario, if the sponsor dislikes the estimate, we can have a fact-based discussion about it. Maybe the project is unlike anything we’ve done before, and our reference data isn’t relevant. That would increase the risks and the estimation uncertainty. Maybe we don’t understand the project well enough to generate a meaningful estimate. We’ll have to approach it incrementally, estimating each chunk as we go along. That brings an associated uncertainty about when the project will be completed and what it will cost. Our foundational data and analytical estimation process serve as the basis for a balanced discussion about reality; whether we all like that reality is an entirely separate matter.

Data is your ally. A manager once pushed back on an estimate I presented. I explained how I generated the estimate based on our records from previous projects and why I thought her assumption of greatly increased productivity wasn’t realistic. I asked about her basis for assuming that this project would suddenly go faster and more smoothly than the projects we’d worked on previously. She didn’t have a good explanation. It was more a matter of hopeful aspiration than realistic expectation. Hope is not a strategy.

Principled Negotiation

Anytime there’s a gap between a stakeholder’s expectations—or demands—and your prediction of the future in the form of an estimate, you’ll need to negotiate. Principled negotiation is a method to arrive at mutually acceptable agreements (Fisher, Ury, and Patton, 2011). Principled negotiation involves four precepts:

• Separate the people from the problem. If the discussion comes down to a personal struggle between you and someone with more organizational power, you’ll lose unless you can build a compelling case to sway their position.

• Focus on interests, not positions. Don’t dig in your heels and defend your estimate to the death. Instead, seek first to understand the other party’s interests—a more empathetic approach. What are their goals, needs, concerns, pressures, and constraints? Perhaps there’s a way to satisfy both their interests and yours is by modifying the problem statement or the proposed solution.

• Invent options for mutual gain. If you’re being pressured to make a promise you know the team can’t fulfill, look for alternative mutually acceptable outcomes with feasible objectives to which you can commit. See if there’s some way to meet in the middle. Neither party gets everything they want in most successful negotiations, but both can live with the outcome—a compromise.

• Insist on using objective criteria. Here’s where your data comes in. Facts and analysis are stronger persuaders than opinions, arguments, and anecdotes. Use your data to build the case to support your estimates, and respect the data your negotiating counterpart presents.

No one can predict the future accurately. The best you can do is extrapolate from previous experience, make adjustments where warranted, and acknowledge the uncertainties. Let your data do the talking, and invite those with whom you’re negotiating to share theirs. There’s a possible meeting of the minds and acceptable outcome in there somewhere.

Lesson #27. Unless you record estimates and compare them to what actually happened, you’ll forever be guessing, not estimating.

When you face a new piece of work, someone wants to know how long it’s going to take. That person might be a customer, manager, teammate, or yourself. Unless the work is an exact duplicate of something you’ve done before, you need to estimate based on previous analogous experience. Memories are faulty, though. Even if you remember how long some earlier activity took, you probably don’t remember how long you thought it was going to take. To create reasonably accurate estimates, you need data, not vague recollections. Data constitutes a set of facts we can analyze to understand, predict, and improve.

Someone once asked me, “If we should base our estimates on historical data, where do we get historical data?” The simplest answer is that if you record what you did today, that becomes historical data tomorrow. Individuals, teams, and organizations should get in the habit of recording their estimates and keeping records of actual outcomes. This is the only way to get better at estimating upcoming activities.

If there’s a big discrepancy between a forecast and the ultimate reality, explore why and consider how you could create more realistic estimates for similar work in the future. Did you have to perform more tasks than you expected? Did they take longer than you thought? Were your productivity assumptions overly generous? Did unexpected factors impede the work? As you accumulate data over time, you can calculate some averages to help you generate more meaningful estimates for future work. Without the data, you’re just making guesses.

Multiple Sources of Historical Data

There are four potential sources of historical data. First is your personal experience. Individual performance varies significantly depending on the skills and experience of the person who performs the work. I’ve been self-employed in a one-person consulting and training company for more than twenty years. Knowing how long it takes another consultant to, say, develop a training course doesn’t help me predict how long it would take me to do something similar. I must rely on my personal history, so I keep records of my plans, estimates, and actual task durations for work that I might encounter again.

Some years ago, I decided to create eLearning versions of six of my training courses. Having never done anything like that previously, I had no idea how long it might take. I created a task list with all the steps I could think of. As it was a novel experience and I faced several learning curves, I had overlooked some tasks, so I added those to my planning list for subsequent projects. I recorded how long it took me to perform each item on the first course I developed.

From that data, I estimated how long the next course would take. I adjusted the estimate based on the learning curves I had now mastered, new tasks I had discovered, and differences between the two courses. After completing that second course, I compared my estimates to how long each step actually took so I could derive better estimates for the remaining courses. Having that data helped me prepare a decent estimate when a client hired me later to develop customized eLearning courseware on a fixed price contract.

I find planning worksheets helpful for thinking of all the work I might have to perform for a particular project and how long each activity might take. They remind me of tasks that I might otherwise overlook. For instance, people often forget to plan time for performing rework following quality control activities like testing and peer review. However, some rework is virtually always needed. I include rework tasks in my estimates, even if I don’t know exactly how much time it might take in a particular situation.

Three other historical data sources are your current project, your organization’s collective experience, and industry averages for projects similar to yours. The most meaningful data comes from recently completed portions of your current project. That reflects the influences of the current team, environment, culture, process, and tools on performance. Agile projects are well suited for this data collection. The most accurate forecasts of future performance are based on the average velocity from recent iterations, assuming that the team’s composition and the nature and quality of the delivered work remain constant.

Data from previously completed projects in your organization and industry averages are less reliable predictors of your future, as the variations across projects, teams, and organizations increase the uncertainties. Nonetheless, relying on this kind of historical data is still better than estimating based solely on memory or guesswork.

Software Metrics

What’s past may be prologue, but memories are fallible and perceptions are subjective. If you want to understand what happened on previous projects and make more meaningful plans, you need to collect some metrics. People can measure various aspects of software projects at three levels: individual contributor, project team, and development organization. Measurements in the categories of size, effort, time, and quality can provide a lot of insight into your project work (Wiegers, 2007).

• Size. Choose some measure of size—the quantity of work—that’s meaningful for the kind of work you’re doing. Possibilities include requirements, function points, user stories, story points, classes, and—more dubiously—source lines of code. For my eLearning courses, I counted the numbers of course modules and slides.

• Effort. Track the labor hours of effort needed to create each deliverable or complete each piece of work. Combining size with effort lets you calculate your productivity.

• Time. Record the estimated and actual durations of work done in units of calendar time. Numerous factors influence how work effort translates into calendar time, as we saw in Lesson #23, “Work plans must account for friction.”

• Quality. Counting defects found by various means shows which quality practices work best to find errors and where the quality improvement opportunities lie. Recording the time spent on rework to correct defects also helps with planning. If you know where the faulty work originated—a specific iteration, requirement, or activity—you’ll have a clearer idea of where to focus extra quality effort in the future.

In his book Software Estimation (2006), Steve McConnell points out numerous issues associated with measures in each of these categories. McConnell stresses the importance of clearly defining each metric you collect so people can record data in consistent ways. Unless you’re benchmarking against an external reference, internal measurement consistency is more important than absolute truth. For instance, all team members should track their effort and count defects in the same way. Suppose that some team members include debugging and rework effort as part of development, others lump it in with testing, and still others don’t record it at all. That variability doesn’t yield meaningful data for predicting the future.

The idea of software metrics makes some people nervous. Software measurement is indeed a delicate area with many potential pitfalls (Wiegers, 2007). The golden rule of metrics is to use data to understand what’s happened and improve results, not to punish or reward anyone. People are also concerned about how much time it takes to collect and analyze the data, but I’ve found that recording some basic information about project activities requires little effort. It’s a habit you get into as just part of your work process.

It’s impossible to reconstruct data accurately long after the work was done. Therefore, establish mechanisms to collect and store data as you go along. A retrospective at the end of a development cycle offers a good opportunity to aggregate data to evaluate the past and plan the future. If you invest a little time writing down what happened today, then tomorrow you’ll have historical data to help you estimate the next piece of work.

Lesson #28. Don’t change an estimate based on what the recipient wants to hear.

Suppose your customer asks how long it will take you to complete the next portion of your project. Based on your analysis of the work, you reply, “About two months.”

“Two months?” sneers the customer. “My twelve-year-old daughter could do that job in three weeks!” You resist the temptation to suggest he hire his daughter then.

You try again. “Okay, how about one month?”

Now, what changed in those few seconds? The task didn’t get any smaller. You didn’t instantly become more productive. Nobody else suddenly appeared to help with the work. The customer just didn’t like your first answer, so you offered an alternative that might go over better. If your estimate and the requester’s expectation are too far apart, you’ll need to negotiate to reach some agreement. However, there’s no justification for altering your thoughtfully crafted estimate just because someone wasn’t pleased with it (Wiegers, 2006b).

An estimate is a prediction of the future. We base estimates on what we know about the problem at the time, our previous experiences with similar work, and the assumptions we make. If we’re thorough, we’ll also consider any dependencies on factors outside our control, possible risks, potential changes in the problem statement, and uncertainties that could affect our plans. The less we know about all these factors, the less likely it is that the estimate will match the ultimate reality. Someone else whose thought process involves different parameters could generate quite a different estimate for the same work.

Goals versus Estimates

It’s important to distinguish an estimate from a goal. I once observed a discussion between a senior manager and a developer regarding a new project. The developer’s expectation for the project’s duration was four times longer than the manager’s expectation. The developer simply agreed to the manager’s demand for the much shorter schedule, which had zero probability of being achieved (and wasn’t).

A more rational approach would have been for the developer to say, “Here’s how I came up with my estimate. How did you come up with yours?” In this case, though, the manager didn’t have an estimate; he had a goal. The developer didn’t have an estimate, either; he had a guess. The goal and the guess were miles apart. Had either of the two parties developed a true estimate, they might have been closer together. Instead, it became an adversarial debate, with the individual who had more power gaining a lip-service commitment from the other one.

When to Adjust

Your estimate should be independent of what you think the requester wants to hear. Having said that, there are times when it does make sense to change an estimate or—stated more properly—to reestimate, including these:

• If you discover that an assumption or piece of information was wrong.

• Once you get into the work and understand the task better.

• When the scope of the work changes.

• If you find that you’re making progress faster than you expected (it happens).

• When conditions change, such as the people working on the project.

• When a risk materializes or a dependency fails.

Unless some change like this takes place, it’s not appropriate to alter your prediction of the future.

If your estimate doesn’t align with someone else’s goals, expectations, or constraints, the parties should collaboratively investigate the gap. It doesn’t help anyone to bury the conflict unresolved. You can question assumptions, discuss risks, and try alternative estimation methods to validate—or reject—the estimate. Perhaps the historical data that you relied on wasn’t an appropriate model for estimating the work under consideration. You can negotiate scope, resources, or quality to see if there’s a knob to turn to reach a more acceptable estimate. But if you’ve prepared an estimate analytically, don’t cave just to make someone else smile. They won’t trust your future estimates, because they know they can override them.

Lesson #29. Stay off the critical path.

Identifying the many tasks that must be performed is the core of project planning. Many of those tasks must be carried out in a particular sequence, and some tasks are linked to others, so the planner must also identify timing dependencies between tasks. It gets complicated.

Critical Path Defined

Project planners often draw an activity network diagram to show these timing relationships between tasks. Figure 4.3 shows an activity network diagram for a project with just six tasks, labeled A through F. The estimated duration is shown for each task. Actual activity network diagrams include a lot more information, such as the earliest and latest start and finish dates for each task. For simplicity, let’s assume that no task can begin until all of its predecessor tasks are completed. That is, Task F can’t begin until Tasks A, D, and E are finished.

If you add up the estimated durations of the tasks in the various pathways that lead from start to end, you’ll see that path E-F is the longest, at 5 + 4 = 9 days (heavy arrows). That task sequence is the critical path. It defines the shortest estimated duration needed to complete the project (Cohen, 2018). If any task on the critical path overruns its schedule, the project’s overall completion date gets pushed out by the duration of that delay. New tasks that are added to the critical path will similarly delay project completion.

Tasks that don’t lie on the critical path have some slack (also called float) time. They can run long without delaying the overall project—up to a point. For instance, tasks A and D combined have one day of slack: 2 + 2 = 4 days, which is one day shorter than task E that’s on the critical path.

The critical path can change, though. Suppose task A consumes 4 days, double the original estimate. The critical path now would become A-D-F at 10 days (4 + 2 + 4), thereby pushing the project to a 1-day overrun of the 9-day E-F path.

Added tasks that aren’t on the critical path will consume resources but won’t delay the project’s completion, provided there’s enough slack to accommodate them. However, if those resources were otherwise going to be working on critical-path tasks that now will be delayed, then those additional tasks could indeed extend the critical path’s duration.

Tasks on the critical path have no slack time. If you want to shorten a project, you need to find ways to accelerate the critical-path tasks, perhaps by performing some of them in parallel. Astute project managers will keep a close eye on the critical path and try to ensure that those tasks complete on time or early.

Staying Out of the Way

My philosophy is to keep my work off the project’s critical path as much as possible. I don’t want to be the bottleneck who’s holding up someone else’s progress. I prioritize my daily work by considering the two dimensions of importance and urgency (Covey, 2020). A task that lies on the critical path is more urgent than one that does not. If a task could force other people to wait until I complete it before they can continue with their part of the work, that task jumps to the front of my priority queue. I strive to avoid being the cause of dead time and wait states that could impede the whole project.

I apply this thinking when writing books. The process of conceiving, planning, proposing, writing, reviewing, editing, and publishing a book is about a year-long project with many activities, particularly if more than one author is involved. Much of the work can be done in parallel or in an arbitrary sequence. Sometimes, though, one participant must complete a particular activity before someone else can take their next step. For example, I can’t finalize a manuscript chapter until all of my beta readers (peer reviewers) have returned their comments. Unless I built in some slack time—which I do—to stay on schedule, I must ignore late-arriving review input, thereby wasting the reviewer’s time and possibly reducing the book’s quality.

To get off the critical path quickly, when the publisher sends me the typeset pages for final proofreading, I drop everything else and start reading. The publisher can’t make corrections or finalize the index until they receive my review feedback. Delays in proofreading could potentially delay publication, depending on how much slack time we included in the schedule and whether I’m ahead of plan overall.

Frequent communication is essential to staying on a schedule. Sometimes, two parties are waiting for the other to respond because of confusion over whose turn it is. You don’t get an answer to an emailed question, so you call, text, or email the other person again: “Did you understand my request in the email I sent you three days ago? Or did you already reply, and either I didn’t get your email or I overlooked it?” One person is holding up the other one unnecessarily. There are many ways a project can slip when people are juggling multiple activities that they must finish in a particular sequence.

I always feel good when I promptly complete an activity that I know could otherwise slow down someone else and perhaps the entire project. I leap off that critical path as quickly as I can.

Lesson #30. A task is either entirely done or it is not done: no partial credit.

“Hey, Phil, how are you coming on implementing that subsystem?”

“Pretty good. I’m about 90 percent done.”

“Wait—weren’t you 90 percent done a couple of weeks ago?”

“Yes, but now I’m really 90 percent done!”

The notion that software projects and tasks are reported to be 90 percent done for a long time is something of an industry joke (Wiegers, 2019b). (A related joke states that the first half of a software project consumes 90 percent of the resources; the second half consumes the other 90 percent of the resources.) This optimistic but misleading status tracking makes it difficult to judge when you’ll truly complete a body of work. We all need to resist the temptation to cross items off our to-do task list until they’re entirely finished. If you tell yourself or someone else, “I’m all done except…,” you’re not done.

What Does “Done” Mean?

A fundamental question is what exactly we mean when we say some piece of work is done. You might have finished all the tasks you initially thought were needed, only to discover that the job involves more work than you realized. This sometimes happens when implementing a change in an existing system, as you keep encountering additional components to modify. We often don’t think of all the necessary activities when we plan some chunk of work. The larger the chunk, the more likely we are to overlook some tasks.

The agile community has tackled this question head-on by incorporating the definition of done, or DoD, into activity planning (Agile Alliance, 2021a; Datt, 2020b). Early in the project, the team should itemize the criteria they’ll use to determine whether they’ve completed a specific backlog item, task, or iteration. Checklists are helpful to specify the minimum work that must be completed to consider a particular task or product increment to be finished. Certain individual items might have additional completion criteria.

The definition of done provides objective criteria for judging how a project or iteration is progressing toward successful completion. Done means entirely done, such as an increment of software that has been fully coded, tested, integrated into the product, and documented and hence is potentially releasable to customers. Individual units of work, such as implementing user stories, are either 100 percent done or they’re not done; there’s nothing in between (Gray, 2020).

I often create planning worksheets that itemize the steps involved when I perform recurrent activities. These worksheets reduce the chance that I’ll overlook anything and help me estimate how much time to plan for each instance of the activity. The worksheets also let me track progress. Figure 4.4 shows a portion of such a worksheet for converting my PowerPoint training courses into eLearning courses, as I described in Lesson #27. I use the Status column to track the tasks I’ve started, those I’ve completed, and those I’ve not yet begun.

The tasks in the list vary considerably in size. Establish pricing (task 12) takes just a few minutes; recording the audio scripts for all the course modules (task 5) will consume many hours. My courses vary considerably in size, from just four modules up to eighteen. I wanted finer granularity than the form in Figure 4.4 provides for tracking both status and the time I spent on tasks. Therefore, I created a spreadsheet to monitor how I’m coming on each of the activities needed to implement each course module. But the only status values I use are: not yet started, underway, and done.

No Partial Credit

One problem when assessing doneness is that we give ourselves too much partial credit for tasks that we’ve begun but haven’t completed, which can make us feel happy and overly optimistic. You might contemplate the algorithm for a complex module one morning and conclude that you’re about 30 percent done because the algorithm was the hard part. Maybe it was, but writing the code, reviewing it, testing it, and integrating it with other work could still consume a lot of time. It’s difficult to assess the percent completion of a large task accurately. It might be larger than first thought, unidentified activities could remain to be discovered, and we’re not sure how the remaining work will go.

The first step to address this doneness problem is to break large tasks (milestones) into multiple small tasks, whimsically called inch-pebbles (Page-Jones, 1988; Rothman, 1999). Each inch-pebble might range up to four to six labor hours. This size permits good insight into everything you’ll need to do to complete the task. A useful heuristic is to identify inch-pebbles that can’t be subdivided logically into smaller parts. If you have previous experience performing an activity, you can probably estimate it accurately at a milestone level of granularity. For less familiar, more uncertain, or more complex activities, the finer granularity of inch-pebbles will be more illuminating.

Monitor your progress on these granular inch-pebbles in a binary fashion: done or not. You get no partial credit for incomplete tasks. None. Zero. Progress on a large task is then determined by what fraction of the inch-pebbles for that big task are entirely completed. This tracking is more insightful than trying to guess what percentage of a large and perhaps vaguely defined body of work is finished (Rothman, 2004).

By “large task,” I mean some unit of work that delivers value to a customer. With my eLearning project, the ultimate goal was to have a completed course that I could sell. Decomposing that large task into the myriad smaller activities involved, as we saw in Figure 4.4, provided visibility into how I was approaching my final goal. Within that major target were multiple course modules, each with its own set of subtasks. Rather than estimating percent completion of the entire project or individual subtasks, I used binary done/not done tracking at the lowest granularity level.

Some project tracking tools include a control that lets you indicate what percentage of a task is complete. Figure 4.5 shows a sample Gantt chart view with a few project tasks. The gray bars labeled Task 1 through Task 4 in the aggregate make up the large objective called “Create a Module.” The control to which I’m referring appears as the narrow black bars within the gray taskbars. They indicate how much of each task has been completed. I advise against using those partial-completion indicators. They can mislead you into thinking that you’re farther along than you really are. I find that the approach of tallying smallish inch-pebbles indicates progress more meaningfully.

Tracking by Requirements Status

Another option for monitoring project progress is tracking requirements status rather than estimating the fractional completion of each requirement’s implementation (Wiegers and Beatty, 2013). Each requirement—be it a functional requirement, use case flow, user story, feature, or subfeature—that’s allocated to a body of work has a specific status at a given time. Possible status values include proposed, approved, implemented, verified, deferred, and deleted. In this approach, a planned body of work is complete when the status of each requirement allocated to it has one of three statuses:

• Verified (the requirement is fully implemented and tested)

• Deferred (the requirement was delayed for later implementation)

• Deleted (the requirement is no longer planned for implementation at all)

Doneness Leads to Value

The point of project tracking is not simply to make sure you’ve done all of the planned work. It’s to complete chunks of work that will provide value to customers when they’re delivered. The best way to gain visibility in your progress toward that value is to flip a task’s status to done only when it’s truly finished.

Lesson #31. The project team needs flexibility around at least one of the five dimensions of scope, schedule, budget, staff, and quality.

“What do you want: good, fast, or cheap? Pick two.” This colloquial notion of a triple constraint or iron triangle appears throughout the project management literature. I’ve seen several representations of the triangle with different parameters on the triangle’s vertices or edges and various assumptions about what’s being held constant. In my view, the traditional iron triangle is overly simplistic, although the concept of constraints and trade-offs is certainly valid (Wiegers, 2019c).

Five Project Dimensions

I think in terms of five dimensions that a project team must manage, as illustrated in Figure 4.6 (Wiegers, 1996). First, there’s the scope (or features), which describes the product’s functional capabilities. But it’s important to separate quality from scope. I can write software very fast if it doesn’t have to work correctly. So unlike the traditional iron triangle, I show quality as a distinct dimension. The other three dimensions are the time needed to deliver (schedule), the budget, and the staff available to work on the project. Some people add risk as a sixth dimension, but risk is less of an adjustable parameter than the other five.

People often combine staff and budget as “resources.” I prefer to separate them. Most of the project cost is indeed staff salaries. Sometimes, though, a team has adequate funding but is constrained by a headcount limit. In that case, perhaps the project manager can use the budget to buy a package solution, license some software components, outsource part of the work, or bring on contractors.

Each project must decide which dimensions are most critical and balance the others to achieve the essential project objectives. The trade-offs among these five dimensions are not simple or linear. For example, if you add staff, the cost could well increase, and the schedule might be shortened—although not necessarily (Brooks, 1995). A common trade-off is to shorten the schedule or add features at the expense of quality. Anyone who’s been victimized by buggy software questions such trade-off decisions, but development organizations do make that choice—sometimes deliberately, sometimes by default.

Each dimension can take one of three properties on a project:

• A constraint

• A driver

• A degree of freedom

Constraints define restrictions within which the project must operate. The project has no flexibility around a constrained dimension. If a team of immutably fixed size is available for a project, then staff is constrained. Cost is a constraint on a project being done under a fixed-price contract, at least from the client’s perspective. Quality will be a constraint for a project that develops a safety- or life-critical product. Projects tied to fixed-date contracts or events—think Y2K, elections, Brexit—are schedule-constrained.

A driver is a key objective or success criterion for the project. For a product with a desired marketing window of opportunity, schedule is a driver. Commercial desktop applications often have features as a driver for competitive purposes. The drivers provide a little flexibility around some dimensions. A specified feature set might be the primary driver of the project, but scope is a constraint if the features aren’t negotiable at all.

Any project dimension that is neither a driver nor a constraint is a degree of freedom. The project manager can adjust degrees of freedom within certain bounds. The challenge is to adjust the degrees of freedom to achieve the project’s success drivers within the limits that the constraints impose. For instance, projects following agile methods treat scope as a degree of freedom, adjusting the scope of what each iteration delivers to fit within the constraint of their iteration schedule.

I have bad news: a project with zero degrees of freedom is likely to fail. All five dimensions can’t be constraints, and they can’t all be drivers. An added feature, a team member who becomes ill, a risk that becomes a problem, an estimate that’s too low—all will trash the schedule because the overconstrained project manager has no flexibility to respond to those events.

A student in a project management class I taught told me, “Our project has a fixed budget, we can’t get more people, all the features are critical, there can’t be any defects, and we have to finish on time.” I wasn’t optimistic about that super-constrained project’s chances of success.

Negotiating Priorities

A significant aspect of this model is that the team, customers, and management should agree upon the dimensions’ relative priorities at the project’s outset. For instance, schedule is often presented as a constraint when it’s actually a driver. The way to tell the difference is to ask a question like, “I understand that you want this delivered by June 30. What happens if it’s not done until the end of July?” If the answer is to forget the whole thing because it won’t be useful to us or we’ll be socked with contractual penalties, then schedule truly is a constraint. But if the answer is, “Well, we’d like it by June 30, but we can live with July 31 if we have to,” then schedule is a driver.

The Flexibility Diagram

A Kiviat diagram—also called a radar chart, star chart, or spider chart—provides a visual way to depict the amount of flexibility for all five dimensions; Figure 4.7 shows an example. Readily generated in Microsoft Excel, a Kiviat diagram has multiple axes radiating from a common origin point. All the axes are the same length and normalized to the same scale. In this case, each axis represents how much flexibility the project manager has in the corresponding dimension, so I call these pictures flexibility diagrams (Wiegers, 1996).

I use a relative scale from zero to ten to indicate flexibility. Plotting a point at zero—the origin—indicates that the dimension for that axis is a constraint with no flexibility. A point fairly low on the axis, between zero and about two, represents a driver. The project has a small amount of flexibility in that dimension. Any dimension plotted at a higher value on its axis represents a degree of freedom that offers more latitude for adjustment. Connecting the plotted points for the five dimensions outlines an irregularly shaped pentagon. Different types of projects will lead to flexibility diagrams having distinct shapes.

Figure 4.7 shows the flexibility diagram for a reusable software component my team once developed. The schedule was constrained because this component had to be delivered before several other applications being developed concurrently could use it. Therefore, the schedule dimension had zero flexibility. The component’s reliability and correctness were very important, so quality was an important success driver. I’ve plotted quality with a flexibility value of two in the figure. We needed to deliver a core set of capabilities initially but could grow the functionality over time. Hence, the project scope has a flexibility of four. We had considerable latitude regarding budget and staff: it had to get done on time. Therefore, the values for these degrees of freedom are plotted high on their respective axes.

The flexibility diagram is not a high-resolution or quantitative tool. The pentagon’s shape visually indicates the project’s important aspects, but don’t calculate the area of the pentagon or anything like that. However, the pentagon’s size does provide a rough indication of how much flexibility the project manager has to work with. A small pentagon means that you have multiple constraints and drivers, making it more challenging to steer a path to success.

Applying the Five Dimensions

This five-dimensional analysis can help a project manager decide how best to respond to changing project conditions or realities to meet a project’s prime objectives. Suppose staff is a constraint. If new requirements must be included, the only parameters that can potentially change are scope, quality, cost, or schedule. Nothing is free. The flexibility diagram can facilitate a discussion to decide how to proceed. Can some other features be cut or deferred? Can we add a development iteration and extend the schedule to accommodate the new functionality? Must the product work perfectly on Day 1? Contemplating these five dimensions is a more rational way to understand your project priorities than assuming that every aspect of the project is vital and nonnegotiable.

Lesson #32. If you don’t control your project’s risks, they will control you.

A company once engaged me to determine why a recent international contracting project had failed. As I studied their project records, I discovered that the team had maintained a list of project risks—a solid project management practice. However, their monthly status reports showed only the same two minor risks each time, with a minimal estimated threat from each of them. Since the project failed, some additional risks apparently sneaked up and attacked it when no one was looking. The project managers failed to consider some common risks on complex, distributed projects: slow decision-making, communication issues, scope changes, requirements ambiguity, overoptimistic commitments, and so forth. We can take several messages from this experience:

• If you’ve identified just two risks for a multimillion-dollar project, you haven’t looked closely enough.

• If you underestimate the potential threat a risk could pose, you might not pay enough attention to it.

• If the same items remain on your list of top risks month after month, either you’re not actively managing them or your mitigation efforts aren’t working.

What Is Risk Management?

A risk is a condition or event that has the possibility of harming your project (Wiegers, 1998a). It’s a potential problem that hasn’t happened yet. The goal of risk management is to ensure that the project will succeed despite the potential negative consequences of the risks it faces. Risk management is an essential component of effective project management. It’s been said that project management is risk management, particularly for large-scale projects (Charette, 1996). Put more whimsically, risk management is project management for adults (DeMarco and Lister, 2003).

Risk management involves identifying scary conditions and events, assessing their possible impact on the project if they were to materialize into problems, prioritizing them, and trying to control them. Formal risk management focuses your energy on the greatest looming threats. There’s no point in worrying about something that couldn’t do much harm even if it happened. No one can predict the future, but you don’t want to be blindsided by something that you perhaps could have seen coming and evaded.

Identifying Software Risks

An amazing number of things can go wrong on a software project. Each project should devote both early and ongoing effort to confronting its fear factors. If risk management isn’t someone’s responsibility, it won’t happen. Large projects often appoint a risk officer who has the lead responsibility for coordinating risk-related activities. Following are several techniques for identifying potential risks to your project.

Brainstorming

Group sessions let all team members participate in risk identification. They’ll all bring different perspectives and experiences to the table and have complementary thoughts about concerns that keep them up at night. A good place to start is to examine any assumptions the team is making, including those that feed into estimates, as tenuous assumptions might contain risk.

I’ve found that many of the proposed risks that come out of such sessions actually state a current project reality. Those aren’t risks: they’re problems. You need to deal with existing problems more energetically than potential problems.

Published Compilations

Another strategy is to start with an extensive list of risks drawn from software books. Books by Capers Jones (1994) and Steve McConnell (1996) include lengthy lists of software risks that are largely as relevant today as when the books were published. Various project risk lists can also be found online, such as one from Bright Hub PM (2009).

Reviewing a long catalog of potential risks is a little frightening, like reading all the potential side effects of some medication. Not all items will apply to your project, but the lists can alert you to possibilities you wouldn’t have imagined had you started from scratch. Software risks are grouped into categories such as these:

• Requirements and scope

• Design and implementation

• Organization and personnel

• Management and planning

• Customer

• Outsourcing and contractors

• Development environment and process

• Technology

• Legal and regulatory

Local History

A third risk identification strategy is to examine accumulated information from your organization’s previous projects. These risks will be more relevant than those in a generic risk list. Project retrospectives are opportunities to collect and record both good and bad project experiences. Project events that surprised the team often reflect risks that they didn’t anticipate. It’s tempting to conclude that some unpleasant event was a one-off, but add it to the master list anyway so future projects can consider whether it is a concern for them.

Your organization’s risk collection also should include information about mitigation strategies that previous teams had tried for specific risks and how well they worked. Future projects will benefit from relying on previous experience to assess their risks quickly and decide how to control them. Studying previous experience is a way to avoid having to climb every painful learning curve on every project.

Risk Management Activities

Risk management is not a one-time project action, something you do at the beginning of the project and then set aside. Figure 4-8 shows a flowchart of the various activities involved.

Identify Risks. Sift through the software risk compilations you have available and note any that could pertain to your project. Risk lists generally state a condition that might pose a problem, such as “Inadequate reporting requirements from internal regulators.” Yeah? So what? I like to write risk statements in the form of the condition followed by a possible consequence: “Inadequate reporting requirements from internal regulators could lead to audit failure post-deployment.”

Writing risks in this pattern might reveal that a single condition could give rise to multiple consequences, thereby making that a high-leverage condition to control. Alternatively, the same consequence could result from multiple risk conditions. In that case, it might be hard to avoid the consequence entirely, so consider developing a contingency plan to deal with the consequence if it becomes necessary.

Assess Risks and Prioritize. Once you’ve built a list of conditions and their possible consequences, think about how much damage each one could do to your project. Risk assessment considers two factors:

1. What’s the probability of the risk becoming an actual problem? Some risks are unlikely to materialize, but others pose a clear and present danger.

6. How much impact could the problem have on the project if it did materialize? Some impacts are too minor to worry about; others could be devastating.

I like to estimate probability on a scale from 0 to 1 and impact on a relative scale from 0 to 10. Multiplying the probability by the impact yields an estimate of the exposure from each risk item.

After estimating the risk exposures, sort your list by descending exposure to float the highest-threat items to the top. That prioritization step will focus your attention where it’s needed most. Start your risk control planning at the top of the prioritized list and work your way down. Savvy project managers keep their top-10 (or so) risk list front and center for continuous monitoring.

Select Strategy. You have four choices of how to respond to each risk. The first option is simply to absorb the risk. Yes, it could happen, and it could have some negative impact, but you decide not to take any action—you’ll just wait and see what happens. Sometimes you have no choice. If you identified a potential change in a government regulation as a risk, for instance, you can’t do anything about that. If you must absorb a risk, consider devising a contingency plan, just in case.

A second strategy is to avoid the risk entirely by changing direction, such as choosing different technologies or business partners that pose less danger. As a third possibility, perhaps you can transfer the risk to some other party, so it’s no longer your concern. Most frequently, though, you’ll need to go with option four: try to mitigate the risk to reduce your exposure.

Plan Mitigation Actions. Mitigation planning involves selecting actions to reduce the likelihood of the risk becoming a problem or to reduce the impact if it does. Mitigation actions become project tasks; someone must own each one. Also, try to identify any triggering conditions or events that would alert you to the risk becoming a looming threat, not just a possibility.

Perform Mitigation Actions. Even great plans are useless unless they’re executed. Monitor implementation of the mitigation actions just as you would any other project task to ensure that they’re carried out as intended.

Reassess Risk Exposure. If your mitigation actions are successful, the exposure from those risk factors should decrease. (If they aren’t successful, try something different.) As Figure 4.8 indicates, risk management is a cycle, not a sequence of one-time activities. A good practice is to reevaluate your top-10 risk list weekly (McConnell, 1996). The risks you’re actively addressing should drift down your prioritized risk list as their estimated risk exposure decreases. Monitor items farther down the list to see if their status has changed. Risks can drop off the list entirely if their window of opportunity for doing damage has passed. Alternatively, project conditions might change such that a risk that initially wasn’t too threatening becomes either more likely or more impactful. New risks can pop up at any time, so everyone on the project should keep their eyes open.

There’s Always Something to Worry About

The risks are out there whether you choose to look for them or not. Failing to manage your risks is tantamount to accepting them and absorbing the consequences. My preference is to confront project threats early and often. It comforts me to see the active risk list dwindle as the team’s mitigation actions succeed.

Alternatively, you could ignore the risks and just hope nothing surprising and unpleasant happens. Good luck with that.

Lesson #33. The customer is not always right.

It’s fashionable in our society to say, “The customer’s always right.” This statement implies that if a customer asks for something, you’re obligated to deliver. You may have seen a sign at a business that said, “We have only two rules. Rule #1: The customer is always right. Rule #2: If the customer is wrong, see Rule #1.”

The reality, of course, is that the customer is not always right. Sometimes the customer is misinformed, unreasonable, confused, in a bad mood, or didn’t do their part. I prefer to say that the customer is not always right, but the customer always has a point, and we need to understand and respect that point. That’s not the same thing as always doing what any customer says they want.

Being “Not Right”

I remember being irritated at the interminable road construction going on near my house. I had to pass through a torn-up intersection every day for months. “Why is it taking so long to finish this road?” I would think every time I drove by it. Then I realized an important fact: I don’t know anything about road construction! I had no basis for assessing how long it ought to take to rebuild that intersection. It was annoying, but it wasn’t reasonable for me to demand that it be finished earlier if that wasn’t realistically achievable. I could be a dissatisfied “customer” of the new road, but that didn’t mean my expectations were right. Let’s see some examples of how a software customer might not always be right.

Conflicting Requests

Suppose two customers demand conflicting solutions to a problem, such as different ideas regarding how some part of a system should function. They clearly can’t both be right. Nevertheless, some thought process on each of their parts led to their respective requests. We must understand the rationale behind the requests to assess which one is more closely aligned with achieving the project’s business objectives. That’s the requirement we should address.

Solutions versus Needs

During an elicitation discussion, a customer representative might present not their requirements but rather some proposed solutions. A skilled BA can detect when a stated need is actually a solution idea and ask questions to reveal the underlying problem. Sometimes the customers don’t fully grasp the point of this dialogue. Their reaction might be, “I told you what I need. Haven’t you heard that the customer’s always right? Call me when you’re done.” This attitude doesn’t reflect a nicely collaborative approach to solving a problem.

A Surrogate Representative

A customer might offer to provide requirements on behalf of some user class to which they do not belong. This happened to me when I was the lead BA on a project. Our two most important user classes were a large community of chemists and a few people who worked in the chemical stockroom. The woman who managed the chemical stockroom said, “I was a lab chemist until a few years ago. I can tell you all of the chemists’ requirements for this system.” Unfortunately, she was wrong. Her understanding of what today’s chemists expected from the system was out of date and incomplete. It would have been a mistake for us to rely solely on her input. Instead, we found several actual chemists to help us understand their requirements, which worked out much better.

The same problem can occur if a manager in the user community wants to serve as the representative for requirements discussions. The manager might not know all the day-to-day details about how users perform their work. Perhaps the manager’s experience is obsolete. In either case, the manager can’t do as good a job of presenting user requirements as perhaps they think they can.

In Through the Back Door

Someone might try to bypass established processes to gain an advantage for themselves. I once asked a group at a consulting client site how requirement changes and enhancements got made on their system. An awkward silence ensued. The people in the group exchanged knowing glances. Someone finally said, “If the customer wants to make a change, they always tell Philippe or Debbie. They know Philippe and Debbie will work the change in, but the rest of us will give them a hard time about it.”

The company had a mechanism for evaluating change requests, but that customer tried to slip changes in through the back door instead of following the process. People definitely will try to bypass ineffective and unresponsive processes, and perhaps they should. In this case, though, the customer just didn’t want to bother going through the process and possibly have the decision makers reject their change request.

Jumping the Gun

My colleague Tanya, a skilled BA and software engineer, was hired by a company to specify the requirements for—and perhaps implement—a new information system to automate some of their activities. This was a brand-new, major transition. Tanya began by understanding and documenting the potential users’ current manual business processes. From there, she planned to develop a proper set of solution requirements. The users, who had been leery of switching to an automated system, were delighted with Tanya’s work and receptive to the project.

Unfortunately, the users’ manager took Tanya’s impressive binder of preliminary current-state work, erroneously claimed that the requirements had been completed, and decided to buy an existing software package that a friend of his just happened to sell. That new package was woefully inadequate and failed to meet the user needs. Had the manager waited until Tanya had specified the real solution requirements, he could have made a more appropriate build-or-buy decision that would have achieved the desired business objectives.

Positional Power

Customers sometimes demand that their requirements should get top priority because of their organizational status or other influential position over the project. (See Lesson #15, “Avoid decibel prioritization when deciding which features to include.”) Those demands can be a problem if people request functionality that won’t be used frequently enough to justify putting it ahead of other capabilities. Just because certain individuals have power doesn’t mean they’re right.

That said, high-level people who have far more visibility into the company’s strategic plans than the development team has could legitimately prioritize requirements in a way that might not seem logical to the team. It’s worth understanding the reasoning behind their request to align everyone toward the proper business objectives.

Change Isn’t Free

A common example of the customer not always being right is when they ask for new functionality or other changes but expect the price and delivery date to stay the same. Their attitude seems to be, “Change is free; just do it.” It sounds like a Dilbert comic, but it happens in real life.

Respecting the Point

We’re all customers in our daily lives. We buy products from stores and services from assorted providers. We aren’t always right, even though we’d like to think we are. I might see my doctor, convinced from an Internet search about my diagnosis of some medical symptoms, only to learn that I’m completely wrong. One time I took my car to a service shop to get the brakes replaced. When I went to pick up the car, the mechanic told me the brakes didn’t need replacement, just adjustment—no charge. In that instance, it was to my advantage to be wrong as the customer.

Remember, though: the customer always has a point. There’s a reason behind what they’re requesting—or demanding. As software providers, we can’t say we’re providing the best solution unless we respect the customer’s point, seek to understand it, and satisfy the request if it’s the right thing to do. When the customer’s wrong, we have to explain that with all due respect and resist the pressure to do something inappropriate just because some customer demanded it.

Lesson #34. We do too much pretending in software.

Because reality isn’t always the ideal they have in mind, people sometimes pretend that things are different from how they are. Pretending could involve alternative facts or even outright fabrication, but the pretending I’m talking about here is more a matter of self-delusion or unwarranted optimism. Sometimes it’s sticking one’s head in the sand and hoping reality isn’t still there. Other times, it’s wishful thinking.

Living in Fantasyland

As an example, we might pretend that we’ve identified all of the relevant project stakeholders. We imagine that they and we understand their objectives and that we’ve accumulated all the necessary requirements and other project information. There’s a chance that’s not correct, though. What if we didn’t conduct a thorough stakeholder analysis, starting with a long list of potential stakeholders and asking how many of them pertain to our project? What if we weren’t able to identify or work with people who can accurately communicate each group’s needs and constraints? Those situations could all cause problems

Even if we did interact with suitable stakeholders, we pretend—perhaps hope is a better word—that we got the right requirements and recorded them accurately so that others can work with them. Former US president Ronald Reagan adopted the Russian proverb “Trust, but verify” when negotiating arms treaties with the Soviet Union. That concept applies to software projects as well. We trust the people we work with, but we must also validate their information and verify that work done based on that information was performed correctly.

Software people sometimes do some pretending regarding project management. We pretend that we’ve thought of all the necessary work and that our estimates are accurate. It’s comforting to imagine that a project’s scope is well understood and won’t grow out of control, but that’s not always the case. We pretend that none of the risks or surprising events that clobbered our previous projects will be a problem this time. Maybe not, but we’re likely to encounter new disruptions, so we need to anticipate that possibility and consider how to respond. All project participants need honest, accurate information to keep the project on track. Managers should encourage their team members to deliver good news quickly—and bad news even sooner.

Irrational Exuberance

People who expect their next project to go faster and smoother than the last one might be confident that the team’s enhanced experience will pay big dividends. Or, they could just have great faith in the team. I’ve heard managers espouse the grand productivity increases their teams will reap from new tools and methods. However, they didn’t factor in the learning curve that will slow the team down for a while. Nor did they consider whether vendor marketing hype influenced their expectations. They just pretended the productivity miracle would happen.

We might pretend that we have top-flight talent on our team, although it’s not possible for every team to have 90th-percentile staff. Some companies genuinely have built software organizations populated with superb talent. That implies that more people from the lower part of the capability distribution are clustered in other places. I’ve seen a broad spectrum of organizational capabilities in my consulting work, with some standing out at both ends of the scale.

Another form of pretending is to imagine that team members can devote 100 percent of their time to project work and still find time to learn, innovate, and grow the team’s capability (Rothman, 2012). That doesn’t work at all. As we saw in Lesson #23, “Work plans must account for friction,” many factors erode the time spent on the job down to a reduced level of effective work time. A manager who pretends that full utilization of staff time on project work is feasible and desirable is denying reality. Not having time to learn, explore, and improve sentences the team to always work in the ways it always has. That’s a meager foundation for expecting better results the next time.

Games People Play

Teams and organizations sometimes claim they’re following a particular process or methodology either because they know they’re supposed to or because it sounds good in some context to say that they are. In reality, though, they’re doing something different. Maybe they conform to certain parts of the process but skip others that they find inconvenient, time-consuming, or hard to follow.

I consulted to a government agency that had an interesting pretending behavior. Their projects were funded on a biennial schedule, from July 1 of one year through June 30 two years later. They always completed their projects on schedule, by June 30. If the system wasn’t completely shippable by then, they’d deliver an incomplete and buggy version so they could still claim schedule success. Then they would pay for the completion and fixes in the next funding cycle. They pretended they never missed a delivery schedule in this way, but I don’t think the strategy fooled anyone.

Does any pretending go on in your organization? If so, what are the impacts? Is there anything you can do about it?

I’m not a big fan of pretending. Hoping that the world is different from how it really is can be comforting, but it’s not constructive. Sometimes I’m not that crazy about reality, but it’s all I’ve got. I must live with it. So must we all.

Next Steps: Project Management

2. Identify which of the lessons described in this chapter are relevant to your experiences with project management.

3. Can you think of any other project management-related lessons from your own experience that are worth sharing with your colleagues?

4. Identify any practices described in this chapter that might be solutions to the project management-related problems you identified in the First Steps at the beginning of the chapter. How could each practice improve the way your project teams plan and track their projects?

5. How could you tell if each practice from Step #3 was giving you the desired results? What would those results be worth to you?

6. Identify any barriers that might make it difficult to apply the practices from Step #3. How could you break down those barriers or enlist allies to help you implement the practices?

7. Put into place process descriptions, templates, guidance documents, and other aids to help future project teams apply your local project management best practices effectively.