Herding Cats

The Last #NoEstimates Post

I've concluded the #NoEstimates advocates have difficulty stating the domain and context in which their exploration is applicable. Without a Domain and a Context in that Domain, it's difficult to have a conversation about the merits of the idea.

Can I apply it to embedded flight control systems? How about emerging databases for nuclear safety and safeguards? Enterprise health insurance processing? How about pipeline right of way document management? Maybe editorial systems in media? Turbine controls, emergency shutdown, fire and gas monitoring? Radar signal processing?

You see the problem, right? General claims like making estimates is a waste of time seem to beg the question - in what domain? Answer comes back Software Development is a domain. Ah, not really. Kinda ends the discussion doesn't it.

Related articles

Complex Problems Require Better Solutions

Estimates and all that...

Estimate Anything

Why Estimating Is Mandatory

The #NoEstimates notion has merit in the right domain. If you're looking for motivation for estimates outside of the domain where the customer doesn't really care about the final cost, just the final product developed inside a "level of effort" budget, look here and remember.

When you are spending other people's money - billions of dollars of other people's money - you'd better have a credible answer when they ask "how much is this going to cost and when will you be done? This is separate from "will I get what I asked for?" That's another topic all together.

There are several things we need to remember about agile:

• Agile means paying to discover the requirements as we go. No problem if you know that up front.
• #NoEstimate means you don't have an Estimate At Completion (EAC) other than the passage of time multiplied by the total labor load. No problem if you understand that.
• When there is a budget cap, and deadline for delivery, and a minimal set of useable features, then some notion other than we don't make no stink'in estimates probably needs to be in place.

Related articles

No Estimates of Costs and Schedule?

Unrealistic Cost and Schedule Estimates

Estimate Anything

When I hear people talking at #NoEstimates I have to smile. When someone is paying you to spend their money and produce something of value with that money. When that someone has an expectation of that value arriving sometime in the future. You're response, probably shouldn't be we don't do estimates, just give us the money and we'll spend it.

That's a bit over the top I know. Ron Jeffries has a rational approach to actually developing the software, ONCE the needed capabilities have been defined.

But without some high level estimating processes, the software development efforts are considered Level of Effort. Which means keep going until the money runs out. You can certainly do this using the methods defined by Ron. It's called maintenance. PayPal does this. But you have to pick your projects carefully.

Quote of the Day

How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn't make it a leg
- Abraham Lincoln

The notion that we can rename things and then assume they are the same doesn't work, just like Lincoln said. The notion of measuring progress with the passage of time and calling it Earned Value, doesn't mean we're doing Earned Value.

Doing Agile without doing Scrum, XP, Crystal, or DSDM is not doing agile.

No Estimates Mean Better Estimates?

The conversation on Twitter around No Estimates #NoEstimates brings a smile. Here's some samples

• Marketing needs a rough idea of when alpha-level code will be available. Allowing a few weeks for alpha testing and a few more for beta testing provides a time line. That may well be good enough. 

That's called an estimate. A rough estimate for sure, but it's an estimate

From the same blog (a good one BTW)...

• We're on an enterprise system now and management needs to know how long and how much cost it will take to get to a Minimal Viable Product. The first release has to be functionally complete in order to be competitive. Everyone understands that this effort will take several months to get to beta-level code.  Management needs some idea of what they’re getting into, how long it will take, and how much it will cost.

Now we're into the realm of actual estimating

Are No Estimates Better Than Estimates?

Before answering this another question needs to be answered...

What is the value at risk?

This means how much money and time are you willing to risk without understanding how much time and money is at risk.

So before anyone can answer the question about estimating value, that question needs to be answered by the owner of the money. NOT to consumer of the money. 

This at risk question rarely comes up in the agile world. It doesn't come up enough in our formal FAR/DFARS acquisition work either. The at risk question is a risk management question. Agile claims to be a risk management process - which of course is laughable in our DOD/NASA/NRC/FDA/NNSA risk management world. All software intensive by the way.

So before venturing further, what's the value at risk must be answered. Then the owner of that risk, can tell those who should be working in the best interest of the owner of the risk, if an estimate is needed. Not the other way aorund.

Without this answer, the discussion on #NoEstimate is just sharing of personal opinions in the absence of any value at risk.

Related articles

Time to Revisit The Risk Discussion

When We Say Risk What Do We Really Mean?

More Uncertainty and Risk

Measurement of Uncertainty

Estimates in Software Development. New Frontiers.

Risk Management

Analogies, the Good, the Bad, and the Ugly

There have several rounds of how to use analogies and how not to use analogies in the past few years. 

These involved notions like agile is an untended garden. Actually and untended garden and called a weed patch.

Or we can't really stop and develop a strategy, because we're always putting out fires. Actually firemen rarely put out fires. They spend the majority of their time preventing fire with fire safety, inspections, fire inspections. Their job is to never have fires start.

And of course for false analogies of the double pendulum as a stand in for chaos and unpredictability. Since the equations of motion are easily defined - an exercise for any upper division physics student - and a MathLab plugin, you can plot the path of the double pendulum. 

And my favorite the attractor analogy, in which it is presumed that some how in chaos theory the attractor attracts. Without understanding  that those pretty pictures of the attractor are the result of the underlying equations for the system.

So with that in mind, there is a new book from one of my favorite authors, Douglas Hofstadter, Surfaces and Essences. In the book Hofstadter makes the case for analogy as the fuel for creative thinking. Using Robert Oppenheimer's quote... 

whether or not we talk about discovery or of invention, analogy is inevitable in human thought, because we come to new things in science with what equipment we have, which is how we have learned to think, and above all how we learned to think about the relatedness of things.

But as always we need to take care to assure that those analogies we use to expand the conversation, don't violate the laws of physics, gardening, or mathematics.

Related articles

The Misunderstanding of Chaos - Again

Happy 50th Anniversary, Chaos

Managing in the presence of all things

The Myth of "Trying Things Out"

There's a tremendous popular fallacy which holds that significant research can be carried out by trying things. Actually it is easy to show that in general no significant problem can be solved empirically, except for accidents so rare as to be statistically unimportant. One of my jests is to say that we work empirically — we use bull's eye empiricism. We try everything, but we try the right thing first!

Edwin Land - The Journal of Imaging Science and Technology, Vol. 37, No. 3 (1992), p. 537

The notion that the architecture will emerge, that requirements appear as we go along spending other peoples money, and the customer knows the right solution when they see it, is just that "notional."

Without some agreed upon description of what Capabilities are to be provided by the system, you'll just be spending time and money to find out you don't know what DONE looks like.

Related articles

The Myth and Misunderstanding of Waterfall

It's Not Chaos It's Football

A Breathtaking Paper

Came across "Lost Roots : How Project Management Settled on the Phased Approach (and compromised its ability to lead change in modern enterprises),"  Sylvain Lenfle and Christoph Loch.

From the abstract:

The discipline of project management adheres to the dominant model of 
the project life cycle, or the phased stage-gate approach, of executing 
projects. This implies a clear definition of mission and system at the 
outset (to reduce uncertainty), and subsequent execution in phases with
 decision gates.

 This approach contrasts with the way the seminal 
projects were conducted that are credited with establishing the foundation of the 
discipline in the 1950s. These
 projects started with missions that were beyond the currently possible, 
thus any solutions had to emerge over time. They succeeded by a
 combination of parallel trials (from which the best would then be 
selected) and trial-and-error iteration (allowing for the modification 
of solutions pursued over a period of time). 

Although the success of these approaches was documented and explained by scientific 
work in the 1950s, today they seem to fly in the face of accepted 
professional standards, making managers uncomfortable when they
 encounter them.

 The explanation for this contradiction has its roots in the 1960s, when 
the so-called McNamara revolution at the Department of Defense gave a 
control orientation to the PM discipline. This shift was cemented by the 
encoded practices of the DoD and NASA, contemporary scientific writing,
 and the foundation of the Project Management Institute as a professional
 organization that translated the standard into the educational norm for 
a generation of project managers. The project management discipline was 
thus relegated to a "grunt work niche" - the engineering execution of
 moderately novel projects with a clear mission. As a result, it has been
 prevented from taking center stage in the crucial strategic change 
initiatives facing many organizations today.

 This article describes the historical events at the origin of PM's
 reorientation, arguing that the discipline should be broadened in order
 to create greater value for organizations whose portfolios include push-the-envelope projects.

Agile may ne making a come back in project management, but the contracting aspects of large programs needs to deal with the uncertainties as well as the developers.

Agile and the Federal Government

TechWell is an agile site that has been around for awhile. There is recent post on Agile and Federal Government. While the concepts of the post are useful, there are some issue with the underlying processes that need clarification.

Earned Value Does NOT Define the Development Process

The post suggests EVM requires Waterfall. First the development process defined in the picture on Page 2, is not allowed. Not to say there aren't people out there using it. While the Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System may appear overwhelmingly complex, it is the basis for all complex acquisition processes. It defines an itertaive and incremental process for buying weapons systems. Increasing maturity of the deliverables is defined at each Program Event.

But in an EVM program which is defined by several Federal Acquisition Regulations and the Defense Supplement, DI-MGMT-81866 calls out an Integrated Master Schedule. Along with is the DOD acquisition Life Cycle process where incremental maturity of the delivered products are defined in the Integrated Master Plan. The Guide of the IMP/IMS shows how to build a credible Plan and Schedule for a program.

We have to remember EV is only required on programs greater than $20M and a validated system on programs greater than $50M. DOE requires EV on programs greater than $5M and HHS has similar requirements. But $20M of software development is a BIG program. And you'd better have something better than Scrum looking after the expenditure of $20,000,000 of the government's money.

Waterfall Replaced By Rolling Waves

The second picture suggests that Agile provides an iterative solution. But in fact Rolling Wave development, defined in the acquisition guides does the same. RW's can certainly be a substitute for iterations. 

But a better solution is to move the Agile Iteration down to the Work Package level. A Work Package in the Earned Value Management paradigm, is a self contained "package of work" that produces a tangible outcome that fulfills the Criteria needed to complete the Accomplishments that define the increasing maturity of the deliverables for a specific Program Event. Look at the IMP/IMS Preparation and Use Guide for how to do this.

So Here We are Again

I'm speaking again at EVM World in Naples FL, on integrating Agile with EV. Notice a critical phrase, Agile integrated with EV. Not the other way around. If you have a project less than $20M and are currently using Agile, there is no need for EVM. Don't do it, assuming you've actually got control the program. EV can add value for sure, but it's not mandated.

Here's the previous briefing on integrating agile into EV - EV+Agile=Success. The current one is slightly better and will be available May 26th, 2013.

So What's the Point

While there is growing enthusiasm for integrating agile into government programs, the acquisition community has not caught up. The agileist suggesting how to do things need to understand more of how the acquisition community thinks about managing the government's money. Open ended development may be the rage in commercial business (probably not), not if we are be to good stewards of the public's money more than just agile needs to be in place. 

This notion of agile on governemtn prorgams is itself an emerging topic, that needs much more discussion before true value can be created. There are examples of success in the AirForce, DOE, and NASA. I've worked some of those programs and written about them in conference proceedings. But to simply apply agile in the absence of the acquisiton communities participation is going to lead to disappointment. Agile is needed, but so are the controls in place in the FAR/DFARS processes.

Related articles

Connecting the Dots in Agile

Agile Paradigm

Federal Goes Agile

The Myth and Misunderstanding of Waterfall

More EV and Agile Confusion

Performance Based Management

The Myth and Misunderstanding of Waterfall

The classical mistake of many agilest is to equate Waterfall with a method that is in use today. Projects @ Work (subscription required)has a discussion about Method Madness in which the classic mistake is made.

“Waterfall methods are notorious for leading one to believe projects are on schedule when, in fact, they are not.”

First the notion of waterfall is agile code for bad project management. Second the process of Waterfall is actually misrepresented. The Winston Royce paper "Managing the Development of Large Software Systems," is the place to start. In this paper is a description of the development of a small software program and the issues created when that approach is scaled up to larger programs. In Figure 10 of the Royce paper shows how the steps in software development were defined in the Spring of 1970.

Looking at the statement above, leading one to believe project are on schedule when, in fact, they are not. This is a common myth created by the BAD practices of project management in general. Here's a short summary of how to manage a project using a simple method of tangible evidence of progress to plan.

5 immutable principles and 5 processes in 60 seconds from Glen Alleman

If we're not making use of these Five Principles of Project Success, no method, no matter how cleaver is going to help. If we are making use of the 5 Principles, then the Red Herring of Waterfall - the code work for bad project management - will be evident and we'll know better than to make the statement that introduced this post.

Related articles

Agile Project Management

I'll Really Wish the Agile Thought Leaders Wouldn't Talk Like This

The Misunderstanding of Chaos - Again

Exposing Agile Software Development Myths

Sailing and Agile

In a recent post on the  Agile Paradigm, I used sailing as an example. John Goodpasture provided a much better example that needs to be shared across the board.

Agile for project managers - a sailing analogy-UPDATE from John Goodpasture

Note several critical concepts that are sometimes lost in the question of self-actualization of the team members:

• Team work has a leader - the skipper
• The path to success is defined by the course or the destination. This path is guided by the physical obstacles in the way to the destination - either placed there intentionally or as part of the environment.
• Emergent situations are part of the normal process, but the solutions are constrained by the rules of the race or the physical rules of the boat and the sea. 
• Everyone has a job, some are specialist, some are generalist, but everyone knows their job before stepping on the boat.
• The skipper is the leader. 
• The team - crew- works as the crew, but they don't make things up as they go. Everyone is focused 100% on reaching the goal. For racing that is simple. For open ocean transist, that is reaching the distant port. For day sailing in Mission Bay, that is enjoying the day and trying not to get run over by the tourist in rental boats, for coastal sailing out of Newport Beach that is staying away from the power boats. Rarely if ever do we just sail blinding waiting for the destination to emerge. 
• And like all real sports - we keep score.

And a final concept in the sailing analogy:

Agile development is not self-organizing. It is a highly structured, rules of engagement based, process, guided by the rules of the course and the sea. The emergent part comes when the conditions change and the crew and skipper have to respond. The notion of self-organization works great for children on the playground kicking the ball around. If you're spending other people's money, you're value is guided by strict rules of the game. Which us back to Disciplined Agile Delivery.

 

Related articles

Agile Means ...

Agile Paradigm

Metrics for Agile

Agile Paradigm

I'm speaking at EVM World on several topics. Embedding agile in Earned Value Management Systems in one. The briefing has been given several times, and gets updated every time.I've used materials from Scott Ambler in the past. His site has a very nice picture of a sail boat as the paradigm of Disciplined Agile.

I was a coastal sailor while in college before moving to Colorado, in Shields, Soling, and Tempest. That experience was life changing in that it was the first time true team work was required with absolutely correct functioning of personal roles. Iin racing, there is no one to pick up the slack when an individual is having trouble. On the Tempest and Soling there are only two crew. The Shields crew varies, but is typically 3. 

Scott's book, but mostly the book cover is a paradigm for how agile is applied in our domain - aerospace, defense, nuclear cleanup, enterprise IT. This paradigm is means:

• Individual functions must be performed without error
• The "rules" for racing the boat are defined outside the class and are inforced by a judge. Violating the rules is cause for disqualification. Rules of physics also apply. Violating those rules means losing.
• Emergent situations are the norm. Competitors, weather, seas, technical equipment, changing strategy, all require rapid response within the "rules."
• Team work is mandatory, but command and control is a critical success factor. All the crew must work in unison, but the skipper of the boat is in command. We win or lose with both.
• While sailing the boat, self interest is never in place, it is about the crew. Once on shore, ego's can come back, opinions expressed, and sea stories told.
• Skill, practice, strategies, and tactics are developed before the race starts. Strategies and Tactics emerge while underway, but skills and the lessons learned from practice must be in place - no on the job learning if you're going to have any chance of crossing the line without embarrassment.

The notion of disciplined agile is the basis of success in sail boat racing and mission critical software development. 

Related articles

The Basis of Capabilities Based Planning

Performance Based Management

Federal Goes Agile

Agile Requires Discipline, In Fact Successful Projects Require Discipline

Crackpot Index

John Baez has a Crackpot Index he uses for scientific theories. Here are his points:

• 5 point starting credit. 
• 1 point for every statement that is widely agreed on to be false. 
• 2 points for every statement that is clearly vacuous. 
• 3 points for every statement that is logically inconsistent. 
• 5 points for each such statement that is adhered to despite careful correction. 
• 5 points for using a thought experiment that contradicts the results of a widely accepted real experiment. 
• 5 points for each word in all capital letters (except for those with defective keyboards). 
• 5 points for each mention of "Einstien", "Hawkins" or "Feynmann". 
• 10 points for each claim that quantum mechanics is fundamentally misguided (without good evidence). 
• 10 points for pointing out that you have gone to school, as if this were evidence of sanity. 
• 10 points for beginning the description of your theory by saying how long you have been working on it. (10 more for emphasizing that you worked on your own.) 
• 10 points for mailing your theory to someone you don't know personally and asking them not to tell anyone else about it, for fear that your ideas will be stolen. 
• 10 points for offering prize money to anyone who proves and/or finds any flaws in your theory.

Maybe we can construct a similar index for project management theories and processes.

• 3D WBS will build a schedule for you in 1/10 the time, yes 1/10, that is 10 times faster - probably not
• Self directed teams are best for solving complex problems - except when spending other people's money on a fixed schedule and budget, with a mimimal set of features.
• Football self organizes within the boundaries of the playing field, so should software development teams - really, no play books, no called plays, no positions, no team captain, no coach calling in plays from the side line? 
• Self organizing appears without a central authority - not true at any level, we'd have to suspend the laws of physics.

Related articles

Project Controls is the Basis of Project Management

How to be a Master Scheduler

The Misunderstanding of Chaos - Again

There is another round of discussion of the Chaos aspects of software development projects and the models of this chaos.

• The chaotic ones that are totally unpredictable like a double pendulum
• A double pendulum (two pendulums attached to each other) is also a simple system. It is easy to make and easy to understand. And yet, it undergoes unpredictable chaotic motion due to a high sensitivity to the initial setup of the pendulum.
  

The common paradigm of the Double Pendulum is misunderstood and misapplied to the problems of modeling systems.

A double pendulum, is one pendulum suspended from another, shown below. The path of the bottom element (m₂) is a potentially chaotic system. When certain parameter ranges undergo a slight change in one of the initial starting conditions there can be dramatic effect on the subsequent motion of the pendulum. As a result the motion of a double pendulum extremely difficult to predict without a model of the system. The external observation is the pendulum exhibits seemingly random or chaotic behavior.

The first step in solving for the motion of m₂ is to understand the difference between chaotic motion and unpredictable motion. The double pendulum can behave in a chaotic manner. But the motion of m₂ as well as m₂ is predictable. These terms get mixed up and we need to keep them straight if we're going to apply them to paradigms outside of the double pendulum. 

Chaos can described as:

• Being sensitive to initial conditions. 
• Possessing topological mixing, meaning the system evolves over time. 
• Possessing a density of periodic orbits, meaning every point in the space is approached arbitrarily closely by periodic orbits.

Why Is This Important for Project Management

When we use analogies in project management to explain a situation, we need to actually have the right analogy. The Double Pendulum is a common explanation of chaotic behaviour. But the Double Pendulum, while behaving chaotically, is a deterministic system driven by the solution to the Hamiltonian equations of motion. This is called Hamiltonian Chaos. 

The Hamiltonian description of motion uses momentum as the variable.

Depending on the initial conditions the system behaves regularly or show chaotic behaviour. The solution to this equation can be found in Java at Physics Department of the University of Buffalo.

This solution plots the path of the double pendulum in its normal mode or in its chaotic mode. Solutions in Mathematica can be found in Matematica for Theoretical Physics: Classical Mechanics and Nonlinear Dynamics.

So we can see that the solution to the double pendulum is not unknown. The plot of the path can be known by running the simulation for the needed period of time. 

What this means is using the Double Pendulum as an analogy for chaotic behaviour of projects requires careful wording and application. Human systems don't not have Hamiltonian's, double pendulums do. With Hamiltonian, we can write a simualtion to show the motion of the pendulum, run it and see whatit does - Exactly what it does. We can run the simulation forward in time and Predict what it will do sometime in the future.

No mysteries about the path of the pendulum parts, they are completly specified by the solutions to the Hamiltonian. They may look chaotic, unpredictable, and wandering all over the place. But the equations of motion are explictly defined in the Hamiltonian solution and its simulaiton in our favorite language, Java or Mathematica.

A Point Measures Need A Variance

All frequent flyers know the drill if you're like me and have a reserved seat in the exit row. The flight attendent gives the personal talk about our willingness to be in the exit row, how to open the door, than reminds us that the door weighs approximately 32 lbs - just like it says on the Placard.

Now what does appoximatey actually mean? Approximatley 32 lbs could be the door weighs between 31 and 33 pounds. Our it could weigh between 25 and 50 pounds.

No Simple Point Estimate Can Be Credible Without The Variance

This is the phrase that must be used at all times will doing project work. When someone states the cost of the project, you ask what is the variance? When they state the planned duration you ask what is the confidence level for that estimate.

If they answer what do you mean you know immdediatly that project will be late and over budget. They have no clue of what it will cost or when they will be done.

Back to the Agile paradigm one more time. Agile is essentially a time boxed approach to cost and schedule. The features are the variable. This is a wonderful concept for customer that can accept functions that vary. But what about those customers that need all the features, for some level of confidence of cost and schedule. 

We now need a process that can produce a baseline plan that produces ALL the needed capabilties, on or before the planned completion data, at or below the planned cost. This will be a risk adjusted cost and schedule.

Related articles

Sources of Variance

Time to Revisit The Risk Discussion

Quote of the Day

It's a good principle that when people don't want to tell you when they will get something finished, or how much it will cost, it is not because they are worried that the good news will pitch you into a paroxysm of ecstasy.

"No More Time: We need an F-35 IOC date and debate," Aviation Week and Space Technology, January 28. 2103, pp. 12

This is a core  issue when thinking of deploying agile software development in the absence of an overarching set of needed capabilities, a master plan for delivering those capabilities, and some form of measuring actual progress to that plan.

So when we are spending other peoples money, we need to make some attempt to do it on time and on specification.

Project Controls is the Basis of Project Management

Shim Marom has a great blog post about a conversation around using Earned Value Management. The exchange is typical of those not starting with the Project Controls paradigm for managing projects. I attribute this typical exchange to missing information about how projects get to be successful. PMI has not done a good job around project controls, AACEI lives and breaths the notion, Agile has something to say, but leaves many gaps, and most of the ad hoc approaches to managing the expenditure of other peoples money in pursuit of a product have little to say.

It's been said before, but Shim's post needs as many voices as possible. If we want to show up on or near the planned time, at or near the planned budget, with something that has a hope of working, we need a method of planning work and controlling cost.

Here's are 11 activities that contribute to that goal on the non-technical side of the project. The odd numbering system will be revealed at the end

1. Define the deliverables – what does the customer want? Do we know this at a level of detail so we and the customer will recognize it when it arrives?
2. Define who is going to produce these items – do we have the people needed to produce them? Do we know the skills needed to do this work? Do we know something about how this work effort is going to be organized?
5. Put these two thing together - so the people on the project know who is doing what. Who is accountable for producing the outcomes of the project? How will they communicate this to the customer? 
6. Plan the sequence of work – so everyone is not doing anything and everything out of order. Einstein's quote that the purpose of time is to keep everything from happening at once is applicable here. 
7. Define when you need things to be produced – what day do I need something? The order of the deliverables is usually important to the assembly of the parts of the product. Spoilage is actually an issue when developing software, since emergent requirements many times result in rework.
8. Figure out how much money you’ll need for producing things – do we have enough time and money to produce what was asked for at the time it is needed? If you're spending other peoples money, you'll likely have to explain how much money you need and when you need it. Open checkbooks are rare these days.
16. Capture how much you spent – who spent what on what outcome at what time? The people giving you the money, will probably like to know what you spent it on.
23. Determine if there is a difference between what you planned and what you spent – why did we not follow our plan? When spending other peoples money, they like to know you've got their interest at heart. This can be done with a budget versus actuals discussion. Just like any business process (or even in life), having and budget and trying to stay on budget is a demonstration that you're trusted to spend the money.
25. Add up all these variances – do we have enough time and money remaining to do what the customer wants? This is a quetsion you probably ask yourself every month as you're paying bills. Same goes for managing other people's money on your project. The surprise of we have no more money (or time) is unpleasant in all circumstances.
26. Take action to stay on budget and schedule – either way, yes or no, what should we do about it. If we're on budget and on schedule, what do you need to do to keep it that way? If you're off budget or schedule, what are you going to do to get back?
28. Implement you actions – with the knowledge from #26 do it, Project Management is a verb, do something about the variances.

These 11 activities are simply good project management. These are what project managers should be doing on the Programmatic side of the project. The Technical management of the project can be done in a variety of ways, and of course they will influence the programmatic side. Add to that the people management and you've got the picture of what a project manager should be doing.

By The Way these 11 activities are numbered from the 32 Guidelines of ANSI-748-B - Earned Value Management. So when you hear someone say - we can't do EVM on our project or EVM is a waste of time in our domain usually spoken by the IT folks and even by the senior thought leaders of IT, ask yourself - are these 11 activities missing? If so, what's the chance your project is in the ditch and you don't even know it?

Quote of the Day

“If you’re naked, you don’t have any clothes on,” he explained, “but if you’re nekkid, you don’t have any clothes on but you’re up to something.” - Senator Alan Simpson, in a discussion with Washington Post reporters Wednesday morning about the debit crisis.

When we're talking about program performance measures, risk management, product development methods are we being Naked about the truth of their effectiveness or Nekkid? Many measures cook the books by ignoring risk adjusted measures and technical performance measure compliance. You can't be on schedule and on budget of the risks are being reduced and the technical performance measures narrowing within the upper and lower bands. You're gonna be late and you gonna be over budget if these tqo measures are improving along with the CPI and SPI of the program.

Agile Means ...

I was at a conference for government contractors and the software systems we use to manage those programs. In the federal government agile is moving forward. Greater Accountability and Faster Delivery Through Modular Contracting.

During one of the session there was a quote that says it all about Agile Development

AGILE MEANS YOU'RE BEING PAID FOR DISCOVERING THE SCOPE OF THE PROJECT

This says it all. Agile is a powerful approach to software development in the commercial world. Agile in the government domain, encounters the Federal Acquisition Regulations (FAR) and the Defense Federal Acquisition Regulation Supplement (DFARS).

In these environments, Earned Value Management, the Six Business System Rules, and other procurement guidance define how work is performed. This is all being worked out, but the quote above did it for me!!

It's Not Chaos It's Football

There is a popular myth - mostly by those Agile Management 3.0 thought leaders who don't play or even know much about team sports involving balls, grass - about "emergent" behavior. The myth is that the "rules" of the game and the boundaries of the field are the governing guidance in the game of Football.

The Michigan coach in the picture to the left is looking at his playbook. The playbook defines what plays can be, or are going to be, used during the game.

The playbook has to follow the rules of the game. That's the role of the referees and field judges. If the play is not in the playbook, it is not going to be used during this game. There may be more plays available to the team than are in the playbook for today's game, but they're not going to be used.

So here's the lesson for Project Management.

Where is your Playbook? And If you have a Playbook, are those Plays going to increase your chances of winning?

Don't have a playbook?, then it's going to be an ugly day. Have a playbook but don't execute the plays properly?, it's going to be an ugly day. Execute the proper plays in the proper sequence, your chances of winning will improve. No guarantee's, just be improved.

The Playbook for a project is the Integrated Master Plan. The application of the plays, like American Football, depends on the emerging situation that resulted from the last play. Not the score on the score board. That's the Integrated Master Schedule.

Does this mean the Master Plan doesn't change during the game or during the project? Of course not, that would nonsense. But you better have a really good reason for changing the plan. In football and baseball, that's actually a strategy - to get the other team to change their plan. To go off the playbook and try doing something that they haven't practiced well enough to properly execute. To disrupt the flow of play.

How about changes in the Master Schedule during the game or during the project? Happens all the time. Here's a thought to put to work in ball games as well as projects.

Planning is not “plan and forget” but an ongoing dynamic activity that peers into the future for indications as to where a solution may emerge and treat the plan as a complex situation, adapting to an emerging solution.

If you have a Plan B, you should have given thought to the possible Plan B's, before you execute Plan B. Otherwise your Plan B may be just what your opponent wants you to do - decrease your probability of success.

This idea comes from a colleague Mike Dwyer, IT Program Manager, used with permission.

So why the notion that a football team - or a project - that self-organizes within the boundaries of the playing field and the rules as they are laid down by the football association? Without the understanding of the Playbook, with most times the plays being called in by the coach. Can't say. Maybe because those notions come from observers of football, not players of football.