The Regenerate Web

The new DoD 5000.02 (2 Dec 2008) procurement guide has updated the acquisition process from Spiral to Evolutionary. The previous guidance (May 2003) stated:

• Incremental development: end-state is known; requirements met over time in several increments.
• Spiral development: end-state is not known; requirements for increments dependent upon technology maturation and user feedback

The current (5000.02) states:

• Capability delivered in increments, recognizing up front need for future capability improvements
• Each increment:

• Depends on mature technology
• Is useful and supportable operationally
• Successive Technology Development Phases, may be needed to mature technology for multiple increments.

If US DoD can figure this out, why can't Enterprise IT?

    PM Hut once in awhile has a really good post. Working Toward Success: How to Keep the Project Afloat is one of those.
    The BAD project management processes of "not planning," or "dealing with change when it arrives," or "let's let the customer tell us what we should do next and have the project emerge out of their head," is of course nonsense in most project domains.
    If it's your money, your friends are the customers, you're doing the development yourself and all the other aspects of the project work, and you've got no bounds on budget, time, or functionality - then you've got the perfect "emergent" project. Ignore all those project management processes. They're a waste of time and money.
    If however, there is a finite amount of money and you're not getting any more, there is a due date for the project's deliverables and they have to show up on or before that date in some usable form, a customer that would like to know how much this will cost and when you'll be done - then you probably need a plan, a process for handling change, and some way of telling the customer about how you're making progress to this plan.
    You know Project Management type of things.

Bas de Baar on Project Shrink has a guest post titled "What Does a Well Run Project Sound Like?" The idea of a project rhythm is common if not mandated in the aerospace and defense and large construction business. But just participating in the business rhythm meetings is necessary but not sufficient for project success.
    The Business Rhythm Meeting must be guided by a Plan and a Schedule for the work being performed. First comes the Plan. The Plan is a Strategy for the successful completion of the project or program.
    Let's talk about strategy. Wikipedia says (and you should get your own sources, but this one fits our needs)

    The project's strategy is the Plan for doing the work in a way that minimizes risk, maximizes value, conserves resources, and guides the tactics along the path of least resistance to the end.
    In order to execute the strategy we need to Schedule the work activities. When the Strategy and the Schedule are integrated you get the Integrated Master Plan / Integrated Master Schedule (IMP/IMS) paradigm, mandated by US DoD and used to great advantage in the Enterprise IT domain. What this approach tells us is:

1. What does done look like for the entire program?
2. What does done look like for some point in time where we want to put the produced capabilities to work?
3. What does done look like for a periodic assessment - say once a month? How about a Week?
4. What does done like like for each Business Rhythm meeting?

You get the idea. If we don't know what done looks like, we can't really have a meaningful Business Rhythm meeting, so several reasons:

1. When we sit in the room we want to talk about past performance. That's nice. But the real discussion needs to be about the the future performance of the project.
2. Using the past performance, how can we improve the future performance to get to done on-time, on-budget, and with the the capabilities the customer is paying for.

So  what does a well runs project "sound" like:

1. A walk through of the planned deliverables for the past period
2. A discussion of any missed deliverables
3. A statement about how and when these deliverable will "get to green," meaning when will they be delivered and how much extra that will cost. It has to cots more because it is likely we spent the money to NOT deliver them.
4. What are the deliverables for the next period of performance, and do we have everything we need to show up on-time, on-budget, on-spec?

The core concept of the business rhythm paradigm, is:

The Project is Lost One Day at a Time - If we don't know what done looks like we can't have a meaningful conversation of progress

and

The role of the business rhythm is to ask and answer these question at least once a week.

There is no reason to work hard, work harder, have meetings about working hard or harder, if we don't know what DONE looks like.

    There are 4 questions that must be answered during the course of any project. These question are unrelated to the type of project.

1. What capabilities does the project's solution need to provide the buyer to fulfill the mission or the business case?
2. What technical and operational requirements are needed to fulfill these capabilities?
3. What is the plan for implementing the components of these technical and operational requirements?
4. During the development of these components, how can we tell we are making progress to plan?

    No matter what method is used, no matter what the domain or context, if we can't answer these questions at all times, then it is likely the project will be late, over budget, and a disappointment to the buyer.

    We could be building bridges, build spacecraft, building software with your favorite method - agile or traditional. These are the irreducable attributes of a project that need to be "managed" in some way.

He who every morning plans the transaction of the day and follows out that plan, carries a thread that will guide him through the maze of the most busy life.
But where no plan is laid, where the disposal of time is surrendered merely to the chance of incidence, chaos will soon reign.
— Victor Hugo

    There is usually a post somewhere blasting the use of Gantt charts, Mr. Gantt, his philosophy and approach to management. Oh throw in Taylor as well for good measure.

    Many times these rants are for the right reasons, most times not,especially when the ranter is on the outside looking in,rather than doing the actual work of project or program management. But Gantt charts have powerful forms as well. When the Gantt chart is used as a Power Point presentation tool, it's pretty much a waste of everyone's time and effort. It confuses and actual hides the elements of the schedule. But like anything - a fool with a tool, is still a fool. Don't blame the tool, look for the fool.
    But when the Gantt chart is combined with the concept of Integrated Master Plan and Integrated Master Schedule it paints a clear and concise picture of where the project is headed and how we can recognize "done".

Remember to always ask anyone presenting a picture of the project or a tool that claims to help you on the project - "does this picture or tool help me to see what DONE looks like?"

    Here's a picture of a project plan using a Gantt chart that does show what DONE looks like.

The elements of this chart are:

• The Program Event (PE) - which is the maturity assessment point in the project. This is the point where we look at what has happened so far an determine if it meets the planned maturity. By maturity we mean - what technical or operational performance measures "should" have been met at this point in time.
• The Significant Accomplishments (SA) - are those accomplishments that should have been done, or are required to be done, before the planned level of maturity can be reached.
• The Accomplishment Criteria (AC) - are the "exit criteria" for the work performed in the schedule. This work is performed in a Work Package and the AC describes what done looks like for the Work Package.
• Finally there are the tasks - this is the work activities inside the work package

Most poorly defined Gantt's, like poorly formed Work Breakdown Structures,  just list the work to before performed. There is no explicit statement of what DONE looks like, how we are measuring progress toward DONE, or what are the entry and exit criteria is for DONE.
    So when this occurs, you have every reason to say Gantt's are of no use.
    Build an IMP/IMS style plan and you can see what done looks like right there in the MSFT Project schedule.

    Take a look at the DoD IMP/IMS Preparation and Use Guide for the principles of planning and executing projects in this manner.

    The next thing to do with your Gantt chart formatted in this way is to draw it as a PERT Chart using the Critical Tools PERTChart Expert tool. The picture below is an actual IMP/IMS showing the Program Event, the Significant Accomplishments, the Accomplishment Criteria and the Tasks needed to produce the Accomplishment Criteria.     This picture, along with all the other Program Events, hangs on the wall of the program area. The engineers and developers can then "see" the flow of their work, how it moves the project forward in terms of increasing maturity. The numbers of task are in the 100's so they're clipped off the bottom. The PERTChart Expert tool can also sort and plot the plan by the persons name, so I can see what I'm accountable for in this program event.

    This is the Big Visible Chart, the agilest talk about. In fact the BVC, was hanging in the hall of Building 06, TRW, One Space Park, Redondo Beach, in the late 70's when I would walk through the lobby and to my office, where I was writing FORTRAN code for a spacecraft. So like everything else of value - there is nothing new.

    Here's an example of a "real" Integrated Master Plan. Below the Accomplishment Criteria (AC), there are work activities (tasks) needed to make the AC produce it's little piece of "done."

    Notice we always speak in the Integrated Master Plan in past tense verbs - "done." This forces the conversation from effort based words, like "we'll get a short list of review it," (A.03.01) to "we reviewed and short list and now we're done reviewing the short list." This is a powerful notion - to speak about "done" in the past tense. No escaping the description of "done." No confusing effort with the results. We're only interested in results. Done is the result. The semantics of these nouns and verbs goes like this:

    These phrases "focus the mind" on what DONE looks like. How many times have you seen a line in a schedule that says "test." Test what? What is the outcome of the test? Why are we doing this test? To add direct measurable value to any schedule, Gantt chart form or not, use the semantics above to replace "test" with "Final Integration Testing of SharePoint SOA interface with HR Complete.

    By the Way all this formatting in MSFT Project is done with macros, flags, outline level codes.

The Final Summary

Here's the topology of a good project schedule, along with it's plan, that can be laid out in a Gantt Chart, plotted with PERTChart Expert and used to describe what "done" looks like.

This picture is from the Lewis & Fowler Deliverables Based Planningsm, handbook. Deliverables Based Planningsm is an end-to-end program management method, applicable to nearly every project or program domain.

    The road from our neighborhood to the main road (Niwot Road) is getting a new water system. Moving water from a reservoir to the west to the water treatment plant 6 miles to the east. It's a two lane road, no shoulder - bad for bikes - and typical overhanging cottonwood trees, bounded by stables and farms, a golf course or two and the IBM Global Services Plant.
    I drive this route most mornings when I go to the office in Denver. I finally noticed something. The construction company would dig a trench for the water pipe - a 48" diameter blue plastic snap together segment. Place the pipe pieces in the ditch, laid on sand, cover is up, pack down the top soil and cover that dirt with hay.
    That's do a couple 100 yards a day. In the evening all the equipment was back in a storage area in a farmers field. There was evidence of work, but no open ditch, no partially completed work. All the blue pipe stacked neatly ahead of the next days work.
    At the crack of dawn - around 5:15AM here in the mountains, the work began. Around 6:00PM the sweepers where finishing off the final clean up for the day.
    I thought tonight on the way home

Agile water project! If they can do this, why can't IT? Good question.

There are lots of moving parts, supervisors, dump trucks coming and going, road graders, ditch digging machines, pickups with plans and schedules on the hoods in the morning, people in hard hats walking the side of the road with radios in their hands in the late afternoon. Pickup trucks parker everywhere along the side roads, in fields, and the ubigtuous flag-man directing the one-way movement up and down Niwot Road.

No "self organizing teams," no "cow boy developers," not a customer in sight. OK, one Left Hand Water district pick truck parked up the road.

The discussion still abounds comparing Agile Software Development methods with Waterfall. There is absolutely no doubt that some, if not many, IT shops still plan their project in a "Waterfall" style manner.

But my sense is the agilest confuse speaking about the writing of software at the lowest level of the program activities – that task level in the IMS - while using the term "waterfall" at the programmatic management processes of a program.

I also know from daily practice that even in the highest ceremony business of all - US DoD Defense Acquisition - the traditional vision of a "Waterfall" project management method is long ago dead and in the ground.

So why this "red herring" as the basis of discussion? Can't really say. But I can say what is current practice in the domain in which we work.

The current DoD 5000.02 guidance eliminates the term "spiral" (used in 2003) and replaces it with "evolutionary acquisition."

Here's a quick assessment of the new impacts of .02

A Short Survey of the Current DoD 5000.02 Processes

The spiral development process was directed in 2003 through DoD 5000.2 along with incremental.

Another Short Overview of 5000.02

Here's a summary from INCOSE as well:

A Slightly More in Depth of How Programs are procured under DD 5000.02

Especially look at Page 13 of the INCOSE brief

Looking at individual service guidance - NAVAIR for example - the topologies found in waterfall - linear acquisition - were replaced a decade of so ago with incremental, iterative, spirals.

So what's the issue here and why is this conversation important?

1. When we have a discussion about development methods and confuse them with Program Management methods, neither side of the discussion is informed.
2. Confusing software development methods with project management methods, removes a large percentage of the work activities for a project from the conversation and possibly from the project, leaving the project open to risk. Wanna answer why project fail. Look at the real statistics - Poor Planning and Controls. No Requirements Management, No measure of Physical Percent Complete - Agile does shine here.
3. The context and domain of many development methodologies is just that "the development of software" - code. No the management of the program. Round Peg Square Hole.

In the end providing a Value Proposition of Agile has served us better than comparing Agile to some mythical obsolete method no longer allowed in the DoD. Tell me "why" I should use something, not "why" the old way is bad.

I fat fingered a reply to good point Pawel Brodzinski was making on a previous post about change. I deleted his post by mistake while trying to update my response. So here's my response

Enterprise IT is Not a Science Experiment. If we need a discovery phase for some portion of the system, plan and budget that discovery phase. Change at the code and lowest functional level is part of the development process - which is itself a science experiment. Change at the business process level is considered a “non recoverable sunk cost.” I’m speaking and will start to always make it clear – that the undesirable change I mean  is at the business process level.

The absolute problem with frequent changes at the business process level is the customer is wasting money by being lazy and engaging in sloppy thinking. Unless those changes are reviewed approved, warranted, assessed, confirmed, budgeted, ... Otherwise change is simply the churning of money with no return. When we see high - un warranted change - we see poor planning and poor thought process on the project management and business management side of the operation.

Of course "change" happens, but it absolutely must be for the right reason.

Now if it's your own money, who cares. If it's the public's money there's a public accountability issue. If it's the stock holder’s money, there’s a SOX issue.

I know many hold dear to their hearts this notion of "change is good," but as a stock holder in the firm in which someone is churning my paid in value by making changes to the corporate ERP system  to things they should have thought about before you started, I'd be selling short.

Ask ourselves this - what is the reason for the change?

1. Was the business lazy and didn't plan far enough ahead to know that the database architecture doesn’t scale?

2. Was the business bought by another firm and the database architecture doesn't scale?

3. Did the business buy a database engine from a firm that went out of busines?

The Blanket statement "change is good" without a context or domain is not very useful. I will try my best to include context and domain as well.