Herding Cats

Even the Department of Defense Understands Evolutionary Development

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?

Don't Plan for Change - Yea Right

    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.

Project Rhythm

   

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)

Strategy is the plan of action designed to achieve a particular goal. Strategy is different from tactics. Tactics are concerned with the conduct of the work. Strategy is concerned with how different work elements are linked in a chain to produce value for the program.

    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

How Long You Are We Willing to Wait Before We Find Out We Are Late?

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.

The 4 Questions That Must Be Answered

    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.

PM Quote – Victor Hugo

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

Long Live the Gantt Chart

    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 Planning^sm, handbook. Deliverables Based Planning^sm is an end-to-end program management method, applicable to nearly every project or program domain.

Agile Water Project

    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

One day iterations
100% completion at the end of each day
No wasted materials, effort, or motions

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.

Waterfall? What Waterfall?

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.

 

Enterprise IT is not a Science Experiment

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.

Agile Development Versus Traditional Development

Brad Egleland has a post titled Agile Software Development Project vs. Standard Software Development Project where he conjectures there is less cost, lower rework, and the final product is closer to the customers needs. Which may or may not be true. It'd hard to tell without parallel projects. But that's not the point.
    He describes the traditional project activities as:

• Requirements definition
• Development
• Unit/system testing
• User acceptance testing
• Deployment
• Post-deployment support (break/fix & tech support)

Nothing wrong, that's pretty much what happens ON EVERY SOFTWARE DEVELOPMENT PROJECT independent of the development method. Yes I'm shouting.
    It's the granularity of how long each of these is performed. Nothing in the "agile," approach be any different in the end. It's simply not possible. Agile MUST:

• Capture the requirements in some way - use cases, story cards, hand waving at the white board
• You gotta right the code
• You gotta unit test and system test
• The user needs to confirm no matter what
• The system needs to be placed into service
• And of course updates and the like have to take place

    So why is type of comparison still occurring? I don't know.
    I had an long ago picture from Kent Beck that showed the evolution of XP. Starting with the traditional Design > Code > Test > Fix sequence. All linear. Then evolving into multiple shorter cycles of DCTF. Then a two week cycle of DCTF.
    My friend who is the CTO at BoldTech here in Denver has a DAILY DCTF, and on some projects a twice a day DCTF.
    No matter the method the steps Brad shows in the traditional approach MUST be done, in SOME order.
    It's the order, the granularity, and the response at the end of the cycle that seperated agile from traditional. It's NOT agile versus traditional is GOOD project management Versus BAD project management. Everything else is a matter of granularity.

So to take up Brad Challenge - Show Agile is Better

In the agile world you find problems faster. By agile I mean finer granined cycles. Finding problems faster lets you fix them faster. That's obvious. If you have a stable baseline for the next iteration, you can improve the quality as the process proceeds. That's likley meausreably better. Agile is simply good rick retirement planning. The same risk retirement planning we employee on multi-billion manned spaceflight programs. Like build a full scale mock up of the same weight and shape to see if the crew can fit inside. Like taking a short flight in the desert - the Flight Test Article

Agile is a sweet spot software development process. But remember it's just that a software development process, not a complete end-to-end project management method.

Collective Responsibility is No Responsibility

It dawned on me today the primary difference between agile management and actual management.

Collective Responsibility is No Responsibility

On our programs there is a single point of integrative responsibility - The Program Manager. The Program Manager is accountable for getting the program done. For getting the product delivered to the customer. For leading the team to the launch party.
    Of course there are many contributors to the success of the program. But there is only ONE contributor to the failure of the program - The Program Manager. Everyone knows this. Everyone accepts this. Every lives by this rule. Everyone supports the Program Manager. If they don't, they can look for another program to work.
    Why is it we get this confused in the agile IT world. Is there a different work ethic? A different egalitarian motivation is let people "try there hand," to learn by failing. Maybe.
    On the other side how do people "learn" in our world, if they don't fail?

Here's My Tale of How That Happens
    I was a young programmer. OK, not that young, having server a tour in Vietnam between undergrad and grad school. A fresh developer with a graduate degree in physics, who knew how to write a micro-coded version of partial differential equation solvers for digital signal progress algorithms. Finite Impulse Response Filters and Kalman Filters. Things found in particle accelerators - my dream job. But also found in radar signal processors. These filters grab signals from way below the noise and turn them into "targets" that the anti-missile systems to which they were connected shot at.
    Our job was to replace an analog system with a digital system. A simple job. Write a FORTRAN program and some assembly language I/O drivers that is an exact emulation of an analog computer and a bunch of analog filtering parts. This is the easy part. The hard part is to make this program performance the EXACT same function, with the EXACT same response times as the analog computer. No analog computers had been around a long. Our boss had designed and built most of the analog computers on this system and was now a "big wig" manager. We of course being fresh young student thought his bald head was an indication that his had missed the technology revolution of embedded microprocessor based digital signal processing. The AMD 2910 bit slice machine was going to make look really old when our cleaver machine made his analog box go away.
    Trouble with analog systems is their algorithms are embedded in the arrange of circuits. The math description of the system is written in a manual - a document of the process. You documentation of what the system did. And the other problem with analog systems is there cycle time is limited by the speed of light. Plus a bit if delay for the response time to signal level changes. A hell of a lot fast than a 2901 bit slice machine emulating the linear amplifiers, slope inverters, op amps, integrators, differentiators and the other parts that implemented the sets of partial differential equations used to point the radar and process the signals into targets.
    Well after several months of coding and testing we were ready to show off our work. Our boss stood in the corner of a very large warehouse sized room, with the radar antenna in the middle mounted on a hydraulic steering pedestal, maybe two stories high. When we turned on our "digital emulation" of the analog control system, the antenna spun around looking for the signal source and slamed into the spring stops, shaking the build, our teeth, or our bosses hat.
    He leaned against the wall, recovered is engloish dirving hat that he wore everywhere to cover his cue ball head, and simply asked:

You boys know what the hell you're doing?

    Why am I telling this story? Because he was responsible and accountable for the success of our little Internal Research and Development (IRAD) project. No sharred, collective, communal responsbilty. Just Fred (Fred Leary). And is question has never left me. We had on one answer - "I guess not."
    When people talk about collective responsbility of development teams I get an internal smile.
Oh you need to talk to Fred about that, I think to my self.
I'm he's long passed away. Our analog systems engineer, who designed and built F-86D flight controls.
    So when some says "we have a collective responsibity approach to software development," ask your self - "really and who do ask if they know what they doing?"

Project Controls Cost Money ! (V2)

This is true, project controls costs money.
Now ask yourself some simple questions:

• Are you, as the project manager, accountable in any way to steward the customers money, to show up on or near the planned time at or near the planned cost?
• Does your customer need to know when the project will be done and how much it will cost when it is done?
• Does anyone outside your small circle of developers on your team have a concern that the money is being spent in ways that support the business strategy - why are you doing this project?
• Is there someone in your organization that hands out money? If so, might they ask you "what did you do with my money?"

If the answer to any of these is NO, then Project Controls costs money that cannot be recovered by the success of the project. Stop doing project controls, you're wasting money.

But if the answer to these questions is YES, then project controls still cost money, but they MAY increase the Probability of Project Success (PoPS). I say MAY, because we work several programs where PP&C is a massive endeavor and the program is still "challenged."

Having good PP&C is a necessary but not sufficient condition for success. I exactly the same way having a credible software development method is necessary but not sufficient.

Bridge Building and Software Development

    There are vocal proponents that software development is unlike any other engineering process. This may be true, but for different reasons. I was reading a PhD Thesis from Robert Powell at the Stevens Institute of Technology. Powell's thesis is titled A Definition of High-Level Decisions in the Engineering of Systems.
    In the thesis was a brilliant set of statements. From the Standish reports (which of course have statistical confidence interval issues), approximately 85% of IT project fall short of achieving complete success. The problem with Standish of course is "success" is defined as On Budget, On Schedule. It does not take into account the other variables of a project. But that's another topic. I want to get to the bridge building processes.
    In the Standish report the failures are attributed to Human factors as opposed to Technology. In 1986 Alfred Spector, president of TransArc co-authored a paper comparing bridge building with to software development. Spector was the former Director of the Information Technology Center, Carnegie Mellon and is now a VP at Google.

    Bridges are normally built on time, on budget. Software never comes in on time or on budget. Spector found when a bridges falls down (or has technical and business difficulties) it is investigated, and a report is written on the cause of the failure. The resulting information is used to produce or refine the decision or decisions in an attempt to prevent recurrence of similar failures. This report becomes part of an architecture that is used to guide future decisions for successful bridge construction.

    However, in the computer industry failures are covered up, ignored, and or rationalized, which may be due to the absence of procedures for analyzing failures.

    Subsequently, due to he lack of a rational explicit process, the same mistakes continue to occur and negatively impact the success of software development projects. Because of human failings, critical information is lost, decision making becomes difficult, and mistakes are repeated. It is the repetition of mistakes and the occurrence of new ones, because of improper decision making, that result in canceled projects, cost overruns, time overruns, and failure to provide expected features.

A second reference is a US Air Force study stating three common reasons for software system development failure:

• Risks associated with teams - if the team of developers, acquirers, end user, and system maintainers had not worked together before and did not learn to communicate effectively, they were not likely to develop a successful system.
  
• Risk associated with technology - Teams that pursued a new technical approach (for
  example, the first foray into client-server computing) found that the lack of experience
  with a new technology, architecture, or development approach contributed to failure.
  
• Risks associated with requirements - the most often-cited reason for failure
  was poor management of requirements characterized by frequently changing
  requirements, requirements that were not well understood, and requirements proliferation

A KPMG report cites the principal reasons for failure among IT projects as poor project planning.

No project can really get off the ground without a valid plan. The project plan reflects many decisions made during the development process (e.g., compatible tasks, schedule, budgets, defined and acceptable risks, etc.) and a poor plan is simply a reflection of poor decision making.

So in the end it's not about developing the software. It's not about applying one method over another. It's about project planning, good requirements, and having teams that can work together with the technology selected for the project.

When someone says bridges are not software, they're right. Maybe software development should learn from bridge building and stop doing poor engineering processes. With the advent of COTS products as the basis of most Enterprise IT, it's time to stop making software "special."

If the software development business doesn't start behaving like they are building bridges - or other projects that increase the body of knowledge from their failures - no "magic beans" are going to improve the outcomes.

The Basics of Software Project Management

    There's lots of chatter going around in my Google Reader Project Management list about making project management simpler, removing the complexity from project management, ditching the need for project controls, and the like.
    I can't actually formulate a response to these - mainly because I consider this approach ill informed, short sighted, and not focused on the stewardship and governance aspects of writing software for money, or for doing anything for money. Especially other people's money. Especially money they gave you expecting a return on their investment. This is not elitist
    I always fall back on Norm Brown's Project Breathalyzer. I discovered this many years ago and use it when ever someone says, "we don't need all this process. And besides who needs project controls anyway?"
    So when someone makes a statement about "we need or don't need this or that process," take out your Breathalyzer chart and ask if they can answer these questions - with or without their suggested approach.     Maybe they don't need to answer them.    Maybe the answers don't provide value to the project. Maybe they're simply not interested in managing the project from this Point of View. No problem. But now you've established a context and a domain to have a conversation about the activities that take place in a software development project.
    It could be there are another set of Breathalyzer questions. This is an opportunity to development them. Maybe from the POV of "agile project management." But I mean PROJECT Management not software development.

How Long Are You Willing to Wait?

    How long are you willing to wait before you find out you're late, over budget, the thing you're build doesn't work, that the team is unhappy, that the customer is looking for alternatives? Or a myriad of other questions.
    If you ask and answer these question, why in in the world would anyone ever use the term "waterfall" to describe a project management method.

• Because they are professional amateurs
• Because they are incompetent as project managers
• Because they  live on another planet

    For mega projects in the NASA world, the answer is two (2) weeks. You heard me two weeks. Every month there is a contract performance report due. The NASA 533M. At mid-month the "flash" report is due, showing what the program performance will be when we get to the end of the month. To support the "Flash" and the 533M we have to take weekly earned value.
    For that to work we have to have predefined physical percent complete forecasts for all work packages planned to be completed within the reporting period.
    Add to this an Earned Value Management System Description requirement that Work Packages can not cross more than one accounting period and you've got the basis for answering question for a multi-billion $ program.
    Now if NASA can do this, why can't an internal IT project do it?
    The answer is in the mirror. Because the "will" to do it is simply not there.

The Recurring Agile Myth Article

Over at Gantt Head Dr. Andrew Markar has a column titled "Debunking Agile Myths." (You'll need a free account to read this.) Andrew is a frequent commenter here and has contributed to advanced the profession of project management.
    Andrew's article makes some good points, so please sign up and read this and other articles. I'm always troubled though by some items that are missing from discussions like these. So here's my additions to Andrew's good content.

• Agile Myth Number 1: Agile is just an excuse to code with no documentation

    The notion of incorporating the "right" amount of documentation is in the eye of the beholder. Actually its in the eye of the IT Governance Committee. Good IT development processes has the "right amount" of documentation. This "right" amount is rarely defined by those developing the software - the "developers."

    Having been a developer in a former life - embedded control systems for products ranging from refineries to missiles. I personally would do only the bare minimum of documentation. It's the standard approach. But in fact I wasn't writing software for my self, I was writing software for the air force, for Exxon, for Boise Cascade, for the Navy. It was their software in the end, since they were paying for it. They wanted documentation that described the Who, What, When Where, Why and How of the delivered product.

• Agile Myth Number 2: Agile doesn't follow any PMBOK compliant processes

    Agile is a provider of technical solutions. Agile is a engineering process. Take a look at the CMMI-DEV V1.2 process areas to see there are many other activities involved in building software products that writing code. There is process in Agile. Agile is a process. A disciplined process. PMBOK is a description of Process Groups and Knowledge Areas.

    PMBOK is NOT a project management method. In the same way Agile is NOT a project management method. Agile is a software development method. If the software is the one an only outcome of the project, then agile can be substituted for the project management method. But I have never in my life - and it's a long life of software and project management - been on a project where the software was the business outcome. The business outcome is the business outcome.
    The software was the means to achieve that business outcome. Even when the business outcome is to fly to the moon or kill people on purpose, the software is just the means. The project or the program provides the means, the software is just one piece. When you substitute Agile for Project Management you're confusing development with management.

• Agile Myth Number 3: There is no planning in agile

    Planning is in the eye of the beholder, just like documentation. When Andrew says there is more planning in an agile project than in a waterfall project (what ever that means), I'd like to see the waterfall project. It's probably a bad waterfall project. We (our firm) provides program planning and controls staff to a manned spaceflight avionics program. This program is a mix of software, firmware and hardware. The current rolling wave for all this work runs about 30K lines of MSFT Project schedule. For about $500M worth of development. This is a big project. Smaller projects have 5K to 10K lines of activities for $20M to $50M worth of software and hardware development.
    Having a plan means you not only know where you are going, but how long it might take to get there and how much it might cost when you arrive.

• Agile Myth Number 4:Agile Won't Work with Distributed Teams

    Most of the programs we work are distributed. Most are software intensive programs. Coordinating the actions of teams across the continent or across the world has pretty much the same problem. If you can't look someone in the eye then it is a narrow band communication channel.
    Other ways of increasing the bandwidth are needed. Agile addresses some of these, but others are needed. NASA solves this with full fidelity simulation - Simulation Based Acquisition is the official term.

    In the end here's the issue if have with the agile view of the world. In the right hands agile is a wonderful paradigm for developing software. In the right context and the right domain it remains a wonderful paradigm for developing software. But software is a product. The product is NOT the project. The product is the means to the delivering value to the project. The project (or program) may be commercial - process insurance claims. If may be scientific - point the orbiting telescope at a distance galaxy. It may be industrial - process tall skinny pines trees into money (paper) at a rate of $4B per year in southern Louisiana. Or it may be more dark - fly the missile to a target in a distant land and delivery it's cargo.
    But in all cases, the project is larger than the software. While to Scrum folks would have us believe Scrum is a project management method, when you map Scrum to the PMBOK Process Groups and Knowledge Areas you come up with empty cells. When you map Scrum to CMMI-DEV V1.2 Process Areas you come up with more blank cells. When you map Scrum to a DoD 5000.02 Integrated Product and Process Development map you come up with loads of blank cells.

    Agile is a software development method

Putting "project" in the title of an article, a training course or a certification does not make it so.

Customer Requirements Creep

    Returning from a one week holiday, I found the June 8^th Aviation Week had an editorial titled "VH-71: Spending to Save." The cancellation of the presidential helicopter brought everyone out of the wood work. The article's key point was "failure to manage requirements on the part of the government is a key cause of the cancellation." What started out as a $6.8B program grew to a $13B program. The president was quoted as saying "The helicopter I have now seems perfectly adequate."
    Marine One is actually a fleet of VH-3's and VH-60N's. Emphasis on "Fleet" since more than one is needed to move the president. That aside the management of requirements seems to be a common cause of failure in may programs these. Both in and out of government procurement.
    So why is this? Why with all our fancy dancy project management process ranging from PMBOK based methods to extreme programming, can't we manage requirements?
    I'm not a requirements management specialist. Program Controls is my sweet spot. But I can say by observation where the problem is.

If Requirements Management is NOT a profession, You're going to get unpleasant results

Not a profession in many domains that is. Requirements growth is a key contributor to cost overrun as documented in many GAO, NASA, DoD IG reports as well as the commercial IT and construction press.. Managing requirements is a verb.
    But requirements growth in the absence of budget management is the real problem. Budget authority without requirements management controls leads to OTB. OTB is the code word for "you blew the budget." Over Target Baseline. Here's some quick background.
    This problem is common in commerical IT as well. We simply can't control our urges to add features. What we're really saying is we can't manage the project in a professional manner. One that controls the requirements in a way to assures all stakeholder know what they're getting for the money invested.
    How could the government has not known that adding requirements to the VH-71 woudl not have increased it's cost? How could the government not had a "not to exceed" budget - the Total Allocated Budget shown on the Earned Value Management Gold Card?
    Poor management, that's how. Simple as that. Poor Program Management. Rememeber that the next time someone comes with "magic beans" in an attempt to convince you that the profession of managing projects and programs has been replaced. No Magic Bean is going to fix poor management.

Program Success Factors

    At the PMI EVM World 2009 conference, Pat Barker of MCR presented an alternative talk when an opening appeared due to a cancellation. First MCR is one of those firms that is a real life "thought leader." Many what to call themselves "thought leaders." Very few are.
    Pat presented a concept that needs to be repeated. Repeated again and again. Shouted from the roof tops. He'll forgive me I know for restating his thesis here. His talk was titled "Anchoring EVM Analysis in GAO Guide." For anyone serious about Program Management and the cost and schedule aspects of program must own a copy of Cost Assessment Guide: Best Practices for Estimating and Managing Program Costs. There are chapters on Earned Value as well.
    This may sound pedantic, but if you're not familiar with the concepts of managing cost and schedule as an inseparable set of variables, you're probably not an actual project manager. Those who manage project managers - program managers - probably have come to understand this.
    Any way here's Pat's concepts. There are 5 elements of a programmatic control system:

• Cost
• Risk
• EVMS
• Schedule
• Technical

MCR calls this CREST. This is a trademarked and copyrighted for concept.
    Inside the CREST concept there are questions that need to be answered. Like any good method, these questions reveal the maturity of the program controls processes:

1. Is the management system producing reliable information to support decision making?
2. How much progress has been made?
3. Is the schedule reasonable and can I meet my required date?
4. Are cost and schedule trends getting better or worse?
5. Will performance expectations be met?
6. Is Management paying attention ot the performance trends and forecasts?
7. Is the estimate to complete (EAC) reasonable?
8. Can the program effectively identify and handle risks?

    These questions are simialr to the Project Breathalyzer questions and the questions I've mentioned in the past. They're the questions program managers and project managers ask. If you're not asking these question every week or every month at least, then you're not "managing" the project, the project is managing you.

The Reason for Program Performance Measures

    There's always voices on the web and blog sphere saying that the effort for measurement is not paid back.
    Here's two simple questions that need answers for any credible project management paradigm:

1. What is the customer getting for the money being spent?
2. If it was your money, would you spend it in the way you're spending the customers money?

That's it. All other project management processes can be derived from these questions. The Knowledge Areas of PMBOK, the DoD Earned Value Management processes described in ANSI-748B, the DoD IMP/IMS Preparation Guide all provide detailed gory guidance in an attempt to answer these questions.
    Maybe these can be test questions for any proposed PM method or suggestion that old methods need to be replaced by new methods.

Following the PM Method

Ron Rosenhead posted a quote "Strict adherence to the project management methodology is more important than the delivering the project.
    At first I thought - naw that can't be the right way to go. Then a second later I thought, "yes that's exactly what we do."
    One starting point is to close the loop with the concept that "We adhere to the project management method over delivering the project outcomes" This of course depends on the domain and context:

• In FAR (Federal Acquisition Regulation) program, adherence to the PM method is mandated.
• At the enterprise project level for IT, adherence to PM method is usually mandated by the IT Governance policy

Now before all the agilest start foaming at the mouth, this approach is highly domain and context sensitive. Here's why:

• If I have a portfolio of projects in IT or a Program in defense then the underlying programmatic management processes need to be similar in some way to make comparisons of the performance of projects in the portfolio.
• On Defense and Space programs within the same company or possibly in the same business unit, business unit performance measures need to have similar underlying methods - again to have the same units of measure for all project or programs in the business unit.
• If I'm burning my own money (figuratively) then adhering to a consistent method over time is probably not that interesting. If I'm spending the public's money it's a different issue. By public this can mean tax payer - any tax payer - federal, state, local. Or stockholder.
• I'll go out on a limb a say that many of the "method wars" make no mention of the funding sources. They seem to be all about the developer or the individual.

In the end having one PM method works IF there are graded version of the PM method. These means:

• Methods are subsets of the largest set of process areas.
• Brookhaven National Laboratory produced a  Graded Application of Project Management method based on Department of Energy O413.3 and PMBOK that we used at Rocky Flats.
• This graded approach allows tailoring of the PM processes to fit the needs of the project.

In the end the PM method in an enterprise or large project environment should be followed OVER getting the work out the door. Getting the work out the door is necessary but not sufficient for sustainable performance of a project-centric business.