In 1988, in San Diego California, a competition was conducted to build a house from the ground up in four hours or less. The competing groups could not use pre-fabricated parts, they had to put in the foundations, and they had to abide by all of the strict Californian building codes, including being earthquake resistant! Oh, and they also had to paint it, furnish it, install the kitchen, and create a garden with shrubs and a lawn. They took just two hours 45 minutes.
To achieve this remarkable feat the project demanded the coordination of some 370 contractors; including landscape gardeners, roofers, plasterers, plumbers, and electricians. All of the professions that would typically be involved in a building of house but would not usually work together at the same time!
The planning demanded extreme measures to ensure that there was no rework, and no unnecessary activity: the roof had to fit the walls—the first time; the plumbing was in before the floor went down, and the dry-skin walls were up before painting commenced. None of the items on the list is unusual in building a house, but in this case, because of the extreme time constraint, the processes used to deliver them were.
You can see highlights of the four-hour house on YouTube. Scan this QR code (Figure 2.1 ) with your smartphone, or enter the URL into your browser. Perhaps you might take a break to have a look at the clip and consider the question: What did the project planners use to trigger the deployment of such innovative processes by such traditional building practitioners?
Figure 2.1 QR code for the four-hour house and a short URL
Compressing Time Means More Planning
You will have realized by now that this was no four-hour house! That was merely the time it took for the implementation stage. As the video explains, the design and planning taken together—and they have to be taken together as we will see—took over six months. The detailed planning, re-planning, scheduling, and the testing of the schedule was at least as time-consuming as the technical design. So the project took more than six months. Planning under extreme constraints takes time!
One extraordinary achievement made possible by this project planning was that despite the extreme workforce build-up index (MBI), it used virtually the same total resource as under normal conditions. Figure 2.2 illustrates the differences between the MBI for a standard house build and the four-hour house.
In Curve 2, we can see the long pre-execution build-up where a relatively small group is involved in designing, planning and coordinating the scheduling process. Then within the space of a few minutes, the number of resources escalates rapidly from a few to over 370 people on site. 370 people working for three hours is just over a thousand person-hours, which is approximately the same level of effort to build a house normally, over a seven to 10 week period. However, what any PMP qualified project manager will know, typically when you crash a schedule by adding more resources, individual productivity declines steeply. How did they manage to avoid this in this project?
Figure 2.2 Comparing workforce build-up indices (MBIs)
Well, it didn’t happen by accident! In time-constrained projects, the planning is intensive. Alternate routes (schedules) are set out to deal with unexpected and unwelcome events, and the level of task and productivity monitoring is exceptionally high. (In the video, there is a glimpse of monitors with walkie-talkies allowing the project manager to coordinate across the activities.) In such a project, shortcuts do lead to long delays. Unresolved issues and risk events, without associated pre-defined management actions, kill schedules. The impulse to start quickly and “get on with it,” so often asked for by sponsors and key stakeholders needs to be resisted.
Another aspect to note in this project was that the schedule was set up to achieve completion within four hours, but on the day, it was finished in less than three hours. The schedule had been designed to take advantage of tasks completing early. Allowing for this is a strong argument for keeping high fan-out and high fan-in nodes out of the task sequence, and shows why and how allocating contingencies at the activity level is such a good idea.
Fan-outs occur when one task triggers the initiation of several others. Fan-ins are when, to complete one task, many others need to finish. Both of these are often accidentally created by careless scheduling practices. When running a project assurance exercise and the project has used PERT or a similar scheduling tool, it is an easy visual check—you see structures like those shown in Figure 2.3
Figure 2.3 Risks created by scheduling
Knowing how to plan and schedule for ‘as soon as possible’ (ASAP) and taking opportunities that present themselves to accelerate a schedule is not straightforward using standard PERT charting. If you model using aggressive activity duration estimates, the likelihood of slippage is high, and the schedule quickly becomes out-of-date. If you model with built-in contingency—a more normal practice—it tends to hide the target duration and to create ‘wait’ states, not something you want when looking for opportunities to go faster. And if you create lots of dummy activities to model the contingency explicitly, the reporting process becomes overly complicated, as does the representation of the schedule. Figure 2.4 illustrates the problem with using aggressive durations versus tasks with the contingency ‘hidden’ in the duration number in classic PERT charts.
Figure 2.4 Scheduling for opportunities
A possible alternative to PERT and its critical path approach, in this type of scheduling environment, is to adopt the critical chain approach to scheduling a project developed by Goldratt (1997). Figure 2.5 shows, for comparison, the way a critical chain approach models the same problem. It also shows how it deals with contingency and access to critical resources through the use of buffers. The critical chain schedule shows a time-constrained project with seven activities and a total aggressive activity duration estimate of 11 days. The end-date is set by adding the project buffer to the aggressive duration estimates. To protect the critical chain are two feeder buffers; to protect the end-date there is a project buffer; and to ensure tasks are not held up for lack of availability of a necessary resource, there is a resource buffer.
Figure 2.5 Using critical chain sequencing
When Time Is of the Essence
What are the causes of elapsed-time delays in the projects with which you and I get involved? Waiting for approvals and authorization to proceed are common culprits. When building a regular house, the need to wait for building inspectors to visit the site and provide approval documentation interrupts workflow. To address this, in the four-hour house project, the building inspectors were on-site during the build, and their activities planned into the tightly scheduled process, thus eliminating the usual build-wait-build cycle.
In the UK, a large retail group suffered a catastrophic fire, which destroyed one of its primary distribution centers. Although insurance would cover the loss of stock, the business could fail due to the disruptions to its logistical and supply chains. A rebuilt distribution center was needed quickly if a corporate crisis was to be averted.
The Board agreed to allocate a single sponsor, who would take responsibility for the decision making during the build. One of the first deliverables was a luxuriously appointed temporary accommodation onsite for this sponsor. He lived and worked there for the duration of the project. There was never a delay when issues arose. The project manager simply walked the sponsor to the problem and waited for the answer—the governance process had been integrated into the project. The new site was delivered and made operational in record time. As the project manager reported, “Having the sponsor onsite was more important than any other factor in bringing this project in so quickly.”
As every experienced project manager knows, often the real enemy is calendar time. You can manage effort time, but not the passing of hours. The trick we all have to learn is how to package effort to maximum advantage. When the challenge is to maintain high levels of productivity, the project manager has to consider all of the things that would, in normal circumstances, result in increasing the elapsed time:
- Resources (people, supplies, and tools) not on-hand when they are needed
- Resources not competent or unsure of how best to do something
- Roles and responsibilities unclear—who does what and when
- Delays caused by poor communications between individuals and teams
- Non-collaborative behaviors between individuals and teams
- Unresolved issues
It is for these reasons that planning is not an activity for a master planner working on their own. Planning involves active consultation with teams and their leaders. They know best the needs and in what sequence to start activities; and what can be allowed to run in parallel safely. Engaging with subject matter experts (SMEs) is a crucial part of gaining insight and commitment.
Constructive Use of Constraints
A slight modification of the CPPRRSS planning process allows for a very rapid iteration between the products (outputs) and possible processes, thus providing the opportunity for innovation when that would be advantageous.
Consider the case of laying the foundations in the four-hour house. The project management question is not “How do we lay the foundation?” It is, “How can we walk on a foundation—that meets all of the acceptance criteria—in 45 minutes?” The process of installing a ceiling is known, the question given to the SME is “How do we ensure it is in place and the room ready for the next activity in 12 minutes?”
The way the solutions affect the scoping, costing, and scheduling, not the technical engineering aspect, is what fully engages the project manager during the planning. Initially, standard processes are chosen because they have the lowest technical risk. In the context of projects that means that the defects they create (all processes generate defects) are known, as are the workarounds. People know how to recognize them and where to look for them.
If, however, the standard processes are too slow or create unacceptable dependencies with other activities, this makes them unusable; they threaten the success of the project. Under these circumstances, innovative approaches, together with the increased monitoring and control they demand, are indicated. Better by far to take a managed risk than to plan to fail. This is the role constraints have in project management. They validate the plan. They are not, therefore, as Goldratt and Cox’s (1984) operational view would have it, obstacles or hindrances to the achieving of the objective, but shapers and guides to the best options to take.
Often, when seeing the four-hour house for the first time, project managers grumble—“Yes but ...” and will point to special circumstances: strong stakeholder backing, skilled and motivated people, publicity. Some points they make are factually accurate, others mere surmise, but all are in the power of a project manager to make a reality for themselves.
One observation sometimes made is that the project was “allowed” to build a test house first. It’s almost as if it was cheating or unfair to rehearse the tasks, the schedule, and the innovative practices to identify problems and areas where productivity could be improved before the final build. As we will see in Chapter 5 on mission-critical projects, it’s not unfair; it’s fundamental!
Another, sometimes overlooked, part of the planning was running the project party before the start of the project; a sensible and project-like thing to do. Projects, in general, are characterized by having transient teams, groups of people who have not worked together or even know each other, and who, after the project, will go their separate ways. So, why project managers run after-project parties is a bit of a mystery to us; while holding a party at the beginning to establish and encourage team relationships seems like money well spent.
Personal discipline is needed when adhering to a schedule, but not at the expense of an appropriate level of ‘can-do’ attitude. In the four-hour house, the rehearsing activities and the creation of good, rapid communication links between teams were emphasized. Each team had a clear view of what their role was regarding both the outputs and the outcomes they needed to deliver. They were also acutely aware of the interdependencies with other groups. These were made explicitly visible in the planning.
Roles and responsibilities by the team and by individuals were set out in the plan. The schedule, when it was drawn up, was a series of minutely detailed and timed steps. The difference being that the scheduled activities were set out by the SMEs, not the project planner.
Why? Because when a project member is unclear or hesitant about how and when to act, delays occur in project execution. De-complexifying the ‘who does what’ is part of the project planning process. In a complex project, clarity will come in and out of focus over the life of the project as activities change and new people become involved with the project. The project manager has to monitor the ‘team state of understanding,’ restructure roles, and re-communicate as many times as necessary. This is different from telling a person how to do their job—they know that better than you do.
This brings us to the importance of communication.
The Importance of Communication
“We are ready for you.”; “Approvals have been completed.”; “We need more paper.”; “It’s gone wrong!”;” Wait, we are not ready.”; “What should I do now?” are typical communications between individuals and teams that need to be swiftly and unambiguously transmitted to maintain productivity. That means establishing controlled and effective communications within the execution process.
In the four-hour house, monitors with walkie-talkies (a 1980s equivalent of mobile phones and messaging systems) were dedicated to the task of communication between teams and between teams and the project manager. Today we have many modes of communication from which to choose. The concern remains the same, however: How to ensure that the communications remain coherent and coordinated? The project plan should inform and facilitate appropriate targeting of communications, Who needs to know what, and when? are the fundamental questions. Shotgun communication, spraying everyone with everything, is a direct route to project failure!
“The teams are working together so well. Normally they would be throwing hammers at each other!” commented a senior building inspector involved in the four-hour house. Many projects are set up to work within functional boundaries and for a good reason. Functional groups generally work best within their own function. Many of the most valuable projects, however, involve cross-functional transient team structures, with groups having to find ways of working together, crossing existing functional and cultural team boundaries. Work, which requires acting outside these boundaries, is more difficult to achieve. So, are there any good ways?
In the four-hour house, perhaps the critical contributor to the successful cross-team work was the competition itself. This unusual situation created the motivation for teams to act in the best interests of the project rather than focus on narrow functional agendas. The collaborative involvement in the planning provided broader visibility and transparency on what was to be achieved. The planning process essentially gave the teams ‘permission’ to look over the fence and seek out approaches to optimizing productivity in how they engaged with other teams.
This situation can be simulated in more everyday projects, and in time-constrained projects, it may well be worth the effort. In a post-merger project in which the end-date was immovable, and there were seven teams from different functions collaborating, two objects were swapped between the teams. One was a plaster cast of a hot potato. This was given to the team that was causing delay. No team wanted it and tried hard to get rid of it as quickly as possible. The second was a small anvil with two acorns on it. This was given to the team that was working on time-critical activities and was a sign they should not be interrupted without a serious reason. The results were extraordinary! Motivation levels were high, communication within and especially between the groups was excellent, and the outcome was an impressively performing on-time project.
This need to find ways of engaging with other teams in supportive ways was captured well in an interview with a portfolio manager in a leading South African-based grocery retailer. She explained some of the benefits that they were getting from using techniques such as Kanban and Jira.
We are not a full-blown Agile environment,” she said,“But we’ve found that techniques such as work-in-progress, job-cards and streams have been a very effective way of building energy, commitment, and collaboration between technical teams, and invites much closer business ownership.
They had found that by sharing and making visible the ‘to-dos,’ issues, and challenges, the contributing teams found more collaborative solutions. The teams could see the problems and then work together to find answers, which they would not have found on their own.
Protecting the End-Date
In any project, even one as meticulously planned as the four-hour house, problems will arise to which the project will have to react quickly. Many can be anticipated and management actions formulated on what might be done should the situation arise. This is the basis of sound risk management—the identification of possible events and forethought around actions to be taken to reduce or deal with any negative impacts should they arise.
For the four-hour house, the possibility of rain was a real concern. Of course, rain of itself is not a risk—it’s just something that could happen. The actual risk, appropriately stated, is that if it should rain, the timing of various processes will be extended (the consequence or impact of rain falling). Given the time constraints within which the project is operating, this is a genuine threat. In a time-constrained project, the first consideration must be how events and their consequences may affect the end-date.
You can see how the constraint simplifies the identification of appropriate risk strategies and management actions. You can’t avoid rain, and you can’t transfer the risk. You can reduce the likelihood of it raining by choosing the time of year and picking a ‘window’ of predicted good weather, but for the rest, it means protecting yourself against the worst of the delays caused by wetting. It should also be clear that ‘fix-on-failure’ or mitigation is not an option. So, it means spending money ahead of the possible event. (See Figure 2.6.)
Figure 2.6 Risk management actions options tree
Breaking Process Norms
Several years ago, we were working on a severely time-constrained project, which involved the demutualization of a major insurance company in the UK. Legislation demanded that the company ensured its name always correctly reflected its legal status. To ensure compliance, and to avoid expensive legal issues, before demutualization the company had to use its old name, and after demutualization, all public documentation had to use the new name. This program, with a legally determined fixed end-date, was made more complicated by the fact that the actual demutualization date had to be kept secret from all but the inner circle of managers to guard against insider dealing.
One of the projects in the program was set up to ensure all documentation and external references (websites, and so on) would be ready to be moved to the new company name on the required date—called D-Day. The first problem was precisely how many such documents were there? Acknowledging that it was possible that some might be missed, the sponsor demanded that no outbound document could leave the building on, or for 10 days after D-Day without authorization from one of six people. To give you a feel for the size of the problem, by D-Day minus 10, about 5,000 legally binding outbound documents had been identified, with perhaps six times that number of internal documents. All of them had been or had to be altered.
How to make all these changes and meet the strict deadline? The process in place for all legally binding documents was that any change had to be approved, and in many cases to be carried out, by the compliance team. At that time, the company’s actuarial team always carried out compliance.
Initially, they were actively involved in the planning process, and their estimate for completing the checks was in the order of three calendar years. An answer that paid tribute to the thoroughness of their procedures, and their incomprehension of the needs of the business! Even finding more of these very scarce resources—a pretty long shot—would make little difference to meeting the hard deadline. An impasse resulted with the compliance team insisting this was the way it had to be done, and the project rejecting their estimates as unacceptable.
The most senior of the stakeholders got involved. The project team planners and the compliance teams were brought together and the reality of the hard constraints—the legal deadline—was used to force a shared exploration of how to solve the problem. For this project, it was finally agreed that the ‘normal’ process just could not be used. Working as a task force, the actuaries and the project members worked to solve the problem: How do we deliver sufficiently ‘safe’ legally binding words in 5,000 documents in seven elapsed months? Once the problem had been set out in the right terms, the players found the solution.
In the four-hour house, one of the most extended elapsed time activities was the concreting of the foundations and floor. Concrete, mixed and laid conventionally, typically takes three to four days to dry before it can be built on safely, which the teams just didn’t have. During the planning stages, various solutions were considered, and in the end, the chosen process involved chemically heating the concrete. This hot concrete could be poured and would be walkable on within 20 minutes. More expensive, a higher risk than the normal process, but a process that would meet the primary constraint for their project—being quick!
In time-constrained projects, operational processes, resourcing solutions, and their associated risks, which are the standard ways to do things, may have to be modified to deliver the project outcomes. Innovation and creativity must be encouraged to allow team members to come up with new ways of achieving the desired outputs and outcomes.
The relationship between the project constraints and the way the project’s products are to be delivered has to be considered in the early stages of the project planning.
This is the first example where the standard CPPRRSS sequence is modified (see Figure 2.7.) The impact of the time constraint on the choice of processes may affect the product set. For this project, concrete is now an aggregate created using chemically heated components. A tight iteration between product and process is a common experience when ‘time is of the essence.’
Figure 2.7 The planning steps when time is the top constraint
In a different environment, the patching and completing of plasterboard ceilings using a bucket as a platform might be considered risky, but the risk to the end-date takes priority over the risk to a ricked ankle. Projects are about planning to achieve the desired objective, not a work environment designed to accommodate the worries of the world, though ignoring safety is not a recommended practice.
Fast-Tracking or Crashing the Schedule
Fast-tracking means compressing a schedule, not by working faster or changing processes, but by spreading the work across resources working concurrently, introducing parallel tasks as opposed to serial processing.
Let’s consider a simple project: We need to dig a trench, lay a pipe, and then fill in afterward. It takes three days to dig the trench, one day to lay the pipe, and two days to fill in and make neat. So with one person, let’s call him Chris, it’s going to take six days. You could crack the whip or attempt to incentivize with gifts, but Chris will pretty much take the time it takes him. The situation is set out in Figure 2.8.
Now suppose after a day of digging, Mary starts to lay the pipe in the bit of trench already dug. She’ll have some hanging about to do because laying pipe is much quicker than digging. And then there’s Ken, who as soon as a length of pipe has been laid fills in and neatens up. He’ll also be kept waiting quite a lot, but here’s the thing—done right the ‘dig, lay, fill’ project would be finished in just a little over three days. That’s fast-tracking.
Figure 2.8 Dig-lay-fill
Figure 2.9 Four types of link in a directed network
In the four-hour house, one example of fast-tracking is the roof being built separately and in parallel with the floors and wall going up. Normally the roof would not be started until the walls were up. The roof is then built to fit the walls. Scheduling parallel activities, and doing things in unusual sequences, introduces risks. Building the roof before the walls means that the tolerances for the building of the walls are much tighter—the roof has to fit when it’s lowered onto the walls! Another new process and an expensive one is also required—we need a crane with a very skilled crane operator. Once again, the interplay between constraints and processes are influencing the planning process.
Crashing a schedule, adding more resource, does occasionally work, but it is a lot less valuable than inexperienced project managers believe. Just as a thought experiment, how many people can effectively paint the inside of a broom cupboard?
A Detailed Schedule
How often do you use your schedule to determine, dictate even, what your resources will do, hour by hour, minute by minute? It may be no surprise that on the four-hour house project the schedule listed the duration of every activity in great detail. You can see how necessary it might be to keep so many people coordinated.
Perhaps what may be more surprising is the level of detail required to control the transfer-to-operations stage used on a technical project that introduced a new capability to an insurance company. With the business demanding 24/7 availability of its operational systems, it had become increasingly difficult to schedule in major systems upgrades. Table 2.1 is an extract from a schedule controlling the migration of updates to a business-critical IT system.
It had to be done over the weekend, and the plan included a rollback process should things go wrong. Everything (either the completely recovered old system or the fully functioning new one) had to be up and working on Monday morning—without fail. The level of attention to detail of the scheduling and the intensive communications to ensure the coordinated input from a variety of stakeholders is a perfect example of how planning can support the delivery of capability within tight time constraints.
Table 2.1 Detailed scheduling of implementing a business-critical system
|
Event |
Comms groups |
Description |
Method |
Time |
||
|
ManCo |
Techs |
Testers |
||||
|
Milestone 1 communication |
X |
X |
X |
SMS |
07h00 |
|
|
Checkpoint 1 |
X |
Key technical resources to confirm completion of packed physical server and commencement of transportation to CDC per SMS |
SMS |
09h00 |
||
|
Checkpoint 2 communication |
X |
Key technical resources to confirm start-up of the physical server at CDC |
SMS |
10h30 |
||
|
Milestone 2 communication |
X |
X |
X |
Environmental update as to physical server delivered and start-up at CDC |
SMS |
11h00 |
|
Checkpoint 4 |
X |
Stand-alone VM storage. Synchronize source and target volumes completed |
SMS |
12h00 |
||
|
Checkpoint 5 |
X |
Un-map storage mappings in DC2 completed for standalone systems |
SMS |
13h00 |
||
|
Milestone 4 communication |
X |
X |
X |
Environmental update as to physical server installation completed successfully at CDC |
SMS |
14h00 |
|
And so on until final go/no-go decision |
||||||
|
Checkpoint 9 |
X |
X |
X |
Go/no-go decision |
Conference call |
21h01 |
The plan identified when and where it was necessary to schedule at this level of detail—not all parts of a project will gain any benefit from this approach. An obvious problem when micro-scheduling is that any delay or acceleration will cause the timing and sometimes the sequence to become invalid. One of the genuinely brilliant aspects of the planning of the four-hour house was that the detailed schedule not only included start times, and finish times but it also dealt with how to handle delays and opportunities—events that occur that provide earlier-than-expected completed tasks. Opportunity management—the opposite of risk management—is a genuine, if somewhat underused, discipline in project management. In the context of scheduling, it is how to implement ‘as soon as possible’ (ASAP) scheduling, without dislocating the sequencing of tasks and introducing non-productive ‘wait’ states.
What Do We Mean by End-Date?
For the four-hour house, giving an end-date was easy; it was later that day! Project managers, when asked, will usually volunteer an end-date, or a ‘completion’ date, for example, August. Incidentally, when pressed, it always seems that it is the end of the month. The truth is, however, that less than 20 percent of projects are genuinely end-date driven. The dates given are not deadlines: they are either:
- Estimated dates: baseline finish dates that have been calculated based on a task-sequencing tool. These vary over the life of the project as the level of certainty around what is to be delivered and how long the tasks will take, fluctuates
- Target dates: a date agreed with the sponsor as a target, but with the understanding that it can be renegotiated should it become necessary to do so. Targets are not constraints—unless, of course, the sponsor makes them so.
And this is important! The target date may be regarded as a deadline, but it is not treated as a drop-dead end-date. It is not the primary driver as it is not at the apex of the hierarchy of constraints. It will, therefore not be the factor driving the behavior and approach of the project manager.
When we were researching the characteristics of successful project managers, we found that high-performing project managers (HPGs) were acutely aware of what the constraints were on their project, and adapted their approach and planning techniques accordingly.
For example, when scheduling time-constrained projects, HPGs worked backwards from the end-date rather than forwards from the start date. They found it more helpful to recursively ask, “When do I have to finish by?” than to try to develop optimum schedules and then apply constraints to provide the working schedule. They would also ask, “Can we deliver the scope with the current processes and resources?” If the answer to this question was “No,” then they would revisit the plan and adjust the processes or the scope, rather than making often infeasible and unsupportable assumptions about productivity and completion rates to make the schedule work.
Time-constrained projects can be tough on teams; they may involve hard work and lots of overtime. However, our research suggests that managerially, they are often less complex. With an understood, agreed and, most importantly, an immovable constraint—a genuine drop-dead deadline end-date—the compromises that have to be made are clear-cut. Either you meet the end-date—or you fail. It is much easier to manage when the conditions of success are clear.
Project managers can sometimes become typecast. For some, all the projects they do are end-date driven, or they think all projects are end-date driven. Either way, they adopt a single style and a single approach, and it can get them into trouble.
In one notable case, we tracked an IT project manager who had completed three successful time-constrained projects in a row. With such a track record, she was the obvious first choice for a most important project. This project, however, was not time-constrained. Its critical success factor—its topmost constraint—was creating and maintaining intensive collaboration with several business stakeholders.
She struggled and struggled with this project and was eventually taken off it. In the lessons-learned review, it became apparent that she had continued to plan and use a style, which had worked well for her on the previous projects—“We have to get it done in this time frame.” However, that just was not the case on this project. The sponsor knew that the project’s success depended on active and willing engagement from important stakeholders. As for timing, as far as the sponsor was concerned, today would be fine, or tomorrow; but in fact, whatever the date was when the stakeholders reached a consensus was the right date. The project manager did not understand how to do that, or how to plan a project that had to reflect the voice of the stakeholders. Her approach and her planning style were directive and forceful: necessary to drive forward time-constrained project, not so useful when creating collaborative alliances.
Recognizing a Time-Constrained Project
Time-constrained projects arise from four external drivers:
- Window-of-opportunity—the value of completing the project is severely compromised if delivery is late, for example producing a game for the Christmas market
- Compliance—meeting a legislated delivery date, for instance becoming compliant with new privacy laws for personal data
- End-of-life—increased risk of unprotected catastrophic failure caused by using systems and products after their predicted shelf-life, for example using obsolete switching gear
- Public commitments—exposing the organization to public ridicule or genuine reputational risk, for example, the opening event of the Olympic Games
In each of these cases, the significance of meeting the end-date varies depending upon the sponsor’s view of the risk exposure, or loss of benefit, they are prepared to countenance. Missing a legislative compliance date may result in a fine, but the sponsor may decide that this is preferable to the additional costs associated with speeding up the delivery of the project. In a time-constrained project, the project manager must understand the sponsor’s position about the date.
There is a fifth cause of time-constrained projects. It’s called timeboxing.
Noticing the often-useful management effects of rigidly maintained time constraints on projects some software development methodologies—notably DSDM and RAD—adopted the imposition of rigid time constraints on the product development process.
In the right circumstances and for the right products, a time-boxed approach works. Its value arises from the impact on what management is obliged to implement to meet its obligations driven by the temporal constraint. Done well, and using the time constraint as a driver for innovation in tasking and resourcing, it is a powerful productivity tool.
Implemented poorly, the time constraint becomes an excuse for de-scoping with disappointing results. There are many circumstances where the imposition of an unnecessary time-constraint leads to trouble, including situations where incurring the associated technical debt is unacceptable. Whatever else it may be, timeboxing is not a panacea for every project.
Strategies for Planning Time-Bound Projects
As we see in the four-hour house, where an end-date must be met, the planning process changes. The standard product-to-process stepwise elaboration is not productive. These two need to be considered together in a close iteration, mediated by the impact that the candidate processes have on elapsed time. Planning under time constraints always demands more effort in planning, not less. It is essential, therefore, that the project manager engages with the stakeholders so that they become aware of this and in so doing resists the just ‘get on with it’ pressure so often applied by them.
Table 2.2 summarizes time-constrained project planning strategies. If ‘time is of the essence’ for your project; if you need to bring in your project in tight time-scales, use this as a checklist of actions.
Table 2.2 Possible time-constrained project planning strategies
|
Strategy |
Tactics |
|
‘Crash’ the schedule—add resources |
Working with larger numbers of resources influences the way work is structured, scheduled, and communicated. Model activities and allocations to make sure you can apply these resources productively. Remember the bigger the team resources; the less productive each member will be. And, more resources and more tasks mean greater monitoring |
|
Identify elapsed time delays, those activities which are not compressible using existing processes |
Develop new processes, which allow products to be delivered faster. Process experts may not be your best source—they tend to be naysayers. Remember new procedures will create new types of errors, and you won’t have prepared ways to correct them. So test and monitor more |
|
Identify delays which may be introduced because of decision making processes |
Ensure clarity on who makes what decisions and stick to it. Factor in decision making; bring governance closer to the project. Delayed issue resolution is likely to kill your project |
|
Fast-track the schedule—look for ways of breaking dependencies between activities |
Evaluate and manage the additional risks associated with changing the standard dependency structures. Identify management actions and include in plans. Parallel tasks increase resources and risks, so increase monitoring. Remember to investigate Start-to-Start with lag times sequencing rather the Finish-to-Start serial sequencing |
|
Identify resource skills gaps up front |
Whenever a task demands effort from a specific resource, spend the time to try to eliminate it—it is a significant risk on time-constrained projects. If that is not possible, make the attaining and managing of that person as a CSF for the project |
|
Communicate and re-communicate the purpose, objective, CSFs, and value of the project throughout the project’s lifecycle |
Find ways in meetings and one-on-ones to rehearse the mission of the project with every member of the project team—and in the steering group—and keep checking back with the sponsor that nothing has changed |
|
Identify foreseeable problems (risks) |
No risk statement should be logged unless there is at least one management action associated with it. Most ‘fix-on-failure’ solutions will cost more in time and money than the other four risk strategies. In time-constrained projects, making good is the least favored option |
|
Be prepared for unforeseen problems |
Schedule milestones, and if necessary inch pebbles. Only schedule at the level of detail that reflects your level of uncertainty. The less you know, the greater the detail! Remember schedules are the most volatile project document. Expect to change it frequently to account for the unplanned circumstances |
Reflections
It is likely that most of you reading this will have been exposed to a time-bound project, even if it wasn’t quite a four-hour house! Consider for your projects:
- When planning a time-constrained project do you have an option to negotiate the end-date? If it really is immovable, what is the reason: window-of-opportunity, compliance, end-of-life, public commitment, or something else?
- Have you used any of the strategies described in Table 2.2? Are there any others you have found useful when managing time-constrained projects?
- If you have used Agile as a development approach, do you consider timeboxing to be a way of controlling effort, or stimulating creativity? What additional risks are caused when applying rigid time-constraints to a project?
- What techniques do you find most useful when monitoring a time-constrained project? Does your plan support this easily? How different are these from those you use in other types of projects?
- When scheduling time-constrained projects, which of these approaches do you find useful, and in what ways?
- Effort-time analysis and sequencing of tasks
- Calendar-time sequencing of tasks
- Dependency graphing using:
- FS, SS, FF, SF (S = Start F = Finish)
- Critical chain
- Gantt charting