DEFINING VALUE: A NEW LENS FOR JUDGING PROJECTS INFORMS THE DEVELOPMENT PROCESS

The most traditional definition of a successful project is one that meets the budget, the schedule, and delivers the product to specification. However, if the specification isn't right or the business context changes during the project, that product will miss the most important target: it won't be valuable to the stakeholders who paid for it or have to use it. The best project managers take responsibility for delivering business value, so it is worthwhile to add a new perspective for evaluating a project.

IDEO Framework: Viable, Feasible, and Desirable

IDEO is a design firm that has become famous for its contribution to innovation. IDEO consultants work with firms in every field to promote organizational cultures and practices that foster creativity and innovation. A signature concept is their triad of factors for evaluating potential solutions.¹

• Feasibility. The solution is technically feasible.
• Desirability. There is a market for this solution. People want it.
• Viability. The solution can be delivered within a sustainable business model.

This framework is startlingly easy to understand and can be applied to any project—even those that don't claim to be innovative. The IDEO variables don't conflict with traditional cost‐schedule‐scope metrics; they just look at them from a different perspective.

These three variables are particularly useful for evaluating potential projects. In fact, a project business case, as described in Chapter 5, should address each variable. We will reference these IDEO variables throughout this chapter.

What Is a Product Development Process?

A product development process describes the work to be performed at both a macro and micro level, laying out the overall flow as well as detailed activities. That includes specific techniques for determining the right product or service to build and the methods for ensuring it is developed correctly and efficiently.

It should be no surprise that a development process is specific to the nature of the work and the product or service being created. Table 4.1 is an example of the process for development and commercialization of a new pharmaceutical drug. Table 4.2 is an example of a product development process for capital projects that could apply to any college or corporate campus.

Comparing these two linear processes, we see some similarities:

• At each new phase there is a progression from uncertainty to certainty.
• Each step of the process is devoted to a particular aspect of development. In fact, the nature of the work within each phase can be substantially different and is typically devoted to solving a specific set of problems, isolating or removing some unknowns, making key decisions, and creating deliverables that may be used as inputs in later stages.
• A development process frequently includes phases and clear Go/No‐Go decision points between phases. These decision points, also called phase gates, serve two purposes: to evaluate the quality of the work completed in the phase and to reevaluate the business case, or value equation, based on the new information that was added during the phase.

There are also clear differences between the drug development and capital construction life cycles, because a development process reflects the unique challenges associated with the product.

• The new pharmaceutical product shows the enormous cost of research and development, as well as the high cost of ensuring the product is safe and effective. The three stages of trials that are dictated by the U.S. Food and Drug Administration also demonstrate how a development process can be standardized within an industry.
• In the capital construction life cycle, actual construction is only one phase, even though that phase contains the majority of the expense. Capital construction invests heavily in design. The cost of revising a design during the design phase is minimal compared to the cost of rework once actual construction has begun. (For more on the cost of rework, read how fast‐tracking a Major League Baseball stadium increased costs by 25 percent in the section “Stellar Performer: Seattle Mariners Baseball Park” at the end of Chapter 13.) Notice, too, that this development process focuses on the owner's perspective. Architects and contractors each have their own phases and deliverables that focus on reducing their risk or improving their own performance.

Benefits of a Consistent Development Process

A defined development process focuses on the right work being performed in a particular sequence on every project. Every phase can have a completion checklist, which is a way to integrate lessons learned from past projects. Standard work guidelines and deliverable examples can be developed so that every project team does the work at least as well as the previous team.

The capital development life cycle in Table 4.2 establishes a common way for the organization to view every capital project, which becomes a basis for continuous improvement. If a similar problem occurs on multiple projects, they can look at the life cycle for a common cause of the problem.

In Chapter 9 you'll learn all about “work breakdown structure (WBS),” which is the complete list of tasks for a project. It is common for a development process to contain a standard WBS for each phase of a project. This common list of tasks speeds up planning and ensures that all the bases are covered during every project, particularly those that address quality assurance.

Estimating benefits from a consistent development approach. Collecting actual cost and schedule performance information by phase and by task is easier and more meaningful when every project has the same phases and tasks. Actual performance data from past projects make it easier and more accurate to estimate future projects. (Read more about estimating in Chapter 12.)

A Development Process Addresses Feasibility, Viability, and Desirability

The three IDEO solution evaluation criteria provide a new insight into a development process. The drug development process focuses on feasibility during the early research phase, because that is the greatest unknown. Many experiments take place to identify the chemical compounds that might eventually become a drug. Feasibility is really the number one question for a new drug, just as it is with other new product development efforts where invention and discovery are the critical components.

Contrast that to the capital projects development process, where technical feasibility isn't really in question. Most buildings on corporate and college campuses don't push the envelope on constructability. Instead, the capital project phases focus on balancing desirability—what the users want—with viability—what the organization can afford. Each phase progressively refines this balance. The multiple phases of design highlight how important it is to get the design correct when it's on paper and revisions are still inexpensive.

Waterfall Is a Predictive Development Approach

When teams began developing software for business systems in the 1960s, there were few people doing this work and there was little agreement upon the best approach. By the 1970s, common strategies were emerging and by the 1980s many large‐scale information systems departments had a formal system development life cycle, or SDLC. While there were as many versions as there were consulting firms promoting their own, the common theme was that they all followed a sequence of phases that looked much like the facilities life cycle in Table 4.2, described earlier in this chapter. A common portrayal of an SDLC is shown in Figure 4.1.

The term waterfall emerged to emphasize that this is a one‐way process: Requirements are gathered, and design is based upon the requirements. The system is programmed and data bases are constructed based upon the design. Just as water cascades downhill by the force of gravity, the development phases are followed sequentially without repetition.

The logic supporting this sequential approach is the same logic we use to construct a house: It must be designed before the foundation can be poured, and so on.

The Project Management Institute (PMI^®) refers to this sequential approach as predictive, and has been promoting this term since 2013.³ In this case, “predictive” means that early in the life cycle it is possible to establish a clear agreement about the scope of the project, and therefore the project team can establish a highly reliable schedule and budget. Unfortunately, many information systems projects that followed this development process found that it did not enable them to accurately determine scope or estimate cost until they had clear requirements and a solid design.

On the one hand, it makes sense that we must get requirements and design before planning the system construction phase. That's how it works for the facilities life cycle in Table 4.1. But on a complex information systems project, the total budget might be 40 to 50 percent spent before the design is complete. Even then, the accuracy of the construction phase estimate for information systems projects is often poor. The result is that this predictive, waterfall approach really isn't that good for predicting project cost and schedule.

This is one of the major failures of the waterfall life cycle that motivated software developers to promote alternate practices that emerged under the umbrella term agile.

Agile Frameworks Are Iterative

A frequent obstacle for those who followed the predictive waterfall process was the difficulty of fully grasping the system requirements during the early requirements phase. The customers and users often had difficulty imagining exactly how they expected a future system to perform. Agile frameworks, by contrast, accept this difficulty as a natural part of creating something new. The agile approach is to begin with a high‐level goal for a system or software product, then create it one piece at a time, refining requirements each step of the way. Development of each piece is called an iteration.

Imagine a Snow Fort!

Building anything complicated one piece at a time can be hard to imagine. Instead, let's use something very simple as our example. When the snow falls and the weather is right for snowballs, kids will construct a snow fort by rolling big snowballs and pushing them together, as shown in Figure 4.2.

The kids don't really know how hard it will be to roll a big snowball, so they start with one big one. Then roll another. If they are worn out, they stop and the fort is finished. Or they might keep on rolling snowballs, and even make smaller ones that can be stacked on top. As long as they have energy and snow, the fort grows, one iteration and one snowball at a time. A key factor in our example is that as each snowball is rolled, it is added to the fort. There are never a bunch of snowballs lying around the yard, waiting to be assembled. The fort is always “ready for action.”

How is an agile software project like a snow fort? The team builds the first piece of the system in such a way that it can actually be used by the customer. It may be extremely simple, but users can see it and try it out. And if the user doesn't like it, they explain why and the team tries again. Each iteration consists of detailing requirements for that piece, designing it, developing that piece of software, testing it, and, finally, showing it to the user. The Palermo Plant Pizza Restaurant website example in the following box illustrates the iteration concept.

Software Products Can Be Delivered Incrementally

The snow fort example is extraordinarily simple and software projects can be immensely complicated. One factor that both have in common is that both can be developed and delivered to a customer incrementally. We see this every day as major websites, such as Facebook, release a new feature or functionality. As a user, we find all the usual features act the same but suddenly there is some new functionality. We also see incremental delivery work for the pizza restaurant website. This capability for incremental delivery is a significant reason that agile methods emerged from the software development community. Let's contrast this to more physical products, then dive deeper into agile methods.

Incremental delivery is not possible for many types of products. Incremental delivery of new residential construction would mean that a construction team could start with a general goal of a family shelter with electricity and plumbing, then let a construction team build for 30 days. After 30 days, the family would move into whatever shelter had been created. Then the construction team would get another 30 days to add on to the shelter. If the family liked what was built, they would pay for it and use it. If they didn't like it, the new addition would be removed and the construction team would try again. Month after month, the family would have their shelter improve in size and comfort. As this example shows, iterative, incremental delivery is not common practice for residential construction. We can imagine other products that do not lend themselves to this approach. Software, however, can be delivered incrementally. Now that we have established the concept of incremental delivery, we can dig deeper into agile practices and benefits.

Requirements Are Prioritized into a Product Backlog

A key characteristic of agile development frameworks is that the overall product is described at a high level when the project starts, and the major elements of the product are broken into a list called a product backlog.

For example, the primary features of the Palermo Plant Pizza website were listed in an hour of brainstorming. Then, as each iteration began, the Palermo family chose the most important features to add to the website. The remaining features were listed in order of most to least important, creating a prioritized product backlog.

After four iterations, they may have other ideas to improve the website in the future but those are less important, so these ideas weren't included. Later, when the restaurant is generating a profit, the Palermos may add more to the website, such as detailed nutritional information about each menu item.

Detailed requirements for any feature are only examined during the iteration that is focusing on that feature. As a result, little time is spent maintaining detailed requirements.

Each Iteration Is Structured

Each iteration has a pattern, which adds discipline to the development team. There are different ways to structure an iteration. A popular method is Scrum, which is described in detail in Chapter 11. The following actions are common to all iteration approaches.

• An iteration begins with the customer selecting the most important functionality as the goal for that iteration.
• The team focuses on the desired functionality and produces a working product for the customer.
• Every day during the iteration the team meets to coordinate and prioritize their actions.
• At the end of the iteration the team reflects on their own performance, celebrating what they do well and identifying opportunities for improvement.
• At the end of the iteration the customer reviews the product and may accept or reject it. If it is rejected, that functionality may remain the subject of the next iteration.

These iterations are most commonly one to four weeks.

Each Iteration Produces a Useful Product

The goal for each iteration is to produce a working piece of the solution. For example, The Palermo Plant Pizza website was generating results after the first iteration. Customers could find the website using search engines. Every subsequent iteration added more functionality to the website and that functionality was valuable to their customers.

Not every project that uses agile will be putting pieces of a final working product into their end user's hand at every iteration. For a complex product like an airplane wing, multiple iterations could focus on the wing design. One iteration could produce a specific design decision. If a company is building a video game, they won't release the game to their customers incrementally. But each iteration will add a feature to a working game. This means that each increment must be thoroughly tested before it is added, and the whole game goes through a test after every new increment.

Customer Interaction Is Systematic and Frequent

To produce products that are desirable, we must listen closely and constantly to customers. The structure of iterations incorporates the voice of the customer in multiple ways.

• The customer owns the product backlog. They work with the team to prioritize the backlog and they revisit it at the beginning of every iteration.
• Customers are expected to be available to answer questions during an iteration.
• The team presents the result of the iteration to the customer as part of the iteration closure. Their feedback on each piece that is created informs the next iteration.

Results from an iteration can still be off target, but the course correction happens frequently, so the customer has a strong hand in the overall direction of the product under development.

The structure of customer involvement during each iteration has an important cultural effect: Customers change their own expectations about their responsibility to the development effort.

Iteration Reveals the Right Solution

It is a common practice for homeowners contemplating a kitchen or bathroom remodel to visit showrooms displaying beautiful examples of up‐to‐date kitchens and bathrooms containing the latest products. Visiting a showroom gives homeowners an actual look at what they might have in their own house. Showrooms provide tangible examples of what a customer can expect, helping the homeowners and the remodel contractor be very specific about what will be built. Agile iterations can serve the same purpose.

Rather than asking a customer to imagine an entire future information system, the development team can use an iteration to create one working component of the system. This addresses the customer's dilemma of not being able to describe what they want, but “I'll know it when I see it.”

It's important to recognize that a customer may completely reject the output of an iteration. They should, however, have a much better idea of what they do want. The next iteration should produce something that is much closer to a desirable product. Iterations progressively refine the customer's and team’s understanding of how best to solve the problem. With each iteration the team and customer have more confidence in the solution being developed. They are unlikely to find out they've substantially missed the target when they are complete.

Iteration Delivers Value Faster

When a product is delivered incrementally, and each increment can be used, then a customer begins to experience the benefit sooner. This is an important difference between software products that use agile and predictive development approaches. With a predictive development approach, the first several months of a project could be spent on documenting requirements or designing a solution. On an agile project, the team would have a portion of the final solution already working.

The Palermo Plant Pizza website example demonstrates this benefit. They began drawing customers with the first iteration! The related benefit is that as customers see the results of quick iterations, they become more excited and creative about what can be built next. “I'll know it when I see it,” becomes, “Let's try something out!”

Iteration Reduces Scope

A consistent criticism of a predictive approach is that customers and users are motivated to maximize scope during the requirements phase. Why? Because the budget will be established based on requirements. New ideas or changes will be subject to change control and might be rejected. The result is that lower‐priority requirements become part of the requirements baseline, which adds design, development, and testing effort.

When a team delivers a solution incrementally, they deliver the most important pieces first. Before each iteration, the customer decides which piece will be built next. Since each new piece of the solution actually works (like each new snowball on the fort), the customer can see their solution growing and working. And the customer can see when it works well enough. The result is that the final delivered product is likely to have less functionality and therefore be less expensive.

Product Architecture Supports Incremental Delivery

The website and the residential construction examples above illustrated the concept and challenge of incremental delivery. Software can be designed, developed, tested, and delivered incrementally. If it couldn't, then iterative, incremental delivery would make no more sense than it does for residential construction.

If you don't work on software projects, incremental delivery might be difficult to imagine, but it's worth reconsidering what you are building and asking if it could be sliced into smaller pieces and delivered incrementally in order to get the benefits of early customer feedback and early value. Here's one example:

A training manager of a growing business was tasked with developing a comprehensive management training program. After benchmarking similar programs at other companies, she had envisioned a year of development followed by a big kickoff led by the CEO as the first group of thirty managers began the progression of workshops and mentoring sessions. After seeing a presentation on agile, she realized that she could probably release the first component of the program within two months, then continue to release a new component every two months.

Compare the Cost of Scope and Design Changes During the Construction Phase

A significant difference between physical construction and software development projects is the cost of design changes. Review Table 4.2 to see that there are eight phases in the facilities life cycle, and the first six are focused on requirements and design. Changes during these phases all take place on paper or on electronic blueprints and drawings. Once physical construction commences, every change includes the cost of removing the previous work, disposing of the wasted material, and performing the work again. The size and structure of a building's foundation is directly related to the size and shape of the building, so once a foundation is in place it would be prohibitively expensive to alter the design of the overall structure.

Changes to software projects are more like changes to the architectural and engineering specifications. The primary cost is labor, with virtually no materials costs. In addition, agile design and development methods create systems that easily accommodate change, so the incremental cost of a design change is low. That's not to say that software architects don't make foundational design errors and that these cause very expensive rewrites. Yet even here, there are no dump trucks full of wasted material to haul away.

The nature of what is being built and the cost of making a change is a major factor in whether iterative or predictive life cycles provide the best value.

The Development Team Members Remain Constant

Agile stresses the importance of having a consistent cross‐functional team that can stay with the project, iteration after iteration. This consistency has many team management advantages associated with collaboration. It is also a major project management advantage because it simplifies resource forecasting. When a ten‐person software team is assigned to a ten‐month project, you know the resource plan. That means the project manager does not need to know what this team will be working on month to month in order to have the right people involved at the right time.

This benefit is magnified for groups with multiple projects, like most information technology departments. Not only is there a product backlog for a project, but there is a backlog of projects. Iteration after iteration, a high‐functioning team is intact and can switch attention to other projects.

A ten‐month residential construction project, in contrast, could require many different specialized skillsets, such as plumbers, electricians, painters, tile installers, and so on. A major reason to have a detailed predictive schedule in place is the need to schedule each of these different resources, all of whom must participate in a specific sequence.

Find the Iterative Development in a Predictive Life Cycle

Agile development practices are increasingly being used outside of software projects. Project teams are reexamining their assumptions about their development life cycle. Large, complex projects are finding portions of their life cycle that benefit from iterative, incremental delivery.

Problem‐solving activities lend themselves to iteration. When architects collaborate with owners on new construction or remodeling, the earliest activities are very creative. Short iterations encourage exploration of ideas without spending a lot of time working through details. Applying agile practices during this phase enhances productivity.

Another example comes from the challenges of building spacecraft. The components of a spacecraft that control its flight have exacting performance requirements as well as restrictions on size. The combination of hardware and software requires mechanical, electrical, and software engineers. Syncroness, an engineering firm serving the space industry, made a conscious effort to apply agile concepts. Their previous approach to development did not easily lend itself to sharing incremental deliverables with their customers. However, they reimagined what it meant to have a tangible increment of value, including using prototyping earlier in the life cycle to force integration between the three engineering disciplines. The result was stronger design and increased customer confidence. The example of this spacecraft component supplier should prod every project team to reevaluate the nature of their work.⁴

Some types of projects will always follow a linear, predictive life cycle. Others will find a pure agile approach makes the most sense. But in between these two extremes other project teams will discover that a phase within a linear life cycle may benefit from an agile approach. That's important, because when that happens, the project manager should also use team management methods designed for agile projects.

PMP Exam Prep Questions