Timebox Alternatives

By Mike Griffiths

The Mayans may have had the first timeboxed project. They had a strict 2012 timebox cut off with little room for extension since the world would no longer exist. Although agile methods have been preaching the benefits of fixed timeboxed schedules since their creation, it still raises concerns with many stakeholders.

The triangles diagram from DSDM created in 1994 shows the shift from fixed Functionality (vary resources and time) to fixed time and cost (vary functionality).
 


So, instead of fixing functionality (scope) via the signoff of a specification document and completing all of this functionality (hopefully within the time and budget specified), instead the resources and time are fixed and as much of the functionality as can be completed is done before the time and money runs out.

This sounds a bit like time and materials, but there is an understanding that the core functionality, the Must Haves, the Priority 1’s, or whatever you want to call them, will be delivered. In fact 80% of the outlined functionality should be delivered and it is the last 20% that is up for replacement with late breaking changes that could add even more value.

So, the best of both worlds then? All the important features and an opportunity to swap out low priority elements with things that might crop up as we go. However this is not how many stakeholders view it. Projects typically have three stakeholder groups: Sponsors who commission and fund projects, Users who, well, use them to do some work, and the Project Team who builds them. While at the 30,000 feet level all the these stakeholder groups want the same thing, a successful project, when we dig a little deeper other priorities emerge.


 

Typically Sponsors are looking to get what they asked for, when they want it, performed as cost effectively as possible. I.E. All three of the “Good, Fast, Cheap – choose two” parameters. The Users on the other hand, usually care less about price and want the very best system they can, that is easy to use, and makes their work easier for them. I.e. feature rich and so likely expensive.

The Project Team wants to be successful (via budget, schedule, scope, quality, happy users measures), get recognized and acknowledged as going a good job, and have fun and learn new things along the way. I.e. the do the least possible to be successful in the most interesting and fun way.

So a successful project then has to balance these competing needs and manage the diverging expectations of multiple stakeholder groups. (“Tell me why you wanted to be a project manager again?”) Given this conflict, fixing the time and resources and varying the functionality turns out to be about the best option we have but it has a major stumbling point. First let’s see why it’s better.

If we were to flip the triangle a different way, with Time and Functionality fixed, but varying the Resources. We would end up with a Timecrunched, Unknown Cost” project
 



This should allow us to meet out deadlines with all the functionality we need, just by using a variable number of resources. Of course Cost is a factor of how many resources we use so we could not guarantee cost. However if you were a Mayan King looking to get a temple build for a solar event maybe cost is not too much of a problem.

There is of course another problem that labour does not scale linearly. Fred Brooks told us that adding resources to a project that is late will not get it done on time and can in fact make it later. Some problems scale better than others in this space, digging trenches and piling rocks actually scale quite well and doubling your team size can get nearly double the productivity. Move to the knowledge work domain though and things are very different. Here the resourcing curve follows the Putnam, Norden, Rayleigh (PNR) Curve.

 



Here, in the knowledge Worker domain (software, teaching, engineering) adding more resources to a project just forces us further up an ever steeping curve of higher cost without much of a time saving. So much so, that Capers Jones christened the area of the graph associated with attempting to crash the schedule to shorter that 75% of the optimal time the “Impossible Region”. In all of the software projects he looked at that tried to shorten the schedule by adding more people, 0% were successful in shortening to less than 75% of the normal delivery period.

So, trying to fix the Time and Functionality might sound nice in theory, but in the knowledge worker domain it actually brings no guarantee of meeting that time estimate either. The other option we have would be to try and fix the Functionality and Resources and vary the time.
 
 



This now becomes an Odyssey, or hobby, a journey with no know end point. The good news is that we should get the functionality we want, and since the resources are fixed we will not experience the non-linear cost escalation of the Timecrunched approach. For some companies this is a perfectly acceptable way of undertaking sustainment work – bringing work to an established high functioning team, but it is not a great value proposition for launching a new project, because we cannot say when it will be done.

Without knowing when something will be done, we cannot work out return on investment or compare the viability of one project compared to another and so it is not a favourite with project sponsors (nor users, or project teams come to that).

So, by default the agile approach of varying functionality is the one we generally use. The issue it faces though is that it is the initially least appealing to sponsors. Once we get into the project they value being in control, and towards the end it provides tremendous flexibility and a better chance of on budget, on schedule completions. It’s just that initial sell.

Now let’s see how the traditional fixed scope projects and more agile equivalents typically play out for sponsors. :

Fixed Scope Project – with signed-off specification
•    At Start: “Great they have signed off on all the things on my wish list, I will get everything I want”
•    During Execution: – “They’re charging me a fortune for every little change; they are a bunch of crooks!”
•    Nearing the end: – “What, now you tell me you will be late! And you need more money, our contract said you would deliver all this for 500 gold coins, fetch more slaves, work faster”

Fixed Time and Resources – with flexing of functionality
•    At Start: “Will I get it all done, or just some random subset of the easy stuff?”
•    During Execution: – OK, I can see I am in charge of things and get to insert new changes if I am happy to lose some lower priority features
•    Nearing the end: – “Those lazy slaves still worked slower than promised and cost more than I wanted, but at least I got my temple built before the eclipse, for 500 gold coins with all the important features I wanted. Some of the things left over might be worth funding a follow-on project for.”

Basically any endeavor with uncertainty runs the risk of unforeseen complexity and additional work. We can try to control this notoriously uncontrollable scope by lots of very expensive scope exploration work and documentation, or accept the uncertainty and direct that analysis energy towards the product being built. The tough sell part is the convincing the sponsors this is actually the smart thing to do.

Timeboex projects will be in the news this year, not just because 2012 is the end of the Mayan calendar, but London is working towards their Olympic Games preparation.  Events like the Olympics are classic candidates for a fix the resources and time, vary the functionality approach. The government has an immovable deadline, a fixed (albeit large) budget and only scope (functionality) to play with. As long as they get the facilities, safety, and logistics established, the urban beatification, garden plantings, and hospitality extras can all be varied to meet the remaining budget and time. If however the Mayan timebox runs out first then they need not bother.
 

Bio: Mike Griffiths is a project manager and trainer living in Calgary, Alberta. He served on the board of the Agile Alliance and the APLN. Mike is a contributor to the PMBOK v5 Guide, the Software Extension to the PMBOK Guide, the PMI Agile CoP, and the PMI-ACP Steering Committees. He maintains the blog www.LeadingAnswers.com.

I first wrote this article for GanttHead.com here

Comments

[Vin D'Amico]

Agreed. In the end, there has to be some level of trust...on all sides. Everyone needs to be reasonable and willing to negotiate. Giving up some control to the software developers is hard to do. Business people don't understand the technology challenges...of course, technical people often don't understand the business challenges either.

If everyone took a little time to educate the other side, the whole process would be much easier.

[Cullenob]

This is a brilliant. Moreover, it is hugely helpful to those of us who sell agile approaches to multiple client-side decision-makers. I am grateful to you, Mike.

[Mike Griffiths]

You are very welcome, I am glad you found it useful.

Best regards
Mike

[Cesario Ramos]

Great post. I will refer this blog in my trainings as people always want stories they can use to convince
people.
Thanks,
Cesario