Herding Cats

Improving Projects With Pithy Comments

Pithy comments seem to be the norm on some forums and blogs around improving the probability of success for a project or program.

• "Buy my software and your dream of project success will come true."
• "Buy my book or better yet hire me, and your project processes will improve."
• "Listen to my critique of two forms of project management in a domain I have ZERO experience in and you too will understand how smart I am."

It's sad really how we become trapped in seeking simple solutions to complex problems. There is good advice of course. The books referenced in the FAVORITE BOOKS section on the bottom left side of this page are a start. But they are just books. Journal articles provide guidance as well. Refereed articles that is.

So what to do?

• When ever there is advice, ask the adviser if he has direct experience in the domain and the context of that domain of the problem you're facing. More than just "passing through the airport in question," how about working on the team the built the airport in question. Our own Denver International Airport was a classic example of local opinions at the time, with ZERO hands on experience.
• Ask about past performance of those "magic beans" that are conjectured to fix all that is wrong with the type of project you're working. Did those "magic beans" have a quantifiable measures of success from the starting baseline plan? That is, did the plan turn out to be the actual? If so, can the method, process, or advice be attributed to the success of the plan? Or more important;y can the disappointment in the project be attributed to the use of a method or process. This is the classic "red herring" of mis-informed agilest. "I was on a program once that used waterfall and it failed." Likely true, but what else caused the failure? Don't know? Then making the attribution is sporty business.

Which brings me to the final "what to do"

• What was the probability of success on day one? Was there a measure of this probability?
• "We have an 80% chance of completing 'on or before' the 3rd week in November with a 5% error rate"
• Statements like that are a starting point. But look at Program Success Probability for some insight.

In the end there is only ONE piece of evidence of success for a proposed method or process - Past Performance. Past Performance in a "like" domain and a "like" context in that domain. If there is a gap in the context, then the adviser must show how that gap will be closed. Notice "will" not "can."

If there is a gap in the domain, then the adviser has to show how the past performance is "close enough" to be meaningful.

For general class of problems, past performance is easier to use, but even there, care is needed before acting on the advice, to assure that the general class of problem is just that "general class."

One of my favorite issues is the conjecture that competency based assessments are somehow the solution to poor project management staff. In fact the solution to poor project management staff is good project management staff. The idea that you can "test" for competency  has merit and of course their are numerous organization ready to sell you courses and assessment vehicles to support their claims that they have the right approach to improving project performance.

There are only a few classes of advise I know of that can be generalized for complex projects, and the staff that manage them:

• Application of ANSI-748-B in a manner validated by an external agency. Not the 3rd party, but an agency tasked with Validation. In the US that is the DCMA (Defence Contract Management Agency).
• Application of probabilistic risk assessment - in a manner prescribed by DID 81650.
• Development of an Integrated Master Plan and Integrated Master Schedule - in a manner prescribed by the US DoD.
• Integration of these into the Performance Measurement Baseline - as prescribed by the DCMA.
• Application of Technical Performance Measures to assess physical percent complete.

There are likely others, but I can't think of any now.

Agile in the US Department of Defense

The 2010 National Defense Acquisition Act, Section 804 requires Department of Defense IT implement processes that include:

• early and continual involvement of the user;
• multiple, rapidly executed increments or releases of capability;
• successive prototyping to support an evolutionary approach; and
• modular, open-systems.

Here is the paper describing the implementation plan for this.

Alert - Joint Strike Looses $11.5B

Daily or semi-daily blogging is some times not enough. I'm going to try out the notion of an ALERT.

When the term "complex project" is mentioned here's an example. Joint Strike Fighter. The $380B (yes that is a Billion) program has just been cut by $6.8B trough FY 2016, along with a $4.6B shift from production to research.

The management of these class of program is truely a "complex adaptive system."

I'll try this for awhile to see how easy it is and how many items are really ALERT class.

Quote of the Day

John Goodpasture had this on his Blog.

"It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers" - Fred Brooks.

This is more the case than not. One of the principle sources of project failure on the cost and schedule side is the lack of credible estimates. This is not limited to badly managed IT programs. Joint Strike Fighter suffers from the same problem. It is a universal problem.

 

Are You Doing Project Management?

Long ago I had a Blog conversation with an expert in MSFT Project Server about cost management in projects. His position was managing the details of cost with a resource loaded schedule was a waste of time. I was embedded TOO much in the IT world to remember my construction and defense roots. Now that I've come back to A&D for the past 3 years, I remember that conversation fondly as laughable.

I'm editing an appendix to the PMI Earned Value Management Practice Guide, and here's a clip from a paper that defines all we need to know about projects and project cost. From "Combination of Project Cost Forecasts in Earned Value Management," Journal of Construction Engineering and Management.

Reliable cost estimates are essential for effective project control and the management of cash flows within the project and at the company level. Conventional approaches to project cost forecasting, which rely on detailed information developed for a specific project (the bottom-up estimate or inside view), often result in cost overruns. It is argued here that the inside view project cost estimates should be adjusted by combining them with the outside (or top-down) view of the project, which is based on statistical models of historical project data. This paper presents a probabilistic cost forecasting method and a framework for an adaptive combination of the inside view and the outside view forecasts of project cost using Bayesian inference and the Bayesian model averaging technique. During the project execution phase, the Bayesian adaptive forecasting method incorporates into the predictions the actual performance data from earned value management and revises pre-project cost estimates, making full use of the available information. Qualitative examples are presented to demonstrate the validity of the proposed method as a tool for effective project cost prediction and control.

If you're on a IT project, someone, somewhere is interested in cost management. If you're working a government contract we know who that is - finance. If it's construction we also know who that is - finance and the customer.

There is no such thing as doing project work and NOT managing cost. The notion - wrongly - that Agile projects are not managed in the traditional sense of cost and schedule only occurs when there is no one who cares about cost and schedule.

The key to success of any project contains Five Immutable Principles:

1. Where are we going?
2. How do we get there?
3. Do we have enough time, resources, and money to get there?
4. What impediments will we encounter along the way?
5. How do we know we are making progress?

All these questions have a component of money.

Wild Swans not Black Swans

I was riding the DC Metro back from our new office to the hotel downtown, when I saw a rider reading a book "Wild Swans: Three Daughters of China," Jung Chan.

It dawned on me this was the true paradigm of risk addjusted "long tail" distribution discussion. Those long tail items - the probabilities that occur in rare instances with significant consequences - are there, they are known to be there because of the long tailed signature that the "event" is there.

This "event" may be a wild event, but it is there - sitting in the long tail of the probability distribution. It is not unknown. It is not an unknown-unknown. Only unknowable events are unknown.

Black swans are in the world. We just has to look for them. We need a method for looking for them. We need to do our home work and ask why would Black Swans NOT be in the world. What would prevent Black Swans for existing. If there is no reason for Black Swans, then we need to assume they exist and are just not seen.

There is a fundamental principle in physics...

If it is not forbidden it is possible - just not observable (at this point).

Quote of the Day - Leadership

When people speak of leadership, agility, mission, vision - they are many time not speaking from experience or past performance. But instead speak as an adviser to those attempting to lead. The exceptions exist of course - Jack Welch, Larry Bosidy, Colin Powell and the like.

Here's a quote from Chief Naval Operation's (CNO) priorities on "alignment," (meaning alignment with the mission) ...

This involves a couple of things. First, we must ensure that our organizations, systems, and processes are aligned to deliver exactly what they are designed to produce — a combat-capable Navy, ready to sail into harm's way. Second, alignment involves clear communication, from the recruiter, to the LPO to the CO to the CNO. It's about communicating realistic expectations and then helping Sailors accomplish realistic goals — in a word, credibility.

Notice the "sail into harm's way." When we speak of leadership, from self organizing to command and control, we need a a domain and a context in that domain. If there are no or little consequences for failure, leading a team is pretty much a straight forward task. One you can probably learn by reading a book or listening to "leadership" voices on Blogs and conferences.

Quote of the Day

If you can't describe what you are doing as a process, you don't know what you're doing.

- W. Edward Deming

The notion here is that everything is process. Process is King. People over process is pretty much nonsense as a standalone statement. With the right process for the problem, the people have a defined purpose for their actions.

Risk Management Source

There are several risk management resources that are needed to connect the dots between Cost, Schedule, Technical Performance and Risk adjustments to each of these. One of the best starting points is at the Mitre Systems Engineering Practice Office.

This post started with a question about distributing risk dollars across the WBS. Yes, you have a WBS and yes you have risk dollars outside your Performance Measurement Baseline. Both are needed to have a credible plan.

But first let's have a quick review of what "risk" means when we use the term in a domain and context. The cynic is me has learned there are very few outside the formal world of EVM, space, defense, and large construction actually know what risk management means - specially in the IT world. Here's the starting point from the DoD

The process for assigning risk at the WBS level - which was the motivation for this post - go like this:

1. Starting with the WBS/CWBS confirm the proper decomposition of the deliverables and the processes that produce those deliverables. The WBS definition is from only one place - MIL-HDBK-881A Don't let anyone tell you there are alternative descriptions of a WBS. They're aren't.
2. With the WBS the Integrated Master Schedule (IMS) can be further developed. All the work in the WBS is in the IMS.
3. With these two items, the programmatic and technical risk can be assessed. This is a standard approach defined by the 2006 Risk Management Guide for the Defense Acquisition University. The other guide is the SEI Continuous Risk Management. Either risk management guide will work. Domain and context is important here.
4. Now that you have the work, the schedule for performing the work, the risk involved in delivering the outcomes from that effort, you can start to assess the impact of these risks on the probability of completing "on or before" a date and "on or below" the target cost.

• For each deliverable, there must be a schedule and cost margin
• For the technical aspects, there needs to be an error band on the technical performance measure.

A good overview of how to start "thinking" about risk see "Rethinking Risk Management: NDIA Systems Engineering Conference 2009." This briefing outlines the processes and issues of managing risks on projects. It is software focused, but is applicable to any domain. This is one of those approaches that sets the baseline for how to do it properly. There are many voices out there for risk management. Don't start any where other than here (or the DoD). Then ask if other approaches are applicable.

The final thought, as always

Risk management is how adults manage projects - Tim Lister

SV=1.0 and You're Late?! Not if you're paying attention

There have been suggestions that SV is not a good indicator of performance. That Schedule Variance Can Equal 0 and We Can Be A Year Late! This suggestion was made on EV Linked In. I also found a similar suggestion of page 18 of the PMI Practice Guide for Earned Value.

This can only be true if we were not paying attention when the Planned Completion date went whooshing by. Here's the starting point.

Some Discussion

• The planned total budget is $100.00.
• The planned duration is 10 months.
• The Planned Value for each month is $10, for 10 months to get to $100.
• The actual performance is less than planned – Physical Percent Complete does keep up with the plan.
• When the planned completion date arrives, it turns out we’re late because we’re underperforming and SV showed that from day one.

What does SV look like on the day we're supposed to finish?

• Well it doesn't look good and hasn't looked good for awhile
  • SV = $18.8
  • SPI = 1.23
  • It's been unfavorable since day one
  • We're late and the SV/SPI shows it
• Are we "managing" this project or just reporting numbers?
  • If we were managing we'd have seen this coming back in month 1

Can SV =0.0 at end of the project?

• No, not if planned end of the project was at month 10. In month 10, SPI=1.23
• Yes, if we complete the work in month 12 and ignore the fact we blew past the end date and redefined the new end date in month 12!

We have remember Douglas Adam's quote

I love the sound Milestones make, as they go whooshing past

A Project Managers Formula for Success

John Wooden had a pyramid for successful basketball teams. That same pyramid works for successful project managers. This does not necessarily mean a successful project.

Each of these items builds on each other or supports each other. If we look at these, they are not that "touchy feely" approach. They are focused on success of the team as well as the success of the individual. They are tangible, measurable, visible behaviours. Other can rcognize these being present.

Quote of the Day

Good writing is not written; it's rewritten!

Thanks to  John Goodpasture for providing this quote in his post about Red Teams. It triggered all the proposal development brain cells from past engagement. There are "color team" reviews during proposal development. The proposal development process is a Project itself. I've been on proposal teams that have a $20M budget, 100's of people, and multiple locations. Managing a proposal is not for the faint of heart. It's an all out, full contact engagement with a fixed deadline and usually a fixed budget and an emerging set of requirements.

Themes are the starting point all good writing. Why would the customer buy what we have? This is where clear, concise language is mandatory. I've been trained how to write proposals. It is a painful process, guided by feedback from the proposal manager - "you're section stinks, redo it by morning, and this time follow the theme outline!"

Here's some advice from 5 or so years doing proposals, technical memos, guidelines (Earned Value Management System Descriptions), and general business development writing in the DoD world.

Do not write so that you can be understood, write so that you cannot be misunderstood. - Epictetus

Most techies confuse features with benefits. People buy benefits, not features. Here's an example.

Many techies didn't get through that English class either:

• Emphasize present tense
  • Establishes credibility
  • Establishes that "some thing" real is being proposed
  • Poor - our project management office will publish monthy status reports to the contractor
  • Better - The project management office publishes monthly status reports to the contractor
  • The word "will" says to the reader there is an alternative - won't
• Use the first person plural- speaks to the reader directly.
  
  • Passive - the launch of our product will be in month 26
  • Active - we will launch our product 26 months from program start
  • Passive - Tom Thumb has been appointed our program manager
  • Active - Our program manger is Tom Thumb
• Use the active voice - passive voice is weak "we will" says strength. It is simpler, more direct and believable, forceful and confident, usually less wordy, and eaiser to understand.
• Be positive and confident- negative statement sound evasive
  • Positive - Mary often arrived late
  • Passive - Mary often did not arrive on time
  • Confient - Our cost accounting system ...
  • Conditional - Our proposed Cosrt Accoutning system ...   
• Nouns, commas, and the finer points of style- this and these are not nouns.
  
  • Poor - The new sales process has better quality. This is because ...
  • Better - The new sales process has better quality. This increase is due to ...
• Be specific
  • Poor - Our saling vacation was delayed because of inclimate weather
  • Better - Our sailing vacation was delayed because of high winds
  • Best - High winds in excess of 50 knots delayed the start of our sailing vacation

Write the thesis statement first, then tell the reader why this is a benefit

“Our affordable, supportable approach to Balanced Scorecard has line of sight visibility, providing actional information to the decision maker, built on the integration of all sales and warehouse performance data, for lower deployment and operational costs on a 12–week, low-risk delivery schedule”

– 30 words telling the reader why they should buy the benefit.

Addeum. Dominic pointed out the error in my use of feight versus faint. Common Errors in English Usage.

 

Basis of Succcesful Project Controls

A successful approach to project controls system needs to define the processes for:

• Thorough planning;
• Timely baseline establishment and control;
• Information broken down by product as well as by organization or function;
• Objective measures of progress and performance against the plan at levels where the work is being performed;
• Consistent reporting to higher management for use in decision–making;
• Analysis of significant variances; and,
• The implementation of management actions to mitigate risk and manage cost and schedule performance.

These, like the 5 Immutable Project Management Principles, Risk Management, and the Nine Best Practices of Software Project Management, form the basis of a CREDIBLE process to increase the probability of program success.

Why Some Agilist Think One Size Fits All

I the mistake of commenting on a Lean Development Group post about the differences between Heathrow's Terminal 5 and Beijing's Capital Airport Terminal.

I suggested that capital construction projects in totalitarian societies, remember the country is name People Republic of China, are not subject to all the "progress prevention" activities found in western governments.

The legal system for contracts is dramatically different, there are no unions, subcontracting is usually a draconian flow down, and critically important - getting people to do things on time and on schedule has much different dynamics in China than in the UK, US, or EU.

The respondents don't seem to acknowledge this. What disturbs me most is the assumption - conjecture actually - that everything that works in the software development world or their own paradigm, is applicable to other domains and contexts.

One other issue - a personal one for me in our domain - is that past performance and deep domain knowledge and experience is the prerequisite for being able to give advice others.

I'd had a similar encounter a year ago on the same forum and the same author talking about the construction of the 787 versus the A380 and the business strategy of Southwest Airline's point-to-point. Of course the fact that SW does 42% of their passengers taking multiple hops - this is called hub nd spoke. But those facts are irrelevant to the authors point.

I'm reminded of Daniel "Pat" Moynihan's quote:

Everyone is entitled to his opinion, but not his own facts.

So why do some Agile and Lean thought leaders hold the position that - Agile and Lean are applicable to every problem they encounter? It seems to more common the more prominent the speaker.

There are powerful advantages to an agile approach to software development. This is not in question. There are powerful advantages to a Lean approach to business processes. This has been known for some time. CMMI and Lean Six Sigma for example. The Lean Aerospace initiatives of MIT, which changed it's name to Lean Advancement (which seems to not have a functioning web site). Or my favorite The Lean Enterprise - A Management Philosophy at Lockheed Martin.

I wish these thought leaders would stop talking about how things that "could be or should be," and start writing about their actual experience in a case study they have personally participated in, and how those actual cases could be transferred to other domains and context. By this I mean actually doing the heavy lifting of translating those personal experiences into a real project in another domain, then "connecting the dots" between what worked in one domain and how those process can be applied to the new domain.

Past Performance in the specific domain and context in that doman are mandated for any government or large construction procurement.

But I've learned - the hard way again - that those who preach the gospel of agile or lean may not have the past performance another domains to support their claims of universality of their philosophies.

Like I said - It was my mistake.

 

Connecting Risk and the WBS

When risk management is mentioned as an activity in project management, it is not always placed in a proper context, or any context for that matter. Here's a suggested way to "connect the dots" between risk and core element of the project - the Work Breakdown Structure (WBS).

1. The Earned Value schedule elements - are the emasures of physical percent compete for each "package of work," defined in a way that actually measures Physical Percent Complete?
2. The Earned Value cost elements - have you defined the "elements of cost," their repaltionships to the deliverables?
3. The risk management process itself - do you have a risk management processes? More importantly, do you apply it?
4. The Critical Path - do you have one of these? Do you have a probabilistic version?
5. Techncial Performance Measures - how do you how what progress looks like in units meaningful to the stakeholder - both buyer and seller.
6. Process management - do you have processes that add value to the project?
7. Staffing issues - where are all the people you need?
8. Overtime usage - are you working them too hard? What does too hard mean?
9. Independent Estimate At Completion - do you have any idea of what this will cost when you're done. Our even knowing when you're going to be done?

Agile Analogies

I'm not a big basketball fan. I don't know that much about the game. I was a volleyball player in college and as a young adult (30's). At breakfast today (Sunday), while working a DoD program for the past 4 months in prep for the IBR, was highlights of basketball. One of my team does know basketball and I asked how do the players coordinate that drive, pass and dunk play? Do they practice that?

The answer was perfect...

The play evolves from skill and experience of the players. They "know" where the other people will be during the emerging play. They have situational awareness, skill, and deep experience to "know" what to do next.

The agile processes that are successful have players that "know" what to do from skill and experience.

Microsoft Project Has Stopped Working

Want to know why Microsoft Project is both loved and loathed in our business - aerospace and defense?

Under heavy load, hours of working with large files, and lots of opens, closes, usage of all the fields, all the narratives in Outline Codes, loads on macros, and uploading and downloading from the EV Engine, MSP starts to wobble and eventually drives into the ditch. One our of 42 of the assigned labor categories - yes, we have resource loaded IMS's as any credible schedule does - MSP stops on one of the resources for printing to PDF. The PDFs go in the CAM notebooks for the work.

This is common in MSP at the level we use. It's frustrating, especially on a Sunday before the IBR, where flag officers are attending.

In the end, we use MSP as a word processor, since it can't do Earned Value - no accounting calendar, no real month end close process, no EV types, pretty much lame EV. It's got lots of truly bone headed features - like when you select a column, then do a CONTROL F to find something in that column, it searches on the last column you used, no the !@#$'ing column you're on. Wouldn't you think the Search feature would see that you're on that column. Or another favorite, the comment field in the Outline Code has a 255 character limit. So much for including the WBS dictionary in the IMS. View control, conditional colors (not).

Another bone head feature - the Print function does not allow you to change the printer except in the FILE PRINT pull down, not the preview, or any other place. Clearly not Windows compliant UI.

I'm convinced MSFT does not actually use this tool to run their business. Unlike Larry Ellison's "eating your own dog food," MSFT doesn't. Same for Dynamics and Visio. If they did, they fix this crap in a month. It's still the tool of choice for 98% of the planet, but man is it lame.

I really wish the MSFT developers could come site with us over the last 4 months trying to build a PMB (Performance Measurement Baseline) for ~$300M worth of Army program using MSP, a time keeping system, and ERP system, and an EV engine - all integrated together. Once MSP 2007 swallows a problem, it can't be repaired in the way 2003 could (at least that I can do). This is a major flaw, cause once you've busted it, it's busted.

EAT YOUR OWN DOG FOOD MICROSOFT

Earned Value Management Training

There are many sources of Earned Value Management training. Some good, some not so good. Here is the training materials from Department of Energy, that is one of the better resources.

• Module 1: Introduction to Earned Value Management
• Module 2: Work Breakdown Structure
• Module 3: Project Scheduling
• Module 4: Budgeting
• Module 5: EVMS Concepts and Methods
• Module 6: Metrics, Performance Measuring and Forecasting
• Module 7: Integrated Baseline Review and Change Control
• Module 8: Reporting

Each of these modules provides an indepth view of EVM from a practical point of view. When someone speaking about EV, its applicability in a domain, its application to specific projects, and the like - take care to vet the source of the advice, the domain and context where that advice is applicable, and the credentials of the adviser.

Quote of the Day

The task of estimating costs, planning and scheduling men and materials and then controlling these resources to maximize production output, while minimizing costs, can be a very difficult job.

These efforts become more complex with the increase in the size of the shipyard organization and the scope of the yard operations. Modern-day shipbuilding poses no mean management challenge.

A very basic problem has been job progress visibility, or lack thereof.

Without it, management must operate blindly. Cause and effect relationships become blurred in the midst of daily shipyard production problems and drain away the capacity to direct production effectively and economically.

Knowing precisely, and in a timely manner, the exact status of men and material, a responsible management can rectify problems quickly before they become critical.

From a brochure for a ship building ERP system.

The Point Here is Simple

Cost, schedule, risk, and technical performance planning is the start for a credible project management process. If you don't have these details, you can't possibly have a credible understanding of where you are going, when you are going to arrive, what the difficulties are going to be along the way, and when you arrive how will you recognize that you've arrived.

Failure of Projects

There is lots of discussion of the number of projects that fail. Standish has their "infamous" report with all it's faulty statistics. But there is a better set of data in a broader domain. "The core problem of project failure," by T. Perkins., 2006, The Journal of Defense Software Engineering. Vol. 3, 11, p. 17. June 2006.

Of 155 failed software projects, Perkins tells us for each of the 155 project

1. In 115 project managers did not know what to do
   • Of those 115, 110 had not received the proper training
   • 105 project managers did not have the proper experience
2. 120 project management overlooked the need to implement a a project management principle
   • Of those, 110 did not properly their knowledge
3. 125 allows constraints to be imposed from higher levels that prevented them doing what they know they should have done.
   • Of those, 110 did not properly their knowledge
4. 130 did not believe formal project management principle added any value.
5. 135 believed that project management were flawed.
6. 140 thought the Project Manager's goal was something other than the success of the project.
7. 145 said policies and procedures prevented them from doing what they knew they should be doing.
8. 150 said statutes prevented them from doing what they knew they should do.

Notice a trend here. It's the project management skill, experience, processes, and support that is a root cause of project failure. Others have stated other causes, like requirements, stakeholders, technology, and other topics.

These are second order items. Notice that each of the 8 areas include those items.