Ideas for Managing at the Milestone

Nothing really good happens at a milestone because too many things have to come together to have success.  At a milestone, seemingly independent activities have their fate joined.  At the milestone, everyone is in, or else everyone is stymied when the gate is not opened to pass through.  

Here's one idea: The fact is, joining together at a common event, like a milestone, is hazardous because of the concept of ‘merge bias’.  Merge bias simply means there is a strong tendency to slip to the right at a milestone, thereby stretching the schedule.  In other words, when you look at a schedule and you see a milestone, think immediately that there is a risk to shift right—that is, milestones are hazards to on-time performance and represent the first weakness to look at when assessing the schedule for risk.

Here's another: It’s common sense that the more independent an activity is, the more freedom of action there is.  After all, there is minimum need to coordinate outcomes and processes if no one else is depending on your production.  So, by corollary, dependencies limit choices, limit agile methods, and place constraints where there would not otherwise be inhibitions.  Dependencies increase the effort that must go into coordination—team of teams, staff meetings, and the like—and this effort must come from some budget, and potentially the distraction of more coordination could impact other value-add work.

It’s no accident that milestones tend to shift to the right on the schedule.  There is actually a mathematical explanation for this phenomenon that arises from the statistical behavior of somewhat risky activities.  In a project, no activity can be known for certain—there is always some risk that things will take longer than planned, or in some cases take less time than planned

In statistics, the explanation comes from behavior of intersections and unions of events.  A union is an ‘or’ case; an intersection is an ‘and’ case.  A milestone is an intersection of two or more joining tasks.  

Statistics defines the intersection of independent events by the product of their probabilities.  There is no general formulation for the statistics of an intersection unless the events are independent.  If they are not, then the only practical way to determine the performance of the intersection—in our case, the milestone—is to simulate the project by running many trials.  Simulation for this purpose is the subject of another presentation.  

In similar fashion, we can multiply out all the other cases of one late/early and the other either late/early or on time.  For two joining paths, there is one success case—both on time—and three failure cases—one or the other or both are late.  The sum of the success case and all of the failure cases must account for all the possibilities—100%.  If the sum of all cases is not 100%—either more or less than—then the analyst has made some error in accounting for the possibilities.

For the project manager, the quick take away is that by glancing at the schedule and picking out milestones defined by joining paths, the weak points of the schedule are immediately seen.  At every such milestone, there is a bias towards shifting to the right—an obvious hazard to on time performance

Take a look at this slideshare presentation for more information

Are you on LinkedIn?

Share this article with your network by clicking on the link.

Ideas for Managing at the Milestone

View more presentations from John Goodpasture.

My Agile Top Five

Somebody asked me the other day for my definition of agile--I think they heard about my new book coming in January, "Project management the agile way ... making it work in the enterprise".

From the book, I say this:
Agile’ means small teams, working collectively and collaboratively, with this mission:

To deliver frequent, incremental releases of innovative functions and features, prioritized for need and affordability; evolved iteratively from a vision according to user reflection and feedback; and produced at the best possible value

Below are my top five points; I guess it is my version of the Agile Manifesto

Are you on LinkedIn? Share this article with your network by clicking on the link.

Top Five Ideas -- Statistics for Project Management

Do you love statistics? Probably not!

Nevertheless, they are present in every project and so a few minutes to grasp the top five ideas is time well spent.

In my presentation (at the slideshare link), adapted from my book "Quantitative Methods in Project Management", I talk about Monte Carlo simulation, the Central Limit Theorem, the Law of Large Numbers, probability distributions, and the merge bias problems in schedules.


Click here for a slideshare to show you the ropes on the top five ideas for statistics that help the project manager.

Are you on LinkedIn? Share this article with your network by clicking on the link.

Driving Adoption -- Benefits realization in the agile space

There's no time like the present--Benefit tracking begins with the first release.

Adoption may be slow. Because of the natural reluctance to change, embracing new capabilities may not be automatic. To encourage adoption, competing or legacy capabilities should be withdrawn as soon as practical.

Remove the legacy
It may be possible to help adoption by having the first few iterations produce product increments that are naturally attractive and capable of creating a buzz.

Early adopters
There are, of course, early adopters who will eagerly grab new capabilities, especially technology capabilities rich in software features and functions, and especially those that are user-configurable. But early adopters are only one of five personalities in the body of knowledge known as diffusion of innovations.

The five are:
1. Innovators: Those who are anxious to work with the product in a preproduction or beta status and take risks with immature product; usually very personable and networked individuals, well connected with technology, and able to handle a high degree of uncertainty;
2. Early adopters: Those with opinion leadership eager to put product through its paces and be first on the block to have the advantage of a new capability;
3. Early majority: Those willing to adopt after visible proof that the bugs have been worked out and operational effectiveness has been proven;
4. Later majority: The reluctant but willing, not too comfortable giving up what they know best; and
5. Laggards: Those that might never adopt and so drop out of the pool of users.


Innovators often make their own decisions to engage using new ideas; they are often in at the beginning and may be drivers behind the original vision. Early adopters may wait for official sanction before taking up a new product; later adopters may be forced by decision makers to get involved. Regardless, Everett Rogers, one of the early academics in the theory of diffusing innovation, posits that everyone passes through a five-stage decision-making process, albeit on difference timelines.

Roger’s paradigm is:

1. Seek knowledge: Seek basic information to become familiar and acquainted with a new idea, product, or service;
2. Accept persuasion: Evaluate benefits in context of personal use and application;
3. Decide: Decide to adopt or reject;
4. Implement: Begin to apply the product or service to the everyday routine; and
5. Confirm: Accept the product as a fully qualified alternative to the prior capability.

Agile impact
In the agile space, this five-step process repeats with every release, although the steps begin to merge and the timeline is shorter as each release builds upon the past. The mission of business preparation is to smooth this decision process as much as possible; to prepare the knowledge base; and to prepare persuasive information so that moving to implementation and confirmation is as rapid as possible.

Are you on LinkedIn? Share this article with your network by clicking on the link.