Herding Cats

Want To Be A Professional, Then Start By Acting Like A Professional

There is a debate going around the project management community about whether a Project Manager is a Professional. It's a slightly silly debate in the end, for the simple reason - in my opinion - that whether a PM is classified as a Professional or not will have little impact on the success of failure of projects.

Looking at other professions. Doctors, Airline Pilots, Lawyers. The certification of the professional status of these fields - for the most part - is rigorous. I know about two of these fields - Lawyers and Airline Pilots. Both hold "licenses" to performance their professional duties. Both professions have numerous examples of un-professional behavior. It is rare that we read about lawyers killing people. Airline pilots do at a rising rate in 2009.

But airliners still crash due to "pilot error," people still die on the operating room table due to negligence, lawyers get sued themselves for misconduct. These appear to be rare, but in fact they are not. A check of the Stats at the National Institutes of Health, or the stats at the National Transportation Board aviation accident database.

To the question of Professional Project Managers

There are upsides and downsides to being labeled a Professional Project Manager. Professional are liable for their actions in ways non-professionals are not. But there is a question of credentialing. Credentialing refers to mandated licensing and voluntary certification programs.

The "profession" of project management at this point is a voluntary certification program world wide. For example registered nurses are licensed to practice, but board certification allows them to access to specialty areas.

There is the prestige of being called a professional. And let's not forget those who provide training, education, and certification for professional designation. They've got lots to sell us and money to be made advancing the profession.

This by the way is why state certification of professional engineers is an good thing - since the state is not in the business of making professionals out of the engineers, but protecting the public from their actions. The states issue licenses

The step to become a Professional - whether PM's ever become professionals or not - is the start acting like a professional.

• Keep up to date on all things project management
• Become a member of organizations related to the "profession" of project management
• Be informed about matter concerning the "profession" of project management

Now to the Point

If you want to start down the road to acting like a professional, start by reading journals that contain information needed to be a professional

• Project Management Institutes Project Management Journal - irregardless of your opinion about PMI, the PM Journal has peer reviewed papers about the "profession" of project management
• International Council of Systems Engineering (INCOSE) - certifies Systems Engineers
• Society of Cost Estimating and Analysis (SCEA) - is a cost estimating professional organization, whose Journal of Cost Analysis and Parametrics contains papers focused on cost and its impact on projects mostly in the US Government Defense sector.
• International Society of Parametric Analyst (ISPA) - is the parametric side of cost analysis
• Association for the Advancement of Cost Engineering (AACE) - is similar to SCEA is some ways, but heavily focused on the construction industry.
• IEEE Engineering Management Society - the management profession in the IEEE
• The National Society for Professional Engineers - has something to say about project management in the PE context.

What Does All This Mean?

First of there is to be any value from certifying - in some yet unknown way - project managers, there must be a clear and concise beneficial outcome to both those being certified and those making use of those that have been certified.

This top down approach - defining the unassailable beneficial outcome - seems to be missing from many organizations and individuals who have proposed assessing the capabilities of project managers in the context of a "profession."

Just as aside, everywhere I have every worked, the units of measure of this unassailable beneficial outcome have money in it somewhere.

So Show Me the Money

If we had Professional Project Managers - or even certified to some level of skill, knowledge, or competency - how can project success be improved? How can money be saved? How can safety be increased? A few of those annoying little things that people with the money ask, when someone asks them to part with it.

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
  

Using Earned Value in a Changing Scope Environment

The basic principle of Earned Value starts with the establishment of a Performance Measurement Baseline (PMB) and the measurement of progress against it. The Budget At Completion is the total target for the budgeted cost for the project when it completes.

Everywhere we turn we hear about projects that are over budget, behind schedule, and are failing to deliver the promises made when the project started. This is the mantra of most IT projects. Business requirements change. Technology requirements change. Everything changes.

But for the owners of the funding source, change is not something they like to hear about when it comes to budget increases and schedule delays. The agilest will tell us as well, that the system be produced must be ready to be put into production - or at least be complete at some level of maturity - at all times. This way the customer - the one with the check book - can get something for their money at all times.

And here's the rub with most IT projects. Most projects in general. The customer has a budget. The customer has specific needs that must be there to fulfill the business case. Those needs need to appear on or before a specific time to start earned their keep for the business.

Being told the requirements will emerge along with the code that we're developing is of course little comfort to the holder of the check book, when what was planned to be delivered turns out to be less than what was delivered - even if the budget and schedule numbers are met. Most business people I've met kinda want to know when it will be done, will I be within my budget, and can I get what I need - at a minimum - to fulfill the promises I made to the board of directors.

We showed up on time and on budget, but the features you wanted - or even the features you needed for the business to work - aren't there.

So Let's Look at Some Environmental Impacts That Drive Scope Changes

• The original baseline plan left some things out. 

This is a common occurrence. Happens all the time, even in very formal programs. This should actually be expected and therefore a process is needed for handling it when it does.

The first step is to establish a time when "new" items can be added. This can be an open widow, on the rolling wave boundaries, through a formal process of change management. Something that is predictable.

These changes need to be connected to the CURRENT scope of the project. They need to have a reason. The best approach is to connect the change to the business case, the Concept of Operations, or the Mission Statement. But if they expand the scope of the project, there must be another process. Otherwise the scope grows with bound and the value of EV becomes worthless.

• We've got a new way of doing the work

This is similar to the item above. No change in scope has occurred but we've discovered a better way of doing things. This of course will impact the BCWS and how we measure physical percent complete. Like the additions to the existing scope - usually more details and slight changes in the external behavior of a feature.

• The original estimates for budget and duration turn out to need "fixing"

We always learn as the project progresses from left to right. We must use this knowledge to improve the schedule baseline. This is a motivation for rolling waves. The Planning Packages in the future rolling waves have less fidelity at the task or work package level, than the current rolling wave. This is why they are called Planning Packages.

• There is real scope changes to the project from the customer

Additional scope - not just improvements in the current scope - must go through a formal change management process. This process is not, nor should ever be, an impediment to improving the project. It is a red herring from agilest to suggest that change control is heavy weight. But if we're changing the scope of the project without understanding the impact of those changes, the business value of those changes, the risk impacts of these changes, then we're no longer managing the project. We're just spending the customers money.

• The work we planned is taking longer than we planned and it is costing more than we planned

These activities can not be accommodated in Earned Value. If we're late, we're late. If we're over budget, we're over budget. The Performance Measurement Baseline must show that. Rebaselining or "rubber banding" the baseline is the beginning of the end for  using Earned Value effectively.

For Earned Value to produce value for the project, baseline integrity is a must.The only reason to deploy EV is to identify variances in cost and schedule from the baseline. Fiddling with the baseline negates all the beneficial outcomes of EV.

So there is a simple and hard rule, "no messing with the baseline in the absence of formal change control." No changes to the baseline can be made to fix poor performance - period.

So Now What's the Real Problem?

• Maintaining the Performance Measurement Baseline in the presence of pressures for scope changes
• A change control system that is not burdensome, but at the same time maintains the integrity of the PMB

And in the end...

• How to actually use Earned Value in the presence of changing scope.

Friday Round Up

• "Why Big Software Projects Fail: The 12 Key Questions," Watts S. Humphrey, CrossTalk, March 2005
• Air University Press - has a variety of US Air Force history and current guidance books. All free and many times free shipping.
• Navy Earned Value Center of Excellence

Beyond the Novice and the Advanced Beginner

I've been chatting back and forth on email, blogs, and forums around several things of interest to me this week. Some conversations were fruitful some were not. These topics include: Earned Value, Project Management, and the competencies needed to successfully manage project.

On the way home from Montgomery Alabama and the Air Force IT Conference at Maxwell Air Force Base, I come to understand that humans have a proclivity for fuzzy thinking and logical inconsistency.

This should come as no surprise when reading blogs and forum messages on almost any topic. The topic of earned value, competency measurement of project managers, success rates of government contracts, the effectiveness of agile software development, the interpretation of CMMI–DEV V1.2 are a few discussions that easily succumb to fuzzy thinking.

Fuzzy thinking and logical inconsistency is not the same as differences of opinion, or even differences in fact. The level of fuzziness and logical inconsistency usually follows the level of maturity of the speaker. According to Dreyfus gaining expertise in any subject has 5 levels

• Novice
• Advanced Beginner
• Competent
• Proficient
• Expert

Let's look at Earned Value Management as an example.

• Novice – a set of context free rules are acquired. These rules ignore the context sensitive features of Earned Value, such as the stability of the Performance Measurement Baseline, the management of Management Reserve, the flow of funds from the Total Allocated Budget down to Control Accounts and Work Packages.
• Advanced Beginner – through practical experience, the novice begins to recognize situations where the rote rules cannot be described in objective, context free terms. Size implicit size of a Work Package and the associated budget (BCWS) compared to the implicit or explicit risk determines the method of physical performance measurement.
• Competent – superimposing an overall strategy on the development of the Performance Measurement Baseline (PMB) on top of the Advanced Beginner and Novice's understanding of the principles. Does this PMB describe the inherent risk of the program and the mitigation activities needed to handle that risk? What impacts on physical percent complete arise from this risk?
• Proficient – in the previous levels of maturity decisions are made using deliberative and conscious choices. The proficient user of Earned Value makes decisions, as well, on the "feel" of the data. "These numbers don't feel right for our current phase of the program." "This SPI should be decreasing after we have passed Preliminary Design Review, and since they're not, there is some other issue we have to discover." The instinctive reactions to information come of similar experiences in similar situations. There is a spontaneous response comes from an "understanding" of the plan or strategy.
• Expert – no longer sees Earned Value as a data gathering and reporting process. The PP&C expert uses Earned Value as a paradigm to "manage" the program. The problem solving and decision making processes become integrated with the information produced by Earned Value. These "actionable information" processes are embedded in the daily rhythm of the program.

Now To The Problem

When there is a suggestion to "simplify" something or replace it with an alternative, or even to redefine formulas and words, say the application of Earned Value, the proficient or expert will respond with "OK, here's the minimal set of activities within the 32 Criteria of ANSI/EIA–748B that can be used and still call it Earned Value." The Novice might say, "I've got a better idea, let's copy ACWP to BCWP and we'll be doing Earned Value." (This is a nonsense approach of course, but one I have actually seen in practice on a $130M ERP deployment.)

The Advance Beginner might say "Let's move our unused Work Package funds back to Management Reserve (MR) to be used latter," or "let's extend duration of this Work Package and re–spread the BCWS." This is called "rubber banding the baseline."

When there is a discussion on a forum or a blog about applying EV and response come back, "why are you making this so complex?" the first response might be "well to get actual value from Earned Value you need to apply it at the Competent level or above.

Simplification "tricks" are just that "tricks." To move from the Novice to Advanced Beginner requires careful step–by–step deployment. Seeking advice and feedback from more mature sources. These don't have to be people, but working examples of how EV is applied at the expert or at least the proficient level. The best source of expert and proficient application of Earned Value is to look at the Earned Value Management System Descriptions that can be found on the web. These are DCMA (Defense Contract Management Agency) assessed processes for programs subject to Earned Value Management (EVM).

Not every use of EV is guided by DCMA, but every use of EV should – I'd say must – be guided by ANSI/EIA–748B and the NDIA Earned Value Management Intent Guide (EVMIG). In the absence of this framework, you might call what you're doing Earned Value – using BCWS, ACWP, and computing or "making up" BCWP – but it "ain't so."

Of the 32 Criteria from 748B there 10 or 11 "must do's" for anyone to say "we're doing EV." They are:

Organization

1. Define the authorized work elements for the program. A work breakdown structure (WBS), tailored for effective internal management control, is commonly used in this process.

2. Identify the program organizational structure including the major subcontractors responsible for accomplishing the authorized work, and define the organizational elements in which work will be planned and controlled.

Planning and Scheduling

6. Schedule the authorized work in a manner which describes the sequence of work and identifies significant task interdependencies required to meet the requirements of the program.

7. Identify physical products, milestones, technical performance goals, or other indicators that will be used to measure progress.

8. Establish and maintain a time-phased budget baseline, at the control account level, against which program performance can be measured. Budget for far-term efforts may be held in higher level accounts until an appropriate time for allocation at the control account level. Initial budgets established for performance measurement will be based on either internal management goals or the external customer negotiated target cost including estimates for authorized but undefinitized work. On government contracts, if an over target baseline is used for performance measurement reporting purposes, prior notification must be provided to the customer.

9. Establish budgets for authorized work with identification of significant cost elements (labor, material, etc.) as needed for internal management and for control of subcontractors.

Accounting Consideration

16. Record direct costs in a manner consistent with the budgets in a formal system controlled by the general books of account.

Analysis and Management Reports

22. At least on a monthly basis, generate the following information at the control account and other levels as necessary for management control using actual cost data from, or reconcilable with, the accounting system: (1) Comparison of the amount of planned budget and the amount of budget earned for work accomplished. This comparison provides the schedule variance. (2) Comparison of the amount of the budget earned the actual (applied where appropriate) direct costs for the same.

27. Develop revised estimates of cost at completion based on performance to date, commitment values for material, and estimates of future conditions. Compare this information with the performance measurement baseline to identify variances at completion important to company management and any applicable customer reporting requirements including statements of funding requirements.

Revisions and Data Maintenance

28. Incorporate authorized changes in a timely manner, recording the effects of such changes in budgets and schedules. In the directed effort prior to negotiation of a change, base such revisions on the amount estimated and budgeted to the program organizations.

Is EV for Experts Only?

No, but it's not for Novices either. Some level of knowledge and experience is needed for success. The advanced beginner will soon run into trouble once the reporting process starts to be "cooked" in any way. No amount is "simple" process can seem to prevent this even in sophisticated environments. Constant vigilance is needed to assure the numbers have meaning.

There are dozens of ways to make the number look better than they are. Some level of competency is needed to get beyond "reporting yesterday's weather," and start using EV to forecast the future. This requires experience and skill and most all the INTENT of Earned Value as described in the Earned Value Management Intent Guide and some higher level overview from Neil Albert on Earned Value Management Application, Guidance, and Education.

If you're doing all of these, you're doing Earned Value Management. If you're doing some but not the others, you're NOT doing Earned Value. You may be doing something else, but it's not Earned Value. The level of maturity needed to perform these 10 activities is beyond the Novice. Possibly the Advanced Beginner can take a stab at it. But competency is needed to use Earned Value Management in a project management context. Beyond just reporting. Managing the project.

So in the end the usefulness of Earned Value starts with the Competent user and gets better as you move to Expert. But even programs looked after by experts have troubles. All programs have troubles. It's simply the nature of complex, high risk programs. EV must become of tool to provide actionable information to the program manager (as one of our tag lines suggest), otherwise it's just a bunch of meaningless numbers.

A Gold Mine of Knowldege

I'm attending the Air Force IT Conference at Gunter Annex - Maxwell Air Force Base in Montgomery Alabama. We're here because our firm is a partner with a prime contractor on the NETCENTS 2 program. While walking the halls today I came across the Air University book store.

For anyone with an interest in Air Force history or modern strategy this is a gold mine. The books are all down loadable or can be mailed to you "free of charge." Well not really free in that sense, since you pay taxes, this is a way to get back some of that money.

I mentioned this for several reasons:

• There are authors on commercial project management sites that speak sometimes about the failing of government projects, the processes and tactics used during military operations. Some of these authors are missing information about the topic to which they speak.
• There are other authors that speak strongly against the way the government (US Government) manages programs. A few of these authors are also missing information and providing opinions devoid of facts.

I'm back in my hotel tonight with a stack of book:

• Sharing Success - Owning Failure: Preparing to Command in the Twenty-First Century Air Force, Col David L. Goldfein, USAF
• Expansion or Marginalization: How Effects- based Organization Could Determine the Future of Air Force Space Command, Edward B. "Mel" Tomme, PhD, Lt. Col. USAF (Ret)
• Engineering the Space Age: A Rocket Scientist Remembers," Robert V. Brulle, Lt. Col, USAF (Ret)
• Responsibility of Command: How UN and NATO Commanders Influenced Airpower over Bosnia, Col Mark Bucknam USAF
• Into the Unknown Together: The DOD, NASA, and Early Spaceflight, Col Mark Erickson, USAF.

and a little closer to home

• The Air War in Southeast Asia: Case Studies of Selected Campaigns (during the Vietnam War), Dr. Herman L. Gilster

The Point Of All This

The Air Force, like the Army, Navy, and Coast Guard, is a source of information about current and past activities. Many of these could be classified as "projects," with a beginning, middle, and end. A finite bounded set of work activities with a defined outcome.

One an author starts to speak about some topic related to military operations that seems a "bit off," these publishers can be a source of information beyond personal opinion or out of context opinion pages in the newspaper.

An Open Challenge

For those of late who proffer a solution to the issues of project success - this includes all who have a collection of "magic beans," who claim an alternate to PMBOK and us PMP's who put it use, who rail agianst Prince2 and its practitioners, who consider Agile of all stripes inappropriate or the opposite - the second coming, IMP/IMS, or any other project management system currently in place and being applied- here's the challenge

Go work a program or project. Show us that your method, assessment, certification, or what ever you're pitching actually does result in a statistically significant increase in the probability of success of projects or programs.

When this evidence arrives, call me and we'll see how to put it to work on the programs we work.

In the absence of this evidence, I'll consider the message you're sending as just another sales scheme to capture my money.

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.

Quote of the Day

“It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.”

and it's companion ...

“Get your facts first, then you can distort them as you please.”

— Mark Twain

Percent Complete?

Here we go again, redefining project management terminology to make a point that doesn't need to be made if we simply read the literature and followed the guidance and explored a little outside the narrow confines of agile...

There is no such thing as percent complete

Is Johanna Rothman's post about how percent complete makes no sense. Johanna needs to do some homework along with her class on this subject.

1. Physical percent complete is a contractual statement used on large project acquisition to mean How much of the physical deliverable has been completed.
   • How much of I-25 has been completed as of this date and how much should the State of Colorado and the Federal High Way Administration pay the prim contractor for this work?
   • This is not an arbitrary measurement. Nor was it an arbitrary assessment.
   • The measure of Physical Percent Complete is clearly and concisely stated in the contract
2. Physical Percent Complete is a Earned Value Management System (EVMS) term, clearly and concisely defined in ANSI 748B.
3. Physical Percent Complete is evidenced by artifacts from the work effort. Pieces of metal, working segments of code, walls of a building, assembled elements of an aircraft, numbers of drawings for the design of that aircraft, subcontracts issued to the components for the assembly of the aircraft.

In the software world, without tangible evidence of physical progress, the project is late and no one knows it.

Physical Percent Complete is the Only Measure of Progress.

In Johann's class room example how many features were planned to be done? How many features were done? Johanna is factually correct

Percent complete makes no sense. Features are done or not done. You can count done features and see how far along you are. You can't reliably count any percentage done.

Percent complete makes no sense if you don't know what done looks like. Counting features when you don't know how many features were planned for this iteration makes no sense. 

This is a core failing in all software projects. No wonder they're over budget and behind schedule. No one knows what done looks like. So there is no way to assess if progress toward done is being made other than the passage of time and the expenditure of other peoples money.

 

You Know You Work in Aerospace When...

A little joke going around the office. This could be almost any place in the corporate world.

1. You've sat at the same desk for four years and worked for eight different managers
2. Your resume is on a jump drive, in your pocket
3. When someone asks what you do for a living, you lie.
4. You get real excited about a 3% pay raise
5. Your biggest loss from a hard drive crash is that you lose your best jokes and Internet sites
6. You sit in a cubicle smaller than your bedroom closet.
7. It's dark on your drive to and from work.
8. Fun is when "projects" are assigned to someone else.
9. Communication is something your Group is having problems with.
10. You see a good-looking person and know immediately it is a visitor.
11. Free food left over from meetings is your main staple.
12. All art involves a white board.
13. All real work is done prior to 9:00 AM or after 5:00 PM
14. You're already late on the assignment you just received.
15. Dilbert is your favorite carton.
16. Your boss's favorite lines are: "When you get a few minutes," "In your spare time," or "I have an opportunity for you."
17. 90% of the people in your company do not know what you do.
18. 90% of the people in your company do not care what you do.
19. Vacation is something you rollover to next year or a check you get each January
20. Change is the norm.
21. You read this entire list and understood all of it.

Physical Percent Complete

There is always a discussion around how hard it is for software projects to measure progress.

They're not like construction or building ships or airplanes

I'm calling BS on any approach like that. The notion of measuring physical percent complete is at the very core of every project management method starting with eXtreme Programming and ending with full DoD Earned Value based IMP/IMS (Integrated Master Plan / Integrated Master Schedule).

In fact if you're not measuring physical progress to plan with tangible evidentiary materials, then you are working on a Level of Effort project - where the passage of time means progress.

So What Does Evidentiary Material Look Like?

The real question is "What Does Done Look Like?" That is the question that needs to be answered at all times.

• What does done look like for today?
• What does done look like for the week?
• What does done look like for this iteration?
• What does done look like for the delivery cycle?

You get the idea. If you not speaking about "what do done look like" you can not recognize done when - or if - it arrives.

So what does done look like?

• A running piece of software that does something that the customer actually wants it to do.
• A functioning piece of hardware that passes a predefined set of tests.
• Dried concrete in the piece your wife wanted it to be - between the garden and the grass

Something tangible. Something that was described BEFORE you started. The idea that emerged code or emergent concrete walkways is quaint for projects that have no important purpose. But if you are spending other peoples money - or your home improvement budget - when you are done, you want the person who gave you the money to agree that you did what they asked you to do.

So predefine what done looks like for this increment of the project. The Plan of the Day, the Plan of the Hour, the Plan of the Week, ... Then check that you actually did what you said you were going to do.

That's how you measure physical percent complete. If you can not measure Physical Percent Complete, than only one of two things has happened. You are working on a Level of Effort project, or you chould not start work.

Quote of the Day

Well Done is Better Than Well Said

Inside the cap of a bottle of SweetLeaf Iced Tea, while watching Lance Armstrong cross the finish line of the Leadville 100 with a time of 6:28:51 for 100 miles of mountain trails. And well done it was, the next finisher was 29 minutes back. Number 688 crossed 6 hours back

Friday Round Up

I've watched several blogs do a collection of good ideas on a periodic basis. "Hey I can do that too and add more value."

So I've started to remember memorable blogs, sites, and announcements I've come across during the week - or maybe every two weeks.

Here's what hooked me this week.

• Agile Architecture is Not Fragile Architecture - James Coplien and Kevlin Henney present a breathtaking tour of agile architecture. This is a must see tour of architecture and agile in general. Never again will you be pushed around by the agilest that claim you don't need architecture, a project manager, or all the other buzz words tossed about in the absence of a context or business domain.

Requirements Management for Grown Ups

Josh at PMStudent reminded me that DOORS is our "standard" requirements management tool. For those not familiar with DOORS, here some webinars.

DOORS was purchased by IBM awhile back. It's the standard in NASA and DoD ans is now moving into the commercial market place.

The statistics show poor requirements management means poor project performance. But with DOORS you actually have to have "real" requirements management. None of that "make and list and start coding" type of requirements.

With DOORS you can become a "real requirements engineer," and a Systems Engineer as well, since requirements engineering is Systems Engineering.

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.

First Pass of PMI Practice Standard for Project Risk Management

I've started through the PMI Practice Standard for Project Risk Management.

First my biases in general. The absolute best book on "risk" is Ed Conrow's, Effective Risk Management: Some Keys to Success. I have read and reread this book dozens and dozens of times. It that kind of book. Each read brings out something new. As well the history of PMI's risk approach was based in the risk value of Probability of Occurrence x Impact to give a risk value. This is simply not possible in the mathematical operator world, since the probability of occurrence is a Probability Distribution Function (an integral equation) and the impact is a scalar value. Multiplication is not defined between these two constructs. 

The new practice guide moves away from this notion toward the accepted DoD approach of defining the elements of the Probability and Impact Matrix. But does a weak job of stating how to construct the various elements. Look in the DoD Risk Managers Guide for a much better approach.

After the first read there is two show stopper concepts:

• There is no formal separation between technical risk management and programmatic risk management.
• They include the notion of threat and opportunity.

Only if the Project Manager is a technical manager can these two notions be handled by one person. There is a picture in Figure D7 that lists the taxonomy of risk - the Risk Breakdown Structure (RBS). This notion is poorly developed when compared to places like NASA's Probabilistic Risk Analysis handbook and the INCOSE Systems Engineering Handbook. But I would suspect the authors don't travel ion those domains.

• Technical Risk – uncertainty about the functional and performance aspects of the program’s technology that impacts the produceability of the product or creates delays in the schedule
• Programmatic Risk – uncertainty about the duration and cost of the activities that deliver the functional and performance elements of the program independent of the technical risk

Without separating technical from programmatic risk, the management of risk is clouded by the possible "risk handling" processes. They are not identified, classified, handled, reported, or analyzed the same.

I have mixed opinions about the threat / opportunity notion. Rarely are threats and opportunities. Interchangeable. They should not be treated in the same discussion. This is a very IT centric view of risk management, so I'll stay away from the discussion. The article "Opportunity Management: By Careful What You Ask For," Edmund H. Conrow and Robert N. Charette, Defense AT&L, March-April 2008, should be your starting point before getting excited about mixing these two concepts.

This brings up another issue. PMI likes to invent their own set of words and processes, when there are already well defined and broadly used definitions for the processes. SEI's Continuous Risk Management (CRM) and DoD's Risk Managers Guide have clear and concise definitions of the risk management processes. No need to invent yet another set of confusing words, in an already confusing world of risk management.

A previous post Risk Handling shows two options for this.

For all those wanting or needed to start at the beginning for risk management here's Risk Management in Five Easy Pieces.

So far I'm luke warm on the Practice Guide. It's all personal and all based on the defense and space point of view.

Quote of the Day

"To generalize is to be an idiot." - William Blake

Minimum Elements of an Earned Value System

There are 32 criteria of a DCMA (Defense Contract Management Agency) certified Earned Value Management System (EVMS). Such a system is mandated for federal contracts greater than $50M and must be considered for contracts greater that $20M where EVM is mandated.

For the non-DoD, NASA, or DOE program there are easier approach to deploying EV. The first place is to start with what is the minimal "good practice". Below are the 32 Criteria from EIA/ANSI-748B

The consensus - lead by Ray Stratton is that they are: 1, 2, 3, 6, 7, 8, 16, 22, 27, 28. There are other opinions, but that is a moot point. These are the starting points for deploying an EVMS for commercial or other domains, where the DCMA is not visiting on an annual basis.

So What are These items

1. Define the WBS

If you don't know what the components of the deliverables are, you can't be expected to know how much it costs and what work needs to be done. The WBS is a Product Breakdown Structure (PBS) and the services needed to produce these products. NOT the functional organizations that deliver these services.

2. Identify the Organization

Who's doing the work? With the WBS and the Organizational Breakdown Structure (OBS) you can build the Responsibility Assignment Matrix (RAM). In the defense business the intersection of the OBS and WBS is the Control Accounts and the Control Account Managers (CAM). This is probably too formal for many domains. But the RAM is always needed. If you don't have a RAM there is no way to hold anyone accountable for the deliverables, the budget and schedule for those deliverables. The notion of a "self managed" team is possible in the presence of a RAM. Without a RAM a self managed degrades into chaos.

3. Integrated Subsystems

Every non-trivial projects has subsystems. Allocating budget and schedule to each subsystem is critical to segregating cost and risk. Decision making around trade off is driven by this type of information.

6. Schedule the Work

When are you going to do what the WBS says is needed to complete the project? What is the order of this work? What is the critical path of the activities for this work? What are the dependencies between the work elements?

7. Identify Products and Milestones

How will you know you are making progress. The presence of a tangible physical outcome from the work effort is the best way to do this. Passing a milestone is not my favorite. The "products" can be intermediate versions of the final product. Prototypes, partially functioning products. The favorite approach for the Agile. In the end only physical evidence should be used to measure progress to plan. And - most importantly - the define of what "done" looks like must be in place BEFORE the works starts, so when the Milestone (which is just a rock on the side of the road) is passed, you can look at the result to see if it was what was planned to be done.

8. Set a Time Based Budget

Money is converted into products. What is the profile of the spend rate for this money? How much money do we need? How much money do we have? How are we planning on spending the money? This is called budget management.

16. Record Direct Costs

How much did we spend? This is the direct cost of doing the work we planned to do.

22. Periodically Collect Control Account Sums

Once a month, collect all these numbers in one place and look at them. Ask hard questions. Did we do what we said we were going to do? Did we spend what we said we were going to spend?

27. Revise Estimate at Complete

If the answer to the questions in #22 is unfavorable, then change the plan.

28. Incorporate Changes

With the changes in hand, make a new plan and execute it for the next period of performance.

That's it. That's all you need (for now) to do earned value. You've got the planned cost (BCWS), the actual costs (ACWP) and the earned Value (BCWP). The only formula you need is

BCWP = BCWS x "Physical Percent Complete"

 

 

Follow the Baton Not the Runner

When someone says - "we have this much better process," or "you should do XYZ this way instead of the way you're doing it now." Stop, think, and ask some questions:

1. What are they selling. Maybe a product. Possible a philosophy. Maybe a political position. maybe themselves.
2. How can you know what they're suggesting actually works in your domain? What domain does it work in? Work domains doesn't it work in?
3. How can you tell it will actually work in your domain, if that's a domain they claim it will work in?

A phrase from the track and field domain for relay teams is to:

Watch the baton, not the runners.

This means never confuse effort with results. Never confuse a self-proclaimed expert with a practitioner. The more credentials behind their name, the higher the probability they is either the world's expert on a topic, or poser. Both use degrees, certifications, and credentials to impress you.

Instead ask - what value to they bring to the conversation? Always determine the unit of measure of  this value and the results of the processes. Make sure this unit is measure is meaningful to you or your customers. Without a unit of measure for the claimed beneficial outcome, there is no way to confirm there is actually any beneficial outcome to the suggestion.

This is an all-too common approach. As project managers we need to poke deeper at every claim of improvement. Ranging from tools to processes. So when someone says try my "magic beans," or "I've got this very clever spread sheet that short cuts all the work you have to do in your ERP system." The first responses should be:

• What's the evidence you gathered showing is provides improvement in your domain?
• Is this evidence statistically meaningful?
• Have you thought about how the benefits would be transferred from your domain into my domain?
• What evidence should I look for the see that your improvement is actually happening in my domain?