Time boxing IT Projects - Part 1
• What is Timeboxing?
For those newbie’s to IT Project Management, Time boxing is where a group of tasks are given a fixed period of time to be completed. Time Boxing is often used in project management, not just to set the delivery goals for small groups of tasks, but rightly or wrongly to set the delivery date for entire projects /programmes of work.
• Different Timeboxing techniques
The “Top Down” setting of a Timebox is where management dictates what product is produced - where, how, when and with what resource.
“Top Down” is often used at project level by sponsors /clients wanting to set a delivery date for a project of specified scope /quality /cost.
Usually no attempt is made to discover whether such a project is feasible other than a “gestimate” by the senior management and sponsor. At project level I have never seen a top down timebox plan work to time without significant stripping out of scope and quality. Often the descoping has been so aggressive that very often the IT system delivered has failed to remotely achieve its original business case objectives.
Quite often “Top Down” Timeboxing of projects fail due to poor staff moral. A project manager who decides to produce a project plan dictating a project teams work breakdown structure and associated tasks /durations and effort required to complete a project without seeking buy-in on a task by task basis, is heading for disaster. Such an approach simply demotivates good project teams.
It’s a message to the project team that either your do not trust their professionalism, you don’t know how to manage or worst of all you and or the management team and sponsor are arrogant and autocratic. Either way if you continue down this road, you will be setting yourself up for a fall, with a now resentful, demotivated project team which no longer respects its project manager or the management team.
“Bottom-up” is where the timebox is set by the project team not by the management. This involves full participation by the project team in an iterative project planning process (explained in part 2 of this post) where every product, and its associated task breakdown, is estimated in terms of time, cost, ownership (who does what and who is responsible), effort and dependencies. All iterative estimates will detail, where applicable, team based risk /issue assessments and what assumptions had to be made in order to make the estimates possible./ul>
-Timebox duration limits
Each product level timebox should be no more than 6 to 8 weeks in duration. Any longer and you should consider breaking the product down into further lower level product deliverables and timebox these in turn. For example, a Use Case model could be one deliverable but if this turned out to be something that might take more than 8 weeks to deliver then it should be broken down into Use Case model components (key product features) each with separate product owners and independent quality checks and reviews.
-Timebox Stage Planning
I tend to plan my large projects in stages.
Blueprint >>> Build>>> Test>>> Deployment
When I plan a stage i.e. Blueprint (requirements definition) which requires timeboxing (bottom-up), I put together all the timeboxed and planned blueprint products i.e use case model, test strategy, architectural design etc with connecting dependencies into an integrated stage plan. This usually happens not as a separate task but as part of the iterative project planning process to be detailed in Part 2 of this post. Once complete you must obtain minuted agreement by your project team that the Stage Plan and its component products allowing for contingency (assigned in accordance with the projects risk, issue and assumption profile) can now be fixed in terms of the deliver dates. If the answer is YES then your stage plan is now timeboxed!
Especially with projects which have a poor risk /issue and assumption profiles, timeboxing often fails to get a project or stage in on time. If you feel this is likely then you must get agreement from the client as to the projects 4 key drivers and their relative order
e.g Time > Scope> Cost >Quality
If the client /sponsor agrees with these drivers and their respective order, then it is clear that you have authority to first reduce quality, then increase cost, and then start cutting out functionality in order to bring in a slippage in target delivery date and set a new Timebox.
It is very important before making these adjustments to the project plan that it is done with the consent of the project team and the sponsor /client. When informing the client /sponsor of a slippage and providing your suggested “What-if” changes to the project plan to bring in the target delivery date and set a new timebox, it is very important that these driver trade offs are explained in terms of risk to the business case.
Normally all these details /procedures and definitions of quality would be explained in the Project Initiation Document (PID) which is normally signed off by the client /sponsor and governs the way the project is managed.
-Advantages of “Bottom-up” Timeboxing
Compared to the “Top Down” approach mentioned earlier this approach has the following advantages:-
- Promotes better staff motivation.
- Feasibility is at the heart of the Bottom-up timebox.
- Greater control over the delivery as eachtime box is only 6 - 8 weeks in duration, so it is easy to understand what is going on in each product level timebox.
- Limits scope creep and gold plating by the project team because of tight delivery deadlines.
- Puts brackets around chaos enabling people to focus sharply on meeting minimum requirements for success.
I have always made “bottom-up” timeboxing at product /stage level an integral part of the way I have always managed projects /programmes of work whatever there size or complexity. It’s a fundamental technique, which has to be understood if you want to be known as a successful delivery focused Project /programme Manager. “Bottom-up” timeboxing can dramatically increase productivity without effecting quality if applied across an entire project /programme of work.
• How do you set-up a “Bottom-up”Timebox?.
What I describe hear is not just a description of a tried and tested “Bottom-up” timeboxing methodology, but what is the most appropriate working environment /culture necessary to make timeboxing work effectively?
To “bottom-up” timebox a product /project you need to following the following 5 stage approach.
STAGE 1 - Study & Understand Human Nature
One of the biggest barriers to Timeboxing working effectively is a failure of Project Managers to understand human behaviour. Human beings as mentioned in my post – AGILE fails to take into account human psychology are characterised rightly or wrongly by the following behaviours:-
- Self Interested – Why democratic capitalism does work (As Churchill stated – “Capitalism is a bloody awful system buts it’s the best we have” )
- Will always put self interest over that of the group (why communism does not work)
- You cannot get more than 5 people to agree as part of a team on anything (Karl Popper’s first law of collective action)
Therefore, if you want timeboxing to work you have to work with these behavioural traits and not against them. Do not naively believe that IT project teams work hard for altruistic /cultural reasons (patronising and a highway to nothing if you believe this). These professionals have a living to earn and personal career aspirations to satisfy.
Play to these needs and not against them.
Click Part 2 or Part 3 to see other posts in this series.
This entry has been viewed 16154 times.