Herding Cats

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 World of Probability and Statistics

This is from an article about the application of Bayesian Statistics to a civil suit in the UK over the source of a building fire.

The idea that you can assign probabilities to events that have already occurred, but where we are ignorant of the result, forms the basis for the Bayesian view of probability. Put very broadly, the 'classical' view of probability is in terms of genuine unpredictability about future events, popularly known as 'chance' or 'aleatory uncertainty'.

The Bayesian interpretation allows probability also to be used to express our uncertainty due to our ignorance, known as 'epistemic uncertainty', and popularly expressed as betting odds. Of course there are all gradations, from pure chance (think radioactive decay) to processes assumed to be pure chance (lottery draws), to future events whose odds depend on a mixture of genuine unpredictability and ignorance of the facts (whether Oscar Pistorius will be convicted of murder), to pure epistemic uncertainty (whether Oscar Pistorius knowingly shot his girlfriend).

When we build probabilistic models of project performance - cost, schedule, and technical - we assume we understand the underlying statistical processes that drive these probabilistic generating functions. These are the aleatory uncertainties in duration, cost, and performance. We define the Probability Density Function in the Monte Carlo Simulator. Then we apply that to the network of work activities (the Integrated Master Schedule), to produce confidence outcomes for completing on or before a planned date and at or below a planned cost. This is all fine and dandy. But we really don't know the underlying drivers that create coupling, correlation, and cross correlations between the work activities, cost, and technical performance. These can be model by discovering the drivers in the network.

For the Epistemic uncertainties we need another modeling tool. The current tools don't actually use Bayesian statistics, rather they use Monte Carlo Simulation and treat the Probability of an Event as an aleatory process integrated with the other PDF's, ranges, and their shapes (Kurtosis and Skew).

We're missing the tools needed to construct a credible epistemic model of how the program works. Using the Integrated Master Schedule (IMS) as the topology for work, the probabilistic behaviours of the work elements at each node - cost, schedule, and technical performance compliance of the products - and the coupling and cohesion of the nodes. With this information - assuming it is credible, which is a HUGE assumption - we could model the behaviour of the program and ask what if questions. 

So You Want To Work In Program Planning and Controls?

The domain we work in is unique in some ways compared to the general roles of a Project Manager. First is the "management" of the project or program is done by a specific set of people. The Program Manager and the Control Account Managers. The "program controls" function provides oversight and insight to those people.

There are specific roles on the PP&C (Program Planning and Controls) side of the program. Here are the questions we ask when interviewing someone for that role:

Planning

1. Integrated Master Plan

• Speak about your experience with Integrated Master Planning
• Tell where on the web you'd find information about Integrated Master Planning
• What information do you have at your disposal on guidance for developing the IMP?
• Name 5 possible Program Events in the IMP?

2. Integrated Master Schedule

• What DID defines the creation and use of the IMS?
• What are the three levels of the IMS mandated by this DID?
• What does the DID say about a Schedule Risk Assessment>

Earned Value Management

3. Control Account Plan

• What information is contained in the CAP?
• Who participates in the development of the CAP?
• Who typically owns the CAP?
• With the CAP in hand what would the person do next?

4. Work Package

• What is a Work Package?
• What does the Work Package produce?
• What does the Work Package contain?

5. Earned Value Execution, in you experience ...

• Where are the labor cost rating numbers typically kept in an Earned Value Management System?
• Where the non-labor costs typically kept?
• How and where are subcontract dollars usually recorded?
• What is the impact of starting work?

Monitoring and Control

6. Performance Measures

• What would be the preferred measure of task performance in the EV sense?
• How would you construct a performance measurement system at the Work Package level?
• How would you do the same at the Control Account level?
• What would you say is the best performance indicator for forecasting future performance?

7. Performance Reporting

• What is contained in Format 3 of the IPMR?

Programmatic Risk

8. Duration Estimating

• From your experience, what would be a way of capturing task durations?
• Speak about the possible errors that you might encounter in the method you have used.
• Speak about the statistical independence, coupling, and Merge Bias in activity networks.
• Can you remember what the PERT formula is?
• Speak at bit about the concept of Monte Carlo Simulation
• In what DID is Monte Carlo Simulation (MCS) (Schedule Risk Analysis (SRA)) called out?
• Have you applied SRA/MCS to an IMS? If so, what tool have you used?
• Where is the Monte Carlo of the Monte Carlo Simulation located?

9. Technical and Programmatic Risk Management

• Where would you find information on the DoD Risk Management processes?
• Name the four options for handling Risk.
• What is a Five-By chart and how would you label the axis?
• Where on the chart is the GREEN portion most often found?
• Could you speak to why multiplying the probability of occurrence with the impact might have problems?
• What tools have you used or heard of for managing the named risks in the IMS? 
• Have you applied those tools in the past?

10. Critical Path Analysis

• Speak about programmatic risk and the critical path?
• How do activities get on the critical path?
• What is meant by near critical path?
• What is the impact of Level of Effort activities on the Critical Path?

Microsoft Project

11. Building the IMS

• What would be your advice on the least risky way to build an IMS down to the Work Package and Task Activity level?
• How would you construct unique labels (symbols) for deliverables, outcomes of Work Packages, Milestones, dependencies or any other items that need to be distinguished from the standard work effort?
• Show how you can “profile” the assigned labor level for a resource beyond the single assignment in the Resource assignment field for the task. For example how would you assign 100% to the first three weeks of a ten week task, then 50% for the next 3 weeks, and back to 100% for the last five weeks?

12. Microsoft Project Demonstration

• Why would you not want to use the WBS field in MSFT Project for WBS data?
• How would you make a dependency connection between to activities in two separate project files?
• What is the field length limit in a predecessor or successor field?

These and similar question will bring out the level of experience on the PP&C side of the project. These of course are not related to the other aspects of "managing" the project. But when someone says, "I've got experience managing projects," this is one place to start to see if "providing performance visibility" to the project has been one of those experiences.

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.

Systems Engineering Technical Review (SETR) Timing

In the past NAVAIR had a CD with all the SETR Program Event Checklists. Each had an Excel spread sheet that you filled out to determine if you were ready for the Event and a supporting document that describes all the details of the Event, both entry and exit criteria. The picture above has the link to the current spread sheets.

This approach to the Integrated Master Plan spelled out explicitly what "done" looked and there was no way to skip around the check list and call the work "done," without passing all the items with a GREEN. I've requested from NAVAIR the latest, but looks like it has been expanded to be DOD level now.

This paradigm is at the heart of describing what "done" looks like in units of measure for both the buyer and the seller. Measures of Effectiveness for the buyer and Measures of Performance for the seller.

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

Got an invitation to a Webinar today on scaling Agile to larger teams. This is a very important topic in our domain, since we work software intensive programs that are distributed around the campus and across the country.

Here's the introduction...

Why do the Agile thought leader say this crap. There is no project on the planet that can define all the requirements up front. It's actually prohibited in the DoD 5000.02 procurement life cycle. Detailing everything to be done is utter nonsense. Design the complete architecture, are you f!@#'in nuts. No credible architect would do this. Parcel out work to component teams based on architecture and specification. Does this speaker actually work on complex integrated systems, say manned space flight, or ERP integration.

The bio says Howard worked in aerospace, he should know better than to talk this way. The 5000.02 and IMP/IMS paradigms have been in place long enough to stop saying waterfall. I know some commercial places do this, but they are out of touch with reality. This red herring approach is not only annoying, it does a disservice to those working on complex software systems.

Doctor, doctor, it hurts when I do this, than stop doing that you idiot

Ok enough, how about some rational concepts about scaling. What Howard describes in his paper is similar to the iterative and incremental procurement life cycle of DoD systems.We always start with capabilties, not requirements, no details, not architecture. The agile thought leaders might be well served to take a look at this Capabilities Based Planning paradigm.

• The capabilities of the resulting system are defined in Measures of Effectiveness (MoE) from the users point of view. What accomplishments are needed for the system? These capabilities are immutable unless the customer makes a change. For example the capability of processing claims transactions at $0.07 each instead of the current $0.11 each would be a Measure of Effectiveness.
  
• The Capabilities then need some assessment before we start. Since I assume we are spending other peoples money, these people probably want to know what DONE looks like when we arrive there in terms that are meaningful to them.
  
  • Define Capabilities as Operational Concepts
    • Partition system capabilities into classes of service within operational scenarios.
    • Connect the capabilities to system requirements using some visual modeling notation.
    • Define Measures of Effectiveness (MoE) and Measures of Performance (MoP).
    • Define the delivery schedule for each measure of performance and effectiveness.
  • Define Capabilities with Scenarios or Use Cases
    • Define scenarios for each system capability.
    • Connect these scenarios to a Value Stream Map of the increasing maturity of the program.
    • Assess value flow through the map for each needed capability.
    • Identify capability mismatches and make corrections to improve overall value flow.
  • Assess Needs, Costs, and Risks of the Capability Simultaneously
    • Assign costs to each system element using a value flow model.
    • Assure risk, probabilistic cost and benefit performance attributes are defined.
    • Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance.
  • Define Explicit, Balanced, & Feasible Alternatives
    • Make tradeoffs that connect cost, schedule, and technical performance in a single location that compares the tradeoffs and their impacts.
    • Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these alternative tradeoffs.

The level of detail and commitment for these process varies depending on the domain. It may be some of these are not appropriate for the problem at hand. But you do need to ask if this is the case, before discarding them.

With these capabilties defined to some level of fidelity, the development teams can start to apply good agile processes.

• What do the releasse cycles look like? What in them
• If we have Epics what do they contain?
• What's our estimate for our capacity for work? Meaning what can we produce as a function of time and money for the customerto fulfill the needed capabilities?

These questions get answered in a Value Stream Map that describes how the software system is going to evolve over time, what capabilities the customer is going to receive as a function and time and then the customer can assign the Business Value to that capability.

Here's a picture of a real project doing that.

With this Program Architecure the system architecture, the teams allocated to producing the capabilities, and the defined Business Value can all be used to start developing the Use Cases, Stories, Operational Concepts and any other things youthink you need to execute a Scrum process.

In exactly the way Howard describes it in the picture titled Think Feature Partitions, not Components.

But notice the process step above in the first Bullet Define Capabilities as Operational Concepts and then the bullet Partion system capabilities into classes of service within operational scanarios. Well that's standard DoDS 5000.02 Systems Engineering.

What Howard is describing - and hopefully not taking credit as an orginal idea - is mandated DoD Systems Engineering. It's just good program management practice.

Once you get into the article good stuff starts to flow, but those Red Herrings in the tag line a turn off for us in the world of complex systems development and intergation of software intensive products and services.

But there are some Gaps in Howard's Picture

• Perform Integration - really. What are the protocols for this integration. Where was it defined what the built to specification is these disparate parts that will now be integrated. This is called architecture. In the space business it's call Interface Control Documents (ICD) and that is the role of the Systems Engineer
• All that joint sprint retrospective is nice stuff, but where is the corrective actions needed to avoid all the fixes. In complex integration projects we work, there is another team - a parallel team - who's only job is to facilitate all the integration planning and test - this is called Integrated Test and Evaluation. They focus on making sure all those initegrated parts meet the needed capabilities before we get too far down the road.

The critical understanding here - or missing understanding - is that Software development in large complex projects is NOT the repalcement for Program Management and Systems Engineering.

If all your participants are sitting in the same room with the customer, then those processes are implicit in the air. Once you move away from the single face-to-face team you muust have wrapper processes to keep everyone moving in the same direction.

If you look at the Winston Royce Waterfall Paper, circa 1973, you'll see feedback loops for all the process steps. The Red Herring of waterfall is based on a false understanding.

H. L. Mencken: “For every complex problem there is a solution that is simple, neat and wrong.”

Integrating Cost, Schedule, and Technical Performance Measures

In the previous post, the new IPMR DID instructs us to integrate cost, schedule, and technical performance.Here's some more advice.

Now the bigger question. Where is the similar advice for IT projects. Agile starts down this road, but needs a broader capabilities statement. PMBOK based PM doesn't have much to say if anything around this. Home grown PM processes are usually simple and obvious check lists.

Strategy, Tactics, and Execution

The Afterburners has a seminar titled High Resolution. Their tag line is

Without high resolution, an organization can not align its tactics and strategic plan. High resolution details ensure the organization can execute and provide results that align with the expectations of those that developed the strategic plan.

In the project and program management domain, this means several things, that are many time missing. Missing means the probability of success is reduced. Missing means the project participants have to return to just doing work. Here's what's missing - the the Afterburners guys provide in ways that are rarely found in the PM world. They spoke at a Rocky Mountain PMI Symposium and I attended a training session. It's not for everyone, but if you want a clear and concise approach to getting things done, they're the one.

Here's where to take their quote:

• The Plan is the strategy.
  
  • The strategy is a hypothesis, that must have some means of testing the hypothesis.
  • This Plan must describe how the products and services move from left to right and how their maturity is increasing.
• The Plan's measures are of increasing maturity in Measures of Effectiveness (MoE).
  
  • MoE's are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.
  • The MoE's are stated in units meaningful to the buyer, focused on capabilities independent of any technical implementation, and are connected to the mission success
• The Tactical Schedule must be developed.
  
  • This Schedule shows the work needed to move the products and services forward, following the Measures of Effectiveness.
  • The Measures of Performance describe how the sequenced work produces tangible outcomes
• The Schedule's measures are of compliance with the Measures of Performance (MoP).
  • MoP's characterize physical or functional attributes relating to the system operation, measured or estimated  under specific conditions.
  • The MoP's are attributes that assure the system has the capability to perform and are assessments of the system to assure it meets design requirements to satisfy the MoE's.
• The Execution of the Schedule starts with partitioning the work into chunks that have singular outcomes that can be measured as physical percent complete.
  • These are packages of Work or Work Packages, that span short periods of time - 4 to 6 weeks - and have outcomes traceable to the needed capabilities.
  • The Work Packages are arranged in a logical sequence that provides a clear and concise path to reaching DONE with minimal risk.

This all comes together in the Integrated Master Plan and Integrated Master Schedule.

Books PMs Should Read and Put To Use

There are several shelves of books about many topics in our house. Project Management and related topics are in the Office. The list of books below have specific attributes. They have not only been read, they have been marked up, reread, and used in practice. I have many books that are read, but not marked up. Other books that have been read, marked up, but not put into practice. And a hand full of books that have all three attributes plus one more. The contents of the book has changes how I do my job.

There are other books that I've read, marked up, and concluded the content was either not applicable to the problems I work on, or in a few cases complete nonsense. By this I mean the content is not only not appropriate to the problems I work, but if applied will result in disappointment.

So here's my must have list. This list is not populist in nature. By populist I mean a book or paper in which you CANNOT calculate some outcome. A populist book is something to read if you are just coming to the topic and want to discover the lay of the land.The books listed here are nit populist books

This list is in no particular order, other than they were taken off the shelf in this order. One other attribute is if I know or met the author.

General Project Management

These books are about the general concepts of managing projects, including agile projects. They are from authors who are or have recently benn project and program managers. This is important for the simple reason that who wants to read about something from someone that actually doesn't practice what is in the book. By the way, project management techniques that do not address agile approaches are not that useful anymore. As well, authors with 1996 style credentials have likely been passed by the current approaches as well.

• Making the Impossible Possible: Leading Extraordinary Performance, Kim Cameron and Marc Lavine - this is a case study about the management processes at Rocky Flats. Here's a quick summary of the concept of Positive Deviance and Heliotropic Abundance.
• Strategic Performance Management: Leveraging and Measuring your Intangible Value Drivers - Bernard Marr speaks to managing the business value from projects. There is lots of discussion around this, with lots of soft terms. This is a book that turns that populist view into a balance sheet view.
• The Handbook of Program Management, James T. Brown - I have met Dr. Brown. He is a former Program Manager at NASA. This is a book about program management. Program Management is about managing collections of projects. It is a hands on instructional advice type of book.
• The Radical Elements of Radical Success, Dan Ward - this is a book from a person practicing Program Management. Dan is an Air Force procurement officer, just back from theater. It's one of those books that causes me to think. Dan and I have had long discussions about the issues in government procurement. Here's a pre-defined search for Dan's work
• Project Management the Agile Way, John C, Goodpasture - I know John professionally, but have never been face to face. John and I share many common principles. This book is published by Management Concepts, which I do work for. MC publishes books, provides courses, and services for the Federal Government. John's book shows you how to deploy agile processes in the presence of the governance based environment. One where you are spending other peoples money and are accountable for success to external parties, like the Federal Government, a Board of Directors, and share holders.
• Flawless Execution, James D. Murphy - I cam across the After Burners at a PMI conference. The speakers are all ex-fighter pilots. There approach is logical, concise, and clear. The perfect paradigm for managing projects. This approach is not for everyone. It holds all members accountable for their actions, builds teams in ways not found in any other approach and is not one of those touchy feely styles.
• Catastrophe Disentanglement: Getting Software Projects Back on Track, E. M. Bennatan - there are many books about recovering projects. I'm reading another and writing a review. But this book is a check list book, with a step-by-step process of recovering projects.
• Beyond the Hype, Robert G. Eccles and Nitin Nohria - this is one of those must read for anyone interested in processes. Many if not most of the new ideas are actually old ideas in new cloths. Or worse, poor copies of old ideas promoted by self aggrandizing authors who know how to market. This book speaks to the problem of not knowing the past, so you
• Reinventing Project Management, Aaron J. Shenhar and Dav Dvir - this is a good starting point for PM in the IT environment. With field proven approaches, the books provides the step-by-step activities needed to manage projects in the Enterprise business domains.
• The 7 Habits of Highly Effective People, Stephen R. Covey - this is one of my populist books that has direct applicability to project management. Our method - Performance Based Management - contains most of the content of Covey's book is for Project Manager, including the Performance Based Management process we use on our programs.
• The Seven Secrets if How to Think Like A Rocket Scientist -Jim Longuski describes the processes needed to manage complex projects. It's a check list of items rarely thought about in the normal project management paradigm. This is done, because the domain Jim works in has projects that blow up and kill people of not properly managed.
• A Bee in a Cathedral - Joel Levy's book is here because using analogies in the project management world is very common. And most often the analogies are bogus. read this to see how to use analogies properly, since they are powerful tools to get points across, reveal understanding.

Leadership

There are so many books on leadership in the project management space. I'm simply burned out listening to all the voices on leadership from folks who speak and write about the topic, but who have not actually lead people under circumstances that require real leadership. Here's the books that you need from those people who have.

• How NASA Builds Teams - Pellerin led the Hubble Space Telescope program and speaks to how that worked and didn't work.
• Augustine's Laws - Norman was the leader of Martin Marietta here in Denver. These Laws are general business processes but for high tech firms.
• 8 Basic Habits if Exceptionally Powerful Lieutenants - this book and the next come from the Air University Press,  many in downloadable PDF.
• Commanding an Air Force Squadron in the Twenty-First Century - this is another survey books about how leaders learn to lead.

Systems Engineering

In the aerospace and defense business Program Management is a Systems Engineering paradigm. This is because the technical architecture of the program has to be matched with the programmatic architecture. The product that is being designed must also be built and shipped. This means the value stream flow of work needs an architecture as well. This is the purpose of the Integrated Master Plan (IMP) and the Systems Engineering Management Plan (SEMP)

These books are the basis for being a good project manager. Here's a list of specific topics, meaning more technical, needed for project success.

• System Engineering: Coping with Complexity, Richard Stevens - this is another handbook for designing, developing, and deploying systems.
• The Art of Systems Architecting, Second Editon, Mark W. Maier and Eberhardt Rechtin - everything is a system. No those silly descriptions of those populist systems where you can't design or calculate anything. But system we encounter in the real world. The air traffic control system, the banking system, the internet, the enterprise IT systems, manned space flight, building the 787. Systems like that. Rechtin is the father of the approaches used to build real systems. Yes, people are in these systems. And people are an important part, but in these types of systems, the components of the system are the basis of success.

Risk Management

There are lots of risk management books, articles, websites, and Bloggers out there. Here are the two you should own and read.

•  Risk Happens!: Managing Risk and Avoiding Failure in Business Projects, Mike Clayton - I've corresponded with Mike for several years. This is a great book for starting the process of risk management. It follows the steps defined in many locations - the best is the SEI Continuous Risk Management (CRM) model. There are simialr guides from DOD and DOE. PMI has a Risk Management Practice Guide, but like most things PMI they have their own way of doing things and rearrange the work processes.

As an aside determining risk drivers is a critical success factor for any Risk Management process. Typically risk management means making lists of risks, ranking them, and doing some kind of handling. This is not only naive, but it is wrong. You must determine which risks drive which undesirable outcomes of your project. Start with A Framework for Categorizing Key Drivers of Risk and Taxonomy-Based Risk Identification. I worked with one of the authors.

• Effective Risk Management: Some Keys to Success, Edmund Conrow - I've worked with Ed on a proposal and he turned me on to several concepts that I use daily. The first is the serious error in the PMBOK about multiplying the probability of occurrence with the ranked outcome to produce a risk score. This is not mathematically possible, since both are probability distirbution functions. The Method of Moments can help if you don't have a Monte Carlo Simulator. But if you don't buy Ed's book and read how to do Risk Management the right way.
• Effective Opportunity Management for Projects: Exploiting Positive Risk, David Hillson - I have met David, and spoken with him over the web. This is good book for addressing the opportunity concept. You should read Conrow's advice for mixing opportunity and risk before doing so yourself.   

Earned Value Management

There aren't really a lot of books about Earned Value Management. But there is a ton of misinformation about how EV is used, no used, applied, and misapplied. So these books and sources should be the starting point

• Performance Based Earned Value - Paul's book came out a few years ago, and the ideas have been with me ever since. The notion that Technical Performance Measures are part of Earned Value was present in the C/SCSC days, but was lost in 748-B and needs to come back. See Paul web site of the same name for good background.
• Earned Value Management Intent Guide - is the National Defense Industry Association's offical document for US Government Earned Value Management. This guide tells you how to comply with the 32 Guidelines of Earned Value Management. For most projects outside the government this is not applicable. But you should read this anyway, just to have an understanding of what the largest implementations look like.
• Earned Value Management Maturity Maturity Model - Ray's book provides a framework for assessing the processes needed to improve the maturity of your Earned Value Management implementation
• Earned Value Management site at the Office of Secretary of Defense, Performance Assessments and Root Cause Analysis.
• Earned Value Management at the NASA site has lots of background as well.

There are other sources of Earned Value, even in the agile world. But care is needed. To properly use Earned Value you must be able to do several things:

1. Maintain a baseline of the capabilties at least - the end outcomes of the project should not be changing
2. Know the total budget - the end budget and some notion of how this is spread over time.
3. Have some measure of physical percent complete and know how much physical percent complete you should be at when you measure it.

If you can't do these, you shoulded be considering Earned Value for your project

Statistics and Math

Project managers need to know somethings about probability and statistics. All the numbers in project management, cost, durations, head count, technical performance are random numbers. In the absence of knowing how to use statistics and probability, you're going to be late and over budget before you start.

• How to Lie With Statistics - every PM must have this book, must have read it, and must put it to use. When you have a conversation with anyone on the project, have this conversation in the context of this book.
• Then get Advanced Statistics Demystified or Statistics for Dummies and learn about sampling, variances, inferences, and other models of how your project is going to be working even if you don't know that is working that way.

 

Project Management Blogs

I got an announcement today that Herding Cats was nominated for a spot in the Top 100 Business Blogs in the category of Operations Management. I've never been one for awards. I'm certainty not ungrateful, but being influential in your peer group probably can't be measured in a survey.

The list of PM Blogs includes those I know and some I was unaware of. Here's the list. Herding Cats is in between QuantumLeap and Eight to Late. Both good company.

• Stepping into Project Management -a new blog for me, about the experiences of a Project Manager.
• Guerrilla Project Management - an interesting site I have not heard of. The Statement of Work book is worth a read as a starting point for developing a description of what Done looks like for a software projects. A bit traditional for my tastes in our IMP/IMS world, but a great start.
• Fear No Project - I know this Blog but haven't read it in awhile. As a software development Blog it looks like a good read. But makes the common mistake that PMBOK is  method and a waterfall method at that. Waterfall is not allowed in defence acquisition, was debunked in the late 70'2 by Walker Royce. Read Software Management Renaissance to see how this is handled. And the orginal paper, 1970, Managing the Development of Large Software Systems. I do wish those with voices would come to a better understanding about PMBOK and Waterfall. But take a look, good information here.
• Project Management Student - Josh's blog is a must read. I've known Josh for sometime and he's contributed to the development of good Work Breakdown Structure training materials.
• Portals and KM - I have not heard of Bill Ives. The Blog is focused on Web 2.0 and Enterprise computing. I know somethings about those topics, but from the project management side.
• Quantmleap - Shim and I have exchanged emails and Blog posts for several years now. He's recently posted any Earned Value in the Agile world in a way that simply and clearly describes the principles of measuring physical progress to plan. A concept required for success, no matter what software development method is being used.
• Eight to Late - Kailash is a kindred spirit physicist with shared world views about the nonsense that passes off as populist advice in the absence of any evidence that is works outside of anecdotal experience. K's Blog have the proper references to back up his message. One of the best is the background on Reference Class Forecasting that is becoming the normal in probabilistic duration estimates. There's a big discussion going on LinkedIn Earned Value about duration estimates. K's posts would be a good place to start. Reference Classes are used in many domains - manned space flight is one I work - where pre-defined boundaries of the variances are derived from past performance (actual numbers) and models of the interactions of the operating components and their own probabilistic behaviors.
• A Path To Peace - I'm not qualified in the coaching role, at least outside the technocrat domain I work in. This site provides lots of advice about career as well as interpersonal actions.
• The Critical Path - Derek and I have communicated in the past. I like the Zombi's paradigm and the layout of the site is very modern, with lots of great content focused on agile development.
• Leading Answers - Mike's site has recently been focused on risk management and that's of great interest to me.
• Bertrand Duperrin's Notepad - is a site new to me. Looks like Bertrand has hands on experience in enterprise IT at major companies. I worked in France for a year in the petrochemical control systems business. The level of technology was much more sophisticated than in the US at that time, so I assume it has continued to progress.
• Manager Tools - looks like a commercial site for meetings and career processes. Free membership, so worth a look.
• Ron Rosenhead - Ron is one of my favorite UK blogs. Lots of good thoughtful practical advice.
• The Enlightened Manager - is a consultant blog of Cheri Baker. New to me. Coaching and organizational development offerings. Some nice posts about work related activities.
• NOOP.NL - Jurgen Appelo's site promotes his book Management 3.0. A bit too self promoting for my taste. A sample of Jurgen's view of the world is best expressed by him ... According to various sources I'm the "most popular/influential" person in the Agile world in Europe. In the U.S. we'd call this Hubris.
• PM Hut - is a consistent source of PM information. Some really good, some a bit less, only because it is a bit too simple. But it serves its purpose and therefore should be on your list.
• Girl's Guide to Project Management - Elizabeth's Blog is one of my favorites. Lots of hands on experience, thoughtful advice, and working examples from the field. APM focused, so it's a nice reference to how projects are managed outside the US. Elizabeth provides examples from the UK for projects that have run into trouble and makes credible suggestions for corrective action. Between Elizabeth and Ron, a good insight into PM in the UK.
• Crossberry - Paul and I have corresponded for some time, when he ran the SAP Global PMO (or something close). We share lots of common thoughts around how to manage enterprise class projects and how NOT to manage enterprise class projects. Paul's advice comes from the school of hard knocks.

All these Blogs are worth the reading effort. I have some of my own, in no particular order, other than going down my Google Reader list. I'd recommend:

• Shift Happens! - Mike Clayton's site about risk and project management. His book Risk Happens! is a must read for anyone wanting to understand how to be a risk manager. Mike has a nice newsletter, speaks to the topic of risk from hands on experience, and is well grounded in the practical aspects of improving performance of both the people and processes. Mike is another kindred spirt from physics, so the notions of tangible evidentiary materials is the core of his paradigm.
• Projects At Work - Aaron Smith is the editor of this site and provides a very useful service to all project managers interested in well rounded resources. Free membership is required, but more than worth the effort.
• Ferhan Bulca - is a colleague I've worked with in the scientific instrument business. Ferhan is a systems engineer as well as a software product development manager. His posts are focused on the broader issues of system integration, capabilities planning, and over all project performance measurement.
• Mario Vanhoucke - Mario and his colleague Stephan Vandevoorde have state of the art project management tools, based on academic theory tested in the field. Stephan's firm Fabricom, builds airports, energy facilities, and other infrastructure using their ProTrak tool. This tool uses Earned Schedule and other advanced processes.
• John Goodpasture - is one of the best credible sources for agile management. John has several books based on hands on experience in large enterprises. I'd trust John for any advice around agile, since this advice comes from a wide variety of mission critical projects.
• Kelly's Contemplation - Robert Kelly provides hands on advice for project management from direct experience deploying agile enterprise solutions.

Good Project Management Advice

Jesse Fewell has a nice post of how to deliver less and be more successful. What's interesting is this straight forward agile approach is also the straight forward IMP/IMS approach.

Jesse has three major steps to success

1. Define Business Success

In the IMP/IMS world this means having a defined set of capabilities connected with mission success. What capabilities do we need to accomplish the mission? This could be flying to the moon, driving around in the desert with equipment on board, sailing the ocean blue protecting the fleet.

But the mission statement must be based on capabilities. These capabilities must be defined in Measures of Effectiveness. These capabilities described through:

• Operational concepts
  • Partition the system capabilities into classes of service within operational  scenarios.
  • Connect these capabilities to system requirements using some visual modeling notation. A block diagram to a sysML model.
  • Define Measures of Effectiveness (MoE) and Measures of Performance (MoP).
  • Define the delivery schedule for each measure of performance and effectiveness.
• Use Cases or Scenarios
  • Define scenarios for each system capability.
  • Connect these scenarios to a Value Stream Map of the increasing maturity of the program.
  • Assess value flow through the map for each needed capability.
  • Identify capability mismatches and make corrections to improve overall value flow.
• Assessment of needs, cost, and risks of each capability simulatenously
  • Assign costs to each system element using a value flow model.
  • Assure risk, probabilistic cost and benefit performance attributes are defined.
  • Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance.
• Define explicit, balanced, and feasible alternatives
  • Make tradeoffs that connect cost, schedule, and technical performance in a single location that compares the tradeoffs and their impacts.
  • Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these alternative tradeoffs.

2. Define the Business Constraints

Build the Plan for the project using an Integrated Master Plan (IMP). The IMP describes the Significant Accomplishments (SA) and the Accomplishment Criteria (AC) for the Packages of Work needed to provide those Significant Accomplishments.

With the SAs and ACs arranged in the proper order to produce increasing maturity of the deliverables, the constraints can be defined:

• Is there enough time and money?
• Are the impediments to progress defined and handled?
• Can you measure progress to plan in units meaningful to the decision makers?

3. Deliver the Mimimum Necessary to meet the Business within the Constraints

This is where the IMP comes in again.

The topology of the Integrated Master Plan and the Integrated Master Schedule is focused on defining the incremental and iterative development of the increasing maturity of the projects capabilities that meet the mission need. This paradigm is applicable to all project domains, technologies, and product and project management methodologies. It is universal.

There are some key outcomes of this approach - the IMP/IMS approach - that can address the concerns raised by Jesse

1. All requirements must be traceable to a system capability. Why do we need this requirement? What capability does it support? How does it increase the Effectiveness of the system and how would we measure this Effectiveness in tangible units.
2. Over-engineering may be a problem, but the root cause - resulting from the 5 Whys of why is this over-engineered - must be answered first. If we know the Measures of Effectiveness and the Measures of Performance, the Technical Performance Measures, and the Key Performance Parameters, then over engineering is replaced with right engineering.

These issues can be addressed by developing the proper measures, starting with the Mission Need.

For each of the Technical Performance Measures, actual units meaningful to the decision makers can be developed and tracked during the project's life cycle.

No matter the method - agile or traditional - some form of these processes is needed to answer Jesse's need - produce more by doing less. Actually produce more by doing the right amount.

Rings of Success

Olympic Rings featured in nearing everywhere these days. Those rings represent the 5  parts of the world which now are won over to Olympism and willing to accept healthy competition. While there is much talk about the projects of the Olympics, some difficulties and many successes, there are other rings that must be connected for project success:

1. Risk - all project elements have risk. Cost and Schedule risk are a starting point. These can be addressed through straight lists of risks, their probability of occurrence, impacts, costs to mitigation and residual impacts after mitigation. Most approaches to risk management assume an independent association between the risks. That is they are decoupled risks, existing on their own. Many times this is not the case. What is Program Controls? speaks to some of the complexity of integrating technical risk with programmatic risk and addressing the coupling issues that are ignored in the Monte Carlo Simulators of project duration and their resulting cost models.
2. Cost - the olde phrase time is money is tossed around without any real consideration for what that means. What is the relationship between time and money. Where is that relationship defined? What are the statistical attributes of that relationship and its impact on the probability of success for the project. This must be addressed through a cost modeling system. SCEA is one place to start.
3. Statement of Work - What Does DONE Look Like? The SOW is one place to look. Assuming it is written properly. But Statement of Objectives, Concept of Operations, Scenarios, Use Cases, and Performance Work Statement are also places to look. Without a clear and concise collection of deliverables
4. Technical Performance Measures - define what DONE looks like in units of measure meaningful to the decision makers. TPMs involve a technique of predicting the future value of a key technical performance parameter of the higher-level end product under development based on current assessments of products lower in the system structure.
5. Work Breakdown Structure - describes the products or services to be delivered by the project, how they are decomposed and related. At the end of the tree of the WBS, is usually the Packages of Work that produce these outcomes. Without a properly formed WBS, you cannot determine what done looks like in any meaningful way. A typical mistake is to develop a WBS based on work types - design, code, test. This simply states the effort not the result.
6. Integrated Master Plan / Integrated Master Schedule - The IMP is the Plan for the delivery of a set of Capabilities from the project and describes the increasing maturity of these capabilities through Significant Accomplishments and their Accomplishment Criteria. The Integrated Master Schedule describes the sequence of work, usually in Work Packages needed to produce the deliverables for the Accomplishment Criteria.
7. Performance Measurement Baseline - brings the cost, schedule, and outcomes together in one place, puts this under change control, and measures progress to plan through assessments of Physical Percent Complete, and forecasts future performance (Estimate At Completion and Estimate to Complete) using Earned Value Management.

Putting This All Together Through the Tangible Evidence

Each of the Rings are represented by tangible evidence in the form of a document. I can hear the agilest now, no documents. Well sorry, in the domain we work, we need evidence that you do in fact have a SOW, a Risk Plan, an IMS, a cost basis of estimate, a Technical Performance Management plan and other items that show the project is planned properly, being managed properly, and measured properly.

Here's the top level connections...

The Critical Missing Element of Most Project Managment Methods

Most projects we come to for recovery or triage, we find there is a missing piece of the puzzle.

No one knows what actual Capabilities are needed from the system when it is complete, or even what incremental capabilities are needed along the way to the end.

A capability is defined and managed ...

Planning, under uncertainty, to provide capabilities suitable for a wide range of modern-day challenges and circumstances while working within an economic framework that necessitates choice.

By Identifying system capabilities, the elicited technical and operational requirements can be traced from the Measures of Effectiveness to each deliverable in the Integrated Master Plan and Schedule. Capabilities state the “why” of the system.

Without a clear and concise description of the needed capabilities, requirement - technical and operational - have no home. The system them becomes a solution to a laundry list of "stories," "needs," "requirements."

Agile is starting to address this notion through Epics, but the formal development of Capabilities is not found in traditional project management methods.

This approach is the foundation for the business value proposition.

This by the way is where some in the IT business get confused about the "value" of Earned Value. Scott Amber for example, makes this mistake when he claims Earned Value does not represent business value. He is correct, but for the wrong reason. The term "earned value" in the ANSI-748-B paradigm was established long before the notions of modern agile "business value" were and therefore has a different definition. Both are needed, but 748-B earned value speaks to the amount of the budget that was "earned" at the time of assessment, versus the planned amount of budget for that same time.

Using the assessment of the capabilities is how you know that you are actually delivering Business Value. With the defined Capabilities, each Requirement now has a home, you know the reason for the requirement - the why are we doing this question.

Here's the Offical definition of Capabilties Based Planning from the ToGAF 9.1 source

Capability-based planning focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. Capability-based planning accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities. Often the need for these capabilities are discovered and refined using business scenarios (see Part III, 26. Business Scenarios and Business Goals).

From an IT perspective, capability-based planning is particularly relevant. For example, setting up a data center is really about consolidating corporate data and providing the related services. Lead enterprise architects for this capability will find themselves involved in managing construction, personnel training, and other change management tasks as well as IT architecture tasks. In the past, many IT projects were less than successful even though the actual IT implementation was brilliant, but the associated other tasks (business process re-engineering, client training, support training, infrastructure, and so on) were not controlled by the enterprise architects and planners and often were not satisfactorily completed.

On the other hand, IT projects were often described in terms of technical deliverables not as business outcomes, making it difficult for business to appreciate what was being delivered and often the IT architects lost sight of the ultimate business goal. Capability-based planning frames all phases of the architecture development in the context of business outcomes, clearly linking the IT vision, architectures (ABBs and SBBs), and the Implementation and Migration Plans with the corporate strategic, business, and line of business plans.

In many governments, horizontal interoperability and shared services are emerging as cornerstones of their e-Government implementations and capability-based management is also prominent although under many guises. In the private sector, the concepts of supply chain management and Service Oriented Architecture (SOA) are increasingly forcing planners/managers to govern horizontally as well as vertically.

It is the needed Capabilities that fulfill the Mission and Vision of their value proposition.

Fail Forward

I was reading a Bloomberg News article while stuck at the airport heading home. Waiting for the inbound flight Denver where they had 2 feet of snow today. The artilce used the term fail forward. The concept is around innovation and the culture of innovation.

There were example of famous lack of innovation stories. The Western Union internal memo stating This telephone has too many shortcomings to be considered as a means of communication. The wireless music box has not ... commercial use, was the response to David Sarnoff's request to investing in the radio.

These may be urban legends, but Edison did hire dozens of "inventors" to helo him fail forward and share what they learned from these failures.

What Does This Mean For Projects?

It an obvious tennet of agile to fail early and fail often. But that is just a buzz word phrase in practice. It's of no real value in the absence of a PLAN for failure.

Remember a Plan is a strategy for the successful execution of the project. And Strategy is a hypothesis that needs a test to move forward. This is where the fail forward takes place in an actionable manner.

One program I've worked is a BioPharma contract with the US Army for an anti-virus. The Integrated Master Plan has multiple steps to fail forward in the development and testing of a molecule that is the basis of the drug. The researchers are seeking failure in a sense. They having paths they are taking - with intent - to fail forward.

So what this means is:

• We need a risk buy down plan - this plan performs specific work to buy down or retire the risk that the outcome of the project will not be reached on time or on budget. The outcome must of course be compliant with the Technical Performance Measures, otherwise no one will call the project a success.
• We need specific Measures of Effectiveness (MoE) and Measures of Performance (MoP) for the increasing maturity of the product or service the project is producing. These measures have been described before

So the fail forward paradigm must define how you are going to perform work the actually moves the project forward. Edison did not randomly go try out things in his search. He had a Plan and Strategy. It was not a random walk in the woods looking for the solution.

There were 1,000's of trials. 10's of 1,000's of attempts to invent Radar as described in the book Tuxedo Park. All the processes were fail forward, not self organized, self actualized, self guided. But structured, organized, intent of the command efforts to discover something that was not discoverable without failing forward.

This is were the agile approach is at its most powerful.

We know what Done looks like - a blub of light, a radar systems where non existed before. Richard Rhodes The Making of the Atom Bomb describes similar efforts to Fail Forward.

The critical concept, many times missed or mis-used in the agile world, comes from the MoE paper referenced above.

The design of a system is an ill-posed problem that has no solution without a set of criteria to guide choices.

Without this set of criteria to guide the choices, the project wanders aimlessly in the forest of all options. This is the role of a Capabilities statement. The role of a Strategy for fulfilling those capabilities.

The agile notion of Epic provides this. It shows what done looks like in units of measure meanigful to the decision makers. It shows how the fail forward in the pursuit of DONE.

So ask the simple question

What is the Plan that shows the sequence of processes or activities we are going to need to fail forward?

 

You Need A Map To Tell The Outcome

Like Jane Austin's Pride and Prejudice you can't tell where the story is going without a map.

The Integrated Master Plan is the Strategy for the success completion of the project. It shows the Accomplishments and the Criteria for these Accomplishments needed for the successful completion of the project.

The Map of the relationship between these Accomplishments and Criteria shows how the performed work increases the maturity of products, services, or outcomes of the project.

This approach is distinctly different from the horizontal approach of scheduling work by linking work activities in a sequence and measuring progress by the passage of time and consumption of resources. While there are products produced from this horizontal paradigm, there are no explicit measures of the increasing maturity of the work products.

In order to reveal how to increase the maturity of the produced products some form of map is needed. This is an example of one.

This map is read as  

The Aerodynamics Flight Test will be complete when the following Significant Accomplishments are complete.

These Significant Accomplishments include the items shown by discipline - System Engineering & Integration, Safety and Mission Assurance, Spacecraft (structures), Software and Avionics, Operations, AI&P (Assembly Integration & Production), and Flight Test.

Under each of these Significant Accomplishments (SA) are the Accomplishment Criteria (AC), which are the Exit Criteria for each of the Work Packages that contain the actual work activities for this specific Program Event (Aerodynamics Flight Test Complete). These Work Packages, their Tasks are where the work takes place. The Criteria and the Accomplishments are the maturity map for the project showing how the maturity increases and what measures of this maturity are needed.

These measures are Measures of Effectiveness and Measures of Performance.

 

What Does A Master Schedule Look Like?

When we speak about "master" schedules in the space and defense business, this is what they look like. These types of "pictures" are all too common in the commercial world. In the defense business they look notional, but they are build from the underlying Integrated Master Plan and Integrated Master Schedule.

There are several tools that can make these charts from the Integrated Master Schedule. This approach ensures that the dates, dependencies, and top level process flow is represented correctly all the way down to the Control Accounts and Work Packages that on in the Performance Measurement Baseline.

There is no issue with having these types of Program Master Schedules for any project as long as they are connected to real baselined data.

Connecting the Dots in Agile

I presented a briefing to an internal agile development group at a major defense contractor this week. The topic was - as always - integrating Earned Value Management with Agile Software Development. The discussion started with connecting the WBS to the Agile domain. The reason for this is simple. All Federal government contracts come with a Statement of Work (SOW), a Program Work Statement (PWS), a Statement of Objectives (SOO), or similar statements of what DONE looks like.

From these documents, which are part of the contract, a Work Breakdown Structure is either provided or built. A Contractor WBS many times is derived from the Government's WBS. These WBS's define the decomposition of the product and the services that develop the product. There is NEVER a decomposition of the departments or work performed by those departments. Things like Design, Test, Integrate are not part of the WBS. The can be a field in the IMS (Integrated Master Schedule) showing which department is assigned to which WBS elements. This is then used in a pivot table to build the RAM (Responsibility Assignment Matrix).

So here's how to connect Agile to the WBS

In the current vernacular of Agile an Epic is the top level outcome of the Agile project. Per several definition an Epic is a collection of User Stories. These Epics can be put up on the wall and arranged into groups - the Epics. This has a very close connection to the Program Events or Milestone in our defense procurement model.

From the Epic, Stories are decomposed and Features are extracted. These Features are the tangible deliverables of the project. They are what the user bought for the budget of the project. Inside each Feature are Tasks that develop the Feature inside the Iteration.

So this is a nice starting point for connecting the dots between the Agile vocabulary and our more traditional IMP/IMS paradigm.

Here's some background on IMP/IMS:

• IMP/IMS and Deliverables Based Planning
• What does and IMP/IMS look like?
• What is a Work Package?

All of this focuses on building a clear and concise of the Grammar of DONE. If you don't know what DONE looks like in tangible units of measure meaningful to the decision makers, than you'll never recognize it when it walks through the door. With this concise description, the only measure of progress to plan is the consumption of money and the passage of time. Agile does a good job of defining the outcomes of each itertaion, and managing the contents of those iterations during the Planning process. What is needed is an upper level process. This is provided by the Epic.

So starting with these connections, traditional project management structures are connected with agile structures.

What's next is to define the work rhythm. Of course Agile does this with Iterations that run a few weeks. Traditional IMP/IMS does this with Work Packages, running 4 to 6 weeks. These Work Packages are embedded in a Rolling Wave, with multiple Work Packages in each Rolling Wave.

So here's how to flow down the WBS to the Work Packages. In Agile the WBS element can be a User Story (a deliverable capability) or a Feature (also a deliverable capability). In all case these Work Packages are single output work efforts.

What Does Done Look Like?

I've participated in two session at Carnegie Mellon Silcon Valley's Masters Program, as a speaker. And one of our staff is completing his Masters Program there. he sent me this picture.

The inside joke, besides the graduates completing the work, is that "what does done look like," is the phrase used on most of our aerospace and defense programs.

This question and the answer, goes like this:

• When will this thing fly? On or before mid November 2014, with an 85% confidence.
• When can we install the next version of the Command and Data Handling firmware? On or before November 19th, 2010, with 90% confidence.
  
• When can the C-130 (tail number 56-0478) be ready for Ops? Next Wednesday sir, 100% guaranteed.

You get the idea. It serves no purpose to have a plan or a schedule if you don't know what "done" looks like. "Done" is defined in units of measure meaningful to the buyer, user, owner. It serves no purpose to state a date or a time unless you know the confidence level and the error on that confidence level.

If anyone speaks to you about "point" values, ask them what's the confidence level, and what's the error on that confidence. If they don't know, or don't know how to get these values, or don't care to get them - this point value can't be right. And most importantly, the point value can't be credible.

What is a Work Package

Edward Carroll's Blog On Projects, has a post about Work Packages in Prince2. This is the first I've heard of Work Packages outside out Earned Value Management System description. The EVMS System Description of the guide describing how programs are managed at the program planning and controls level. Here's a sample of the instructions provides for Earned Value based programs.

The Work Package appears as the bottom of the Integrated Master Schedule in the majority of programs. It is the Work Package that is "on baseline," rather than individual tasks. There are several reasons for this:

• The Work Package usually has a duration of less the 60 days. This depends on the System Description, but the 60 days is so the planned completion of the work crosses only one accounting period. This answers the question How long are you willing to wait before you find out you're late? The answer 60 calendar days. This sounds long for small software projects, but it's VERY short for large defense and space programs running 5 to 7 years.
• The Work Package has ONE and only ONE deliverable. This deliverable can be an intermediate outcome for the entire program. This removes all the blather and red herrings of uninformed agilest about the defunct Water Fall process in Big Projects. Work Package outcomes are close stories. They can be partial completions of work - these are 5 to 7 years programs, so it'd be hard to produce fully formed outcomes in a single cycle.
• The Work Package "exit Criteria" is the Accomplishment Criteria in the Integrated Master Plan. Here's some background on the IMP/IMS paradigm. IT and software development programs would be well served to look through the guidance for defense and space software intensive programs - to see that Scrum, iteration, incremental, test driven design and other attributes are in place and used everyday. That quote - What has been will be again, that has been done will be done again; there is nothing new under the sun. - Ecclesiastes 1:. Yea that quote, it's true in program management as well.
• The Work Package is owned by the "work package owner." This person is singularly accountable for delivery the outcomes from the Work Package. The Work Package can have a team, they can be organized in any why needed to get the work done. But there is only one person ACCOUNTABLE for the results - the Work Package Manager.
• Work Packages live in Control Accounts (the intersection between the WBS and the Organization Breakdown Structure (OBS). The Control Account Manager (CAM) is singularly ACCOUNTABLE for the progress to plan of the Control Account. The notion of shared responsibility and accountability works nice in theory or on small self contained software development projects. On mission critical programs is does not.

In the whole scheme of things, here's where the work packages live...

Another Version of "What Does DONE Look Like" - This Time Video

The Pad Abort 1 Program Event for Orion has video now.

The structure of the Plan and the Schedule to implement the plan follows the standard IMP/IMS topology has been discussed many times here.

The Event here is the Pad Abort 1 flight test. The Accomplishments are the "entry criteria" for the Event. This describes what has to be done - 100% done - in order to conduct the Pad Abort 1 Flight Test. This Event is named Pad Abort 1 Flight Test Complete. This "past tense" statement reinforces the notion of "done."

The work needed to fulfill these Accomplishments is done in Work Packages. The "exit criteria" for each Work Package is defined in the Criteria. These are tangible evidence measures of "Done," for the tasks in the Work Package.

The sequence of Work Packages, and therefore the sequence of Tasks in the Work Packages is the Integrated Master Schedule (IMS).

This paradigm provides several significant advantages over the typical "horizontal" schedule. The usual "shop floor" schedule - a sequence of all the tasks, hooked up into some network.

• The description of the increasing maturity of the deliverables for the Program Event is defined in the percent complete of the Criteria and rolled up to the Accomplishments.
• The "map" of how this increasing maturity flows is defined in the relationships between the Accomplishments.
• The vertical integration is the starting point of defining what "Done" looks like, not the horizontal execution of the task activities.
• This inverts the conversation by measuring progress as the accomplishment of work in units of physical percent complete. Not the passage of time or consumption of resources.

For Scrum like IT projects, this is an architecture for larger projects that states how the iterations move the maturity final end product, which is missing in the traditional Scrum project process.