Herding Cats

Connecting Agile Teams with the Business Strategy

   There is an unwritten notion in agile development that project management and management in general is an unwelcome member of the agile team. This is course cannot actually work in a real business. The "demand management" processes for IT services - adds, changes, deletes of functionality that drive these agile team must start and end with the most senior management member who is accountable for the business benefit of the IT solution. Not the development teams.

Connecting Business Value with IT development

   Why is this business connection with agile the case? First, business leadership must be the source of work authorization. Those authorizing work - be it a simple change or the development of a new system should be either Directors, or Vice Presidents in the business unit.They need to have some "skin in the game." Usually this comes from business performance measures and the performance rewards that result. The lower on the management hierarchy, greater the gap between business alignment and IT development.

   This authorization responsibility should not delegated. Especially down to the agile team itself. It creates gap into value generation process resulting from IT systems and trivializes the work efforts. And it violates the fundamentals of IT governance. It;s just an all around bad idea.

   So how can development teams be "self managed," "self organized," or "self guided" in the absence of senior business management? How can these teams implement the business strategy in the absence of project, program, portfolio management? Project, Program, and Portfolio management with business leadership at the helm?

The answer? They can't.

   The connection between business strategy and the implementation of this strategy at the software development level requires management. Management of the sources of value generation. This is not self-management. It is plain olde management. Good management for sure. But management all the same.

   The best management method I've seen is to have the C-suite agree to a management process driven by a strategy. This means having the Program Management Office lead a cross organizational elements  with financial and operational leadership on the team.

   All IT activities should be considered business management activities. These may be "teaming" activities, but they are not self-managed software development activities.

Impediments to Successful Earned Value Management

There is so much blather about Earned Value, I've run out of energy trying to provide corrections and switched to have other people do my work for me.

Here's a nice paper that surveys many of the reasons EV fails to fulfill it's promise.

Earned Value Analysis - Why It Doesn't Work

The answers have nothing to do with Earned Value and everything to do with the competencies of the project, business, and technical management of the project or program.

The organization sponsoring the conference this paper is from has a nice library is important topics in cost, schedule,  risk, and earned value management. Worth a read and a shortcut for reference.

Software Engineering is Dead?

Tom DeMarco has an opinion piece in IEEE Software titled, Software Engineering: An Idea Whose Time Has Come and Gone? He conjectures that 40 years after the NATO Conference on Software Engineering where software engineering was first proposed, DeMarco wonders if the metrics proposed during that period are still relevant? His answer is No.

But like many over generalized opinions these days, there is no context or domain for this conjecture. He states that his book Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall 1982) makes the suggestion that metrics are good and therefore more metrics would be better. But of course that sounds silly today, as it possibly did in 1982. If metrics are good, more metrics may not be better. This is a fundamental principle of performance management.

Have the right metrics, not just more metrics

And don't over generalize anything about metrics or their use. Yes we all know software development is not the same as physics and metrics are less precise.  But the measures in physics ALWAYS and I mean ALWAYS have error bars attached. Why on God's Green Earth, can't the software metrics people get through their heads that:

Any Point Estimate (or measure) without an attached variance is meaningless. 

Another way to say this is - all point estimates are wrong.

DeMarco then goes on the retract his statement in 1982 that control is needed for software. He cites GoogleEarth and Wikipedia. Absent again is a context and domain where control IS applicable. Real time Control, ERP, Enterprise systems, telecommunications systems (billing, call routing, diagnostics) and a myriad of other domains and contexts that are not "web centric." The very photographs GoogleEarth uses images from Digital Globe (7 miles from our home) are captured and processed with a high-ceremony development process to assure all users of their imagery that the software works as specified, arrives at the time promised, and costs what the customer was told it would cost.

Simply a Bad Analogy

DeMarco then goes on to use a bad analogy in a attempt to make his point. He uses child rearing. With two children in college I have some experience in child rearing. "You can't control what you can't measure" is his anti-thesis. Using the example of trying to control Honor, Dignity, Discipline, Personality, Grace, etc...

Steering the child is his suggestion. And a good one.

But as parents of a 19 year old and a 20 year old, we most certainty can "measure" their discipline and behavior.

• Any expulsions from college for cheating on tests?
• Maybe phone calls from campus police for drunken and disorderly behavior?
• Unpaid traffic tickets?
• Over draft notices for debt cards for food plans?

We get lots of feedback measurements everyday on their "performance" in college.

Managing Projects In The Absence of Metrics

DeMarco conjectures you manage projects by "managing the people and controlling the time and money."

"You say to your team leads, I have a finish date in mind, and I'm not even going to share it with you. When I come in one day and tell you the project will end in a week, you have to be ready to package up and deliver what you've got as a the final product."

I's say In the absence of a context and domain this suggestion doesn't make sense.

Really and how would we manage 16 subcontractors on the avionics systems (software intensive, flight, launch control and ground systems) for a manned spaceflight program through ONLY controlling the time and money? The answer - you can't. We need Measure of Performance, Measures of Effectiveness, Earned Value measures, Technical Performance Measures, Reliability, Survivability and every other "illity" you can think of.

There may well be projects that are capable of this type of behavior. I personally don't know any. What it says - in my opinion - is these types of projects a manifestly unimportant. They can be terminated at any time and the customer will take what ever you got at that point + one week's work.

"Your job is to go about the project incrementally"

And what if we have long lead items? Hardware, firmware, procurement and installation of infrastructure? Adding pieces to the whole in order of relative value? What is 100% of the pieces are need to get the first tiny bit of value.

• Part of the pre-launch sequencing controls?
• 50% of the "Everything over IP" secure routing system?
• Part of the order procurement process? Not the part that delivers the order, just the part that takes the order and debts the bank account.
• Maybe only part of the Hell Fire missile control system. The part that IDs the target, but not the part the launches the missile.

Who gets to decide what is the most important parts of the project? Who de-conflicts these decisions?

Software Engineering Definition

DeMarco finishes with the statement:

Consistency and predictability are still desirable, but they haven't ever been the most important things. ... We've tortured ourselves over our inability to finish a software project on time and on budget.

Aw, the olde on-time, on-budget metric. The Standish metric. Remember what I said about any point metric without a variance is meaningless.

• On time - within the planned completion date that includes the schedule margin?
• On budget - with the Budget At Completion including the Management Reserve?

In the absence of a context and domain the last paragraph of the opinion article has no beneficial outcome.

Not all projects have transformational goals. They may have the goal of simply moving bits across the net with secure reliability. Or processing insurance transactions for $0.02 less per transaction.

Read the article. But remember it's missing the context and domain. In today's world over generalization leads to under performance on the benefits side.

Subtle Language

Lynda Bourne has an informative post on the connections between project and program management and change management. In this post there are some words that trigger a response from my experience in IT and government program management

• Output versus Outcome
• Benefits versus capabilities

These are not serious issue in the normal sense, but they have subtle impacts on the discussion of measuring progress.

• There are many outputs from the project. Items that appear from the work effort of the project team. But what are the Outcomes from the Outputs. Did the Outcome provide a capability that was not present before the project was chartered? Are the Outcomes meaningful to the project stakeholders. The production of Output is necessary. But it's the Outcomes that the customer bought.
• Benefits abound on all projects. But with these benefits in place from the project are there any new capabilities that the project sponsors now possess.

The subtlety here is the identify "WHY" we're doing the project as well as "WHAT, HOW, WHEN, WHERE, and WHO."

In the defense business this is called Capabilities Based Planning. When you answer WHY first it becomes much easier to connect the dots with the other 5 elements of the project. Many times IT projects fail to ask and answer why. During the project, when things start to go into the ditch, if we know WHY, we can regroup, pull our selves back together and refocus. The underlying reason for the project is always the touch stone to guide us back.

Milestones are Rocks on the Side of the Road

Craig Brown (one of my favorite Blogs) posted a piece about the use of Milestones. Actually it was a comment from Eugenio regarding measuring small increments.

Here in the defense world we work very hard to NOT have milestones in the way discussed in the post. Are are the reasons:

1. A milestone is essentially a rock on the side of the road stating how far it is to some place, or how far you've come. The Romans had milestones all over Europe and England shows the distance to Rome. But in the end that's all it is - "a distance marker."
2. The milestone itself does not state attributes about the project, just that you've arrived at this milestone. So looking at the schedule you can't tell where you SHOULD be at this point, only that you've arrived at the milestone. It's up to another process to assess where you should be.
3. The milestone is a measure of the passage of time not the state or maturity of the deliverables from the project.

So what do you do?

1. Define a program (project) event that describes the expected maturity of the deliverables at this point in the project. This maturity needs to be predefined. "We'll have the preliminary system architecture defined and approved."
2. Define the Accomplishments needed to reach the predefined state of maturity. "To have the preliminary system architecture, we must have accomplished the following..."
3. Define the Criteria used to assess the completion of the work needed to produce the Accomplishment that reaches the predefine level of maturity

Below is a notional picture of the elements of what is called Integrated Master Plan / Integrated Master Schedule. This paradigm speaks about "increasing maturity" of the deliverables independent of the passage of time or consumption of resources. There is a schedule of course, but the schedule defines the sequence and duration of the work needed to increase the maturity of the deliverables. It is essentially secondary to the measurement of this maturity.

The units of measure of the increasing maturity are always measurable in some physical evidence that can be assessed as "complete."

To see this in MSFT Project, the following is again a notional example. The tasks are connected to the Accomplishment Criteria. These are the "exit" criteria for the Work Package containing the work effort. The Accomplishment Criteria (Criteria) then flow to the Significant Accomplishments which are the "entry" criteria for the maturity assessment Program Event.

The construction of the Event, Accomplishment, Criteria relationship is the Strategy for the successful completion of the project. It is the road map for increasing the maturity of the deliverables. Without this road map to show you where you are going, the only thing left are to look at the milestones along the way. But as well know seeing the milestone on the side of the road doesn't tell us if we're on the right road or if this road takes us to the destination.

The basis for this approach can be found in the Integrated Master Plan Integrated Master Schedule Preparation and Use Guide. While it may appear this document is arcane and used only in defense systems it is the basis of all credible project management processes for one simple reason:

You have to know what DONE looks like before you start on your journey. If not, you're lost before you start and you won't recognize it when you arrive.

For those using agile, DONE is at the end of the iteration for the interim progress. But you still need to know what DONE DONE looks like. And it's now when the money runs out.

Remember Covey's advice - start with the end in mind. That's the key to success in any project.

Anyone working in ERP or enterprise IT should have a look to see how complex software intensive systems are managed in other domains and contexts.

Are You Doing Project Management?

There is a continuous discussion about agile and project management. Some voices in the agile community claim "we don't have project managers on our scrum projects, we don't need them." Instead of engaging in the conversation about the need or not for project managers, let's look at what project management does. These are the 9 areas of project management according to PMBOK(r):

1. Project Initiation
2. Scope Management
3. Time Management
4. Cost Management
5. Quality Management
6. HR Management
7. Communications Management
8. Risk Management
9. Procurement Management

So the first - and actually only - question is

Are these activities found on your agile project in any way - independent of who is doing them?

If they are, you're doing project management. End of Discussion. That's it. That's all there is. You can put a name to the person or persons that do these things. You can call them anything you want. But in the end they are performing the activities attributed to a Project Manger.

Semper Fi Mac

In the beginning was the word, and the word was God. In the beginning was God, and all else was darkness and void, and without form. So God created the heavens and the Earth. He created the sun, and the moon, and the stars, so that light might pierce the darkness. The Earth God divided between the land and sea, and these he filled with many assorted creatures.

And the dark, salty, slimy creatures that inhabited the murky depths of the oceans, God called sailors. And he dressed then accordingly with little trousers that looked like bells at the bottom and with shirts that had cute little flaps. He also gave them long sideburns and shabby beards. God nicknamed the "squids" and banished them to a lifetime at sea, so that normal folks  would not have to associate with them. To further identify these unloved creatures, he called them "petty" and "commodore," instead of titles worthy of red-blooded men.

And the flakey creatures of the land, God called soldiers. And with a twinkle in His eye and a sense of humor that only He could have, God made their trousers too short and the covers too large. He also gave them pockets so they might warm their hands. And to adorn their uniforms, God gave them badges in quantities. And gave them emblems and crests.

On the 5th day, He thought about creating some creatures for which He designated a Greyhound bus driver's uniform.  After more thought he called them flyboys.

On the 7th day, God rested. And on the 8th day, at 0730, God looked down upon the Earth and was not happy.

So he thought about His labors, and in His divine wisdom God created a new creature. And this he called a Marine. And these Marines, who God created in His own image, were to be of the air and the land and of the sea. And these He gave many wonderful uniforms. Some were green, some were blue with red trim. And in the early days, some were tan. He gave them practical fighting uniforms, so they could wage war against the forces of Satan and evil. He gave them service uniforms for their daily work and training, so they might be sharp and ready. And He gave them evening and dress uniforms, so they might promenade with their ladies on Saturday night and impress everyone. He even gave them swords, so that people who were not impressed could be dealt with accordingly.

And at the end of the 8th day, God looked down upon Earth and saw it was good. But God was still not happy. Because in the course of His labors, He had forgotten one thing. He did not give a Marine uniform for Himself. But He thought and finally was satisfied knowing that not everyone can be a Marine.

Semper Fi Mac

Three out of Five our our PP&C staff on defense programs are  Marines, Army aviators, Navy, Coast Guard aviators, or Air Force. There is a special sort of experience needed for PP&C in defense. Team, fidelity, most of all the dedication to the mission. The mission is the purpose for our existence. The successful launch, the successful flight test, the deployment of the system to the end user. In this side of our business, the end user is not called the Customer, he (she) is called the War Fighter.

System Dynamics (SD) and Design Structure Matrix (DSM)

    There is a very clever theory that was developed at MIT and put to use by Lockheed Martin and similar firms. This is the Design Structure Matrix concept.
    The other concept is System Dynamics. System dynamics is an approach to understanding the behavior of complex systems over time. It deals with internal feedback loops and time delays that affect the behavior of the entire system.
    There are some claiming this is the next big thing in project management. But like all great academic ideas there is a big dose of truth, and the bigger dose of "a simple matter of engineering to make it work." Not that there aren't brilliant minds working the problem. Tyson Browning is one. Tyson worked at Lockheed Martin, went to MIT and developed some very useful concepts around DSM and project scheduling.
    The SD folks have many good ideas as well. But there is still much work to be done. Here's why:

• The concepts of feedback and rework in SD are not represented on the current scheduling paradigms. In fact rework is not allowed to be budgeted in the same work package as development. This may seem illogical to the SD folks. But "them's the rules."
• The DSM optimization processes are powerfully useful for small projects. The free tools from the DSM site - done in excel - can handle a dozen or so dependencies. Our typical program has several 1,000 activities. While we work very hard to minimize the dependencies, there are still 100's 

What needs to happen on the DSM side, is to turn the tool Latix into a project planning tool. It is a wonderful system architecture tool. Focused on software development. This is their sweet spot market of course. They could probably care less about us planners here in the field. There seems to be a tool - PlanWeaver - that fits the bill, but they seem to have moved on to other products and don't answer the mail regarding their product. I saw a demo a few years back and it was very interesting. Just what a planner would want.
    The SD folks need to do the same industrial scaling up.
    I've used both tools and the paradigms around them to advantage for "test projects." Which brings me to my favorite Yogi quote

In theory there is no difference between theory and practice. In practice there is - Yogi Berra

So when the academics and the theorist DSM and SD to the practice program planning and controls in the same way Latix did for software development we'll be on to something unique and powerful.
    Take a look at these concepts. They will trigger new thoughts:

• What are the interdependencies between tasks or deliverables?
• How can these dependencies be reduced. In the software world this is called "reducing coupling" and "increasing cohesion." This is a software architecture paradigm, that is directly transferable to "program architecture."
• The feedback loops and dynamics behavior of SD is a useful paradigm for production. But for discrete development projects this is a bit more problematical since the core planning tools don't support loops.

It's worth the effort to look further, if only to broaden your horizon. But challenge the academics for sure - those with PhD's behind their names - with the question

Have you applied these concepts to working programs. Program with 1,000's possibly 10's or 1,000's of activities and did it improve the end result in any measurable way?

    The academic approach is critically important. It is necessary before any engineering processes can be generally deployed. So we might be able to answer the question above in the affirmative in the future, but for now us poor slobs in the trenches are still working the Work Package sequence tonight to move the deliverables to the left. We could use some help to get our program on baseline by Friday COB. ;>)

Work Packages are our Friends

Almost every project Schedule I've seen in the commercial and sometimes in defense are horizontal "shop floor" schedules. This means work flows from left to right, progress is measured by the percent complete bar getting blacker, and the task bars organized by function - design, code, test, deploy.
    This approach to scheduling has several issues:

• There is no way to see how the project's deliverables are maturity
• There is probably no specific statement of what the deliverables are
• The critical path is likely the simple path with zero slack

Here's the first step in move away from this approach and undesirable outcomes.
Build a sequence of the Work Packages that produce outcomes. These outcomes can be final outcomes or intermediate outcomes that are needed to produce the final outcomes.
    The Work Packages produce a 100% completed outcome - even if this outcome is incomplete for the final outcome. It is 100% complete for the Work Package. This approach has the smell of an agile development approach. Except that there is a "plan" for all the Work Packages.
    There are two kinds of Work Packages:

• Ones that are being worked on now - in the current "rolling wave." The notion of a rolling wave is that we can't see that far into the future, so why waste time trying to plan in detail. Instead plan at a level needed to see what work is needed to complete the project. The duration of the active Work Package will be finer than the Planning Packages. Remember these duration are statistical estimates, with a confidence interval.
• Ones that are in the future - the planning packages. Planning Packages still have 100% outcomes. The details of how these outcomes don't need to be very fine. But some sense of the work effort to produce the outcomes needs to be in place for the Planning Package to be credible.

With active Work Packages and Planning Packages in place, they can now be put in a sequence. The sequence will produce a Critical Path, the total labor estimate and of course a description of the outcomes from the project.
    The result is directly beneficial to the project:

• You have a description of what "done" looks like
• You have some sense of the order that work needs to be performed in to get to "done"
• The path to getting to "done done" is made visible
• And most of all the team members - stakeholder, developers, funders - can all see the logical flow of the project through the Work Packages.

No What To Do With The Work Packages
    The content of the Work Package must be developed by the person(s) accountable for delivering the outcome from the work. Notice two things here:

• One single point of accountability for the succcess of the Work Package.
• A single outcome from the Work Package

The Work Package Manager is accountable for the outcome from the Work Package. How the work effort is sequenced, in what order it is performed, who does the work, all the details of the Work Package is managed by the Work Package Manager,
    This moves down the accountability and moves up the planning process. Both winner approaches.

Describing What "Done" Looks Like

    A powerful concept in the management of US Defense and NASA programs is the concept of a maturity assessment review. This is usually missing from commercial IT projects. I've seen it in large construction programs at sophisticated firms. In most cases the absence of this paradigm, means the progress of the project is measured by the passage of time or the consumption of resources. Even when the project is using Earned Value, the values that result from the EV calculation are simply measures of cost and schedule performance, not the increasing maturity of the product or service.
    Here are some sample paragraphs describing the assessment of the maturity that results from the work effort:

• The System Requirements Review (SRR) is a multi-disciplined product and process assessment to ensure that the system under review can proceed into the System Development and Demonstration (SDD) phase, and that all system and performance requirements derived from the Capability Development Document (CDD) are defined, aligned with the external environment (systems and infrastructure), and consistent with cost (program budget), schedule (program schedule), risk, and other system constraints.
• The Preliminary Design Review (PDR) is a multi-disciplined product and process assessment to ensure that the system under review can proceed into detailed design, and can meet the stated performance requirements within cost (program budget), schedule (program schedule), risk, and other system constraints.
• The Critical Design Review (CDR) is a multi-disciplined product and process assessment to ensure that the system under review can proceed into system fabrication, demonstration, and test, and can meet the stated performance requirements within cost (program budget), schedule (program schedule), risk, and other system constraints.
• The Test Readiness Review (TRR) is a multi-disciplined product and process assessment to ensure that the subsystem, system, or systems of systems under review is ready to proceed into formal test.
• The Operational Test Readiness Review (OTRR) is a multi-disciplined product and process assessment to ensure that the system under review can proceed into Operational Test and Evaluation (OT&E) with a high probability the system will successfully complete operational testing. Successful performance during Operational Evaluation (OPEVAL) generally indicates the system being tested is suitable and effective for Fleet introduction. The decision to enter production may be based on this successful determination.

How Does This Work For Commerical Projects?

• SRR - what are the requirements for the system? Not just a list of requirements, but a system description in the form of a System Block Diagram, with nouns and verbs. This could be a sysML description.
• PDR - what does the initial design look like. This can be a process flow in some swimlane notation. Use Cases are considered requirements, but they make a good vehicle for speaking to the system behavior
• CDR - using agile or not what does the system look like when it is "done" in enough detail to have the customer confirm this is what they want in the end.
• TRR - what is the transition to production plan look like?
• OTRR - what is the transition to business plan look like?

The Century Session as Started

    I do have a life outside of Program Planning and Controls!
    Here in Colorado cycling is a very popular summer sport. The Garmin/Slipstream Tour de France team is based in Boulder. In the winter of course skiing and boarding takes over. With the rains gone, the road bikers are finally getting enough miles in to start the century rides.
    Centuries are organized 100 mile rides of 100's to many 1,000's riders in our area. Some times fund raisers, some times sponsored events. Here's our first century of the season:

    We're still early in the ride, so everyone has a smile on. We just climbed from the valley floor up to the top of a Dam. No a long climb, but two 10 degree switchbacks test the legs early in the day. Our son is on the right, me, two riding partners in the middle, and another son to the left.
    The teenagers dropped us with 10 miles to go later in the day. They claimed we were not holding up our end of the bargain of maintaining our "all day" pace of 18 MPH.
    Our son is riding my 1980 steel framed road bike. He actually fits it better than I ever did. No flats, several more killer climbs, a long pull home and we had a great day on the front range.

Over Target Baseline / Over Target Schedule

There is a condition in the DoD contracting business called OTB (Over Target Baseline) and its partner OTS (Over Target Schedule). This is the condition program managers want to avoid like the plague. It is a condition almost every commercial enterprise project lives in.
    I'll go way out on a limb here and say this condition in the commercial world has NOTHING to do with the fact that the project is a software project. 50% to 75% of the content of most aerospace and defense "flying machines" are software. It's not software that is the problem it's management process.
    So let's look at the conditions and processes of OTB/OTS in the context of a commercial enterprise software project.

• Step 1 - agree that the project is in trouble. Once we acknowledge this, some kind of replanning needs to be done. Using the lessons learned up to this point, how would we do it differently? Remember a Gen Colin Powell quote - "bad news is not wine, it doesn't get better with age." Face up to the problems and fix them. Don't pretend it'll get better - it NEVER does. Can't tell you how many times I've heard "we'll make it up in System Test."
• Step 2 - establish some consensus on the remaining scope. What have we produced so far? Is it what we planned to produce? If not, why not? If so, what remains along the road to "done?"
• Step 3- Develop a revised plan - using the information from Step 2, what does the new plan look like? This plan must consider what went wrong in the last plan. The new plan must have a plan not to repeat the mistakes of the past. The primary failure mode I see in commercial IT is "Late starts." There is a fundamental run in projects - "late starts = late finishes." Having work start on time is the foundation of success. But you've got to have a credible plan for starting work. This is another core benefit of Scrum style development. The starts are defined on 4 week boundaries.
• Step 4 - review this plan and gain concurrence of the customer, the stakeholders, the development team, any one and every one involved in the project. Concurrence is not the same as consensus. It must be concurrence. 100% agreement.
• Step 5 - issue guidance to replan the budgets for the remaining work. Eliminate the variances. This"resets" the project baseline. But you have to make sure you reset only the schedule first and not lose the cost variance. It is rare, but possible to reset the cost baseline. But care needs to be taken not to lose visibility into the schedule issues
• Step 6 - revise the detailed schedules (you do have those, right?) and prepare a new Estimate to Complete
• Step 7 - input the new ETC into the Earned Value Management System (you do have one of those, right?)
• Step 8 - review all these changes and plans for the future with the owners of the Work Packages. In defense these folks are called Control Account Managers. In the commercial work - if there is someone accountable for both schedule and budget for each Work Package - they have not formal name. This BTW is one of the core failure modes of project management of enterprise IT - there is rarely the "accountability" in the form seen in government projects.
• Step 9 - Finalize all these variables
• Step 10 - have senior management sign off on the new plan and schedule.

How Can This Approach Be Put To Work In The Commerical Work?
    The first action is to agree that the owners of the Work Packages are ACCOUNTABLE for the performance is the Work Package. In many of the commercial enterprise projects we work on this is a novel concept. The Project Manager is accountable and sometimes that accountability flows down to the responsibility of those doing the work.
    But there is a subtle and critically important concept here. Those doing the work are ACCOUNTABLE. Accountability is not the same as Responsibility. One of the core concept of agile software development is the mutual accountability of the team. This is in fact the definition of a team

A group of individuals who hold each other mutually accountable for a shared outcome

Once you move from responsible to accountable you established the foundation for success. Responsbile means "hey I tried." Accountable means "hey I failed to do what I promised to do." This BTW is the basis of Hal Macomber's promise based management method.
    Now most of the 10 steps cannot be directly applied to commercial projects for several reasons:

1. There is not a culture of accountability
2. There is not a culture of planning in enough depth to determine the plan, the risks, and the measures of progress
3. The unified process of managing the project - from senior management down to the developers - is difficult to impose, except in large organizations.

What Are The Simple Steps?

1. Define work packages as the unit of work
2. Define the duration for these work packages to be short to medium. Answer the question "how long am I willing to wait before I find out we're late?"
3. Connect cost, schedule, and technical performance (project deliverables meeting specification) and speak only in these three variables. This is the basis of Earned Value.

The 3 Elements of Project Management

There are three core components of Project Management. Well at least there are three "simple" components:

1. People
2. Processes
3. Technology

This is a naive view, but useful one for the purposes of this post.
    There are many voices in the project management community. I'll take a risk and put these voices  into the three categories above, for the current discussion.

1. People skills are basically the soft skills of managing projects. All those soft skills session at PMI meetings, books on managing the people. Getting humans to engage with each other in a cooperative process of managing the project, developing the products or services of the project and generally moving the project toward it's end state.
2. The processes are methods for managing a project. Ranging from formal to informal. Along with these processes are other processes of assessing the people who are performing the processes. PMBOK, Prince2, and the like.
3. Technology is the tools of project management.Scheduling, cost, risk, reporting, graphics. generally any software gadget used while managing the project.

Each of these three points of view of project are vigorously discussed (debated).
    But most of these voices start and end their discussion with their pet approach in the absence of a critical set of concepts. Can these or any people, process, or technology approach answer the following?

1. Can we state clearly and concisely what "done" looks like? Can we state the intermediate versions of "done?" Can we state this in some units of measure meaningful to all the stakeholders?
2. Do we know what it will cost to get to "done" or any smaller version of "done" along the way? This cost is usually measured in money. But people and other resources are part of the  answer as well.
3. Do we know the date of when we'll see "done" or any part of "done?" What the variance on this date? If we don't know the date of the final "done," how about a "date for the date?"
4. Do we know we will measure progress along the way? How will we have confidence that progress is actually being made? What are the unit of measure for this progress?
5. Can we see what is going to impede our progress toward "done?" Do we have any way to remove these impediments so we can get to "done?"

No matter what approach is being "pitched," if these questions cannot be answered in some credible way, then the message is not about project management, it's probably about trying to sell you something you may or may not want.

• Training
• Tools
• Certifications
• Books
• A philosophy, an idea, or some other point of view
• A membership in some organization
• A conference
• ...

Use the 5 questions above to weed out those trying to "sell" you something from those whi canactuall give some way to "getting to done." Doesn't mean you'll actually get to "done," but at least you have a chance.

Managing in the Presence of Change

Managing in the presence of change is a core competency of any project manager. The complete myth that traditional project management - read PMBOK - tries to control change, to prevent change, or to avoid change all together is nonsense. No credible project manager or project management processes tries to prevent change.
    The challenge though is to manage in the presence of change. First let's look at a quote from a thought leader in the requirements business:

It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are revised, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are -- Karl Wiegers

Now with this stating point how can we manage in the presence of change?

• Establish a baseline for the project as we know it now? What have we committed to do? Without this knowledge, we can't determine the impact of change.
• Capture change requests through some formal method. In other words, no private change requests. It would fantasy to think a change would not impact cost, schedule, or some behavior of the product or service. So assessing the impact of the change is the first step of managing in the presence of change.
• With the change requests in hand, assess the impact on cost, schedule, and product behavior. Why are we doing this change? Does this change disrupt previous work, so we have rework? Does this change impact future work, so we have to replan? If we don't know the consequence of the requested change, then we can't make a decision about what to do next.
• Assess the change in the context of the larger picture. Will this change make the system less reliable? Less robust? Less attractive to the users? Less anything that we don't want to happen? But most of all will this change disrupt the architectural integrity of the system. This is a critical success factor for every type of system - software, hardware, operational. This integrity is the core attribute for making the system sustainable over it's life.

Now that we have a simple process for managing in presence of change. Next we need a process to deliver these activities:

• The Change Control Board is a simple process. This can be formal or it can be very informal. Formal means forms, meetings, signatures. Informal means face to face agreement of what to do next.
• Capture the approved decision in some way. Make sure everyone impacted by the change knows they are impacted by the change. Have them tell you they know they are impacted by the change.

This is the simplified approach to managing in the presence of change.

Sources of Program Failure

    In large, complex programs program planning and controls comes into play in way not found in small self-contained projects. The large programs include Enterprise IT, usually ERP or similar projects. Large construction projects, with subcontractors. Aerospace and Defense programs of course work in this way - having PP&C activities.
    So when we ask "why is there a large number of failures in enterprise IT?" Looking to failure modes of other large projects may add insight.
    The failure modes of these type of projects has been examined over the years. The following "attributes" have been found:

• Inattention to budgetary responsibilities
• Work authorization not always followed
• Budget and data reconciliation issues
• Lack of an integrated management system
• Baseline fluctuations & frequent replanning
• Current period and retroactive changes Improper use of management reserve
• Earned Value techniques not reflecting actual accomplishments
• Untimely and unrealistic Latest Revised Estimates (LRE)
• Progress not monitored in a regular and consistent manner
• Lack of vertical and horizontal traceability (critical path)
• Not capturing and using cost and schedule data for corrective action
• Lack of predictive variance analysis
• Lack of internal surveillance and controls
• Managerial actions not demonstrated using Earned Value

    As the size of the project grows, the importance of these "attributes" grows as well. If you're working a large enterprise IT project, and exhibit any of the behaviors described above - you probably headed for the ditch and don't know it.

    While each of these looks obvious, there are nuances that alos lead to trouble. I'll speak to those in future posts.

Books

A recent post on Andrew Filev's blog - a great blog BTW - answered the question about Project Management Books. Here's a collection of book recommendations going back to 2005

• 2005 books on or about project management
• Books needed for project and program management (update)
  
• Two must read PM books
  

The ABC's and Actionable Outcomes

At PM Hut there is a post about the ABC's of project management. This article has useful suggestions, but does not state the actions needed to produce the benefits. The ABC's are

• Anticipate
• Build a Good Team
• Communicate

So here's some mechanics for fulfilling the promise of these activities:

Anticipate
    You can't anticipate the future if you can't see to options that the future brings. This means you need a Plan for the future and the identified alternatives that result from that Plan. The Plan for the future must state what "done" looks like, what accomplishments must be delivered to get to "done" and what measurement criteria are to be used for these accomplishments.
    Then the Plan needs to assess four levels of uncertainty:

1. The naturally occurring uncertainty of project work - the day to day variances in the progress efforts. Trying to control these is a waste of time
2. The identifiable uncertainties - "what will get in our way to getting to 'done'?" What is our plan to deal with this impediments? Do we have a planned alternative for these impediments? Can we remove these impediments before they get in out way?
3. The unidentifiable uncertainties - what is the real Plan-B when Plan-A fails?
4. The Unknown / Unknowns - this is usually a re-planning process. So for now it's not an issue.

The Plan needs to be publicly published. This is part of the communication piece below. One of the best ways to communicate the Plan is to construct a Big Visible Chart (BVC) and hang it on the wall in a public location. This is a picture of the project's programmatic architecture. It tells a story of how the project is planned to be completed.
    So in the end anticipation requires:

• A credible plan to getting to "done"
• A credible plan to deal with the emerging impediments to getting to "done"
• A pubic review and periodic update of these plans. The periodicity needs to answer the question "how long are we willing to wait before we find out we're late." Visit and confirm the plan is still working at 1/2 that interval.

Build a Good Team
    No member of the Team should be accepted on the Team without the concurrence of the current team members. each team member needs to "earn" their position on team. This means the project team must understand what roles are needed for success.
    For "good" team members to be identified, they need to interview for their job by demonstrating they can add value to the project.
    The definition of a "team" is commonly stated as:

A group of individuals who hold each other accountable for a share outcome

Start with this vision for building the team. Get this right, then get the technical skills and you've got the beginnings of a real team

Communicate
    Starting with the Big Visible Chart, provide credible measures of progress in units meaningful to the project participants. This means the stakeholder and the contributors.
    Meaningful units means meaningful in terms of progress to plan. It means measuring deliverable not cost and schedule. The customer bought "deliverables." Measure progress in terms of deliverables.
    Speak to the participants in terms of "what have we done for you lately in terms of deliverables."
    Connect these deliverables to the business case or the mission description. That way the customer can recognize that there is a return on the invested money that can recognized in her language.

Fidelity of Earned Value Planning

There is a concept that detailed planning is part of Earned Value Management. Some have described projects with 100's of thousands of tasks - 200,000 in one example. This of course is a fundamentally wrong approach to developing the Performance Measurement Baseline for an Earned Value Management based project.
    Here's why.

• In the MIL-STD-881A and the related Earned Value guidance, the EV measures are taken at Level 3 of the WBS - NOT the detailed tasks. The WBS elements before are still not the tasks, since the WBS contains the Product Breakdown Structure (PBS) and the supporting services needed to produce that product. Words like "design" are never at Level 3 in the WBS.
• These detailed tasks are part of a Work Package. This Work Package is where the EV is collected.These tasks usually fit inside some Work Packages time boundaries. Many Earned Value shops limit the duration of a Work Package to one accounting period, 60 calendar days, 45 work days or something like that. The reason of course is the answer the question "how long are we willing to wait before we find out we're late?"
• The Tasks in the Work Package are used to establish the physical percent complete for the Work Package. Usually the measure is 0% or 100% for each task. Either the task is done or it is not. The 0/100 approach allows you to "roll up" each task in MSFT Project and compute a total percent complete for the Work Package. Or you can do a weighted calculation in MSFT Project or Excel before moving this information to the Cost Accounting system (SAP, Cost View, Safran MPM)
• These Work Packages are sequenced in an order that moves the project forward. The collection of Work Packages in the space and defense business is called the Integrated Master Schedule. This sequence is usually "nose to tail," "finish to start" for the Work Package. The reason here is any downstream work that starts with partially completed predecessor work is called "rework." Try as hard as you can to not have leads and lags between Work Packages. Some US DoD procurements guideline prohibit leads and lags or limit them to 5 days. 5 days is the same as 0 days. Break the Work Packages up to prevent this.

So What Does This Mean in Practice?
    First, the rolling waves are the basis of every credible planning process, whether it is Earned Value based or not. The active rolling wave (the one we're working now) is usually 6 to 9 months for the programs we're on. This is around 20% of the total period of performance. The Planning Packages for the future Rolling Waves have less detail than the current rolling.
    But these Planning Packages need a credibly estimated budgeted cost and duration, so they may be vague on the details, but they describe the total budget of the program

Total Authorized Budget = Current Rolling Wave + Sum(Planning Packages)

As an aside here's the structure of the budget flow, used in US DoD contracting for Earned Value Management:

All of this means:

• Detail plan only the stuff you know enough about. Making detailed plans for work a year from now at the same granularity you are in the currently rolling wave is fantasy.
• Don't waste effort on these Planning Packages until they come closer to starting. have credible estimates for future work, but have this work be simple durations and work effort style planning. Any competent engineer shoudl be able to say with a reasonable percent how much effort it will take to do something. If they honestly don't know, go find someone who does. If there is no one who know, then you're on a science project and need to do some research before anyone will give you budget to proceed.
• Don't waste your time planning the details at the Earned Value. Let the Work Package owner compute the physical percent complete for the Work Package. Don't expose this level of detail to the Earned Value Management processes. For the Planning Packages, use a "peanut butter" spread of the BCWS remaining.
• Always measure progress as physical percent complete at the Work Package level for Earned Value. Anything else for EV is a waste and probably wrong. Physical tangible evidence of progress is required for any credible program management process.
• Stay focused on the Work Package level as the indication of progress. Let the Work Package manager figure out how to get the detailed tasks executed to get to the end of the Work Package.

This by the way is the one-for-one match for agile development. Work Packages = Iteration.

Software Complexity and Program Management

There is a nearly infinite number of software development domains. One domain where there is a variety of applications, ranging from embedded real time control systems, to simple database applications for holding temporary date is "flight software" for spacecraft.
    There is a recent report NASA Study on Flight Software Complexity, Final Report. an interesting quote from the cover page is:

“The demand for complex hardware/software systems has increased more rapidly than the ability to design, implement, test, and maintain them. … It is the integrating potential of software that has allowed designers to contemplate more ambitious systems encompassing a broader and more multidisciplinary scope, and it is the growth in utilization of software components that is largely responsible for the high overall complexity of many system designs.”

This statement is likely applicable for ALL software intensive environments, no matter the business or technical domain. There's a summary presentation at the NASA PM Challenge site Flight Software Complexity. The NASA PM Challenge site is a good source of program and project management knowledge (for the most part).

What's the Point Here?

The point here, is that growth in software complexity is a natural occurrence in many domains. Dealing with this growing complexity is the role of the software development and software project management community.
    While there are many voices claiming to have the solution to the complexity problem, the jury is still out, since only anecdotal evidence is around. For the world of complex system, many of the current approaches to are value tools.

• Iterative development processes
• Test driven development
• Full fidelity simulation and emulation
• Emergent requirements and responses to those requirements

Baseline Magazine IT Project Survey and Requirements

    I'm never a fan of "project surveys" for all the right statistical analysis reasons. But Baseline Magazine has a nice presentation that goes along with a survey from a consulting company.
    The Truths About Project Planning is worth a look.
    The pitch is generally about managing requirements. The best books I've got on requirements are:

• Requirements Engineering , Methodology for Writing High Quality Requirement Specifications and for Evaluating Existing Ones, Software Assurance Technology Center,Linda Rosenberg, NASA Goddard Space Flight Center Greenbelt, MD
• Systems Requirements Practices,Jeffery Grady, McGraw Hill, 1993
• “Good Practices for Developing User Requirements,” Ellen Gottesdiener CrossTalk, 3/08
• The Requirements Engineering Handbook, Ralph R. Young, Artech House

There are many others of course, but these cover a broad set of domains and contexts.

A Bit About Requirements

• Requirements need a reasons for being - they must be connected to some business reason. This connection needs to be traceable back to a statement in the business case. This traceability is usually held in the document called the Concept of Operations.
• Requirements need to be "engineered," in the same way the system architecture is engineered and in the same way the software is engineered. That is someone has to look at the requirements and make sure they make sense. This is called Requirements Engineering and Requirements Management. 
• Requirements need to be verified and validated among themselves and back to the business case or the Concept of Operations. Then need to be traceable to the code, hardware, operational behaviors. This allows the project to answer the question "who ordered this requirement?," and "if I drop this requirement, what else gets dropped?"

    There is no way around these activities. The implementation of the requirements processes varies from 3x5 cards stuck on the wall for your XP project to a TeleLogic DOORS database with 10,000 requirements for a manned spaceflight program.