Herding Cats

Project Failure Modes

Lots of conversations around why projects fail. One of the best lists I've come across is from the UK OGC Best Practices site - with some slight edits for non-governmental domains.

1. Lack of clear links between the project and the organization's key strategic priorities, including agreed measures of success.
2. Lack of clear senior management and business ownership and leadership.
3. Lack of effective engagement with stakeholders.
4. Lack of skills and proven approach to project management and risk management.
5. Too little attention to breaking development and implementation into manageable steps.
6. Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
7. Lack of understanding of, and contact with the suppliers of technology at senior levels in the organization.
8. Lack of effective project team integration between clients, the supplier team and the supply chain

Time Is NOT Money

A great presentation of Time and Money on projects.

It's All About The Deliverables

Paul Ritchie mentions a previous post.
The simple concept is that deliverables is what the customer bought. Whether it is a machine that can fly to the Space Station and return or a piece of software that can do something for the business.
"Done" means the desired deliverable in delivered. If the Plan and the associated schedule don't describe how these deliverables will be delivered, then it's going to be tough finding out if progress is being made.

Evidence Based Scheduling

Pawel Brodzinski points us to Joel Spolsky's entry on Evidence Based Scheduling. I have to chuckle a bit inside. The concept of Integrated Master Plan / Integrated Master Schedule, our own Deliverables Based Planning(sm), and the guidance found in US Department of Defense, US Department of Energy, and some other federal and state project management guidebooks mandate measures of Physical Percent Complete at the Work Package level. These measures must be connected to the Technical Performance Measures and describe the tangible evidence that progress is being made against the plan.
    This means that the plan must say several things:

• What level of technical performance should the product or service be at at this point in the schedule? Preliminary means we have a pretty good idea about what it should look like, but still have work to do. Final means we're done. Attributes like that. In the IMP/IMS world the verbs are restricted to a specific set, so everyone knows what we mean when we say Preliminary.
• What is the evidence that we're at some level of maturity? This evidence has to be tangible, visible, and confirmed in units of measure meaningful to the customer.  

What is great about Joel's post is the principles of "Evidence Based Planning" are in full use inside Federal Government Agencies - DoD and DOE are my direct experiences.
    So from one of the thought leaders in software development (Joel) comes confirmation that what we've been doing for the past decade is beginning to be put to use outside our programs.

Schedule Work Packages First, Not Tasks

Many authors describe how to build a good schedule. Their advice is all over the web. But they are startin on the wrong end of the problem.

• Start with a Plan, a strategy for successfully completing the project
• Define the deliverables of the project and the Work Packages that produce them
• Define the end to end duration of the Work Packages through some kind of Kaizen process where the team responsible for the Work Package comes up with the work contained in the Work Package and the end to end duration for that Work Package. This is a first cut estimate and not the final baselined schedule.
• Sequence the Work Packages in the order of increasing maturity for the deliverables. This means put the deliverables in an order that allows the project to proceed along a path of "increasing maturity" of the business value. This is classic agile process
• Revisit the durations and activities within the Work Packages to get all the work to fit within the "time box" of the expected outcome for the customer. If it doesn't fit you either have to get more time, more resources, or less deliverables

By the way a Deliverable is not a feature. A deliverable is a chunk of capability.

Process the top 10% of our supply chain in the new system is a Capability
The deliverables needed to enable this capability will likely include:

• A supplier management system
• An accounts payable components for those suppliers
• Some kind of inventory control system
• Some kind of work flow for the supply chain progression

Each of these deliverables may have some or more Work Packages

Only then start to detail out the schedule for the work inside the Work Packages. But try as much as possible to connect the Work Package "nose to tail," Finish to Start (FS) so that fully complete deliverables are used as input to the next work package. If you fail to do this, you'll be building down stream work on partially complete upstream product. This is call "rework."
    Finding the sweet spot for how big a Work Package shoud be and how to put them in the right order requires some experince and some experimenting. One of the strenghts of agile is the notion of time boxing the delivery durations (the itertaions). This is possible ONLY if there are in fact "time boxable" deliverables.
    In the end, never ever start with the schedule until you have a good idea of the deliverables and how they are going to appear as the passgae time.

Software Estimating

Pawel commented on the previous post about the difficulties in making estimates of duration and cost of software. From an introduction to a seminar conducted by the 309th SMXG in Ogden Utah.

One of the most dominant and serious complaints arising from the "software crisis" is the inability to estimate with acceptable accuracy the cost, resources, and schedule required for a software development. Traditional intuitive estimation methods have consistently produced optimistic results which contribute to the too familiar cost overrun and schedule slippage.

One of the biggest problems in the this area - in my opinion - is the naive approach to the discussion of the problem. It goes like this

• The software team comes up with a credible estimate of duration and cost. The proposed values are unacceptable to the stakeholder. No good reason other than they themselves have done a poor job of estimating. The conversion ends, because the software staff does have sufficient clout to stand up to management. No models, no past performance, no measurable data.
• When work starts and then overruns - for what ever good or bad reason - there is little understanding of how to use that information to re-forecast the future.

One of the powerful concepts in Agile is to time box the work and perform work essentially as a "level of effort" task. This is the basis of the notion of Velocity.
    By the way

What good is velocity of we don't know the distance?

Our 18 y/o son is training for his first serious triathlon in the spring. As a moderately serious road rider, he has ridden with our over-50 group many times. The triathlon has a road bike section of 36 miles. "No bad Dad, it it's that long and goes over relatively flat roads - for Colorado." "yea" I say in my best Fatherly voice. "Depends how fast you ride that 36 miles." The Tour of California had prologue yesterday of in individual time trial of a measly 2.5 miles. Very short distance over flat streets. But of you ride that 2.5 miles at 36MPH to get under 4:30 to be in the top 10 - that's called "motoring" in cycling slang.
    So knowing the distance - how much work is contained in the end-to-end project, is mandatory to have velocity be of any use.

Is Software Development Management Project Management?

Cory made a comment on one post back that agile (software development) is more than project management. I took that to mean that the process areas of Agile Software Envelopment are a super set of the Process Areas of Project Management.
    While I understand the agile proponents may hold this opinion, it may be useful to look at the Process Areas in CMMI - as an example - to see where developing products fits in.
    The table below is the Process Areas for the Five Levels of CMMI-DEV

Notice that the Engineering Groups contains the activities usually associated with the writing of code. Code that is guided by requirements, tested and verified in some way, and then integrated into a product.
    The other three Process Groups are also found on projects.

If I'm Doing Project Management Right am I Agile?

This is the crux of the "argument without end," about the role of project management in modern software development. The first question is:

If the project is managed in a credible manner, using current "best practices," is the agile manifesto being fulfilled?

Let's look at each part of the Manifesto in a context and domain beyond 4 developers in the same room with there customer:

1. Individual and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following the plan

Make Speed Not Haste

"Make Speed Not Haste" is a common phrase. Over a morning coffee this week I had a conversation around the agile notion of "early delivery." I'm always troubled by this statement in the absence of any context or business. Looking out the window of the Starbucks, a commercial building was going up. Material was piled in the dirt for use in the construction. Cement trucks were lined up on the street ready for the morning pour. Structural steel was being prepared on another section of the site.
    I posed the question to our small group, "What would happen is those materials or concrete pours were done ahead of time?" Would it be good to be ahead of schedule for the construction of the building? What if instead the building was on time and on budget?
    For the commercial building having it ready ahead of time might be undesirable:

• The construction loan would be over when the certificate of occupancy is done, and the building owner would need revenue from tenets
• For the structural steel to be delivered early might mean it would rust in the snow (Colorado gets lots of snow in the winter).

How can this notion of "being early" transfer to software projects?

• If we complete a software subsystem - say claims migration - ahead of schedule, what happens to the staff working on the development? Can they be reassigned? We'll save money for sure, but at what downstream cost?
• If we have the server farm stood up early, does the warranty start on the equipment? Do we need a staff to support the operations early? Could we start the backfile conversation from the legacy system to the new system early?
• If we release the data entry system early, is the staff ready to go to training?

Software doesn't have the same aging properties are structural steel, but there are aging properties all the same.

• If we release the GPS interface controls software (firmware) to the FPGA fab house early, can they actually start burning silicon? 
• Is the interface to the downstream controlled for the navigation system firm enough to start burning ASIC's from the FPGA's?
• Is the test harness ready in the remote assembly location for the interface cards to be tested, or will they sit in their boxes waiting for something else to happen.

Instead if seeking to be early how about seeking to On Time. The planned need time. The date that the plan shows we need this item? Just having that date is not sufficient of course. The date needs to have cost and schedule margin. How much, that needs to thought through as well.
    Having worked on large complex projects with software, firmware, hardware and humans all interacting a critical question is always asked:

If we show up early can all the other elements of the project to the right of this date, be shifted to the left?

If not, it's a waste of effort to show up early. And there is likely a downside to doing so.

Dumb Project Management Questions

Hal Macomber posted a nice reference on "asking dumb questions" and presented "dumb" questions for project managers. Asking the questions is a good start, producing answers is better. The question's in Hal's post seem to be questions of a project that hasn't thought through much of the planning process. By a "Plan" I mean a "Strategy for the Successful Completion of the Project." Hal speaks many times about "show piping," and other issues with measures of project in construction. This is a symptom of a poorly formulated Plan. Why would a subcontractor be allowed to perform work out of sequence, work that "shows" progress when in fact there is no real progress, or "cook the books," on Earned Value to meet a progress payment?

Here in the Defense and Space business, which include major construction projects - and as well includes federal projects not defense related – the measures of physical percent complete are predefined in the Integrated Master Plan and are placed "on contract." Independent assessment of progress to plan are performed monthly and a full top to bottom review performed 90 after award (Integrated Baseline Review) and periodically during the program's execution.

Having spent enough time watching poorly managed IT projects and listening to all the remedies for these essentially "bad management" processes, I've concluded there is no real hope until management comes to understand that there are principles of project management independent from the practices. These practices can be conventional, agile, lean, or possible even magical. For projects in our domain these principles are:

1. Capabilities drive requirements
2. Requirements are fulfilled by work packages
3. Work packages define the deliverables
4. The Performance Measurement Baseline describes the sequence of work
5. Measures of Physical Percent Complete for each Work Package are the only assessment of progress
6. Work is performed in the authorized sequence
7. Earned Value defines the progress measures
8. Technical Performance Measurement adjusts the Earned Value forecast
9. Past Performance is used to forecast future performance

 

If a project management method cannot be connected to these principles in some way, any way, then the result is usually disappointing.

Learnings from Risk Management training

Working on some proposal language and came across a PMI Risk SIG May, 2005, Tim Lister found several critical concepts:

1. The biggest risk an organization faces is lost opportunity, the failure to choose the right projects.
2. The real reason we need to do risk management is not so much to survive the risks, but to enable risk taking.
3. The only reason to quantify cost (schedule and budget) is to have something to compare the quantification of the benefits against.
4. There is no sense making cost quantification more accurate (precise) than the value quantification.
5. An aggressive delivery date is often driven by cost containment, not by the actual delivery date.