The Fallacy of of the Milestone Driven World

Someone once asked me to explain probability theory to them within the context of a roll of the dice. They didn’t understand why the chances of rolling a six after having already rolled five sixes, was still 1/6. “Isn’t it statistically improbably to roll six sixes in a row?”, they asked. Well, yes. But the probability of something happening depends upon the timing – in other words when you ask the question.

The probability of rolling six sixes in a row is approximately .002% (1/6 to the sixth power). So if you ask what are the chances of throwing six sixes in a row, before you’ve rolled the dice, then the probability is very low. If you’ve already thrown five sixes, and ask what the probability is of throwing a six on the next role, it is just the probability of the independent variable, which is 1/6. Dice have no memory – they don’t know they’ve already been thrown five times.

The point of this is that projects are a chain of dependent events. And, since all task duration estimates have a high degree of variability, the numbers used in those durations are not integers but rather probability distributions.

So, in any activity network, which is a chain of dependent events, the same probability issues exist. As such, the probability of each task (milestone) in a project occurring at the exact time it was planned in advance (keeping in mind that non-trivial projects often have led times in excess of 12 months) is actually very close to zero!

So, if any project environment shows that they have a very high degree of milestone due date adherence, one of two things is happening . . . either the tasks are finishing early and being held until the “due date” and then marked complete, or people are faking the data.

Because of the inherent variability, and the dependent nature of projects, the only thing that can be controlled is the start date and the completion date – all other activities between those two points must be allowed to float as positive and negative variability ensues.

Resource or Vendor – continued

So, now that we’ve established this wonderful “vendor – customer” relationship – complete, mind you, with “contracts” signed between resource groups and the project group – what happens?

At this point the company has essentially outsourced their project management function, in toto, to the product groups within their own company. This is absurd enough when it is other facilities, but as often as not these are resources and people within the same building! Yet, instead of endeavoring to create an integrated, holistic plan that accounts for all of the work on the project, they insist on breaking it up into several pieces, with no ability to see the impact any section has on the others or on the delivery of the project, as well as not having any visibility into any of the individual pieces.

The project manager, who will admit that they’re responsible for the entire project, controls the resources at the very front and the very end of the project – i.e. setting up the team, working on initial design reviews and freezes with the customer and then at the final delivery and commercial issues. Of course, budget issues, Earned Value, milestone adherence, etc. (reporting to the customer) is also their responsibility.

The diagram above illustrates the manner in which work flows in this client environment – which in and of itself is fine – work does, generally, get accomplished by resource functional areas. In this case, however, the company also breaks apart the planning, reporting, visibility, accountability, etc. – and drives not only sub-optimization but direct negative actions as well.

There are multiple project plans (project level and then each resource area) – rather than a single, cohesive, integrated plan that can show the status of the project as a whole.  There is no connection between the multiple project plans and all execute as though they are separate projects and exist in a vacuum.

In order to effectively manage this project, one must create a single, integrated project plan that captures all of the work (tasks) across the project level and the resource groups.  In doing this the project manager has visibility into the project as an integrated, dependent chain of activities as opposed to getting “updates” from various pieces of the project, without being able to see the dynamic impact of slips at any particular point on the project as a whole.

This week’s video client presentation comes from the US Navy Fleet Readiness Center courtesy of Realization Technologies.  Click here to watch.

Webinar: synchronous execution

Save the date!!

The next FREE webinar on Synchronous Execution is scheduled for November 8, 2011 at 1 PM Eastern.

Log-in information will be published this week!

Resource or Vendor?

The concept of resources not belonging to a project is nothing new – in fact it is the norm in today’s matrixed, distributed organizations.  Even the concept of resource groups or areas of technical concentration  in a functional (or product oriented) vertical is not unique.

However, recently I’ve been running into scenarios where the degree of separation is taken to such an extreme, that it is almost as though the organization was really made up of a bunch of separate companies.

Again, dividing companies into multiple division, departments, even profit centers (which, actually, drives to significant sub-optimization and bad decisions) is not new, but the application of that separation within a project management organization is.

I was recently working with a company whose project management organization is composed of projects and products.  Okay – not wanting to get caught up in semantics, I wasn’t concerned that why they called “product groups” I would ordinarily call “functional groups” – as far as I could see it was a fairly standard matrixed organization.

However, in further discussion, it became evident that the people at the “project level” – who are responsible for delivering something at the end of the project, didn’t consider the resource groups just as shared resources – they considered them almost “outside vendors” – in fact, they referred to themselves as the functional area’s “customer”.  Again, not wanting to get caught up in semantics, sometimes people use that word just to indicate to whom within a company someone is delivering something – i.e. if engineering is feeding manufacturing, then manufacturing is like their customer.

However, here it seemed much more literal.  The project level team is responsible for delivering the project, but each of what I would call functional areas (their product groups) are responsible for “delivering into inventory” their piece of the project.  Now, it’s not at all unusual to have outside vendor procurement tasks as part of a project – particularly long lead-time components – but in this case even the parts of the project being done by internal resources are treated as though they are coming from an outside supplier.

Both groups love this – the people doing the work get to pull it into the black hole of their organization with little in terms of visibility or transparency – they have complete autonomy.  The project teams like it because they can sit back and point to their “supplier” as not being responsive or delivering to their customer on time.

So what happens?  A complete decoupling and sub-optimization of the system – driving this home even further is the presence of multiple, department level profit and loss statements  . . . .

To be cont . . .

Next webinar: Project Management – Chaos to Control through Synchronous Execution – Sept. 9

Click here to register.

Or visit www.thegoalinstitute.com for more information.

 

 

Development Chain

Most people are familiar with the term “Supply Chain” – what many aren’t aware of is there is also a “Development Chain” – a chain which can be significant more difficult to manage.

The supply chain, of course, represents everything involved in the manufacturing process – from raw material and component vendor procurement, third-party out-sourced companies, inventory control, sales and marketing, manufacturing, distribution, and everything in between.

It isn’t that the development chain exists in isolation or this –  more like tangentially.  There is much parallelism, but also points where they touch.

A good example of a high level development chain model might be:

Portfolio Management —– Pipeline Management —– Project Management

This, of course, is in a most simplistic form.  And, at various point throughout this chain, it would intersect traditional supply chain tasks such as vendor approval, procurement, long-lead time procurement items, etc.

Portfolio management is primarily concerned with maximizing the return on the particular projects being worked – Return on Investment, Internal Rate of Return, cash flows, market share, market penetration, client groupings, etc.

Pipeline management is involves how do we coordinate, synchronize and effectively resource load all of the projects within particular portfolios.  Typical environments do this very poorly, if at all.  Functional leaders look at the number of resources they have, the number of projects available, and then start partially allocating their resources out to various tasks across the projects – as though any capacity plan of this type will ever execute effectively.  All it achieves is that the resource manager can show that his functional area are fully “utilized” i.e. loaded or allocated.

Project Management entails the actual work package / task level work itself – a discrete deliverable which can be defined, broken down, resource loaded, and against which one can execute.

There is also something I refer to as a “development continuum” – depending upon how far away a project is from the customer or “market” – the dynamics of a project change dramatically.  A basic development continuum – often in the range of five years or so, can be like this:

R&D – Base Technology Development – Advanced Technology Development – Product Development – Project Management – Market

The types and levels of variability within that continuum can be dramatically different – next issue we’ll begin to dive deeper into the development chain “continuum”.

Remember – the next free webinar on “Project Management: Chaos to Control with Synchronous Execution” is scheduled for August 12th at 1 pm Eastern Time.  Please click here to register.  Sign-in information will then be emailed to you.

This week’s video presentation comes to us from The US Navy at Pearl Harbor.  Click here to view.

Webinar!

Thanks again to all who attended the webinar on Friday, July 29th entitled “Project Management: From Chaos to Control with Synchronous Execution”.

The next webinar is scheduled for August 12th, 2011 at 1 pm eastern.

Details to follow!

Synchronization

The key to effective project management is synchronization – which, frankly, runs completely contrary to the way most organizations of any size are set up.  Ironically, conventional infrastructure is established in an effort to better management the various pieces – unfortunately, that is usually not the result.

As organizations grow, it becomes more and more difficult to maintain visibility of the holistic picture – that is to say when an organization is small, one can see and touch and manipulate the various pieces of the organization.  As it grows, and the number of resources and links in the chain explode, the ability to see all of the connections diminishes exponentially.

In order to try to maintain control of a large organization, typically management will begin dividing them up into various pieces – departments, divisions, projects, etc.

The idea, of course, is that these smaller pieces will be easier to control, and then if we can control the outputs of these various pieces, we can gain a higher level of control over the organization as a whole.

There are a slew of negative results that come out of doing this (and perhaps I’ll cover in a separate blog at some point), but for now I want to address this within the context of the project environment.

As we’ve discussed before, any project is a chain of dependencies – both task and activity dependencies.

One of the common characteristics of the multi-project environment is the matrix organization – resources belong to certain departments or groups.  They are not dedicated to specific projects.  They are dedicated to their resource functional area – and they are shared amongst any projects in process.

On the other hand, project managers are dedicated to a specific project – and they have the responsibility and the accountability for the timely completion of their project.  Unfortunately for them, they have all of the accountability for on time completion without any of the direct authority over the resources required to do the work!  The matrix below is representative of this type of environment:

This type of organization creates an inherent conflict within the system between the project managers and the resource managers – project managers are tasked with finishing their projects on time – which, of course, entails resourcing their tasks.  Resource managers, however, are tasked with supporting ALL projects.

It is easy to create conflicts between project managers and resource managers in the above environment – particularly when they lack any kind of synchronization.

So what do we need in order to have control in a situation like that shown above?

We need a system that can give us status of the project at any point in time – no only at a missed or hit milestone or due date.  Ideally, such a system would include reporting like this:

By tracking the remaining work on the longest chain (the critical chain is the baseline) and comparing it to the amount of buffer consumed, a project can be given an objective status from day one – start date is known, end date is known, all tasks in between are fluid – as they complete early or late (or are projected to complete early or late) the system can calculate amount of baselined work completed versus the amount of baseline safety (project buffer) consumed to create a ratio – a one to one ratio over the life of the project means it is on time.  If work is being completed at a faster rate the project will shown in the green.  If safety is being consumed at a greater rate than work is being completed, the project will show in the yellow or red zones.

Next issue we will get into the task level prioritization and synchronization involved in an effective system.

For now, take a peak at this customer presentation from Valley Cabinet works.

And remember, free webinar to be held on July 27th – more details to follow.

The Synchronization Effect -

We’ve discussed so far many of the issues faced in project management – and many of the causes.

Typical Day in the Life of Project Management:

• Several projects are in process at any given time
• New projects are promised without checking availability of resources
• Necessary inputs are not available when needed to complete your tasks (information, specifications, materials, designs, authorizations, etc.)
• Frequent arguments regarding priorities
• Shifting priorities cause wide-spread multi-tasking
• Down stream departments face extreme overloads and under loads.

Simply put, we generally don’t have what we need where we need it when we need it – lack of synchronization.  And synchronization isn’t just about getting work done faster – it can help in the overall load leveling of the organization.

Project plans are also known as project networks – yet many of the plans I’ve seen over the years aren’t networks at all.  They are simply a list of milestones tied to particular dates.  Typical update meetings revolve around how far out to slide the milestones.

A true network implies hard dependencies – precedent and successor relationships.  With this type of dependent relationship, a system can be utilized to ensure work and resources mate up at appropriate times.  Project plans need to have enough detail to provide good execution priorities, but not so detailed that control becomes difficult.

Take the following two projects, for example:

Without any kind of effective synchronization, the following will ensue when trying to execute two projects concurrently that have shared resources:

 

 

Remember – we are having a webinar on Project Management – From Chaos to Control With Synchronous Execution on July 25th!  More information coming soon.

Safety, safety everywhere but still not finishing projects on time!!

Okay – so we admit that we tend to “pad” our estimates a bit in order to give a higher confidence level in the completion of our tasks, and therefore of projects.  So why doesn’t it work?

Let’s look at what happens in typical project environments when it comes to task duration performance.

There are a few key phenomenon that exist in most environments:

• Student Syndrome
• Parkinson’s Law
• Multi-Tasking

Student Syndrome is essentially the “procrastination” issue – when faced with multiple possible tasks on which one can work, and if we feel we have sufficient time in a task, it will typically get prioritized lower on our “to do” list.

The student syndrome graph above shows how this phenomena occurs – at the beginning of a task we might put forth some effort – but given we have other, “hotter” issues on our plate, this one can wait given we have “plenty of time”.  So, as the task due date approaches, what happens.  Our activity level will begin to increase as it suddenly becomes a time priority for us – if negative variability (“Murphy”)  then occurs, we are at risk of missing our task due date – as such, even though we had more than enough time allotted for this task, when negative variability hit, we no longer had the “recovery time” – and missed our due date.

Parkinson’s Law essentially states that work will stretch to fill the time available.  This may not make sense to you right away, but think about a project management environment where tasks are not well defined – particularly within a development environment (software development, for instance) – it is not unusual for there not to be a clear definition of what “good enough” is for a task.  If I’m a programmer working on a task, and the “completion criteria” for that task is not clearly defined, I will tend to work on it for the amount of time allotted – even if in half that time I effectively accomplished what was required for that task.  The reason is if I have time remaining I will continue to “polish” – to work until the time is up and then release it into the system.

Multi-tasking is enemy number one of productivity for project management.  The irony is it makes people feel very productive – but there is a difference between being productive and simply being busy.  Take the following example:

The three tasks above each take one week.  If we were to do them serially, one at a time, task A would finish in one week, task B would finish at end of week 2 and task C would finish at the end of week 3.  However, to be really “productive”, we will work on all of them.  In other words, rather than finishing one before moving on to the next, we will work on part of a task, then work on another, then another, and then come back and finish the original task.  The result is the picture below.

Now, task A finishes in two weeks rather than 1, task B finishes at end of 2.5 weeks instead of 2 and task C finishes in 3 weeks (which it did in original picture as well) – but what are we forgetting?  Set-up and switchover time – any time you switch from one task to another and back you have to re-orient yourself with the work.  So, in fact, task C would not finish in week 3 in the second scenario but some time after.

Multi-tasking is caused, primarily, due to a lack of prioritization and synchronization within our project management system.  Success or failure of a project does not rely upon the amount of safety time put into the project – it relies on the velocity with which we make progress through the project.  The keys are in the execution – effective synchronization, prioritization, real-time visibility into the status of the project, and the ability to focus in on those relatively few points in a project that, at any given time, are getting the progress.

The safety issue is relatively minor – in fact, we can cut generally cut about half of the safety out of a project and still execute it on time.  How?  What is missing in the “conventional” approach?

A project, like any system, is a chain – a chain of dependent events.  Nothing happens in isolation.  So what is key is how those tasks interact and the manner in which we execute.

In short, then, regardless of how much safety time we embed within a project, the manner in which we manage resources, prioritize (or more likely don’t prioritize) tasks and release new projects into the system without regard for the load of the system is the primary reason projects fail.

Next installment – the beginning of the solution!

For now – here’s a video of the US Navy’s presentation on their success with the Critical Chain approach.