Herding Cats

Project Manager and Agile?

I watched the “Does the PM have a role in agile” at the PMI Agile Community of Practice. It was nice, nothing provocative. I’ve read the Gartner Enterprise Wide and Enterprise Class agile report as well. What struck me was what has always struck me:

Good project management does most of the management processes found in agile:

1. The processes that are dedicated to actually writing code in agile are unique to agile.
2. The “management” wrappers in agile that look after these development process are just good project management, see below.

The Gartner report has a list that is simply good PM and logical for any successful project:

1. Customer-Centric – the customer on site is not always necessary, but at some periodic point the customer has to give feedback. In our domain that is monthly for programmatics and monthly or on planned boundaries for Technical Interchange Meetings (TIM)
2. Collaborative and Cooperative – yep if it is adversarial it’s going to fail.
3. Constant Feedback – you’ve got to answer the question how long are you willing to wait before you find out your late?
4. Heterogeneous Environment – one size doesn’t fit all. Never did. Fools thought it did. But they’re fools.
5. Throughout the Software Life Cycle – Measures of Effectiveness (MoE), Measures of Performance (MoP), Technical Performance Measures (TPM) are embedded in all System Engineering Management Plans (SEMP). When are enterprises IT folks going to figure this out. Enterprise development is Systems Engineering.
6. Continuous Delivery – how long are you willing to wait before you find out you’re late? Answer that and have tangible evidence of physical percent complete at points no longer than half way through the cycle. Otherwise when you find out it’s not going the way you want, it’s too late to take corrective action (that’s a code word for MANAGEMENT) and you’re going to be late, over budget, and probably the thing you’re building won’t work as desired.
7. Adaptive Solutions – the SEMP defines the processes to be used, methods to be applied, technologies that enable to success of the development process. It’s Systems Engineering all over again.

So here we are again, with "bad management" as the starting point for applying agile processes.

Instead I'd conjecture if we looked at how large complex systems (not too large or too complex because they have problems) are done, then we'd see it starts with a Systems Engineering point of view. And the Systems Engineering Management Plan (SEMP). Go look at DID-81024 for starting guidance.

As well these large and complex programs are guided by MOSA (Modular Open Systems Approach). Here Systems Engineering is also dominant.

In this system management paradigm, there are core "management" processes that must be in place. [from Systems Engineering Guide for System of Systems, Director of Systems Engineering, Office of the Director, Defense Research and Engineering] These are outside the development of software.

1. Data Management - addresses the handling of information necessary for or associated with product development and sustainment.
2. Interface Management - ensures interface definition and compliance among the elements that compose the system, as well as with other systems with which the system or system elements must interoperate.
3. Configuration Management - is the application of sound business practices to establish and maintain consistency of a product’s attributes with its requirements and product configuration information.
4. Requirements Management - provides traceability back to user-defined capabilities as documented through the Joint Capabilities Integration and Development System. In evolutionary acquisition, the management of requirements definition and changes to requirements takes on an added dimension of complexity.
5. Risk Management - ensure program cost, schedule, and performance objectives are achieved at every stage in the life cycle and to communicate to all stakeholders the process for uncovering, determining the scope of, and managing program uncertainties.
6. Technical Planning - ensures that the systems engineering processes are applied properly throughout a system’s life cycle. Technical planning, as opposed to program planning, addresses the scope of the technical effort required to develop the system. A mandated tool for this activity is the Systems Engineering Plan. Each of the technical processes requires technical planning. Technical planning for Implementation, Integration, Verification, Validation, and Transition processes and their accompanying systems can reveal constraints and interfaces that will result in derived technical requirement.
7. Decision Analysis - provides the basis for evaluating and selecting alternatives when decisions need to be made. Decision Analysis involves selecting the criteria for the decision and the methods to be used in conducting the analysis. For example, during system design, analysis must be conducted to help choose among alternatives to achieve a balanced, supportable, robust, and cost effective system design.

When it is suggested Agile be applied in the Scrum-of-Scrum manner, it might be useful to confirm if any of these 7 activities are applicable, add value, or may be necessary for the success of the project. And if they are who is the role that is going to be to manage their perform?

Quote of the Day

Where ignorance is bliss ’tis folly to be wise — Thomas Gray, 1742

Earned Value Management in a Nutshell

There is on going discussion on forums and in publications about Earned Value and the confusesion between EV and Business Value.

Here's content from Ray Stratton's The Earned Value Management Maturity Model, Management Concepts, 2006 that makes it clear what EV is about. For any one interested in the actual use of EV in the proper way, this book is a most.

• Planned Value (Budgeted Cost of Work Scheduled - BCWS) - The Planned Value of the Work

Planned Value (BCWS) is the planned value of all the work activities in the schedule. Each piece of work has two attributes: its planned value (its allocated budget) and its planned completion date (the time in the schedule it is to be completed, or the iteration in which it is to be completed).

• Earned Value (Budgeted Cost for Work Performance - BCWP) - The Value of the Work Completed

Earned value results from completing work activities. Assessment of this earned value compares what was planned to be earned (the budget) with what was actually accomplished at the planned time in the schedule, using some meaure of physical percent complete. Those meassures range from 0/100 (you did it or you didn't) to Apportioned Milestones (we agreed up front that when you had this done you'd get 30% credit for being done).

• Actual Cost (Actual Cost of Work Performed - ACWP) - The Cost of the Completed Work

The cost of completing each piece of work, usually reported against the Work Breakdown Structure. Comparing actual cost with planned cost (budget) indicates if the projects expenditures are following the budget plan.

There are other terms used in Earned Value

• Budget - generally is the Budget At Completion (BAC). How much money is expected to be spent for the project.
• Management Reserve - is money held at the project manager level for technical and cost issues that come up during the project.
• Overhead - (burdened cost) is a "tax" on the project cost to pay for the organizational infrastructure.
• Undistributed Budget - money in the BAC that has not been allocated to defined work.

No where in these terms and the formulas that result from their use is "Business Value" defined or used. That is in a separate and distinct set of performance measures. Earned Value's performance measures are the basis of answering two important project management questions needed to provide the Business Value

• When will we be done with the project?
• What will it cost on the day we are done?

Along the way the business value can be measured according to processes like Balanced Scorecard or other business investment processes. But it's not Earned Value's job to do that measuring.

Black Swans? Maybe, Maybe Not

When we talk about risk there are lots of confusing concepts floating around. But risk management, guided by paradigms found in industrial controls, flight systems, enterprise class projects, and "fail safe" systems are a good way to look at the term "Black Swan," in the domain of software development.

Project Managers.net has a post about Black Swans. But this article suffers from the same issues most articles about Black Swans do, it's not about Black Swans, it's about poor risk management. Like those mentioning Black Swans in books and articles based on Taleb's work, there is a serious disconnect between how risk if managed in places where people die - either by accident or on purpose - and the much softer side of risk where political or editorial adjustments are common.

Here's the list from the post and a question about how "black" these Black Swans actually are:

• Original Apple computer - TRS 80, original mail order INTEL 8080 kit predated the Apple machine. What was not understood was the marketing power of Steve Jobs, not the machine. Then came the IBM PC, and then came the Apple marketing machine in 1984. No to Black with the history of PC's in place
• Google - legal search engines pre-dated Google. What was cleaver is the architecture of having users define what is at the top of the list. Google is a popularity contest.
• Terrorist attacks on Sept 11, 2001 - full prediction. The terrorist were known by intelligence agencies, but those capable of stopping them didn't have that information. The attack on the US was forecast long before 9/11, but no one listened.
• Facebook - yea OK, maybe no one could have forecast the power of vanity, except maybe Tom Wolf. But the notion of a community was around in the time sharing days of Boeing Computer Services and the orginal ARPAnet I used iin the defense industry. We had "groups" of geeks working on specific software for the US Air Force, where we exchanged all kinds of information around technical and personal topics. All the pieces were there, what was needed was 10 Million users, not just our small community.
• You Tube - obvious once you have Google in place. Oracle long ago (maybe 18 years) had a project with AOL in Vienna VA to stream on demand video using Time Warner's emerging cable backbone. Didn't pan out for lots of reasons. Worked with two forward tinkers in the newspaper business who used the term "convergence," for what is now the merge of video, internet, voice, and streaming over broadband and wireless (4GLTE).
• Twitter - yea, maybe
• Global financial meltdown - No Black Swan here, fully predictable. Read The Big Short and All The Devils are here, and the University of Chicago economics professors.
• Earthquake and Tsunami in Japan - nope, fully predicted. They just didn't listen. And they did every other bone headed mistake of operating a nuke plant. Look at the nuke plant operations journals. The risk assessment submission was one (1), yep that's ONE page long, and was written 10 years ago and NEVER updated.
• Recent massive tornado damage in the southern American states - nope, grew up in the Texas Panhandle (Pampa), where tornadoes came through every year and tore the living hell out of North Texas and Western Oklahoma. Predicted every year. Some years worse than others. I wnat to know why they always hit trailer parks?

A Black Swan is NOT defined as something that changed the world. It is a ...

Low Probability High Impact Event based on a long tailed probability distribution.

Attempts to redefine Black Swans just confuses everyone. I know that is defined later in the post, but those things in the list are not Black Swans, they are bad forecasts of completely predictable events, expect maybe Face Book, Google, and Twitter.

As mentioned, being prepared is important, but in actual high risk, high impact domains (where I work) like Nuclear Power, Manned Spaceflight, and similar domains have one critical attribute - They Are Fault Tolerant. Take a look at "Fault-Tolerant System Reliability in the Presence of Imperfect Diagnostic Coverage."

This means when the low probability event happens, the "fail safe" aspects of the systems are invoked. For emergency shutdown systems this means "fail to danger" is once every 100 million times using the SINTEF guide. These system are software based, along with some hardware, they are active software, fault tolerant software. fault tolerant in the same way flight control systems are. One example which I worked on (SW Dev Manager) is the Tricon. The referenced paper above is the theory and practice for the continuous diagnostics embedded in the Tricon to control things like the Westinghouse Frame IV gas turbine, pictured at the top of the post.

Quote of the Day - The First Law of Project Success

There are only two phases to a big program: Too early to tell and too late to stop. Program advocates like to keep bad news covered up until they have spent so much money that they can advance the sunk-cost argument; that it’s too late to cancel the program because we’ve spent too much already.

Fitzgerald's First Law of Program Success,in James P. Stevenson. The Pentagon Paradox: The Development of the F-18 Hornet. Naval Institute Press, Annapolis, Maryland, 1993, p. 305.

The above quote is all too common, especially in Enterprise IT and DoD weapons systems. It's not necessarily because the project participants deliberately withhold information. But more because of missing objective and accurate information on the status of the program, its progress to date, and the forecasts of future performance of the program.

This is course is unacceptable to everyone, from the project's participants, to the funding owners for the project. Effective management control is lost the moment accurate information about the project is unavailable.

So what is meant by effective management control and the information needed to apply this control?

First let me displel the notion of "command and control," is the boggy man of project management. It's someone else's money, letting the participants who are developing the product or service manage that money, along with the time is utter nonsense. You wouldn't do that for the lawn mowing service, the house painters, the car wash guys or the tailor fixing your suit jacket.

You'd state what you want done, when you want it done, and how much you're willing the pay for that service. This notion that software is somehow not subject to oversight and management control is pure "hog wash."

So if software is somehow "different," from house painting or suit tailoring, where is the boundary for management control. How about:

• This is how much money I have, what can I get for my money?
• This is how much time I have, what can you deliver to me in that time?
• These are the "must have" features, can I get those within a reasonable time and a reasonable cost, if I tell you the time and cost?

If any answer is other than a measurable number, with a confidence interval around it, developed through some logical, take your money and run away.

Can Agile Fix Bad Project Management?

Vin, has a post that outlines sources problems for project failure. I read this that each topic is the source of the project's problem. And then there is the suggestion that Agile can "fix" these problems. Like many suggestions around agile, there needs to be a seperation between "bad program management," actual benefical outcomes of agile, and the measureable outcomes from applying agile to specific problem domain and context in that domain.

• Requirements: (there are) Unclear (requirements), (they) lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
• Resources: (there is a) Lack of resources, resource conflicts, turnover of key resources, poor planning.
• Schedules: (are) Too tight, unrealistic, overly optimistic.
• Planning: (is) Based on insufficient data, missing items, insufficient details, poor estimates.
• Risks: (are) Unidentified or assumed, not managed.

Each of these can be traced to much simpler source than just the red herring of WaterFall.It is suggested Agile can address these issues. So let's look at that conjecture a bit more.

Requirements

A Requirement is ... "A statement identifying a capability, a physical characteristic, or a quality factor that bounds a product or process need for which a solution will be pursued." - IEEE Standard 1220-2005.

Along with requirements successful projects need to define what capabilities are to be provided by the solution.

A Capability is ...“the result of a method involves a functional analysis of operational requirements. Capabilities are identified based on the tasks required… Once the required capability inventory is defined, the most cost effective and efficient options to satisfy the requirements are sought.”

So when it is said "forget requirements, tell stories instead," what does this really mean? Because a story is a requirement. A requiremment told trough the narrative of the stiry. But it's missing several things good requirements need:

• Traceability of the Requirements to the Business (or mission) Capabilities. Why is this requirement here? What other requirements are related to this requirement? What are the dependencies between this requirement and other requirements? If I drop this requirement to hold the iteration completion time, what's the impact on other requirement in the release.
• Requirements can be represented in many ways. Scenarios are common in our domain. sysML process flows, systems engineering Concept of Operations, and other "story like" narratives can be found in defense

Resources

Resource management is a critical success factor for any project. The estimating, acquisition, management, and forecasting resource demand is the role of program management. The notion that Waterfall is somehow the source of the problem is a big stretch. Bad Project Management will ignore the resource management role. Resource Management is Chapter 9 in PMBOK and other chapter in other PM guides. This is NOT a waterfall isseu, it can just as easily be an agile issue too if not looked after.

Bring in resources as needed including using temporary workers to cover peak demand.

Really, how many resources, what kinds of resources, skills, capabilities, cost, fit with team?How far ahead do we need to start recruiting these resources? Our HR department has 3 full time recruiters just scrambling everyday for PM's, Program Managers, PP&C staff, testing, cost, and all other skill sets needed on our programs.

Agile provides no unique solution here.

Schedules

If your schedule is overly optimistic, then you've got a bad schedule. Period. You're a bad project manager if you sign up for this schedule. You've violated your obligation as a PM for provide a credible probability of success. You've probably violated the ethics code of your PMP.

Either allow schedules to flex or fix them and allow features to flex. You can’t have it all.

Here's some advice we apply and provide to our clients:

• A schedule without margin is late and over budget before you start.
• How much margin needs to be determined analytically. Either through past performance analysis on one end and Monte Carlo Simulation on the other. Either way, or all ways in between mean that you have some understanding of the probabilistic nature of the durations, cost, and technical performance.
• Schedule have show the order of development at some level to maximize the value stream to the customer. This is done on multi-billion weapons systems and done in agile projects.

Planning

A Plan is a Strategy for the successful completion of the project. It's the Plan that describes the sequence of activities needed to maximize this value. Be the value autonomous landing of an F-18 on the deck of a carrier, the delivery of telecommunications services to clients, or some type business capability to customer. The notion of exchanging planning for deliverables requires very careful consideration. With a credible Plan, you cannot know what to deliver. A pile of story cards stuck to the wall is not a plan. It's a pile of story card stuck to the wall.

Plan less, deliver more. Let the deliverables guide the planning.

Which deliverables? What order are needed to minimize the duration of the project? What are the dependencies between these deliverables? Are there deliverables that depend on other deliverables? Who decides what order the deliverables appear? Is there oversight around these deliverables, their connection with the Capabilities needed for business success.

This has nothing to do with Waterfall and is not solved by Agile. Here's a sample of a Plan used for a Scrum based very large insurance program.

Risk Management

Let's start with the seminal quote:

Risk Management is how adults manage projects - Tim Lister

Vin suggests

Evaluate, prioritize and mitigate risks on every project.

Well close, here's some guidance

• Risk Management Guidance
• Risk Management Maturity
• Blacks Swans and Intentional Ignorance

But the process actually is:

 

 

What is a good performance metric?

When the discussion turns to measuring project performance, the question of "what is a good metric" comes up. There are many answers depending on your view of the world. Burn Down charts, cost performance measures, schedule adherence, technical performance measures.

Here's what has worked well for me in a variety of domains - software, hardware, construction, process improvement, commercial, defense, energy, paper mills, power plants, ERP systems, and building our house.

• Define what done looks like in units of measure meaningful to the decision maker.

This means something that has business value. Story points for software probability aren't it. An ability to do something with the software that is connected to the balance sheet probability is. This is called a "capability." This capability should be found in some strategy document somewhere. This document answers the question "why are we doing this?" "Why is these feature needed?"

"We  need the capability to process claim transactions at $0.07 versus our current $0.11"

• Define the budget and schedule needed to produce "done."

If you're spending someone else's money, you're going to need some form of budget control. These means you'll need to know what the project will likely cost with some level of confidence. You'll also need to know some level of detail about where those cost are being allocated. "How much do we need for licenses?" "How much for those external testers we've used in the past?" "Do we have a burdened cost for our staff and if so what is that compared to the budget we've got for this project?"

• Define intermediate assessment points along the way to answer the simple question how long are you willing to wait before you find out you're late?

Planning looks to the future to recognize what done looks like before the time and the money run out. Planning is essential for all project success. From mowing the lawn to flying to the moon. We need a plan.

But more importantly, how can we recognize that we're making progress to the plan? What are the measures of progress? Physical Percent Complete is a good one. This is why Agile is a nice way to measure progress at the software development level. "We planned these features, some appeared some didn't at the end of iteration."

• At each assessment point, determine the actual cost to reach that point, compared to the planned cost to reach that point.

When there is talk of "business value," we need to incldue the "cost" of that business value. Collecting costs  is part of project management. Agile projects have it easy. They are essentially Level of Effort work activities. The staff level is steady, the period of performance is fixed (iteration). For other projects, not so much.

• At each assessment point determine the physical percent complete of the planned deliverable in units you defined before you started the work compared to the actual percent compete at the same assessment point.

Measures of physical percent complete need to be defined before the work starts, That way you'll recognize them when they appear. These measures must be meaningful. They must be tangible.

At each assessment point assure all measures are represented by tangible evidence that the physical percent complete is actually true.

• At each assessment point, assure that the measures of performance, effectiveness, and technical attributes are within the boundaries of the planned performance. This the P-Chart from Six-Sigma. Errors bands for EVERYTHING are a must, no point estimates without variances.

With these measures taken on the day you planned to measure them, for the values you planned to achieve, you will learn if:

• You're ahead or behind schedule
• You're under or over budget
• The thing you're building works as planned or it doesn't

If you kept track of the planned cost versus the actual cost and you kept track of the physical percent complete at the assessment point versus the planned percent complete at the same point, then you've got the numbers needed to forecast future performance.

This approach is called Earned Value - you earned the planned budget at the time you planned to earn it, with the planned performance attributes (effectiveness, performance).

There are no magic beans here. Just units meaningful to the decision makers. Units in money and time.

Do this simple process and you'll have all the metrics you need to have visibility into your projects performance.

Wanna See Agile in the Real World?

There are diagrams suggesting structures for feedback and corrective action. One appproach is the Plan, Do, Check, Act loop. But that approach to systems management has only one feedback opportunity - in the Check stage.

Here's a better one. Col John Boyds OODA (Observe, Orient, Decide, Act).

There are several important points here:

• Each stage has a feedback loop
• The orientation process is critical to decision making. Domain and context in that domain establish the orientation of the observer. Without a Domain and Context in that Domain, the Decision making processes cannot use the information in any useful manner.
• Unfolding events, circumstanced, new information, and interaction with the environment provides the basis for new orientation and new decision processes, and of course new actions in the Domain based on this "new" stuff.

The source for John Boyd's work can be found here. Try this once you've seen that PDCA is missing many interconnections. The reason to try this is simply that the OODA loop is used daily in fighter pilot training to actual program management processes for complex system. It is baked into the "control loops," of many Program Planning and Controls weekly business rhythms. It's agile, it's adaptive, it's iterative, and it's effective in practice.

Quote of the Day - Sketch of the Project's Value Stream

In preparing for battle I have always found That plans are useless, but planning is indispensable - Dwight D. Eisenhower, 34th President, General of European Forces, WWII.

Craig Brown has a nice post titled Sketches go a long way in generating understanding. But where's the Sketch of the Project's flow? In the Integrated Master Plan paradigm, the increasing flow of maturity of the deliverables of the project is represented by a diagram that looks like this.

What this diagram tells us is what is the "value flow" for the work effort. Each chunk of work activity "Pilot" with "Data" gives us a deliverable that can be assessed for its maturity. By maturity I mean a general term. This can be usefulness. It can be verification of the concept. It can be a test of the willingness of the funders of the project to proceed.

Agile would call this an iteration or maybe a release. But what is shown here is the end to end map of the project. In this case an ERP system for insurance claims processes. The Vision of DONE in just that DONE. The senior management of the insurance copy can see to the end of the project. They can see what it means to be DONE. As well the work flow to get to DONE is there as well.

We need to have some data and a pilot before enrollments are developed. This "dependency" structure is part of the Planning process. And of course the Planning processes results in an Integrated Master Schedule. Not for the whole project. That would be nonsense, no one can see that far into the future.

But we do have a Plan for the future and this is it. We need to do these big chunks of work in the order they are planned for the business to receive the planned value from this project. Oh yea at or near (within agreed variance) for the planned cost, since we asked the Board of Directors for the budget we needed and they approved it and put that cost in the GL as an obligation and that obligation got reported in the 10-K for the stock holders to see that 100's of millions are being committed of their money.

Is there a home agile development in this approach? Sure at the work package level that is 3 to 4 levels down. This there a home for Earned Value? Absolutely, that's how progress to plan is measured down at that work package level. This progress to plan is progress against the planned budget, the Budgeted Cost of Work Scheduled (BCWS). BCWS times Physical Percent Complete = Earned Value. We "earn" our budget, if we show up on time, don't over spend, and the thing we're building actually does what we said it was supposed to do. What a concept. No hand waving, no whining about this or that. Do what you planned to do, once that plan is agreed to and baselined.

Emergent requirements? Absolutely. Plans change. Requirements change. That stuff on the right is way out there in the future, it depends on the success of the stuff on the left. No one in their right mind woudl commit to a cost and schedule for stuff that has not been vetted through "past performance" and verification of capabilities.

Just don't commit to this beyond your ability to actually make them appear. This is called rolling wave. It's the basis of Earned Value, it's the basis of enterprise project management, DoD 5000.02, and just plain olde good Project Management.

But if you consider things like detailed planning of current rolling waves, applying Earned Value to measure physical percent complete against cost and schedule "hog wash." Then try doing this and not explaining to senior management how much it's going to cost in the end, when are we forecasting completion (within a variance), how many people are needed (300 or so to start), and what is the sunk cost along the way that can be compared to the expected business return.

Try doing this without those and many other "measurement" processes, and your career as a PM will be short lived. Try doing this without measures of performance based on budgeted cost, physical percent complete, and planned percent complete and if you can, then you'll be very close to Earned Value.

Agile as American Football

Dewayne Washington as a comment on Projects @ Work (free log in required) about Agile and Football.

The notion that an American football team is self-organizing needs a bit of clarification. Certainly during the play, each player reacts to the action in front of him. But the offense and in some part the defense is "executing the play book," at the same time.

Each player does not "make it up" as the play evolves. Each position has a role, either on offensive roles to move the ball down the field, or a defensive role to prevent that from happening. The QB calls that play and the offensive coach and the head coach design those p lays. Yes those teams are responsible for "scoring," but the football team executes those responsibilities through pre-planned plays that have been rehearsed (practiced) for hours, weeks, months, and years as a team.

Watching Jeremy Bloom run the ball on our home field looks like emergent action. But he knows what is happening down field, he knows the oppositions capabilities, he knows his teammates capabilities and has an agreed on strategy to catch the ball and "start running."

It just looks self-organizing and emergent. But it's much more complex than that. It's a fine tuned, well practiced, clearly defined set of actions that results in actual progress.

Dewayne makes great points, lost on many trying to apply self-organization and emergence.

• In American Football, plans are king. The playbook is now pasted on the arm of the Quarterback. The players have memorized the plays but number, the subtle changes made during the snap, and the emergent defensive actions of the opposing team are practiced.
• The rigor, discipline, and practice of the team in executing those plays is required for success.
• Of course the action emerges as the play is executed, but rarely is the action a surprise. This is the definition of a "broken play."
• Success comes from executing better than the opponent, not making mistakes during execution, knowing - stone cold knowing - what to do next as the play action unfolds.

All team sports do this. Soccer does as well, no matter what the suggestions agilest make about the team self-organizing the play inside the boundaries of the field. The ball is passed, defense forms, offensive responds, according the practiced plays.The play action evolves and the players respond. But everyone has a role they are executing. This vague notion of a complex adaptive system is notional at the highest level to the fan sitting in the stands. But the players on the field, the "adpative" part if critical. It's adaptive inside their abilties to execute the play book. Team loose when they cannot execute their play book, encounter offense they have never seen before and con't adapt and fail to execute their individual roles within the structure of the team. This is the difference between school yard football play and the Denver Broncos (not that they're that good since Elway left).

Last week Boston won the Stanley Cup (mcuh to the sadness of my Quebec wife), by simply executing better plays, practiced plays, plays that had been developed over the course of the season to match the Cunacks. It may look like chaos, but it's far from that, it's disciplined,planned action, responding to an emerging situation.

Those who suggest it is chaos need to strap on the skates or cleats and run a few plays with the Bruins. The Eisenhower quote about Plans and Planing (which was borrowed from a WWI German General) is true. But there is a PLAN and that plan has been thoroughly vetted for every possible outcome. What is not known is what order those outcomes appear and what new outcomes the enemy or opponent have devised in secret (this is why game films are critical to football and practice is closed).

But it's not chaos as you might think. It is only chaos when things go wrong. If you execute thinking it's chaos, you're gonna get beat and beat bad. I say this having coached highschool and played college team sports and planned and executed combat missions.

A Reminder

No matter what development process you're using, how you're measuring progress to plan, or how you interact with the customer, all successful project must start with 5 immutable principles.

So when it is said for example, EV is "hog wash," for IT projects, we'll need to find some method that can account for the performance of the work effort that is based on units of measure meaningful to the decision makers. This is most often measured in Dollars.

So we'll need to come up with a measurement process that compares our budgeted cost with the "value" earned from the investment of that budget. With this information, we'll need to forecast an important measures for those accountable for this budget. Those interested in the "real" aspects of the project...

• How much will this cost when we're done?
• When will we be done?

Can't answer questions like this, you're probably not actually "managing" the project. You're developing software that's for sure. But they're not the same.

To credibly address the 5 Immutable Principles, there are 11 practices.

Each of these 11 practices needs to produce some tangible evidence that they are being applied. This evidence is the data produced from the practice or artifacts produced after the practice is applied.

Quote of the Day - Billion Here, Billion There

A billion here, a billion there, and pretty soon you're talking about real money. - Everett Dirksen

When we speak about "program controls," there are lots of domains and context where this is a mandatory role. Some are larger than others. Some are more formal than others. Some have special needs and others are just straight forward Program Planning and Controls using Earned Value straight out of ANSI-748B.

Here's a program we're working on getting on. Look carefully at the total award value for the engineering, technical, and programmatic support services. Programmatic Support means "program controls." That means "project" management, and the process around "managing" projects.

Yep, that number on the right is $19 Billion, as in a $Billion with a $B. In this domain there are all kinds of development and engineering services. Including IT development, including Agile development in IT. So when it is suggested by some thought leaders that EV is "hog wash," ini the IT world, ask yourself the question - who's looking after the $B's? A self organizing team of very qualified software developers?

Uh, probably not.

Part of that number on the right goes to

Yep, good old software development processes. This is where agile is most needed. When we get into serious money as Senator Dirkson mentions above, we need to best of both worlds. Rapid development to verify the requirements are right, put the software to work to verify it can earn it's keep. And control mechanisms that can forecast future performance in units meaningful to the decision makers. Those units are of course Dollars.

Critical Code: Software Producability for Defense

When there is discussion of agile and complex systems, here is some background on how DoD thinks about this important issue.

The National Academy of Sciences is now offering free downloads of PDF's. Registeration is required, but it's free.

Inside is a detailed discussions of how agile can add value to the DoD procurement process.

The Fallacious Comparison Argument

I've come across Scott Ambler's statement from the Dr. Dobbs article again. Rereading it for the n^th time, I'm still struck by the fundamental misunderstanding of the term "value" between Earned Value and Business Management. Scott proffers.

The fundamental problem with EVM is that it has very little to do with earning value and everything to do with managing against what often proves to be naive/fictitious schedules and estimates committed to far too early in the project. Although EVM is interesting project management theory, and I have no doubt that it may work in some non-IT domains, it proves to be a really bad project management strategy in practice for IT development projects.

From my Formal Logic book sitting on the dusty shelf, this is the Fallacious Comparison or the Improper Comparison argument. Flaws and Fallacies in Statistical Thinking, Stephen K. Campbell, is a nice source for these things.

Ignoring for the moment that fallacious statement of "naive/fictitios schedules." If there were such schedules as the baseline for EV, then the project is doomed from day one, and those creating and those accepting those schedules should be excorted from the building. Using bad management as the basis of an argument is, who should I say this - nonsense. Get real. Bad Management is just that, Bad Management.

The "value" in business value is just that value to the business. This is almost always measured in units meaningful to the business - money connected to some investment process. This value can be captured through many sources. Return on Investment, Internal Rate of Return, Balanced Scorecard Critical Success Factors, Key Performance Parameters. Things like that. Numbers that appear on the balance sheet. Numbers reported at board meetings.

The "value" in Earned Value is the "earned budget" from the baselined plan of the budget for the planned work. The Value in EV is simple. These numbers are most often money as well, but the color of that money can be different than the money reported on the balance sheet. Many times this money comes from allocated budget to the project - "blue" money as we say in our domain. It can come from "green" money (customer money) as well. Construction uses the term "hard money

It's just that.

• We budgeted $234,000 for a set of features (capabilities).
• We defined the period of performance over which we planned to spend this $234,000.
• Over this period of performance, we decided to measure physical percent complete in some form of tangible evidence.
• Let's say at 50% of the time we planned to spend $115,000 of our budget.
• We also pre-defined what it means to be 50% "done" at 50% of the time.
• When we get to that point in time - the 50% mark - we take an actual measurement of the physical percent complete, using the pre-defined tangible evidence.
• It turns out that evidence shows 45% of the planned 50% is actually done. It's not for the lack of trying, so we've spend the planned 50% of the budget. The $115,000 of the budget.
• Rats, we didn't "earn" what we planned to "earn."

Our Earned Value says:

BCWP = BCWS x 0.45 = $234,000 x 0.50 = $105,3000

our plan was

BCWP = BCWS x 0.50 = $234,000 x 0.50 = $117,000

We didn't make our plan. We underperformed against plan is a common plan. We're unfavorable to plan is another. With this information and the collection of the actual costs for performing this work - which may or may not be equal to the budgeted cost for the work, we can forecast both the schedule performance and the cost performance of the further project activities in units of "money."

There are issues with EV for sure. First is the schedule variance is measured in money. This is overcome by the Earned Value Engine (the system that produces the reports, maintains the Baseline, and other little details) using labor spreads and labor absorbtion rates.

But this performance is not connected to the "business value" of the tangible evidence of the outcomes from the work. Attempts to connect the Business Value with Earned Value is simply not the right paradigm. Don't do it. Stop doing it if you're thinking of doing it. Ignore the advice of those suggesting EV should be Business Value, or EV is not Business Value and that is a problem. It's not a problem, it's irrelevant.

This approach by the way is not uncommon, Michael Hatfield made a similar error in Earned Value Means Measuring Progress Against Plan Cost Not Actual Cost, Managing Projects with Earned Value, and The Value of Earned Value.

Why Is This Important?

As Agile enters to Enterprise IT domain and more so Agile entering the government funded Enterprise IT, Agile will start to encounter Earned Value guided by ANSI-748B. As this proceeds we really do need to get the facts straight when we start to discuss the applicability of Agile and EV to the same Enterprise IT project.

Program Management Report

Deltek has their annual Program Management Highlights report. Worth the down load.

The key findings around Earned Value, processes related to program success. The big findings are around the use of a Program Management Office as a direct bill to the program. 41% of all the respondents utilize program controls for their work.

2 out of 3 firms reported cost management and cost controls as the most important discipline to planning and scheduling.

Performance Management shows that applying  EV beyond just the required compliance guidance. One interesting measure was the 19% average margin using EVM versus 11% margin for firms non using EVM. For A&D firms using EVM, they reported a 5% higher margin. The biggest benefit came from consulting services using EVM, with a 16% higher margin.

Classic PM processes like PMBOK lead the way in 70% of the firms. More sophisticated metrics like DCMA 14 point assessments reported higher profitability.

When We Say Domain, What's Our Choice?

The current issue of Communications of the ACM, 06/2011, Vol. 54 No. 6 has an articled titled The Profession of IT, Who Are We - Now? There is a table of the professional subdivisions.

So where there is discussion of a method, a management processes, some technology, or anything pretty much that requires a domain and a context in that domain, maybe this table would be a start to answer the question - Have you tried your suggestion in one of these? If so, how did it turn out?

The challenge of course is to separate the generalizations - and likely over generalizations - of any suggestion from the specific domain and context processes. For example Earned Value Management (my favorite topic) is applicable in many domains, but a complete waste of time in others. So when there is an over blown statement like "EV is pure hog wash," and there is no domain or context in that domain, it is pretty hard to derive any value from the conjecture.

The same can be said for the over generalized agile process application, although the list of domains is likley much larger than mine - Aerospace Engineering.

Is Scrum-of-Scrums Really System-of-Systems? Probably Not

Any system of consequence is constructed from smaller subsystems, which are interconnected.

Melvin E. Conway, 1968. Conway's Law (better stated as Conway's Conjecture) was an early concept about the complexity is systems and emergent behavior.

There has been mention that Scrum-of-Scrums is a way to scale Scrum to larger projects. And the Scrum-of-Scrums is similar to System-of-Systems.

Here's a good starting point for the concept of a System-of-Systems.

There are "some" similarities, but when you get to page 16 you'll start to see that the coordination, inter-system dependencies, and the coupling and cohesion issues overwhelm many of the simple (and sometimes simple minded) approaches to parallel Scrums.

For those trying to re-define complicated and complex this tutorial should provide some guidance that these definitions are already in place, well defined by the Systems Engineering community and should be examined before applying yet another "version" of management.

Notice to that the "emergent" behavior is well studied in the SoS world. Again "been there, done that," so no need to take credit for a new discovery. One source of this work is the seminal work starts with SysML Strategies to Characterize and Analyze System of Systems. Here is the book that must be on any bookshelf of those claiming to have opinions of complex adaptive systems - The Art of Systems Architecting, 2nd Edition. Jurgen has a straight forward map of the differences between complex and chaos. The Northwestern Institute on Complex Systems has all the backup material.

But all this tells us is that simply having multiple Scrums working on multiple threads in the project may be necessary but is far from sufficient for success. Much more is needed to control, coordinate, and define the processes between and among these parallel work elements. I hear all the advice, but I'd like to see tangible evidence that this can be applied on real projects, where real complexity is emerging. On those projects that we work, where this is the case, and we're spending other peoples money (the government's money), there is much more complexity around "program controls" than any Scrum advocate is likely to want to participate in.

First Big Ride of the Season

Elephant Rock is the first big ride of the season. It was a beautiful Colorado day, blue skies, cool, and not much wind, until the end.

Didn't have good training weather in March and April, so the last 15 miles was mostly uphill and into the wind (of course) and pretty much "nasty." We're looking good here, but still a long haul to the finish. Don't know who the lady is on the right, but our son Alex, with the Western State Cycling team jersey, rode his fixed gear the whole route without braking once. Alex dropped the olde guys on his right after this little climb at the next right turn over Tomah Pass.

Dave, on the left, is one of our over 50 mens group members.

Here's the elevation map.

Next week is the Sunrise Century course and video fly over...

And the profile ...

We'll see about the route when we get to the decision point. Maybe in the best of agile paradigm, we'll have late emerging requirements and decide to go down Left Hand Canyon through Ward and forget the 100.

Quote of the Day

What are the facts? Again and again and again — what are the facts? Shun wishful thinking, ignore divine revelation, forget what "the stars foretell," avoid opinion, care not what the neighbors think, never mind the unguessable "verdict of history" — what are the facts, and to how many decimal places? You pilot always into an unknown future; facts are your single clue. Get the facts!

Robert Heinlein (1978)

So what are the facts around anything and everything about project management improvement? Can a book tell us how to improve without controlled case studies and working examples? Probably not. Can a "body of knowledge" provide improvements without a practice guide for a specific domain? Probably not. Can we hire a project manager (or anyone for that matter), without tangible evidence that the skills, knowledge, and experience are in fact applicable to the problem at hand? Probably not.

But in all cases get the facts, ask for the facts, challenge the speaker or writer for the facts. Facts talk much more the suggestions, opinions, observations, or down right conjecture.

Team Accountability? Really How Does That Work?

We use a business management process from After Burner. This firm is lead by James Murphy, a former Air Force fighter pilot. This months newsletter speaks to Accountability and members of the team being accountable.

Personal Accountability is part of the team's success. The Afterburner method has 4 simple processes:

1. Plan
2. Brief
3. Execute
4. Debrief

This may sound familiar in the project management world, except for the "brief" and "debrief" parts.

The planning part is of special interest to me. The Afterburner^© Planning consists of:

1. Determine the mission objective
2. Identify the threats
3. Identify available and required resources
4. Evaulate Lessons Learned
5. Develop Course of Action
6. Plan for Contingencies

So What's the Point?

When I hear the notion of "collective" ownership in an agile team principles of "collective ownership." In principle this is a bad idea for all kinds of reasons, not the least of which there is no single point of accountability.