Herding Cats

Impediments to Success from Organizational Issues

Ron Rosenhead provides a great post about the organizational sources of project failure.

There are of course other sources of organizational failure modes, but Ron's list is a great starting point.

A Process Framework for Increasing the Probability of Project Success

The processes needed to increase the probability of a project's success include:

• The cost estimates for the project and the basis of estimate for those costs. The customer wants to know how much the product or service will cost
• A Work Breakdown Structure describing the products and their components to be delivered and the work process needed to deliver those products
• An Organizational Breakdown Structure describing who is participating in the project
• A Responsibility Assignment Matrix that connects the participants in the project with the deliverables of the project and identifies who is accountable for each deliverable
• An Integrated time-phased plan and master schedule showing the flow of increasing maturity of the deliverables and the sequence of work needed to produce each deliverable to its planned level of maturity
• A Work Authorization and Control Account process to allocate funding, control expenditures, and assure budget control of the project
• A means of accumulating costs from each work activity (Work Package)
• Analysis of the cost, schedule, and technical performance measures of the project
• A set of management actions that use the analysis information
• Baseline Change Control processes to maintain the integrity of all commitments of the project
• Training needed to perform the processes
• Surveillance needed to assure the process are being applied correctly and the expected benefits from these process are being delivered to the project

What form each of these processes takes is project and method dependent. But in the absence of some form of these processes, the probability of success is reduced.

More Matrix Management

Came across an article on Matrix Organization for Large Projects. Some good points here on setting up matrixed projects.

Can Matrix Management Work?

There's one of those unqualified, unsubstantiated, and pretty much curmudgeon quotes floating around. You know the kind. "It didn't work for me so it can't work for you." It usually goes like this…

"I think it is clear that matrix management is not and does not work, leading me to conclude that it is one of the LEADING CAUSES for the rather abysmal "success" rate of projects in most organizations."

Of course, there are no units of measure here. No technical, business, or operational context or domain. No actual evidence or facts, other than personal opinion and anecdotes – a dangerous approach to process improvement.

So let's see if we can get all this anecdotal "theory" about matrix management to somehow come in contact with reality.

In the manned space flight business and nearly every other DoD, NASA, and DOE domain matrix management is the basis of Integrated Product (Project) Teams (IPTs). See O 413.3-18 as an example for the DOE context. NAVAIR and NASA have similar practice guidance.

http://www.directives.doe.gov/pdfs/doe/doetext/neword/413/g4133-18.pdf

So here's how it works. Let's pretend I'm the Propulsion Engineering Lead (yes it is rocket science).

I'm accountable for the design and development of the propulsion systems for our flying machine. This is critical concept - accountability - that is missed in most programs that go into the ditch. First Accountable, then Responsible. See http://herdingcats.typepad.com/my_weblog/2007/02/responsibility_.html for discussion on the RAM.

I report to the Program Manager - single line of responsibility flows down. But it flows down through the Systems Engineering Lead. I take direction from two people. The PM and the SE. They work with me in a matrixed manner since we're on an IPT organization. Now if they tell me conflicting things - say how much thrust is needed to hold orbit at Mars, then I need to convene a meeting to get this sorted out. Why, because I'm ACCOUNTABLE to make the propulsion system work. It doesn't work, the mission fails.

Now, the PM has bigger role than the SE's. So during the meeting, the SE's will make their points, I'll make my point (all supported by technical data, no opinions allowed here) and the PM will take all this information in and we – as a team - will have CONCURRENCE on the outcome. Remember we're an IPT.

Now, in walks the Safety and Mission Assurance (S&MA) Lead, http://www.hq.nasa.gov/office/codeq/ . And she disagrees with our little decision. So who trumps whom? Well in the manned space flight business S&MA has a powerful role. More powerful than the PM, because certifying launch readiness is a S&MA role, not a PM role. We're back to accountability.

All these accountabilities are defined in the Responsibility Assignment Matrix (RAM). The responsibility, accountability, communication, information (RACI) model drives how the IPTs work inside the matrix. In fact the responsibility part of the RACI is never addressed until the Accountability assignments are made, and then it's up to the accountable person to flow down the responsibilities.

So to attempt to get the theory to come in contact with the reality of how matrix management "can" work. Because that's what real PM is about, the realities of projects.

No doubt there are numerous examples of how to make it NOT work. But that's called a "false premise" argument. Just because you've never seen it work, or have some quotes from a couple of dead guys who say it can't work, doesn't mean it's not working every day on 1,000's of programs. It's proof by anecdote. NOT

It's critical here to look around for places matrix management does work and see if what they do is in anyway useful and applicable to your project environment. Maybe it's not. But that doesn't mean it is generally the case that it doesn't work. In fact just the opposite. If it works someplace else, you have an anecdotal working example. Try and figure out how they made it work. If you can't figure it out, or can't put to work what they figured out – we've found the problem – YOU. Learn from others, don't belief everything you read in 50 year old books. Ask deeper questions. Investigate multiple views. Try to determine if a concept or statement is in fact universal, or just an anecdote of failure in a specific domain.

This is a common mistake of inverting the search for improvement. "Doesn't work for me, can't work for you," is a weak approach to trying to increase the probability of program success.

The Real Project Management 2.0

The Project Management 2.0 has yet to state how project's are improved in units of measure of the beneficial outcome. Oh there's some time savings in communications of the project team. Lot's of marketing hype. Hype 2.0 is a popular term applied to most 2.0 initiatives.

• Change is coming
• Improve your team
• Doing more with less

How does any process improvement effort actual show that processes are improved? In the absence of tangible evidence of how a project will be improved any 2.0 effort degrades into buzz words.

Not Buzz Word Words

• "We have increased our probability of success 14% for the SAP roll out by using this PM 2.0 process"
• "The non recoverable sunk costs (waste) have been reduced 17% using this PM 2.0 process"
• "Our capacity for delivering finished software components to integration test has increased 26% in the past 4 months with our new PM 2.0 process"

What's Missing?

What's missing from project's? Project Management 2.0 needs to define in units of measure meaningful to the customer (most PM 2.0 messages are product sales messages) and say how PM 2.0 provides the mechanism to:

• Deliver on or near the planned date
• Keep the project cost on or near the planned cost
• Deliver the technical capabilities needed for the business process to function as needed

PM 2.0 needs to be about Project Management, not just software development

The PM 2.0 solution needs to be actionable beyond buying a product.

PM 2.0 needs to:

• Produce actual improvements in "projects" not just communication between the people on the project
• Be attributable to these improvements
• Be sustainable across the organization
• Be repeatable across projects

Process Improvement Project Check List

Michiko Diby referenced a GAO (Government Accountability Office) report titled Business Process Reengineering Assessment Guide. This report, written in 1997 rings true today for any re-engineering for for that matter any IT enterprise project.

A quick (generic) summary

Assessing the decision to pursue a process improvement project

• Has the business reassessed its mission and strategic goals?
• Has the business identified performance problems and set improvement goals?
• Should the business proceed with process improvements?

Assessing the improved process' development

• Is this project properly managed?
• Has the develop team analyzed the target process and developed credible alternatives?
• Is there a credible business case for proceeding with the process improvement?

Assessing the project implementation and the results

• Is the business following the implementation plan?
• is management addressing all the change management issues?
• Is the new process achieving the desired results?

Notice the focus on planning, assessment, measurement, management. Now use the GAO report (adapted to the current context and domain) as a guide for enterprise process improvement projects.

Black Letter Project Law

Paul Ritchie introduced a new idea – the Black Letter Law. This is the notion that there are basic standards for any practice. The original practice for Black Letter Law was of course Law.

So are there Black Letter Law’s for Project Management? Paul mentions three. Here’s my take on expanding Paul’s great concept.

• Do we know why we’re doing this project?
• Do we know what components make up the deliverables for the project?
• Do we have any idea of how long it will take and how much it will cost for this project?
• Do we have any notion of what problems we will encounter along the way and what we plan to do about these problems before the bite us in the butt?

Now why is this important?

When someone comes along and claims to have something new. Be it PM 2.0, agile PM, some clever tool, or even a new take on a way of actually managing a project instead of trying to sell us something that can be used to manage projects – this is a way to ask some simple questions.

• Does your gadget help us understand better why we’re doing this project?
• Does the thing you're suggesting I use reveal the needed capabilities and business justifications?
• Does it do a better job of managing the requirements around the components of the project? Be they software, hardware, concrete, or steel?
• Can your gadget improve the management of my schedule or cost?
• Does your new approach provide any beneficial the impact to the risks impacting the project?

The answers to these and any other questions must be in units of measure meaningful to the buyer. No fluff. No “we’re the best thing since sliced bread,” no “everyone gives us wonderful reviews and votes us the best gadget in the valley,” no "here's a bunch of people who spent money with us, so you shoudl spend money with us as well."

Nope, the answers to these questions have to describe the unassailable beneficial outcomes. Stated in units of measure meaningful to the buyer. These units of measure should be dollars saved, risks reduced, value increased. Never can they be "we increase value." How much value - tell me the actual amount or at least a relative percentage. "We save you time." How much time?

Don’t hear that message? Move away away folks, nothing to see here.

Leadership Framework

The Deputy Secretary of Defense Gordan England has a simple foundation for how to "make" a leader:

• Treat every person with dignity and respect – nobody is more important than anyone else
• Be forthright, honest and direct with every person and in every circumstance
• Improve effectiveness to gain efficiency
• Cherish your time and the time of others – it is not renewable
• Identify the critical problems that need solution for the organization to succeed
• Describe complex issues and problems simply so every person can understand
• Never stop learning – depth and breadth of knowledge are equally important
• Encourage constructive criticism
• Surround yourself with great people and delegate to them full authority and responsibility
• Make ethical standards more important than legal requirements
• Strive for team-based wins, not individual
• Emphasize capability – not organization
• Incorporate measures and metrics everywhere
• Concentrate on core functions and outsource all other

Ask how these can be applied to project work?

The Eight Step Process

The US DoD has started using an "Eight Step Process" for logistics and other activities. These are (in general terms)

1. Look at the overall picture
2. Determine the work unit accomplishments
3. Determine individual accomplishments that support the work unit goals
4. Convert expected accomplishments into performance elements
5. Determine work unit and individual measures
6. Develop work unit and individual standards
7. Determine how to monitor performance
8. Check the performance plan

The source of these steps is rooted in the OODA Loop (Observe, Orient, Decide, Ac t), which originated in the 1950's by Col. John Boyd. It is an objective description of the decision making process. Due to an emphasis on the infinitely repeating nature of decision making, the OODA Loop is an excellent match for the AFSO21 (Air Force Smart Operations for the 12^st Century) principal of continuous improvement.

In the project management context and domain, the Eight Step Process works like this

1. What is the highest level description of "done" that is not "begin, do all work, done?" This means what are the work steps that result in done at a level that is independent of technology and details. This is the description of the path to increasing maturity for the deliverables.
2. What are the work efforts needed to produce these deliverables?
3. What are the significant accomplishments needed to move the deliverables from one level of maturity to the next?
4. What are the units of measure of these Significant Accomplishments?
5. What are the work packages and their Accomplishment Criteria (exit criteria) ?
6. What are the contents of each Work Package?
7. How would we measure the physical percent complete of each Work Package?
8. What are the measures needed to assess and forecast the future performance?

A Thought on Status Reports

Dmitri Ivanenko has some good things to say about status reports in "Are You Ready for your Next Status Report?"

One critical missing piece in this post the raw materials for the status report come from the plan. You plan the work and work the plan, you have the materials for the status report in your plan. This "plan the work and work the plan," is independent of any product development method. Agile has plans. They're called planning sessions. Agile works the plan, it's called an iteration. DoD has a plan, it's called an Integrated Master Plan / Integrated Master Schedule (IMP/IMS). DoD works the plan, with weekly Work Package assignments and Earned Value reporting. So no credible project can not - not plan the work and work the plan.

But the status report still needs to report status of the planned work:

• Perform no work that is not in the plan (in some way). Then you can report what was accomplished from what was planned to be accomplished. If your doing work that's not in the plan - why? Who asked for it? Who's paying for it?
• If you address risks in the status report that are not in the risk registry, then put them there and report on them.
• If you spent more money or delivered late, you should report against the planned spend and deliverables.

What a status report does is

Report the status of the planned activities. So have a credible plan and report progress against it using Dmitri's guidance.

PM 2.0 - Another View

Pat Weaver provides more insight on the issues of Project Management 2. I had not seen Wikipedia article he references. In it Traditional Project Manage is described as:

• Centralization of control
• Top Down Planning
• Authoritarian environment
• Implied structure
• Limited/Restricted access to the plan
• Local access to information
• Limited communications within the team
• Separate projects
• Overly complex tools
• Rigidity of tools

Wow. I didn't know traditional project management operated in this way! Now of course the number one author in the references list at the bottom of the Wikipedia page is selling a PM 2.0 tool based on this premise.

This list, repeated in other blogs and web sights about PM 1.0 attributes is actually a description of incompetent business management, ignorant personnel management, and malicious use of position. You know businesses that are going out of business.

Pat goes on in his post about the reasonableness of the PM 2.0 content of the Wikipedia article. Pat has restated many of the same points I've made and Quant.M.Leap made. My sense is the authors of the PM 2.0 approach defined in the Wikipedia track have somehow concluded all the world are fools and only they have the answer. Yes, ERP projects fail in many ways at an alarming rate in the press.

Of course these PM 2.0 advocates probably haven't actually managed ERP projects or seen successful ones to know the difference between the attributes of success and failure. Nor is it likely they can know the difference between the Boston Big Dig failure and the successful I-25 corridor here in Denver.

It's actually irrelevant in the end

Thank the stars above, no pubic institution or credible private enterprise is going to buy their message "as is" for a simple reason - governance.

Business and project governance. Governance of course does not assure project success. But governance assures that the nonsensical descriptions provided in the Wikipedia Traditional Project Management attributes do not exist in principle. Governance makes every attempt to also assure they do not exist in practice.

So Here's My Simple Minded Conclusion

PM 2.0 will go the way of the first round of "wanna be" extreme programming advocates. Note I did not use eXterme Programming, because Ron had and still has one of the viable alternatives to the "design, code, test" approach of the past - along with Scrum, Crystal, and DSDM. What the extreme programming advocates - those who read the book, but never did the work - wanted was to eliminate all the prep work needed to get in a position where eXterme Programming could work.

The great thing about approach taken my the misinformed, ill trained and inexperienced extreme advocates was they never got hired by any outside firms to practice their voodoo. Same will happen here.

As pat suggests

Beware zealots bearing gifts

Another Run At PM 2.0 Clarification

Here's another attempt to put some structure into what some authors are calling PM 2.0

I'll start with a simple list of what activities take place during a project. PMI calls these Knowledge Areas. This means knowledge of "what" to do is needed to increase the probability of success of the project.I'm not the biggest fan of PMI, but I am a member and the Knowledge Areas are a good starting point for shared vocabulary.

I've learned that without a shared vocabulary the conversation is hard to have. So here's PMI's simple vocabulary about what happens during a project. These are not product development verbs, they are project management verbs.

With this stating point - it's a starting point, but I can't think of a simpler one for this post - what are the activities performed which managing a project in the Traditional, Agile, and PM 2.0 paradigms.

By activities I mean, what does the project manager and the technical teams do while working the project that is independent of the engineering processes - writing code, welding metal, pouring concrete.

Several colleagues and I have tried to make a run at this. The topic of "what is project management" outside of the PMI paradigm has been talked about before. Here's my rough cut for the traditional processes.

People, Processes, and Technology

People, Process, and Technology is a common management consultant set of "pitches."

I'm here to say it's in that order. And the order steps done in logarithmic. Meaning Processes is e (2.71821) less than  People. And Technology is 2.71821 less than Process.

This put process 7.29 less than the people.

Want to find the way to increase the probability of a project's success - It's not the tools it's the people.

Project Management Principles from the Department of Energy

The US Department of Energy has $1.2B allocated for clean energy initiatives. Our firm is working a program that captures carbon from coal fired power plants and uses it to feed an algae farm that in turn makes a refineable "oil" (lipid) that can be burned in vehicles or turbines.

Along the way, we are building a Project Management Plan. The DOE has some useful guidelines for what makes a credible project plan.

1. Mission need must be defined and approved by the appropriate management official
2. A range of alternatives to meet the mission need must be considered, developed and evaluated
3. Project objectives must be defined upfront and used to judge project success
4. Project performance risks (technical, financial, and otherwise) must be identified and mitigated in an implementation strategy
5. Projects must be managed by qualified individuals
6. Scope, schedule and budget must be established for each project and serve as the basis for project management
7. Projects must be managed and reported against the established scope, schedule and budget

Any project, no matter the domain or context, would be well served when using these principles as a starting point.

Project Failure Sins and How to Stop These Sins

Thanks to Ron Rosenberg for another useful post about the failure modes of projects. The Lecture can be found HERE

1. The Challenge of Scale
2. Middleware or Fiddleware?
3. Method or Madness?
4. Where are we?
5. Software development is still an art
6. Integration, the final frontier
7. Will it really work?
8. Change our greatest Challenge

How To Behave Like a Professional Project Manager

• Have all the facts at hand

• No searching through your notes.
• No making things up
• No trying to convince people your idea is better in the absence of actual field experience and testimony that it is in fact better
• Understand - in depth - the context and domain of any topic of discussion before provided suggested alternatives

• Speak only in actionable outcomes

• What does done look like?
• How will we recognize done when we see it?
• Speak with nouns and verbs about the deliverable and its maturity - "The Preliminary Design of the Transaction Processing System is Complete"

• Speak in units of measure meaningful to the participants

• These units are always time and money
• We'll be done on or before this time with this confidence
• It will cost this much or less with this confidence

• Have tangible evidence of physical progress to plan

• First have a plan that shows when you will have tangible evidence of progress
• This evidence must be a "working" thing that the customer will recognize as something they asked you to build. It can be software, a piece of hardware, or even a document.
• This evidence must be compared against the quality standards agreed to before the work started.
• Again this is one of the "what does done look like" questions

• Use a credible form of measurement for assessing progress to plan

• Earned Value is the best

The Power of Simplicity

• Define the outcomes of a project in units of measure meaningful to the customer

The customer bought a product or service. Actually the customer bought a capability. No if fact the customer should have bought an "effect," a change in the current way of doing business, executing the mission, or some other means of changing from the "now" to the "future."

What does this "effect" look like. What capabilities must be possessed to create this effect. That's what done looks like.

• Define the work needed to produce these outcomes through "deliverables" not "effort"

Plan the work that moves the project forward. This work must produce a product, a service, or some processes that supports the production of a product or service. Anything else is waste.

• Define progress in units of physical percent complete, measured in units of tangible evidence produced on periodic boundaries

Weeks are good, days are really good, never more than a month should pass before tangible physical evidence is examined.

If you're not measuring physical percent complete, your project is Level of Effort - Train Watching. If you're not measuring outcomes and the quality of those outcomes - not output, outcomes - then you're a level of effort project.

• Have a plan

A Plan is a strategy for success. Have this plan before you start the project. Without a plan, you will loose sight of what done looks at the first sign of difficulty.

This is a core concept of Covey - Begin with the end in mind. If you don't know what "done" looks like, you'll never be able to recognize it when it arrives.

• Know what can prevent your success and handle it

If you don't have a risk management plan, your risks will become issues and then it'll be too late to do anything about them

It Is This Simple

• If you don't know what done looks like, you'll never get there. If you don't know where you are going, you might wind up someplace else — Yogi Berra
• If you don't know how much work there is to do, you can't know when you will be done. Velocity (or any measures of progress) is worthless is you don't know the distance to be traveled
• Measure only in units meaningful to the customer. The customer bought a solution, capability, or an effect, not you effort to produce those
• No Plan, no way to measure progress
• Risk Management is How Adults Manage Projects — Tim Lister
  

Probablistic Risk Analysis

PMBOK speaks about quantitative risk analysis in Chapter 11. There are several issues with this section of PMBOK that I'll present below. But first, why is this is interest to me and potentially of interest to others?

• The management of technical and programmatic risk is in the domain of project management.
• The tools and processes suggested in PMBOK and syndicated in many other areas have some serious flaws that are at the root of project difficulties.

Opportunities are NOT Positive Risks

PMBOK states in 11.5.2.1.2 that positive risks are opportunities. Harry Jabagchourian and Robert Cvetko of The Boeing Company, Rocketdyne Propulsion & Power, Canoga Park, California have something to say about this in Risk & Opportunity Management: Program & Project Management Success Factors, Fourth National Symposium on Space System Risk Management. This paper provides a introductory overview to the issues of managing both risk and opportunity.

Here Risk and Opportunity are defined - not as opposites - but as two independent domains that must be managed concurrently.

PERT and Probabilistic Risk Management

Like a previous posting, the use of the PERT formula (a+4B+c)/6 is both naive and likely produces wrong results for any non-trivial network schedule. The primary issues with the PERT formula are:

• It assumes statistical independence of the work activities - this is almost never the case
• It assumes a symmetric probability distribution so the mode of the distribution is almost the "most likely" estimate.

So What's the Way Out?

The current "best practice" in the defense and space domain is a Monte Carlo simulation of the Integrated Master Schedule. But this IMS must start with being credible. This means:

• All work is defined as producing an "outcome" that is tangible
• The "health" of the schedule has to be all green. This means no widows or orphans, no long tasks, no leads or lags. essentially the schedule must have "all green" according to the DCMA (Defense Contract Management Agency) IMP/IMS 14-Point Assessment. 

With a credible schedule, the statistics of the task variances must be build. The classification of risk is the best way to do this. DO NOT ask people what the pessimistic or optimistic values are. There is a large body of research showing this produces a highly biased result. Instead build a matrix of risk ranges and their descriptions.

For example:

• Class A: Been done before - low=-5%, high=+8%
• Class B: Some new development - Low = -10% High = +12%
• Class C: New development - Low = -10% High = +15%
• Class D: New technology - Low = 10% High = +17%
• Class E: New physics - Low = -5% High = +30%

These classification are needed for each major category of development - software, hardware, integration, etc. The use a Monte Carlo tool (Risk+ and @Risk for project are my favorites).

The result is a credible model of the variances and programmatic risk areas for the schedule.Use these to mange the project, engage in conversations about the "hot spots" in the schedule and how you're going to "cool down these hot spots." The simulation is not the solution, it simply points to where solutions are needed.

Check List for Managing a Program

Here's a check list for increasing the probability of success for you project. This list should be considered EXHAUSTIVE in terms of the traditional Program Planning and Controls paradigm. But not universally applicable for the simple reason that all projects are not the same. But in general some form of these activities should be found on any non-trivial project no matter the method used to manage the project or the method used to develop the products that result from the project.

The source of this check list is the San Diego Research Center, who was acquired by Argon ST in 2006.

• A clear, concise statement defining the program has been prepared and reviewed by knowledge parties for consensus.
• Performance objectives that follow written guidelines and contain actual calendar dates for completion.
• A Work Breakdown Structure developed to a level sufficient to prepare accurate estimates of cost, resources and working times for all program activities.
• A Statement of program scope that clearly defines the limits of what will and what will not be done or delivered as a result of the program.
• Specifications that must be met are either identified and the "owners" of these specification concur with the outcomes.
• Tangible deliverables are  identified for specific milestones that permit performance measurement.
• A Responsibility Assignment Matrix (RAM) showing the involvement of key contributors to the program.
• A working schedule prepared with allocated resources showing how these resources will be applied over time to produce the project or service from the program.
• A Critical Path and Program Evaluation Review Technique that is the basis for all performance reporting, the working schedules, and the known dependencies.
• A spend plan that shows cash flow throughout the program’s duration.
• Strengths, Weaknesses as well as Opportunity and Threats (SWOT) analysis with particular attention to program risk.
• Where risks have been identified, contingency plans have been started to deal with them as well as a risk register to tract the potentials for the risk becoming a problem.
• If capital equipment is needed in the program, appropriate requisitions have been prepared, with cost justifications attached.
• The Program plan prepared with participation and/or input from the owners of the deliverables.
• A control system has been established using variance analysis to assess in performance measurement.
• All components of the program measurement system are in place as defined in the Earned Value Management System description - or an appropriate measure of physical percent complete.
• Individuals have been selected for assignment to the program whose individual needs will be met through participation, where possible.
• The program is planned to a manageable level of detail at no less that level 3 of the work breakdown structure (WBS).
• Work has been broken down into reasonable durations tasks (work packages) which are assigned with a budget and to a responsible Control Account Manager.
• A post-mortem has been done at each milestone in the program and a final one has been done for the overall program and placed in the program.
• Members of the team have been instructed to record their working times on the program daily.
• A chart of control accounts (level three of the WBS) has been developed to track earned value against the plan and the contract deliverables of the program.
• All members of the team are clear on the expectations of them in terms of authority, responsibility and accountability.
• The standard operating procedures for empowering people has been applied to every member of the team.
• Limits have been established to determine when the program plan will be revised, such as plus or minus 10% total authorized budget variation, etc.
• The needs of customers have been carefully considered and documented in preparing the program plan.
• Qualitative guides have been developed for non-quantifiable program objectives, such as program performance.
• Checklists have been prepared for major segments of the program so that nothing is overlooked.

Software Project and Process Measurement

For those missing the DeMarco post, here's a counter argument from CrossTalk, titled Software Project and Process Measurement.

The notion that measure is of little value is of course unfounded in any software development environment where you are spending someone elses money. If it's you own money, then only you care.

If it's someone elses money, they probably care when you'll be done with the business value they need to implement the capabilities needed for their strategy to actually work.