In my last blog post, I talked about how to manage deadlines when your teams are geographically dispersed. How to create those deadlines? Anyone can guess – and we do – a lot. Sometimes, those guesses actually work out. But not often.
Project teams try to sidestep making date commitments, especially in product and software development, where technical uncertainty is high and the project process is iterative. (How many times will that release go to test? As many as it takes.) Teams are reluctant to make a completion date commitment, but commitments must be made. When customers and management are asking when that project will be done, you must provide a realistic date – or at least a date based on something other than gut feel.
In this post, I’m not going to talk about the element of technical uncertainty in projects, but a different kind of uncertainty that is applicable to all projects; that of the work to be done versus the availability of resources to get that work done. When your teams are distributed, it’s hard to define the overall capacity available for your project.
Identifying that capacity is difficult because:
There is a Lack of Visibility – It’s difficult or impossible for managers to catalog all skill sets and resources from all regions/locations into one comprehensive understanding of available capability. Where is the data? How do we access it?
Accuracy – Local suppliers and managers, even if they’re willing to openly share their capabilities, often lack an accurate assessment of their own capacities. We know this because they tell us, over and over, “Don’t worry, we’ve got this.” Then repeatedly miss their commitments.
Lack of Commonality – It is often difficult to equate resources from different locations. We see that project teams put their resources by people, not skills. It makes it difficult to find an “Ajay” in Denver just like the one you have Mumbai. Even when project teams classify resources by skill set, a resource classified as a “senior engineer” in Houston will have an entirely different skill set as the one in in Oslo. Even minor differences in the definitions that provide a basis for modeling resources (job titles, descriptions, roles and responsibilities) render resource planning models unusable or, at a minimum, unreliable.
Multiply these challenges across locations, cultures, varying work practices, time zones and local agendas, and the scope of the task gets much, much more complex. Remember, the goal here is to get a date that can be trusted – upon which other stakeholders can base their activities.
In essence, delivering reliable commitments requires:
- A common understanding of capacity
- A common understanding of the work to be done
- A process / mechanism to reconcile the two
Items one and two need not be too granular or precise; there is too much uncertainty in projects to be precise. However, you should get something meaningful and workable. The most important is item 3 – reconciliation. If you do item 3, items 1 and 2 take care of themselves.
In 2010, after the Macondo oil spill was capped, BP needed to decontaminate and re-commission thousands of vessels at multiple sites, around the Gulf of Mexico from Tampa on the east to Texas City on the west. We treated the sites like a big factory, with a multiple work centers (that were very far apart), and saw the entire process like an assembly line. This perspective allowed us to better visualize the flow and create a process to rapidly (and safely) process the vessels.
We were unable to know in advance how much work each vessel required, or to which site the vessel would be entering. There was a great deal of technical uncertainty as well as work uncertainty. Some vessels were large, some were small. Some required working in dangerous enclosed spaces, others simply required cleaning the deck and hull. We did not know precisely what we had until the vessel appeared at the decontamination site.
Despite these uncertainties, the vessel owners, the US Coast Guard, BP Management, and BP shareholders demanded to know when the decontamination effort would be concluded. Hundreds of millions of dollars were at stake, not to mention the potential long-term environmental impact.
So we created a unit of capacity based on the system’s constraint (which we designed into the workflow). The constraint was the amount of dock space (measured in feet) and the unit of measure for capacity was feet decontaminated per hour. Based on the estimated number of vessel feet (total number of vessels multiplied by their average size) we could estimate the total work. Measuring the rate of cleaning (feet per hour), we could arrive at a reliable, educated estimate of the completion date.
We developed a formalized communication process on capacity utilization and planned progress charts. As a result of the timely communication of capacity, specific actions were taken that increased the rate of vessel cleaning and reduced the cost of the cleanup activities.
This understanding also helped us identify work blockages. At one site, we found that only half of the available space was being used. This helped mobilize action to increase utilization and accelerate the overall process.
Having the capacity information helped management assess the situation make better decisions that had an immediate impact on the process. The end result was the project was completed in a third of the time and hundreds of millions of dollars under budget.
We overcame Lack of Visibility by providing daily reports at the local level that were shared across functionally and vertically through a daily email and management briefing.
We overcame the Accuracy hurdle by making the unit of measure simple – measure the constraint capacity of each site and the daily consumption.
We overcame the Lack of Commonality obstacle by understanding the overall system’s constraint and how each site related to that constraint. We had the luxury of designing the constraint into the process, but we also responded to the natural availability of resources to the work to be done in that decision.
In order to understand the system’s capacity, you don’t need sophistication, you need creativity. Capacity is not necessarily measured in hours. Find a unit of measure that’s meaningful to your process. Identify the constraint. Build the model and the feedback loop. You’ll be on your way to delivering reliable delivery dates.
Read more about basing promises on an enterprise-wide understanding of capacity in our new eBook, Remote Control: How to Get Productive Teamwork from Distributed Project Teams.