Effective IT is an absolutely critical component of any organization expecting to survive. One of the main objectives of the IT Infrastructure Library® (ITL®) is to provide the capabilities required to survive and thrive in the global economy.
ITIL is important, but does not stand alone. Best practice for implementing ITIL calls for the use of Project Management.
Within Project Management, there are two basic methods: critical path and critical chain.
Critical Path scheduling and management, the most common method in use today, is almost 100 years old, and has remained remarkably unchanged since its inception. Critical Chain is a far more recent evolution that provides dramatic improvements in both completion time and costs when properly utilized.
Critical Chain can be so much more effective one might wonder why not everyone has switched. The answer is that like ITIL itself, it is not so much sweeping and dramatic change that is required, but rather a change in point of view.
Following I describe both methodologies, and explain how to accelerate any project, including ITIL implementation.
Peculiarly, the business world has come to prize predictability above all else. For public corporations, should the company's financial results deviate from analysts expectations by more than a few percentage points, the market is likely to react negatively, even if the company makes more money than expected. The absurdity is obvious, particularly as it relates to projects. The only way to assure that projects meet their time and budget projections is to wildly over-estimate, then sand-bag at critical junctures if things are going well, all the while being prepared with elaborate but plausible explanations if things are going poorly.
While lamentably this may be true (and inescapable) for the enterprise at large, it does not have to apply to the subgroup of information technology, particularly under an ITIL-compliant strategy of aligning IT to business need and business urgency. If IT can deliver better faster cheaper technology closely aligned to and supporting the goals of the enterprise, the enterprise is freed to make better decisions.
Both Critical Path and Critical Chain initially focus upon the deliverables required to fulfill the project, tasks to be performed and the order in which they must be performed, any dependencies between tasks, and finally identification of the resources required to perform the tasks and the estimates of time required to perform these tasks.
Where they differ is most obvious and pronounced in the estimating activity. In Critical Path, each task is estimated, but then a buffer is added to reflect the degree of uncertainty that the estimate is correct. The primary flaw in this approach is that the schedule is based upon the duration of the task and its associated buffer. Should a task be completed ahead of schedule (almost unheard of), the resources for succeeding tasks are rarely able to re-arrange their schedules to accommodate. So, gains are rarely useful, but worse, any delay to the Critical Path activities results in a delay to the completion of the project as a whole.
In many ways, Critical Chain is just the application of common sense. In Critical Chain, the same estimate is made, but no buffer is provided at the task level. Instead, all buffers for all tasks are combined and applied to the whole project, not just to the task. There are a few rules however.
One is that estimates must be honest and specific, based upon the actual hours required under optimum circumstances to perform the task. Let's use an example. You, the reader, are asked to estimate how long a task will take you to complete. You think, "This is probably a week's worth of effort, but to be safe I'll estimate two weeks." Nothing wrong here, but in actual execution most people are likely to procrastinate. They do not start when they are expected to, in effect "burning" their buffer, so that if "worst case" comes to pass, delay of the whole project is inevitable.
Along similar lines, estimates are often reflective of the resource's normal work environment; in other words, the resource plans to "multi-task." Estimates should be based upon the assumption that the resource will not be multi-tasking. Project work usually requires a high degree of focus. Interruptions for any reason dramatically rob throughput.
It has been proven that for people doing work requiring concentration (like writing software, writing processes, accounting, configuring servers, testing) recovery from something like a phone call or a conversation with "the boss" takes 30-45 minutes to return to the previous level of concentration regardless the outcome of the interruption. This means that 50% or more of a given workday can be spent recovering from interruptions in concentration! In Critical Chain, multi-tasking is not allowed. When a resource is working on a project, that project is to be the exclusive focus. No resource is allowed to "multi-task".
"But what about emergencies?" you might ask. The answer is simple. During emergencies, the resource is released from the project for only as long as their contribution to the solution of the emergency is required, then back to the project. Any time losses are taken from the project buffer, and managed accordingly.
Which leads to another key concept: Projects must be estimated reflecting the need for buffers. If the actual truthful estimate is 6 months, a project buffer of 6 months must also be provided. In other words, the project should be expected to require a full year, even though the sum of the tasks is half that. But, and here is the key, it is entirely possible that the project might be completed in far less time under Critical Chain management, where it is almost impossible under Critical Path.
With Critical Chain, communications and cooperation between all members of the project team and stakeholders are critical. Each resource (and their managers) understands that the schedule is just an approximation, subject to change with notice, and that they must accommodate to the best of their ability. Each also knows that any project worth doing at all is done because it provides significant business value and is driven by business urgency. This leads to a brief few comments on the founder of Critical Chain, Elijahu Goldratt, author of "The Goal" (focused upon manufacturing), "Critical Chain" (focused upon project management), "Necessary but not Sufficient" (focused upon utilization of ERP systems), and a number of equally excellent business novels based upon his Theory of Constraints (TOC).
In a highly simplified explanation, Theory of Constraints postulates that every system has a goal (for example, business has the goal of making money, projects have a goal of meeting requirements on time and on budget) and that there exists in every system constraints (usually one, occasionally two, rarely more) that if relieved cause dramatic improvement in the throughput of that system.
However, when a constraint is relieved a new one inevitably takes its place. Therefore, the goal of management is to constantly identify and relieve constraints, thus continually improving the throughput of the system. It is important to note here that in order to relieve a constraint there must be excess capacity on either side of the constraint. This means that concepts of "efficiency" must be re-evaluated. Efficiency has to be viewed from the point of view of the throughput of the whole system, not from the sum of its parts.
It therefore follows that only projects that improve a business's ability to meet its' goals should be undertaken. This of course is entirely consistent with ITIL. If IT projects are closely aligned with business need and business urgency, it follows that supporting those projects will be of high priority to management throughout the enterprise. Woe to the manager who fails to support fully business imperative projects!
Following are the simple Rules of Critical Chain: