Earlier, I had posted how the concept theory of constraints (ToC) can be used for effective offshore communication. Those familiar with ToC might wonder why not apply the Critical Chain methodology, which is a project methodology offshoot of the ToC, for the entire software project itself. I've seen this implemented in some companies fairly rigorously for software projects and think that it's a great idea, but with a few caveats.
Critical Chain Methodology
First, a quick primer on CCM. The project methodology that most of us are familiar with, thanks to Microsoft Project, is called critical path - where the time needed to complete a project is based on the longest sequence of events. The focus in this methodology is on tasks and their schedule. Any unknowns are typically factored into each task by means of a slight buffer. For example, if a task would take 2 days to complete, it's typically calculated as 3 days, adding 1 day for potential delays or distractions.
On the other hand critical chain methodology focuses on the resources involved in the project and on the longest chain of resource constraints that would be need to complete a project. The concept is quite good and has been reported to help projects get completed 10% - 20% before the estimated date.
The primary difference between the two is that with critical chain you pool the buffer time for each task rather than include it with the task itself. So, essentially, the schedule is created based on the 'pure' time needed to complete a task (called 'focus' time) and not on the 'buffered' time. All the buffers are then pooled into a 'project' buffer (at the end of the project) or a 'feeding' buffer (at the end of each chain of tasks). Thus, you don't essentially say you'll complete the project at a certain date, but rather within a range, where the end date equals the date you'd calculate using critical path.
The catch - Consultants and Offshore teams
This all sounds good. So, what's the catch? If your project is completely onshore and does not use any consultants, then there is almost no catch. The concept works very well once people are trained to understand the methodology -which is crucial to the success of the project. The methodology itself has its roots in manufacturing, where these assumptions are mostly true.
The problem comes when you introduce either consultants or offshore teams, which is mostly true in case of software projects. As I mentioned earlier, CCM is a resource-based methodology and hence, has a strong emphasis on the resources and their linkages. When offshore teams are included in the mix, the problem arises due to time difference. Since the project plan itself is time-based and on dependencies between resources, it is difficult to capture the dependencies incorporating the time difference as well. While this is not impossible to capture, it just needs a bit more planning than usual to include this. This is in some sense true even for Critical Path plans, but becomes a bit more apparent here due to the emphasis on resources.
The second issue is when you include consultants. In CCM, resources would constantly shift tasks based on what is more important at a given point in time (as the critical chain would keep moving depending on the constraints at any given day). This is fine if all the resources are part of the same company.
However, let's say you have one consultant and one employee working on two dependent tasks. If the employee decides to move to another critical task for a day or two and not worry about the task that the consultant is dependent upon, what should the consultant do for the two days? Therein lies the issue. Ideally, you have to pay the consultant for sitting around because he's just dependent on another resource, but it may be hard to digest for the sponsor and the knee jerk reaction might be to ask them to do something 'useful', which may in turn, affect some other activity. This becomes more complex when multiple resources and projects are involved.
The other issue on the consultant's side is to create an invoice for the project. Usually, project plans are created where resources start low, ramp up, and finally ramp down close to launch, so as to minimize the overall cost of the project. This is fine as long as the project length is fixed and you know roughly when to on-board or roll-off a resource. However, with critical chain, the project timeline is a range and is not fixed. So, you'd have to create a range in your invoice potentially with an 'early completion' bonus or something similar, because you won't be sure exactly when to on-board or roll-off resources. This becomes messy when some high-value resources are in demand on other projects that don't use Critical Chain.
So, the bottom line is that Critical Chain is a great methodology and one that works really well. However, when brought into a software project, the three constraints - 1) consultants 2) offshore team, and 3) training (for both employees and consultants) must be considered before implementing it. Otherwise, you'll have a lot of headaches.
2 comments:
Sathya,
Great observations. Something that comes only from having worked on the trenches, I guess!
I am not familiar with the CCM that you explained so well. I do understand the emphasis on resources rather than tasks...So, what happens to Work Breakdown Structure/Gantt chart and stuff that we are so familar with?
Also, the estimation techniques mentioned in the wikipedia link closely resembles the Wide Band Delphi ( Best/Probable/Worst case estimates) estimation that we usually employ while sizing for features....
We first calculate the effort/estimates and then do resource loading traditionally, right? So, what you are saying here is that by using CCM, we first have to determine the players in the project and then figure out how the tasks can be done in the most efficient way? hmm...
And then we also have Scrum/Agile way of doing things, no? How does that fit into this?
True. I made the observations when I got the opportunity to manage a project using CCM for more than a year.
Gantt/Pert are essentially tools for Critical path. However, CCM uses a similar approach, but they call it Network Build. There are extensions to Microsoft Project that allow you to build a plan using CCM. There are also dedicated tools (popular being ProChain).
Not very familiar with Delphi - so not sure there...
Well, you don't exactly calculate resources first. You still go by tasks and link them. However, you would also assign roles for tasks and do resource leveling pretty much at every step. The big difference is that instead of adding buffer to every task, you are supposed to define tasks with 'core time' without any buffer (that is, how much effort would it take the resource(s) to complete the task if that's the only task that he would do without any distractions, including meetings, phone, etc.) and then buffer is added at the end of each chain as appropriate.
Actual player identification happens based on the roles.
During project run time, the other big difference between the two approaches is that the tasks priority kind of remains steady in the critical path methodology, while in the CCM, the task priority may change depending on whether your dependency completed the task you are dependent on.
Post a Comment