The Regenerate Web

Project Management means different things to different people. From the social and humanistic aspects of managing the people working on and around projects, to the gritty details of a Performance Measurement Baseline, with in integrated cost, schedule, risk, and technical performance measures.

One advantage of working the in Space and Defense business is the social and personality aspects are minimized. Not gone all together, but certainly much less than commercial domains, where egos get in the way many times of getting things done. In A&D "done" is clear and concise - the machine flys away, the product does it's job as defined in the SOW, with measurable outcomes, soldiers are using the product, things like that. Black and White, either it flys or it doesn't fly. Of course it's not that simple, it never is.

But one thing that is different in A&D is the focus on the processes and tools. I'm working a moderate ($300M) Army program through January when we get to the Integrated Baseline Review (IBR). While poking around looking for some ideas for training our customer, I came across PM Lotus's "Setting Baselines in Microsoft Project."

The Baseline is just what it says it is, the "baseline" of the cost, schedule, and technical performance. Now MSFT Project is not the best at managing baselines. In fact it's pretty poor at managing baselines. No change control, no traceability, not much in the way of mandated documentation. But it's popular and most of our programs use MSFT Project.

Drill down into this site, there are some very good articles for those interested in the programmatic aspects of project management. Like Checklists.

I came across (actually Pat Richards alerted me) to an article about how Earned Value is not applicable for Software Development project. This article was in a PMI IS SIG news letter. See Pat's post. You can retrieve the article by following the link on Pat's Blog.

Here's the core of the concept proffered by a PMI Special Interest Group on Information Systems.

It is very difficult to accurately and objectively measure the progress in designing and developing software.

My first response was "really?" The very essence of project management is to apply some measure of progress to plan. Simply showing up and putting in 40 hours a week is a measure of progress to plan for a Level of Effort task like watching the trains pass the crossing. (They used to have a job like that in the old Federal Republic of Germany when I was there in the mid 70's detoxing from a tour in Vietnam).

Also the very essence of Scrum - or most agile development processes - is to produce planned measurable outcomes from the work effort. All agile methods MANDATE the production of working software. How to define what software to "get working" varies by method, but Scrum connects the work efforts with the "requirements" through a Feature and Story list developed by the stakeholder.

Software projects also have the problem of iterative development approaches in which certain activities often must be revisited a number of times before they can even be considered completed.

Yes this is true. This is true of every project on the planet. It's part of life cycle of projects. From the extreme approaches of XP to DoD 5000.02's procurement cycle, incremental and iterative approaches are used.

This is not a "problem," it is a fact. Apply the appropriate method to deal with this.

And then the final stroke is "really bad project management"

Many of the activities in software development projects more difficult to measure accurately and objectively in order to compute the actual earned value of the work accomplishments. It is very difficult to accurately and objectively measure the progress in designing and developing software. Often the project manager must simply accept the developer’s word for how they are progressing rather than use an objective measurement. For example, when is developing a computer program 25% or 50% or 90% complete? We can measure the cost of the developer’s efforts but not the needed corresponding progress toward completion.

Please tell me this is not the approach being blamed for software project failures. Better yet please tell me that Earned Value cannot be applied to software development because of these types of projects.

Earned Value is successfully used in a variety of software domains - Enterprise ERP, defense and space system, which are all software intensive, embedded control systems.

Core Success Critieria for Earned Value and Software Development

• Define the outcomes of the work effort in some tangible way. Physical evidence is best. 100% working code (at least for the planned deliverable) is best of software. Tangible evidence for other things is just that - evidence that work produced the "thing" that was planned to be produced on or near the day (or week or month) it was planned to be produced for something close to the cost that was planned.
• Define the way progress is going to be measured. 0/100% of the work. Either it's do or it's not done. Other measures of progress can be 50/50 (half when you start, half when you show up with completed product), apportioned milestones. But NEVER EVER is progress measured by asking someone "how far along are you  on the software module you are working on?" The answer can NEVER EVER be "well, I've been working real hard and I think I'm making progress, so let's say I'm about half way there with half to go."
• Define the tangible evidence, the date the tangible evidence is expected, and the associated costs.
• With this you've got all you need to do EV on Software Projects. Ignore completely the suggestion in the IS-SIG article, that EV and SW Dev don't mix. It's done every day on billions of dollars of software development.

There are many discussions around what works and what doesn't work in the management of projects. Words like:

• Earned Value can't work for our problem. I've seen it fail, so it can't work.
• Agile is nonsense, it's not right for our domain.
• Requirements must emerge from the development of software, you can't possibly define what the system will do up front.
• I've taught 100's of project managers how to implement PMBOK® so I must be capable of managing real projects, no matter the domain.
• And endless other anecdotal examples of how a person with an opinion generalizes that opinion to the universe of problems.

Here's a suggestion. One that I've observed over the years. Those years having started in the late 70's when managing software development was an engineering role and having landed in the defense system program management world these days with formal probabilistic models of performance for billion $ programs.

Here's my suggestion. There are 5 IMMUTABLE principles of Project Management. These immutable principles keep coming up every time I hear someone speak about the problems they are having with a concept. The previous post was a trigger to restate these principles.

Five Immutable Principles

If you're going to successfully manage a project you must ask and answer these five questions. If you don't have credible answers for these five questions, do not proceed as a project manager. Stop, get the answers. Insist the stakeholder provide answers. Without credible answers, the project's probability of success is lowered. Possibly lowered to the point of assured failure.

The five immutable principles of project management are:

1. Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now.
2. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan.
3. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable.
4. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.
5. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.

In the absence of credible answers to these principles, you can come up with all kinds of reasons why things (methods, tools, processes) won't work. In fact you can come up with almost any reasons as to why projects fail.

Answering this principles in some credible manner doesn't assure success. But it goes a long way to improving the probability of success.

If you can't afford to mitigate the risk now, be absolutely sure you can afford to resolve the problem later when it happens.

- Introduction to Universal Risk Report, The Risk Management Research and Development Program, INCOSE Risk Management Working Group.

The Design, Development, and Support of High Performance Teams

from The Hunter and the Hunted, James B. Swartz

When you study companies that have bee very successful in the development of teams and compare them to companies that have floundered, you will find that the successful companies share four characteristics:

• Missioning and Contracting
• Structure
• Leadership
• Team Development

Missioning and Contracting

First and foremost the team must have measurable goals that are relevant to the strategy of the business. For example, in Motorola's case the teams were assigned goals such as reducing cycle times, reducing defects, and reducing costs - goals that are a subset of Motorola's overall mission.

There should be a clear understanding of the responsibilities and authority (what the team will do and what they won't do) on the part of management and the team.

Structure

The elements of structure are process, organization, and technology.

• Organization: team members should be located as close together as possible, considering the situation. They should have a clear reporting relationship with the business.
• Process: The team would be provided with training in decision making and problem solving.
• Technology: they should have the best tools available for the job.

Task Leadership

Good team leadership requires a broad range of leadership capabilities, including the ability to both direct and facilitate activities. The most effective leaders focus the team on the mission, while at the same time developing the team's ability to manage itself.

Team Development

Teams do not start as the self-managed level regardless of the experience of the members. Their development can be compared to the processes of parenting. In the early stages both teams and children need structure and direction. As they mature (Hersey and Blanchard define maturity as a combination of willingness and ability, or "will" and "skill"), teams can manage first to be able to assess maturity level. Depending on the maturity of the team, the flexible leader us able to provide direction and coaching in early stages of team development and provide participative and facilitative leadership in the later stages. The effective leader empowers a team in proportion to its maturity.

Motorola has defined development levels that establish the level of empowerment a team should heave as iot graduates through tje stages of development

- Julie Thrope

Nowadays, I make it a practice to call them into consultation on any new work ... I observe that they are more willing to set about a piece of work on which their opinions have been asked and their advice followed. - Columellama, Roma Landlord, 100 A.D.

While not a fan of the "popular speakers," this quote struck close to home...

Success is the result of good judgment; good judgment is a result of experience; experience is often the result of bad judgment. - Tony Robbins

Ranging from posting like "math is too hard," to "let's let the requirements emerge," I always troubled by the lack of attention to the underlying - many times the deep underlying - principles of managing software development projects.

Back in March, Guerrilla Project Management had a wonderful post about the Standish Choas report. But more imporantly are the papers referenced in the post. Rarely and I mean rarely do I encounter commerical IT projects that have discussions around these topics.

Everything important has been said before, by someone who did not discover it.

- Alfred North Whitehead, 1916 address to the British Association for the Advancement of Science

We're working a paper on the integration of Agile software development process and ANSI/EAI-748-B Earned Value Management.

Came across Considerations for Using Agile in DoD Acquisition. Worth a read.

While doing some research for a new engagement on a DoD program, I came across a paper on the Work Breakdown Structure from a PMI Global conference. Applying the Work Breakdown Structure to the Project Lifecycle. The paper provides a good overview of the WBS and its important to project success.

What was curious though was the complete lack of reference to MIL-HNDBK-881-A. This is THE reference for constructing a WBS.

First let's Look at a Bad WBS Example

PMI has a practice guide for building the WBS. Here's a clip from the guide.

This is why most software projects FAIL.

There is no description of what done looks like. Only the work activities - the functional areas of the project. This WBS lays the ground for "confusing effort with results." The is a really BAD example of a WBS for software development.

We see this all the time. It's the concrete and pipe view of a WBS. The Pharma example in the PMI guidance have the same feel. The WBS describes the "functions" and "roles" but never the outcomes or the deliverables, let alone the final Product or Service. Read MIL-HDBK-881A, learn that deliverables that compose the Products are the outcome of project. The structure of the WBS around the deliverables is the Product Breakdown Structure and the Services needed to produce those products. By services, 881 means the manufactuturing services.

Back to our Regularly Scheduled Program

The paper describes how PMBOK® suggests the development of the schedule from the WBS and the WBS Dictionary to Activities and Milestones. No mention of Project Deliverables, although the WBS is a Deliverables Based description fo the project's outcomes. Not just Milestones. Outcomes. Tangible, physical products. We all know the story of the milestone as a rock on the side of the road with the whooshing sound as we pass by.

The paper skips right to the activities and their sequencing. DO NOT do this, you'll create a schedule that describes the "effort" executed by the functional members of the project and not the "outcomes."

The picture belong is the structure that must be in place for the schedule to have any credibility.

This of course is the Integrated Master Plan / Integrated Master Schedule. It speaks about Accomplishments and the Criteria - the exit criteria - for the work performed to produce those Accomplishments. Then assess the maturity of the product - the planned maturity against the actual maturity - at planned points in time. This is the way you can tell if you're "on schedule."

The WBS Describes the Product Structure and the Associated Costs

The WBS is the Product Breakdown and the supporting Processes that produce the Product. Not the project management processes, but the fabrication processes. Machines needed, buildings required etc. But the Product Breakdown Structure is the heart of the Work Breakdown Structure.

Here's what 881 says:

The WBS is defined, developed, and maintained throughout the system life cycle based on disciplined application of the systems engineering process. Other attributes include:

• A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item.
• A WBS displays and defines the product(s) to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product.

Design, Code, Test is NOT a WBS. It's roles and functions. No product description, no project success.

When we speak about the "work activities" for the Work Package in the Schedule, we must speak in a grammar that conveys "done."

This grammar is the language of "systems engineering." PMI fails to adopt this paradigm. This is the source of most program failures. They don't have a grammar and a document that descries DONE. Just the work efforts, the roles performing those work efforts, and a structure showing those work effort. No one knows what DONE looks like from those work efforts.

It's ONLY About Defining What Done Looks Like

Near the end of the paper, the notion of the WBS drives straight into the ditch. The example of construction of a house illustrates where most of the problems come from in projects:

• The WBS is NOT the schedule - the suggestion that the WBS elements and their dependencies are to be represented in the schedule - along with the dependencies - is seriously flawed. At this ppint of the project planning the WBS must be a Product decomposition and a Cost Structure. Not the basis of scheduling.
• The basis of scheduling is the Product Deliverables, and the Work Packages needed to produce those Product Deliverables as shown in the second picture of this post. That picture at the top of the page is NOT the WBS. It is the project architecture that produces the increasing maturity of the products.
• It is the case that the WBS describes the scope of the project. No work should be done that is not in the WBS. This is the "all in" notion. But the sequence in Exhibit is NOT a schedule.

The examples of a House are much to simple for practical use in IT, heavy construction, weapons systems, aircraft or any "system" based project. Move to "system of systems" and the WBS developed in this manner rapidly falls apart and actually creates confusion.

In our work-a-day world, we spend much of our time "undoing" WBS's built in the manner suggested in the paper and the PMI suggestions. Don't have a project where we come to do "triage." Build a credible WBS. Read 881-A to see how. Don't convert the WBS into a schedule, define the Work Packages at the end of the WBS tree and then sequence those Work Packages.

Here are the steps needed to Build a Credible Performance Measuement Baseline. Apply them to you project and use the WBS as intended - as one of many representations of the project.