Pages Navigation Menu

What Lifecycle? Selecting the Right Model for Your Project

A cynical senior manager said, “It feels as if I’m stuck between the traditionalists and the agilistas. We can’t use phase-gate anymore, because it’s not ‘agile’ enough. And the last time, when that multisite project tried Scrum, they failed miserably. Isn’t there a right approach to our projects?”

A project doesn’t have to use just one lifecycle. In fact, the more geographically distributed and the more complex the project, the more each project site or area needs to choose its own lifecycle. Then you need a program manager to help organize all the interdependencies.

But too few project and program managers know about their choices for lifecycles. Without that knowledge, it’s impossible to design a project, to reevaluate the risk as the project unfolds, and to use the lifecycle, or change it, in order to steer the project in another direction.

A BRIEF INTRODUCTION TO LIFECYCLES

You might think that there are only two extremes of lifecycles: the serial lifecycles, of which waterfall is one example; and the agile lifecycles, of which Scrum might be the most adopted example. But the reality is that there are at least 11 lifecycles along a continuum from [serial to iterative, incremental, and iterative/incremental] (see Figure 1).

Continuum of lifecycles

Figure 1 — A continuum of lifecycles.

As you can see, you have many options for which lifecycle to use when in a project [1]. They each buy you something different and will work under differing circumstances.

What do the terms mean?

If you are accustomed to looking at Gantt charts, Figure 2 shows what the lifecycles look like on a Gantt.
Lifecycle.gantt
Figure 2 — A Gantt-like look at lifecycles.

Here’s a brief explanation of the terms. A serial lifecycle is one in which all the phases occur in order. One phase has to finish before the next one starts. Many waterfall projects don’t require that each phase finish before next one starts, but do require that if you’re in phase n, you have to complete phase n-2.

An iterative lifecycle is one where you prototype pieces of the product. You might prototype pieces of the architecture or pieces of features. You might even plan to throw those pieces of the product away. In my experience, the more the project team counts on throwing away pieces of code, the more likely you are to keep them around! Either way, the key is that you try something to learn about how this code might work in the product.

An incremental lifecycle is where you build chunks of the product, most often feature-by-feature.

The iterative/incremental lifecycles use timeboxes, also known as iterations, to finish chunks of work. The iterative part of this lifecycle is the revisiting of the product pieces. The incremental part is the finishing of the pieces you commit to finishing in this timebox. If you’re building a banking application, you might finish, as in test and demo to the customer, a piece of functionality such as “withdraw fast cash money.” You might still have other withdrawal stories or requirements to finish in a future iteration. But “withdraw fast cash money” is done inside one timebox and you can show people it works.

SELECTING A LIFECYCLE

So how do you know which lifecycle to choose when? Well, of course the answer is “it depends”—and it depends on what’s driving your project, whether schedule or technical risk is higher, and of course, your team. Let’s examine each of these factors.

What’s Driving Your Project?

Your customers care about just three things: what you will provide for them (the feature set), when you will provide it (the release date), and how good that feature set is (the defects) [2]. Yes, some customers care about the product cost, but if you provide enough features that work when they want those features, cost is a much lower consideration.

Your corporate management, on the other hand, starts projects because of the project’s perceived value to the organization. That means it cares about the project cost, the people you need for the project and when those people are assigned to the project, and the project’s environment. “Environment” can encompass a number of different factors. You may be delivering your product in a regulated industry, or you may need to follow a specific process for some reason, or you may have a project team that is separated by floors—or continents. Project managers have little control over the costs, people, or environment, but these issues affect how many features the team can deliver, how good those features are, and when the team can deliver them.

What’s driving your project is some combination of what your customers care about and why management initiated the project. If you know what that combination is, you can choose a lifecycle that manages your biggest risks.

Do You Have Schedule or Technical Risk — or Both?

Some projects are lucky and only have schedule risk or technical risk. Many more projects have a combination of schedule and technical risk. It’s worth thinking about the kind of risk you have, to see if a lifecycle can help you manage some of the schedule or technical risk.

For years, the industry was under the illusion that the serial lifecycles managed cost risk. They can, but only if the project team reestimates their progress to date and reestimates their projected schedule and cost. For software projects, that’s close to impossible. If anything changes—requirements, the project team, the architecture—the previous estimates are wrong. Serial lifecycles have a dismal track record for prediction. These lifecycles don’t learn enough about technical risk until the testers start testing, and in most projects, that means at the end of the project. Because there’s little knowledge or management of technical risk, the serial lifecycle also produces the highest schedule risk.

How Adaptable Is Your Team?

Agile lifecycles are the best at managing schedule and technical risk, and because the product is release-able at the end of every timebox, they also manage cost risk. But agile lifecycles require the team to be disciplined to follow the practices they say they will follow, to adapt to changing conditions, and to trust each other to deliver. Not every team can do this.

CHOOSE A LIFECYCLE BASED ON RISK

Since each project is different, you’ll want to choose a lifecycle based on your project’s risk. Table 1provides a summary of the kinds of risks you might encounter and how each lifecycle deals with them.

You may have noticed there’s an extra lifecycle in Table 1, the venerable ad hoc lifecycle, or code and fix. There is never a good time to use code and fix. Any lifecycle, even a serial lifecycle, will provide a better outcome than the code-and-fix.

whatlifecycle_clip_image006
Table 1 — Risks that lifecycles manage.

COMBINE LIFECYCLES FOR MAXIMUM VALUE TO THE PROJECT

Every project is different—and some become different as they proceed. If you have significant technical risk, but your project team isn’t collocated, and your management is suspicious of anything termed “agile,” you have other options than trying to force a purely agile lifecycle that doesn’t fit your environment. Or, consider another scenario. If you have a hardware component to your project, you’ll need different lifecycles before and after you synchronize with the hardware part of the project. A combination of lifecycles may provide the most value to the project. Below I offer examples of how I’ve combined lifecycles in three projects.

Project 1: Iterative + Incremental

For one project, two organizations were collaborating to develop a product. They knew that they wanted to define the architecture earlier rather than later. And they knew that an architecture with no prototypes had no guarantee of working. So, they chose to use an iterative lifecycle to experiment with architecture (the prototyping) and then move into an incremental lifecycle to make sure the pieces worked as they developed them (see Figure 3).

Iterative and Incremental used by collaborating organizations
Figure 3 — Iterative and incremental lifecycle used by collaborating organizations.

Project 2: Staged Delivery + Design to Schedule

Another large program wanted to manage the testing risk — the risk that not enough of the product would be tested early enough to know if the product was working well enough for the customers to use. I think of this kind of testing risk as technical risk, but another project manager might think of it as schedule risk. However you want to categorize it, the risk is in not receiving enough feedback early enough about how the project is proceeding (see Figure 4).

A combination of incremental lifecycles for a large project
Figure 4 — A combination of incremental lifecycles for a large project.

In this project, the developers used a staged delivery lifecycle to add features by chunk. The testers were not truly integrated into the project, but were close to the developers. The testers chose to use a different incremental lifecycle—design to schedule—because they were sure they would run out of time and wanted a breadth-first approach to testing the features.

Project 3: Iterative and Incremental—Plus Scrum!

A project with hardware and software requires a variety of lifecycles. In this project, the hardware (electronic and firmware) groups used an iterative approach until they went to fabrication. The firmware group used an iterative approach to prototype the hardware and then used an incremental approach for the firmware. The software group used Scrum in three-week timeboxes (see Figure 5).

A combination of lifecycles in a hardware/fimrware/software project
Figure 6 — A combination of lifecycles in a hardware/firmware/software project.

The software part of the project took longer than the hardware or firmware. In a real sense, the project used staged integration. But the entire team reduced technical and schedule risk by heavy use of prototyping at the beginning and moving into chunking later. Using Scrum to manage the software was a challenge at the beginning, because the software team did need to participate in the hardware and firmware design reviews. In the first timebox, the software team hadn’t allocated time for reviews. Once they realized they needed to do so, they set aside time for reviews, and made sure they explained to the other teams how they needed to allocate their time inside the timeboxes. And, because the early timeboxes had demo-able (albeit not release-able) prototypes as deliverables, the team didn’t feel as if they’d wasted time.

The hardest part in this project was managing the date interdependencies. But the technical risk was significantly reduced with the extensive use of prototypes at the beginning, and by implementing feature-by-feature throughout the project. In addition, the timeboxes provided the team a chance to resynchronize what they were delivering to the project every three weeks. The entire project team could see the software team’s progress and procide feedback. If they needed to reprioritize fixes or features, the team could do so.

The software team managed their schedule risk not only with the timeboxes, but also by knowing what “done” meant. At the beginning demo-able software was good enough, but once the hardware went to fabrication, that definition of done changed to “releaseable,” thereby reducing overall schedule risk.

WHEN YOUR MANAGERS WANT DOCUMENTATION

If you move from a serial lifecycle to any other lifecycle, your managers will not see documentation when they expect it. They will be able to see the product take shape, but sometimes it can be hard for managers to understand what they’re seeing. In the hardware/firmware/software project, the software was just demo-able, not release-able for much of the project. By demo-able, the software could not run on the hardware—after all, for most of the project there was no hardware. But with primitive simulators and mock-ups, the team could demo the software. The managers wanted assurances that the software would work once the hardware returned from fabrication, but there’s no way to ensure that until the hardware is verified.

Many managers want to see documentation in lieu of working product, especially if it’s early in the project and the managers are unaccustomed to thinking about demo-able product. In that case, you may have to choose points during the project to provide some documentation. I recommend to teams that they put the documentation on the product backlog so their management understands the tradeoffs—that is, that the team is working on documentation instead of product features.

LIFECYCLES HELP YOU GAIN THE MOST THROUGHPUT FOR YOUR PROJECT

If you’re the project manager, your obligation to the project — no matter what processes you use — is to improve throughput and remove obstacles. That means you need to recognize what prevents throughput for your project. I’m not a fan of serial lifecycles for long or large projects because there’s little or no throughput for most of the project, and it’s too easy for project teams and project managers to miss early warning signs of trouble.

For any lifecycle other than serial, because you and the project team receive feedback about the activities completed to date, and you might be able to measure your throughput. As a result, you can review where you are with respect to your schedule, and where you wanted to be. If your schedule risk has increased, you move to incremental development or timeboxes. If your technical risk has increased, you can move to prototyping in timeboxes. (My experience says that if technical risk has increased, schedule risk will increase quickly!)

You don’t have to be “All Agile All the Time.” Nor do you have to be “We are Phase-Gate and We’re Proud.” You, as the project manager, have the obligation to recognize where you are and what to do about it. Consciously selecting a lifecycle or combining lifecycles can help.

REFERENCES

1. Rothman, Johanna. Manage It! Your Guide to Modern, Pragmatic Project Management. Pragmatic Bookshelf. Raleigh NC and Lewiston, TX, 2007.

2. Grady, Robert B. Practical Software Metrics for Project Management and Process Improvement. Prentice Hall, Englewood Cliffs, NJ. 1992.

 

© 2008 Johanna Rothman. This article originally appeared in Cutter IT Journal, May 2008, pp 22-27.

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

2 Comments

  1. I do love this post, I come back to it time and time again! Thanks!

    • Phil, thanks so much.

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>