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.

Agile Earned Value--Part I

There's a common misperception that agile and earned value don't mix: that earned value is too heavy and anti-agle.  Not so! Agile projects earn value by delivering product incrementally, periodically, affordably, and according to the priority of the customer.


If the customer is not satisfied, he may not want to pay for our efforts. If the customer is not successful, he may not be able to pay. If he is not more successful than he already was, why should he pay?

Niels Malotaux
EVO Consulting Project Manager

The agile rule for earned value:

Each release is a value earning; without a go-live to production, there is no earned value.

In project terms, earned value means planning for an outcome and then achieving it, applying only the intended resources. When the project is completed and expectations are met, the entire value is earned—all requirements are rendered in production and equated to benefits.

Agile methods change the bookkeeping a bit, but by Agile Principle 1, delivering value is at the top of the list:

Our highest priority is to satisfy the customer

through early and continuous delivery of valuable software.

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

W. Edwards Deming invents PDCA

W. Edwards Deming and the PDCA cycle
Deming--working in Japan and else where in the mid-20th century--introduced very practical ideas of process control as a means to limit variations in product quality. Today, it is called defined process control.

Deming was a product guy; he came at quality from the point of view of the product: make the product the same way each time and make it work within limits that are acceptable to the customer. The modern poster child for defined process control is Six Sigma.

Six Sigma

• Six Sigma is a problem solving methodology and defect control strategy with the purpose of identifying and mitigating error sources in defined process control.
• The control limits are established such that production yields less than approximately 3.4 errors in one million opportunities either above or below the control limits. This figure is derived from the error possibilities within six standard deviations of a bell-shaped curve, after allowing 1.5 standard deviations drift of the long-term average defect rate.
• The process derives its name from the Greek lower case s, called sigma and denoted σ; σ is the symbol used by statisticians for the standard deviation of a probability density function such as the bell curve.

 Agile Thinking

Ken Schwaber—a leading SCRUM methodologist—objecting to defined process control, puts it this way, “[defined process control] is based on processes that work only because their degree of imprecision is acceptable… When defined process control cannot be achieved because of the complexity of the intermediate activities; something called empirical process control has to be employed.”

In Schwaber’s view, software is too complex to expect defects to be contained within predefined error limits. Empirical control is the answer; empirical control is derived from observed facts, adapted to the situation, and not determined by preplanned limits from previous projects.

Deming contributes PDCA to agile projects
In spite of the fact that software projects offer little opportunity for statistical process control in the Six Sigma and Deming way, perhaps Deming's most noteworthy accomplishment from the perspective of project management and agile methodologies is his famous plan-do-check-act cycle that he originally adopted from Walter Shewhart. Plan-do-check-act (PDCA) envisions planning for what is to be done, then doing it—that is the plan-do. Next, measure results—measuring is the check activity—and then act on the measurement results. To act in the PDCA sense means to reflect upon lessons learned and provide feedback for corrective actions to the next iteration of the plan.

Walter A. Shewhart
Deming was influenced by the work of the process statistician Walter A. Shewhart who is credited with identifying that processes have two variables: assignable cause and chance cause.
The former is systemic and capable of being corrected and maintained to an economical minimum; the latter is randomly occurring in frequency and intensity, not always present in the process, and is mitigated by establishing performance limits for a given process.

Edwards Deming's impact on agile projects
A project management tip: Deming introduced the PDCA cycle, which is wholly embraced by the EVO method.
• The cycle really applies to all agile iterations. The plan-do is equivalent to the planning session followed by development, test, and integration.
• Especially relevant is the check-act that provides measurement and feedback for continuous improvement.
• Deming focused on eliminating unsatisfactory results before they reached the customer. In agile parlance, every object must pass its unit, functional, and system test

Are you on LinkedIn? If so, share this article with your network

Test Driven Development -- TDD

New to the agile scene? Curious about XP -- Extreme Programming? One practice born in XP and now widely dispersed in the agile community is Test Driven Development, TDD.

The main idea
Here are the main ideas of TDD, and they are a mind-bender for the traditionalist: Requirements are documented in the form of test scripts, and test scripts are the beginning point for product design.

TDD works this way: detailed design and development, after consideration for architecture, is a matter of three big steps:

Step 1: document development requirements with test scripts. Beginning with functional requirements in the iteration backlog, and in collaboration with users, the developer writes technical design requirements in the form of a test script, and writes the script in a form to be run with test-automating tools. Automated tools enable quick turnaround. Automated tests run fast, run on-demand, run repeatedly the same way, and run under various data and system conditions.

Step 2: run the test, modifying the object design until it passes. If the test fails, as it often will, the developer implements the quickest and simplest solution that will likely pass. Step 2 is repeated until the test passes.

Step 3: refine the detail design of the object. After the solution passes the test, the developer iterates the detail design to be compliant with quality standards. In doing so, only the internal detail is changed and improved; no change is made to the object’s external characteristics. To verify no external changes and continued functionality, the modified solution is retested internally.

A project management tip: TDD, unit tests, and acceptance tests

• TDD was invented as a design practice; it is commonly applied to the lowest level design units
• “TDD's origins were a desire to get strong automatic regression testing that supported evolutionary design.”4
• Unit tests, distinct from TDD tests, are postimplementation design verification tests. In most respects, unit tests and TDD tests are very similar, but the purposes are very different: one drives design and the other verifies implementation.
• The concept of automated tests is also applicable to higher-level tests, such as product integration tests and user acceptance tests, but these are not for the purpose of driving design.
• At higher levels, designs that pass unit tests are being tested in a larger context and by independent testers, including end users.

Are you on LinkedIn? If so, share this article with your network by clicking on the link!