Boxed In
By Steve Blaise, PMP
That dreaded moment: you have to explain to management why the project is going to be late or you have to go to management and request additional funds for the project. Regardless of the rationale for missing the target, there is always the implication that you made a mistake someplace as a manager, most likely in the initial estimation. Yet you are sure you did it right. You got your team together, constructed a Work Breakdown Structure, laid out a precedence network, estimated the time and cost of the work packages, determined the critical path, laid it out on the calendar with a Gantt chart, and put the results in the project plan.
So what happened? Well, George, your senior technician, was out with the flu for a couple of weeks last winter, and Sally did not start on time because she was held up by the delay in her last project. Over the course of this fourteen-month project, there were many small changes in the requirements and the business environment. How do projects become late? Fred Brooks answered that question this way: “One day at a time.”
The longer the duration is that we estimate for the project, the farther away the actual results will be from the estimated results. This is because we, as humans, have limited ability to view into the future. Moreover, the longer the project takes, the higher the likelihood that changes will occur in the business, in the project specifications, and in people’s minds. Shorter duration projects have a better record in terms of on-time and within-budget delivery.
So, the answer to the estimating dilemma seems obvious: estimate shorter periods of time.
Bite size pieces
The term ‘timebox’ was first used by Scott Shultz of DuPont. He introduced it as part of his Rapid Iterative Production Prototyping (RIPP) method, a precursor to Rapid Application Development (RAD). The concept is simple: instead of estimating how long it will take to do the scope, the team estimates how much scope can be done in a fixed length of time.
A timebox is a fixed period established by management within which the project team accomplishes a task. The end date is typically set in stone and may not be changed. The team estimates the scope of the task to meet the deadline.
As an example, you might estimate that driving from New York City to Miami, Florida, will take 24 hours. That is a project estimate. You might also decide that you want to drive only 8 hours in one day. So you determine how far you can travel in one day of driving and book a hotel for the night in that location, say, Richmond, Virginia. That is a timebox.
Timeboxed iterations require a development team and the business to make decisions regarding the priority of work and risks associated with each part of the work, and then to identify what is of highest business or technical value.
As an example, management asks the project manager how long it will take to create a system: how long will it take to define the requirements, design the product, create the specifications, build the product, and then test it to make sure it does what it is supposed to do? Following the normal project management procedure, the team estimates two years. No one is willing to bet their job on that estimate.
Instead, using a timebox, the project manager and management agree on a deadline that is much shorter, say, two months. The project manager and team determine what can be done within those two months. They may decide that the team can fully define the requirements for review and that will be the project. At the end of the two months, management reviews the requirements and decides whether to continue.
The project manager and team might also select a portion of the overall product and produce that smaller amount of the product, say, a prototype. Again, management can review the results and make a determination of whether to continue building the product.
When management decides to continue with the effort, another timebox is determined and the team delivers more of the product. Changes that naturally occur in business and life can be incorporated more easily, and the overall risk to the project is reduced.
Breaking up is hard to do
One of the concerns about timeboxing is what goes into the timebox in the first place. Here is some advice from the DSDM Consortium:
- Begin with those parts of the process or solution which, if left until later, may cause earlier work to be abandoned or require significant rework. These may be the parts that are considered to be the most difficult or complex.
- Build those parts of the process or solution early about which the project team is unsure.
- Build those parts of the process or solution early that may be difficult to estimate. Actuals gleaned will help planning in the rest of the project.
- Build key processes or functionality early, because this will provide insight into how others will need to work.
- Build the basic structure of the solution so that it provides a framework into which the rest of the solution may be integrated.
- Dependencies between components will dictate the order in which they are developed.
- If delivering incrementally, do so in an order that will deliver the fastest return on investment.
Something of value
A timebox is kept to a very short duration, typically in the two-week to four-week range. In the agile development community, timeboxing is a given; all agile iterations are timeboxes. Scrum decrees a thirty-day cycle of software development—again, a timebox of short duration. Timeboxing always reduces the risk to the business since the maximum risk is the labor expended during the short timebox.
In agile approaches, timeboxing is not only an estimating technique. Instead of simply breaking up a project into smaller pieces, each timebox piece must deliver an additional something of value to the customer.
The advice: deliver something of value, something usable, at end of each timebox. The advantage of this approach is that the business will obtain value out of part of the product with the first delivery. The customer or users get to see the results and provide feedback to the project team much sooner.
It’s about time
The more you use timeboxing, the easier it gets to design a project through its components. Timeboxing does not give the project manager an excuse to avoid structuring and planning the project. The project still must be planned. After the project is planned, then the timebox approach is applied for estimating, delivery, and control purposes.
So, rather than thinking of the project in the whole, think of it in its component parts. As E. F. Schumacher so eloquently put it in his book by the same name: “Small is beautiful.” |