Consider the following scenario: A large, multi-million dollar, multi-year IT project is transitioning from the build phase to the test phase. The project has already encountered significant difficulties and dates have been re-planned previously, extending the timeline and cost of the project. As the planned end date of the build phase approaches, there are still some pieces of the application that are being developed, some that are still being unit-tested by developers, and a large number of unit testing defects.

The project team knows that upper management is counting on them to deliver to the new (extended) project dates. The pressure is high, and this inevitably informs the project leadership team's decision: move into the test phase while the build phase is wrapping up. The leadership team realizes this adds additional risk to the test phase, but they hope to catch up during testing, and they figure that starting early will at least give the test team time to get familiar with the application they are testing, even if parts of it are not fully developed.

As a project manager new to the project, you are called on to give feedback to the leadership team about this decision. What do you say?

The above scenario is one that, unfortunately, often plays out in large, complex software projects. For a variety of reasons, projects end up taking longer than planned, pressure mounts to deliver, and phases become far more elastic than they were initially intended to be. In this article I will make a case that it is our duty as project managers to stand up for what I will call phase containment.

Phase Containment: What is it?

The PMBOK briefly touches on the importance of closing one project phase before moving on to the next phase in the 2nd chapter on Project Lifecycle and Organization: "Overlapping phases may increase risk and can result in rework if a subsequent phase progresses before accurate information is available from the previous phase." This term is often used to talk specifically about defects - the idea is that defects, ideally, should be fixed in the phase where they are created. Steve McConnell has a good article discussing defect phase containment here.

In my definition of phase containment, I will extend the defect principle to all project work and deliverables. Simply put, phase containment means completing all project work and associated deliverables in the phase planned prior to moving to the next project phase. The level of rigidy applied to considering work "complete" will vary from project to project, but the definition of "complete" should be decided upon for each work item/deliverable before the pressure mounts to move to the next phase without truly being done with the previous phase's work.

For example, a project team may decide that they will consider the build and unit test phase complete with 100% of the code is developed, 100% of unit test cases have been executed, and 90% of unit test defects have been resolved. The project team then has an objective measure of complete, and has allowed for some slight overlap when those pesky last 10% of unit test defects are fixed.

Isn't this obvious? Isn't this already implied in defining phases and assigning deliverables to them? In theory, yes, but in practice is it surprisingly easy to justify away not really being done. Do any of these phrases sound familiar?

  • "We'll circle back and finish deliverable X later"
  • "We're basically done, we just haven't updated our documentation"
  • "We finished the important pieces of the application, and we want to get them to the next phase while we work on the rest"

These and many other justifications come easily when pressure is on to meet deadlines and avoid the embarrassment of yet another slippage of project dates. And sometimes (rarely in my experience) it is possible to progress the project too early and catch up later without major negative effects. However, there are often a lot of unexpected consequences of ignoring phase containment.

What are the impacts?

Rework is one of the biggest drawbacks in allowing overlapping phases without closure. If unit testing is not complete, there is a strong possibility that testers will run into the same unit test defects in progress with the developers. Without strong communication, two groups could be doing the same root cause analysis without knowing it.

Highlighting and addressing project issues also becomes more difficult with overlapping phases. Is testing running poorly because there is so much of the application that is un- or under-developed, or is it going poorly for other, more serious issues unrelated to the overlapping phases? If phases can overlap, the push to close out a phase has far less pull. Thus, the build phase could end up extending far beyond its initial planned end date. When the project team makes a commitment to close a phase before moving to the next, the whole team feels the impact of delays and is motivated to support the work of the phase to get it done. More often than not, closing out a phase slightly late is going to save the project time in the long run by avoiding the issues that plague projects with two or more unplanned overlapping phases.

What can I do?

Establishing clear, measurable exit criteria for each phase will go a long way toward avoiding the problems addressed above. When pressure comes to slide into the next project phase, the project manager can demonstrate that the previously defined exit criteria are not met, and can educate the leadership team on the risks of moving forward without meeting them. Comparing the status of a phase to pre-defined criteria also serves as a good benchmark of actual progress so that senior leadership can understand how close the project is to finishing the phase currently in progress.

Alternatively, if phase containment seems unrealistic or unachievable in your organization, it may be a good indicator that following a strictly sequential project management approach is not the best fit. If possible, breaking a large project up into smaller, more manageable projects, and breaking a large project team into smaller, cross-functional teams and moving into an iterative delivery framework like Scrum may be a better alternative. However, it is a mistake to believe that iterative delivery will solve for a lack of organizational discipline. Smaller teams with smaller projects still need to be disciplined and organized in delivering on their projects, and transitioning to an iterative methodology is not without significant challenges.