Monthly Archives: October 2013

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:

  1. A common understanding of capacity
  2. A common understanding of the work to be done
  3. 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.

Schedule a Consultation

Click Here

It’s rare to find a project without a deadline.  Due dates and deadlines drive the entire project management process.  I’m not talking about the dates for each task (which is wise to avoid), but dates that drive task priorities.

Projects can have a single date for completion and for important milestones like progress payments, client reviews, feature releases, etc.  These are the dates.  The important ones.  Where we get paid.

Managing (and meeting) the dates and deadlines in a project is touchy even for the teams that see each other every day.  In a previous post, I talked about the communication problems of distributed teams and the importance of managing content.  Dates are often the most important bit of content to get right.

Distributed teams have a much more difficult time with due dates and deadlines for the following reasons:

Haystack Syndrome: The amount of data, unimportant and important, coming from multiple sources overwhelms team members so no one can form an accurate picture of the true progress.  How to find the most critical bit of information that affects the deadline?  Project teams spend a lot of time sifting through data, working to identify the most important.  When they’re far apart, just finding the data is a challenge.

Reliability:  Project managers need to ensure that their whole team has the correct information that affects delivery and deadline dates.  Team members in distributed teams sometimes withhold information, obscure the real situation, or delay providing negative information, hoping that the situation gets better.  This is particularly true working in cross-cultural teams, where delivering bad news can create a problem in a local team.

Inconsistent vision:  Most people work in their own bubble of their own tasks, unaware of the big picture of the project and how their work fits.  What is important is not always recognized.

Managers of remote teams are often frustrated with their inability to get traction on meeting deadlines.  The challenge is to get the entire team focused on a common set of objectives – including dates.  If you’re not present in the work area, the number of options is fairly limited.

Project managers need a tool one that provides a

-Single consistent window for seeing progress across all task elements and locations, in real time

– Shared view of project status

-Shared view of the obstacles

-Shared understanding of the work to be done to overcome those obstacles

One of our clients found itself a victim of success, struggling to meet critical delivery due dates for a new product that had much higher demand than forecasted.  The company had components from 5 different suppliers tested by 2 different subcontractors.  Part of the solution we helped them implement was a visual project board.  It was good for the local team, but the need for remote collaboration was critical.  We developed and implemented a date – driven visual project board web app that allowed every team member at remote suppliers to see the project’s status, identify the critical bits of information, and collaborate (without losing face) on accelerating progress.  Getting everyone on board with the same deadlines was a critical element in the success of the project, which in the end resulted in improvements in product flow and delivery reliability.  They also found 5 times more capacity, quadrupled output, and reduced lead-time by 23%.  And of course, most importantly, the delivery dates were achieved.  And they got paid.  A lot.  You can get more detail on the viewpoint case study here

Read more about our solutions to the problems distributed teams face and other success stories of the solution implementations in our new eBook, Remote Control: How to Get Productive Teamwork from Distributed Project Teams

Schedule a Consultation

Click Here

It’s rare to find a project without a deadline.  Due dates and deadlines drive the entire project management process.  I’m not talking about the dates for each task (which is wise to avoid), but dates that drive task priorities.

Projects can have a single date for completion and for important milestones like progress payments, client reviews, feature releases, etc.  These are the dates.  The important ones.  Where we get paid.

Managing (and meeting) the dates and deadlines in a project is touchy even for the teams that see each other every day.  In a previous post, I talked about the communication problems of distributed teams and the importance of managing content.  Dates are often the most important bit of content to get right.

Distributed teams have a much more difficult time with due dates and deadlines for the following reasons:

Haystack Syndrome: The amount of data, unimportant and important, coming from multiple sources overwhelms team members so no one can form an accurate picture of the true progress.  How to find the most critical bit of information that affects the deadline?  Project teams spend a lot of time sifting through data, working to identify the most important.  When they’re far apart, just finding the data is a challenge.

Reliability:  Project managers need to ensure that their whole team has the correct information that affects delivery and deadline dates.  Team members in distributed teams sometimes withhold information, obscure the real situation, or delay providing negative information, hoping that the situation gets better.  This is particularly true working in cross-cultural teams, where delivering bad news can create a problem in a local team.

Inconsistent vision:  Most people work in their own bubble of their own tasks, unaware of the big picture of the project and how their work fits.  What is important is not always recognized.

Managers of remote teams are often frustrated with their inability to get traction on meeting deadlines.  The challenge is to get the entire team focused on a common set of objectives – including dates.  If you’re not present in the work area, the number of options is fairly limited.

Project managers need a tool one that provides a

-Single consistent window for seeing progress across all task elements and locations, in real time

– Shared view of project status

-Shared view of the obstacles

-Shared understanding of the work to be done to overcome those obstacles

One of our clients found itself a victim of success, struggling to meet critical delivery due dates for a new product that had much higher demand than forecasted.  The company had components from 5 different suppliers tested by 2 different subcontractors.  Part of the solution we helped them implement was a visual project board.  It was good for the local team, but the need for remote collaboration was critical.  We developed and implemented a date – driven visual project board web app that allowed every team member at remote suppliers to see the project’s status, identify the critical bits of information, and collaborate (without losing face) on accelerating progress.  Getting everyone on board with the same deadlines was a critical element in the success of the project, which in the end resulted in improvements in product flow and delivery reliability.  They also found 5 times more capacity, quadrupled output, and reduced lead-time by 23%.  And of course, most importantly, the delivery dates were achieved.  And they got paid.  A lot.  You can get more detail on the viewpoint case study here

Read more about our solutions to the problems distributed teams face and other success stories of the solution implementations in our new eBook, Remote Control: How to Get Productive Teamwork from Distributed Project Teams

Schedule a Consultation

Click Here