Herding Cats

Agile in the Federal Government with Tony Barrett

Agile project management in the Federal Government is coming of age. A colleague from the Earned Value Management domain - Tony Barrett - was on Federal Tech Talk.
Tony has several important points that are critical to the success of "agile projects," from the agile project management point of view. The management of "agile software development" is not the issue. It is the management of the "project" that encompasses the entire delivery life cycle that drives the success of the project.

Give a listen and learn from a hands on practitioner of agile project management in the federal government space.

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.

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.

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.

Federal Goes Agile

Jeff Sutherland has a post about agile in the Department of Defense. Good stuff, but there are some issue with "going agile" in the Federal IT space. The first is for contracts over $20M require Earned Value Management, per FAR/DFARS flow downs and the OMB Part 7 guides for "FedCiv."

The second is the contract vehicles need to be adapted to how agile does things with requirements, changes, deliverables, progress payments, fee calculations. Here's the "tip of the iceberg" for integrating Scrum with Federal Acquisition. While Scrum is a wonderful concept and applicable to large majorities of projects, but it's not quite as simple as it might seem.

Here is a recent briefing on the top of agile in the federal procurement world is the focus of many organizations in and out of the government. Management Concepts is one source of training for agile in the Fed space, there are others. But in the end this is an acquisition issue.

Without changes in the FAR/DFARS clause flow downs that "put on contract" the behaviors mandated by the regulations of how software is developed, acquired, and put into service. While the agile community has many power tools to improve the problem in the federal government, they need come at this from a acquisition point of view for those benefits to be realized.

Here's some prior discussion

• Agile in the Federal Government
• Agile in the Federal Environment Webinar
• Big Program Guidance - A Caution to Agile

 

Quote of the Day

The real importance of the Greeks for the progress of the world is that they discovered the almost incredible secret that the speculative Reason was itself subject to orderly methods - A. N. Whitehead, The Foundation of Reason.

When there is speculation on any topic, it must withstand orderly assessment for it to be anything beyond speculation. Without this process, advances in any domain are not possible.

The Failure to read "Statistical Surveys for Dummies"

This is from the Standish Blog, introducing the interview with Jeff Sutherland.

So let's think a bit about the survey of 300 IT Executives. You call them up and ask do you thing skills are important in executing a software development method?  An agile development process?

You should have asked do you think skills are important in performing the work assignments of the IT department?

What kind of IT Executive would say nope, I don't think skills are important in performing the work assignments of my department, I'm just going to hire and assign work to people who have no skills in their assigned job.

Are you out of your mind? What kind of survey question is this. What's more amazing is 6% of the IT Executive said skils were only somewhat important.

The sad thing here is Standish then wants you to sign up for access to their survey database for $1,500.

This type of question doesn't even pass the smell test. Here are some alternatives:

• How important do you think having a senior leader in agile development is for the success of your agile efforts, one with sufficient experience and skills to perform a consulting and coaching role?
• Do you think you will be able to roll out agile development in the absence of journeyman level staff?
• Do you have plans to hire journeyman level staff prior to starting your first agile software development effort?
• Would you hire external consultants to play needed roles on your staff until they become journeyman level?

Empowered to do WHAT?

Derek Hunter's blog presents and idea of how to capture the team's decision making. Nice idea, but what struck me is the statement

If the team is not empowered, they are not an Agile team.

Empowered to do what? I don't hear the answer to that question very often.

Where is the discussion of Governance is spending other people's money.

From hands on experience with eXtreme Programing in an enterprise development environment, our success came from chartering the XP teams with the needed capabilities from their work. They agreed to the charter, they could n't change the needed capabilities - these were enterprise needs - but they could organize in any way they needed, work any process they wanted (as long as it did not violate the business rules), and pretty much do what they needed to do with the governance bounds.

So where is additional qualification of empowering the team within the governance framework?

If you're spending your own money, no one cares. But what if you're spending someone elses?

Agile Project Management

Kelly's Contemplation has a nice post on The 3 Phases of an Agile Project. He starts the example with receiving a project that has few actual requirements. The notion of a traditional - or better yet conventional - approach to project management starts looking for requirements. The agile approach is presented in a way that is typical of COTS based deployment through progressive development of the capabilities of the tool set tailored to the needs of the client.

Here's where traditional, er., conventional, project management fails to deal with the current approach to complex project, program, and product development.

I our Defense and Space program, there is a critical first step, that is baked into the procurement process.

CAPABILITIES BASED PLANNING

What capabilities does the customer want to posses when this project is over? These capabilities are the prerequisites to defining the requirements. Here's an end-to-end process for developing the capabilities description. This looks very non-agile, but these are the principles, put these into practice in a way that best suites your need. But check to see if you've covered off all the steps, because is something is missing, you may think you're being agile, but in fact you're missing a critical piece of data.

The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?”

Capabilities statement can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer.

The “meaningful to the customer” unit of measures are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission.

The process flow above is the starting point for Identifying the Needed Capabilities and determining their priorities.

Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that fulfilled by the program.

In order to fulfill these capabilities, requirements need to be met. But we need the capabilities first. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means.

The concept of CBP recognizes the interdependence of systems, strategy organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments. CBP relies on scenarios to provide the context to measure the level of capability.

Here are the details of how to capture the capabilties needed by the customer. Again do these any the way the best suites your need. But do check that you've got - or are going to get - all the information. Otherwise you get to do the work twice.

Notice that most everything talked about in the post is here, plus some other stuff. Trade offs between capabilities is critical. Assessing the costs and the risks. It doesn't do anny good to charge ahead with everything the customer wants to do if you have no idea of the REAL costs and the REAL risk that is being created by your agile approach.

But defined capabilities through Use Cases and Scenarios is the standard approach in large defense and space programs. There is even a language for doing that - SysML is a systems engineering modeling language for Use Cases and Scenarios. I know that doesn't sound very agile, but on a multi-billion weapons systems (mostly software these days) scenarios are the starting point for identifying the actual requirements.

This is the core concept missing from the PMI approach, the dreaded waterfall approach, the conventional approach. And of course these approaches are no longer allowed in the procurement of system for the Defense and Space industry. Those places procure systems using Capabilities Based Planning.

The picure above is one of 5 processes we use in our Performance Based Management activities in our domain. Next comex the requirements, since we're spending the governments money, they want to know those sorts of things.

 

Has Your Theory Been Battle Tested?

I'm working on proposal for deploying agile in a federal agency. They have a need to integrate Agile on the development of standard business systems. The first steps are to determine what existing software development processes are in place, what processes can be introduced, and what processes are imposed by the Federal Acquisition Regulation on their set of programs.

So now the real issue. This is not an environment where we can experiment with other peoples money, since that money belongs to the United States of America.

By Battle Tested, I mean a method that has survived the engagements of actual battle in developing software in the current paradigm - federal acquisition. There are many proponents of agile out there who have all kinds of suggestions. A classic suggestion is celebrate learning, not success or failure.

In this celebration approach, who pays for those learning processes? The citizens of the United States of America? Probably not. This notion that we get to experiment on other peoples money, is unique in the domain I work. The domain of being the fiduciary of other peoples money.

It's fine if your spending your own money, or you have written permission to experiment with other peoples money. No problem. Do it. Write up the results, so the analysis of how your experiment might be extended to other domains and contexts in those domain.

But there is this really annoying little problem with spending other peoples money and then trying our new ides.

Do you have any evidence what so ever - beyond personal anecdotes - that your idea will actually work in the current situation?

No? Then maybe you should try it out on your own money, do some peer reviews, have someone elses try it out on there money, do some more peer reviews, then get someone to fund the experiment to see if this wonderful idea actually does work outside your own personal experience.

I know is an annoying, very annoying approach. But when we're assigned to help out and the money needed to do that work comes from a sovereign or a board of directors, it's just that we have an obligation to actually improve the situation, not just use that money to celebrate our learnings.

Unless we got paid to learn something, we probably should show up with a solution in hand. A solution that has worked in several, if not many, similar domains and contexts. Annoying I know.

Agile Processes and the US Department of Defense

David Rico provides a very nice overview of how Agile development is done on DoD systems. Click on picture, a name and email required by AFEI for a record of who watched.

Hume's Advice for Theoritical Business Process Advice

Hume has some advice for the proffers of business or process improvement that fail to provide tangible evidence from the field that such adbive actually works in a domain interesting the reader ...

If we take our hand to any volume - of divinity, or school metaphysics, for instance - let us ask: "Does it contain any abstract reasoning concerning quantity  of numbers?" No. "Does it contain any experimental reasoning concerning matter of fact and existence?" No. Commit it to the flames, for it can contain nothing but sophistry and illusion" And "The whole world presents nothing but the idea of a blind nature ... pouring forth from her lap, without discernment or parental care, her maimed and abortive children."

Show Me the Numbers!!

 

The Need for Strategy

The pursuit of operational effectiveness is seductive because it is concrete and actionable. Caught up in the race for operational effectiveness, many managers simply do not understand the need to have a strategy. – Dr. Michael E. Porter – Professor of Business Administration, Harvard Business School

When we hear about a method for improving business or technical processes, it is usually delivered in the form of an operational excellence message. We can improve your process of developing software by applying this method. Or we can can reduce the amount of staff turn over through this method.

These of course are all good initiatives, but in most cases they are not connected to any lasting sustainable outcome. They provide short term fixes. What is missing is the reason why. The why is founded in the strategy of the organization that is hosting the initiative.

The stratgey itself is based on three pillars

Mission

• Why we exist - what's our purpose for being here?
• What we do to deliver value to our stakeholders - how will they recognize that we have delivered the value they are expecting?

Vision

• What we strive to be for our stakeholders - how will they recognize that we have fulfilled their needs?
• What our stakeholders want us to be - can they articulate these needs in some form that we can share the description in units of measure meanigful to both parties?

GQ(I)M

• The implementation framework for turning strategy into execution - the processes, people, and tools needed to actually implement the strategy. That is Execute the Strategy.

This last pillar is almost always missimg. GQ(I)M is a method of identifying the Goal, Questions, the (Indicators), and Measures for the work activities that support the strategy. The measures in the M are the technical performance measures for each of the Key Performance Indicators that demonstrate that the Critical Success Factors for the Goals are being met.

When we hear how one method or another is the next new thing, ask if those proffering that method have themselves answered the GQ(I)M attributes for a process that can be applied in your domain, the context in that domain, and have tangible evidence that their method will produce results that map to the strategy you have for your domain - You do have a Strategy don't you?

And for anyone thinking that strategy and strategy making is not agile think again.

Leaders in an execution culture design strategies that are more road maps than rigid paths enshrined in fat planning books.  That way they can respond quickly. - Larry Bossidy

Agile Requires Discipline, In Fact All Successful Projects Require Discipline

Scott Ambler's current post titled Agile Practices Require Discipline restates the core principles of all successful projects. The framework described by Scott can be found in many other project domains, from heavy construction, to spaceflight, to weapons systems, to process control and even well implemented ERP systems.

The time scale may be different from Scott's typical agile projects for important reasons, not the least of which is the scale of the project itself, the business rhythm of the project, and the technological structure of the project.

Bending metal into spacecraft is not a process that takes hours to days. Building the I-25 corridor in Denver was 4 years, but had nearly identical behaviours around daily meetings, teams of collaborators. Same for my beloved Rocky Flats (see Making the Impossible Possible) where for the last year had the Plan of the Day for a multi-billion $ D&D program.

From Scott's nice list around the development of software, there are other domains and contexts in those domains - many times software - where these processes are not only common, they are baked (mandated) into the work process.

These are found in defense, space, nuclear power, process control systems, navigation, command and control of remote machines, intelligence systems - also heavy software - or pretty much any product or system considered mission critical.

• Hold short, focused, and to the point daily coordination meetings rather than infrequent and time consuming status meetings.

 In the ANSI-748-B culture weekly EV is common. This means there is a review meeting every Tuesday (or your favorite daya). And a status meeting some days prior. These are Tuesday the prior Thursday in our case. The review meeting walks through the tangible evidence of progress to plan. The evidence is the physical percent complete of the planned activities. This means working products, completed documentation, installed materials, and the like.

It's always "show me" the results of the work from the preivious efforts. No discussion of "I'm working hard." Only tangible evidence of progress.

During the meeting there is a discussion of "coming due," or "coming start" for all the planned work. Then the project members share their commitments to fulfilling these starts and completes.

• Commit to delivering a set of work items each iteration rather than letting deadlines slip.

 The is an Integrated Master Schedule that shows what the deliverables are, when they are planned to be delivered. This can be iterative, rolling wave, "drops," or any fine grained incremental deployment. This structure is mandated by the guidance for Earned Value Management through a simple statement - "no work package (or in some cases a work activity" shall cross more than one accounting period." This is the 44 day limit called out in the DCMA training materials.

This answers the question "how long are you willing to wait before you find out you're late?" The answer to this on the current manned spaceflight program is 2 weeks. There is the mandated month-end contract performance report and a mid-month flash for the forecast of the month end performance.

• Remove impediments in a timely fashion rather than procrastinating in pursuing a solution. 

This is he role of program management, risk management, the Control Account Manager (a mini project manager), and the program planning and controls team.

Tim Lister's quote "risk management is how adults manage projects"

• Take the time to write tests before code rather than writing code, It takes discipline to consistently work in a test-first manner instead of leaving testing to some time in the (distant) future. 

&The Integrated Master Plan defines the increasing maturity of the produced product - a flying machine, an ERP system, a space craft, an environmental cleanup. The measures of this maturity are stated in Technical Performance Measures. In order to measure the TPM, you need a test. These are incremental assessing of increasing maturity for all work performed under the IMP/IMS paradigm

• Reflect on the team’s experiences and improve their processes proactively rather than relying on process dictated by project managers or external governance bodies. 

Weekly progress to plan provides tangible evidence of progress. Keeping the program GREEN requires that corrective action be taken when there are variances. This is the source of the retrospectives in the agile work. But it's mandated on a weekly basis in 748-B domains.

• Have a continuously working, integrated, and tested solution rather than waiting to do so when you’re “done” at the end of the life cycle.

The measure of continuous is domain specific. But answering the mail of knowing how long to wait before we find out we're late means you have to determine what the business rhythm. Typically this is monthly and many times twice a month.

• Work together in a common area rather than in comfortable but isolated workspace.

 This is likely domain specific. Virtual environments are common. Video conference, shared resources, and technical interchange meetings where people sit face to face.

• Collaborate constantly with the stakeholders or their representative(s) to ensure that their expectations are met.

Team based projects are mandated in the 748-B world. Share outcomes are defined in the Integrated Master Schedule and the Integrated Master Plan.

• Create and evolve deliverable documentation continuously throughout the project. It takes discipline to accept that there’s more to successfully solution delivery than producing potentially shippable software. 

The job's not done until the paper work is done. Aircraft can't fly without manuals. Software can't be operated without manuals. Test articles can't be shipped to the test facility can't be dome without the installation and test procedures. "Cut and Go" ASICS can't be shipped to the silcon foundry without the net-list and gate descriptions. The FPGA's can't be burned without the Handel-C scripts.

In many domains documents are the deliverables. Interface Control Documents (ICD), Systems Engineering Management Plan (SEMP), Program Management Plan (PMP), all the CDRLs for Preliminary Design Review (PDR) are all "shippable" documents. Documents are the product in many instances and are called at with part numbers.

• Self organize and plan the team’s work amongst themselves rather than relying on a traditional project manager to define, estimate, and assign work. It takes discipline to take responsibility for your own work and to respect the collective decisions of your team.

Self organizing teams is a powerful idea, IF the members of the team can work in the presence of self-organization. This is rarely stated as a condition of self-organizing. Much the agile or agile-like management literature speaks to all the joys of self organizing processes in the absence of the per-conditions for success.

For example, one of our clients is building molecules to drugs. The "team" self organizes around chemistry, biology, analytical, QA and other lab processes. These are Masters and PhD level science folks, and they organize their work around the deliverables. But when we move out to the production facilities, the policies and procedures needed for GMP (Good Manufacturing Practices) from the FDA are lock step procedures needed to produce product. No deviation, no making it better, no touching anything. Self-organizing in that environment is chaos and possibly death.

So when you hear - "self organizing teams are the best," ask in what domain, what context in that domain.

So in the end what Scott is so nicely describing - minus some very small details around the domain of software development - is simply good project management. At  least any project and program I've ever successfully worked.

This type of discussion is similar to those when agile first started. When Scrum and XP were propossed as new and exciting. When in fact the principles and many of the practices are simply good project management. There is lots of BAD project management out there. But does not mean it should be the example of how PM has failed. Just the opposite, BAD project management is just that BAD PROJECT MANAGEMENT - period. Don't do it. Look for examples of good project management. In fact good project management is agile. It has to be. Projects are disruptive events, fraught with changing, emerging processes. It's just part of the domain of a project. If you're not "agile" - in the way a 285lb linebacker can be agile - then your project is going to fail.

Scott shows that the agile paradigm can be directly traced to good project management.

Verifying Recommended Practices - You've Got To Show Me the Data

If we're ever going to move away from the anecdotal style books, we're going to need experiments that show the recommended changes actually work. The material to the left, Code of Best Practice: Experimentation is one place to start.

 

In the beginning of Agile it was all anecdotal. Strong push back came when there were questions about applying those practices outside of personal experience. It is a trait of many disciplines that the early developers have a good idea, but resist attempts to have others assess and verify their ideas. Just try it you'll discover what I discovered. That's good when the project is low risk. But when you're using someone else's money, it's a bit harder to just try it.

Same situation in the business process management domain. Listing all the problems is possibly good, but I doubt many are unfamiliar with all the problems. Listing solutions to those problems in the absence of a domain and a context in that domain, mean the anecdotal information is stuck in the domain and context of the author.

In order to move - credibly move - to another domain, an experiement is needed to show the suggested solution methods will actually work.

This is another aspect of popular books, they are usually missing that experiment in another domain.

Here's my working example

Agile development in the form of Scrum has been around for a long time. It is used in many domains.

There is conjecture that it can be applied to government IT programs. There are conferences about this topic. I've spoken at several and introduced the idea that the Federal Acquisition Regulation (FAR) and the Defense version (DFAR) have much to say about how you manage a program and what methods are used.

The work now is to connect the two ideas - Agile and FAR/DFAR/Earned Value - so both can work in the ways they are supposed to work.

So Back To Business Processes

We've got lots of suggestions on how to un-stick business management. Got any experimental evidence that any of those suggestions actually work? No? Then we're at the same place we were when XP started. You gotta try it before you can say it doesn't work. Not likely when someone else's money is involved.

 

Self Organizing Analogy Only Works when the Domain is Defined

While watching the AFC West playoffs with our beloved Broncos v. New England (they lost bad, were outplayed, and couldn't stop Brady), it dawned on me how defining the domain is critically important to any discussion around a method. This is connected to the popular statement in a well known agile management book...

A football team self-organizes within the boundaries of the playing field and the rules as they are laid down by the football association.

The first thing to recognize in American Football, when watching the game in the family room, is the coaches call the plays. A world class quarter back may decide on the line to change the play with an audible, but the offensive coordinators see the field from the top of the stadium and call plays from the  play book - the strategy for winning the game. The game is NOT self organizing on the field. Maybe the company picnic flag football game.

The coach calls plays from the side line, with the advice from the coordinators - offense and defense.

The is how professional football works. Similar processes take place for Volleyball, pre-planned plays. Baseball not so much, since the play evolves from the pitch, but once the ball, if hit, the processes for getting the out are practiced and practiced and all the palyers know exactly what to do. Same for Volleyball - having played in college.

Don't tell me you're game is on, you do it in practice first - Brady to Gronkowski

The 3^rd TD Brady to Gronkowski, where he was ½ step ahead of the defender and the pass landed in his hands without missing a step. This is not self-organizing on the field. That pass had to have been practiced 500 times. Every step, every shoulder turn, every motion practiced. That's called execution excellence.

Hockey executes rehearsed plays, soccer executes rehearsed plays. Once in awhile there is a broken play, but not often. I don't know of any field sport where the game evolves on the field guided by rules defined by some external body. Even professional cycling has a strategy for every portion of the course. Watch the Tour and the coaches in their cars talking to the riders,reading from the play book for the race, guided by the course and the specific responsese to the action developing in front of them.

I know of no successful complex activity that can succeed through self directed action by the player(s) on the field in the absence of a Plan and a set of practiced Plays needed to execute the Plan. There also must be plans for handling the unexpected once the game is underway.

The next popularized statement is ...

Self-organization is the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning.

This of course violates the laws of physics of any system of interactions in the known universe. Human systems of course appear to operate in this way, but only because human systems are complex in ways not understood by other humans. So if the domain of human systems in the presence of poorly understood interactions had been used, then maybe the statement would have merit.

Here's What Has To Be In A Plan For Success

So let's look first at the processes needed in the presence of human systems to establish a central authority and an external planning process. Both are present in all human systems. The central authority, in our program management domain is usually called The Ground Rules. Having ground rules prevents chaos from breaking out on day one. Re-imposition of the Ground Rules can recover the human system from chaos.

I'm working a program now where chaos reigns, because the Ground Rules for managing the project have been abandoned. And this Blog is about managing projects, so we'll stick with the management of projects domain, even complex projects involving complex human behaviour.

So here some Ground Rules for project success in the presence of possibly chaotic human behaviour, whether we're playing a team sport or building the next manned space flight machine.

1. The team has to know what done looks like, so they can recognize done when it arrives.
2. They have to know how to reach done, usually along multiple paths, since the plan never goes according to plan.
3. The have to have the right resources, skills, experience, capabilities, intent, and capacity to execute the plan.
4. The impediments to success must be recognized, handled, and reduced (retired) within the planned budget and schedule. It's easy to handle risk when you've got more money and time than you planned.
5. And finally to succeed you've got to measure your progress in units that are meaningful to the decision makers. In the Pro-Football paradigm, it's not just the scoreboard (well it is in the end) along the way. There are dozens of metrics used to measure progress toward that win. This is the case in any sport and it is certainly the case for projects using other peoples money.

So the football paradigm popularized in the quote above is not actually how American Football, Soccer, or any other ground rules based team sport works unless it is just jungle ball as we would say about the company picnic volleyball game - which I learned long ago never to participate in.

Changing the World? Let's Hope So

I'm not a big fan of the Let's Change the World school of management. But Jurgen Appelo's efforts at the #STOOS Gathering are of interest to me for several reasons:

• Management processes are my profession
• Change processes are hard, and I'm interested to see if there is success here that I can use
• Jurgen has a unique take on the world and I'm interested to see if he has something I can use

The ideas and suggestions are here

 

Stoos Gathering

View more presentations from Jurgen Appelo

 

I've gathered a few ideas from this that are worth commenting on:

• Page 2: Never doubt a small group ... can change the world - Margret Mead. Good stuff, but those small groups always had an actionable outcome. This is one of the failings of the OWS, no actionable outcomes.
• Bob Marshall (Page 3) hits it again - no actionable outcomes
• Paul Boos (a kindred military aviator) - Page 9 - has good advice. The current military small unit structure is a good example of management principles in action that coudl be used in business
• Erika Anderson - viral processes work. Yes they do, but they work because they are effective for the problem at hand. So what is the problem at hand and who has this problem?
• Page 19 has an important message. We are motivated by autonomy, mastery, and purpose. But to suggest most CEO don't get this has no merit, since most is not defined. The CEO's I know and the very few I've worked with ALL have this drive. One problem is too much generalization is the norm when it comes to these sorts of things - changing the world things.
• Page 20 is Steve Jobs and Apple. There's an example.

Lot's more, but you can read them yourself.

Here's my contribution (that not surprisingly didn't make it)

• Define the problem in units of measure of success outcomes. Meaning I want to achieve this outcome. I need possess this capability and need to make these changes to do so. This is called Capabilities Based Planning.
• Look for working examples of success in firms around the world that have accomplished what you are looking to do. There are plenty of them. A literature search is the first step in any development process. Why do all the work if someone else has do it for you.
• Put those successes in some type of taxonomy that makes sense for your domain.
• Look for principles and practices in that taxonomy that can be put work in your domain.
• Look for research of others that has shown the problem and the solutions, and the reasons for less than expected results.

Making the Impossible Possible is a starting point. Heliotropic Abundance is the basis of the processes used at Ricky Flats (the book and place I worked as a Program Manager).

Positive Organizational Scholarship is an approach that might inform the conversation. Look to places where it is working (what ever it is) and determine if how they got it working can be moved to your domain.