Herding Cats

Quote of the Day

"Things are managed; people are led" - Capt. Grace Hopper

Thanks to John Goodpasture for the reminder. I once had the privilege of "trying" to carry Captin Hopper's bag at the Orange County airport for an ACM meeting she was speaking at. She wouldn't let anyone "give her a hand."

A $75 Solution to PM 2.0?

While responding to a post on Herding Cats, I came across a $75 Outlook based PM tool MissingLink Project Management

So minus the software interpreted process of Andrew's tool, what's the difference here? Outlook is ubiquitous, possibly on every desktop and cell phone in some form. It's highly configurable and like Andrew is fond of saying "as easy as email." It is email.

Quote of the Day

We get brilliant results from average people managing brilliant systems. Our competitors get average results from brilliant people working around broken systems

– Fujio Cho, Chairman Toyota Motors

People are needed. But the "system" is the critical success factor. Tools implement the "system," but tools must support the processes defined by the "system." If not the tools are worthless and the people cannot perform their job, so the whole thing falls apart.

Quote of the Day

A smooth sea never made a skilled mariner - English Proverb

Experience comes from "doing." Doing in difficult situations, with difficult projects builds experience that can be applied to the next project which has difficult situations.

Navy Seals are Project Managers

Dan Ward - a favorite Blogger and Author in Defense AT&L - has a nice little post about the principles of the US Navy Seals.

• Humans are more important than hardware
• Quality is better than quantity
• Special Operations Forces cannot be mass produced

Connection with Project Management and Project Controls

I'm home for awhile from a 9 week stint on a large US Army program, rebaselining the next increment of the contract.

• When we don't have the right people in the right roles all the technology - planning and cost tools - provide little value to our efforts. The Control Account Managers needed to be "really good" to get their Budget Change Requests in shape for baselining within the allocated time period. No tool is going to fix a poorly formed BCR and Work Package flow.
• Having all the numbers line up and the Work Package duration be "credible" in the right sequence to maintain the needed schedule margin and cost margin is a critical success factor. This margin is calculated using Monte Carlo simulation, per DID 81650.
• The core cadre of PP&C specialist is rare these days. The training, experience, and skills needed to pull the Performance Measurement Baseline together does not come from books. It comes for Training, Skills, and Experience. Hand On "doing" of the work of PP&C. Same for being a program manager. Being a Control Account Manager is not learned from a book either.

What this means is:

• Tools are 3rd place every time
• People and Process are synergistic. You have have good people and a poor process and be in the ditch. You can have a good process and poor people and be in the same ditch.
• Good people can over come poor process b y making up their own processes, but that process is not scalable.
• Good people and a good process can over come the lack of tools for awhile, but cannot be sustained.

We us a quote around tools and process.

Did it once, and I'll do it by hand. Do it 2 to 3 times and I'll write a VBA macro. Do it 50 times and I buy a "real" tool

In all case though it starts with competent, trained, skilled, experienced, and most of all motivated people.

All success flows from there.

Quote of the Day - Any New Version of Any Thing

For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled
- Richard P. Feynman

When we hear about the latest "gadget" or "process" that is replacing the current "gadget" or "process," in the project management world, let's stop and ask does this "next new thing" provide new or more informative answers to these questions:

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?

And if so, how does it do this in ways not currently provided by our current "gadgets" or "processes?"

Moving Beyond the Obvious

The amount of "restating the obvious" in project management literature, blogs, and commercial web sites is growing. PMI is part of this as are the numerous commercial sites, mostly aimed at managing IT projects.

I'm preparing an abstract for the upcoming EVM World 2010. My session editor is a principle at a Washington DC consulting firm, specializing in EV and Cost management. The leaders of that firm are household names in the cost analysis and forecasting business fro NASA and DoD.

My editor is very strict in pushing me to move beyond the obvious. My topic of "getting back to GREEN" is a critical activity on every aerospace and defense program we work. If everything was going right, they would not need to hire us. Rarely does everything go right of course.

Don't Restate the Obvious

We all know people skills are needed. We all know we need a plan and a schedule. We all know we must have a risk management plan integrated with the schedule. Blah, blah, blah.

These are all necessary but not sufficient conditions for increasing the Probability of Program Success (PoPS). But these are rarely executed properly.

What's the reason for project's being "off GREEN?" Here's my opinion of the bowels of a large DoD contract where I'm working the re-baselining efforts.

1. We don't think about project management from the system engineering point of view. Program Architecture is equally as important as Technical Architecture. The successful programs have a programmatic process flow that describes how the technical components will increase in maturity, how risk will be retired, and how the program as a "system" will recognize that progress and being made.
2. We are missing the direct accountability for Work Package performance as a group. We have weekly Earned Value, we have weekly and sometimes daily stand ups, we have every tool know to man for communicating, visualizing, testing, developing, and doing anything else to the product we need to do. But they rarely operate as a "system of systems." In the successful programs (that don't need us), all these elements are integrated. Sometimes seamlessly, sometimes the stitches are BIG along the seams. More Frankenstein like than plastic surgeon like.
3. We fail to predefine measures of progress are needed to recognize physical percent complete is being reached. The post hoc assessment of progress is the "kiss of death" for any non-trivial program. "How will I recognize success when it walks through the door?" The plan has to tell me this or I won't recognize it.

With all the tools, people skills, processes, and gadgets, we must perform the activities above if we are ever to move beyond the obvious marketing shatter of project management processes and training.

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.”

̶  Mark Twain

Quote of the Day

It has become appallingly obvious that our technology has exceeded our humanity
̶  Albert Einstein

Reading Materials on the Road

I've been on the road too much in the past 2 months. Between our office here in Denver and two client sites in Phoenix and Albuquerque, I've had time to catch up on reading. Here's some materials that have kept my attention:

• The Essential Exponential: For The Future of Our Planet, Albert A. Bartlett, Center for Science, Mathematics, and Computer Education, University of Colorado, Boulder
• "A Methodology for Project Risk Analysis using Bayesian Belief Networks within a Monte Carlo Simulation Environment," Javier F. Ordonez Arizaga, University of Maryland, 2007.
• "Bayesian Inference for NASA Probabilistic Risk and Reliability Analysis," NASA/SP-2009-569.

Agile in the Product Development Context

Ken Whitaker as a wonderful post at Gantt Head on the use of agile development methods and the compliance with FASB 86.

The notion that agile can be used in the corporate product development environment many times fails to recognize that FASB 86 has impacts on when and how the sunk cost of that product development can be considered a capital expense.

In the non-product world, bounded budget and bounded time result in agile projects having scope as the only variable.

This is called time boxed scheduling.

Quote of the Day

Every profession is a conspiracy against the laity
-George Bernard Shaw

Quote of the Day

Omnis enim, quae a ratione suscipitur de aliqua re institutio, debet a definitione proficisci, ut intellegatur, quid sit id de quo disputetur

M. TVLLI CICERONIS DE OFFICIIS LIBER PRIMVS

Every systematic development of any subject ought to begin with a definition, so that everyone may understand what the discussion is about

Marcus Tullius Cicero (196BC - 36BC), De Officiis, Book 1, Moral Goodness

So why do we start projects in the absence of clear and concise measures of DONE?

The Work Breakdown Structure

• Work: "Sustained physical or mental effort to overcome obstacles and obtain an objective result; a specific product, component, activity, duty, function, or assignment often being a part of a larger undertaking ..."
• Breakdown: "to divide into parts or categories; to separate into simpler substances; to undergo decomposition."
• Structure: "something arranges in a definite pattern of organization"

What does done look like?

Look at the Work Breakdown Structure. This WBS doesn't have to be a formal tree structured representation. But you need to have some representation of the components, the relationships, and a description of the tangible evidence that they are "DONE."

Project Communication

The discussion of project communication, softer skills of working with people and the general "self actualization" of PMs and staff fails to recognize a fundamental principle of projects.

If you don't know where you're going, You'll probably End Up Somewhere Else (from David Campbell's book of the same title)

When we communicate inside and outside the team, what is the basis of that communication. When we write a status report, what are we reporting against? When we brief the customer, stakeholder or other interested parties, what is the baseline against which we are telling them information.

Now the interpersonal issues on projects are no different than interpersonal issues in real life. Confused messages, misunderstandings of intent, missing skills applied in improper ways. All those thinsg of "real life."

But projects - good projects anyway - have one thing different than "real life."

A clear and concise description of the goal, the plan to reach that goal, the measures of progress toward that goal, and a Plan B when trouble is encountered along the way to the goal

If the project doesn't have such a thing - It's called an Integrated Master Plan / Integrated Master Schedule (IMP/IMS), a Performance Measurement Baseline (PMB), and a Risk Management Plan (RMP) where I work - then communication becomes a continuous process of trying to discover why we're doing specific things, who's supposed to be doing them, and when are we supposed to be finished doing them.

In the vernacular of our world - the project is a cluster. So like Campbell says

No Plan, your destination may be a disappointment

The Final Word on Cost (and Schedule) Estimating

This is not really the final word in the sense that there are no more words to be spoken. It's the final word in showing that point estimates are fundamentally useless. The quest to produce a credible estimate for a project's cost and schedule is not solved by serializing with work effort. It is produced by constructing a credible Cost Estimating Relationship (CER) model.

Here's an example taken from training materials in the domain where such things are used everyday.

It speaks for itself...

The Challenge Question to any Lifecycle Mehtod - Serial or Not

How long are you willing to wait before you find out your late? (Or over budget, or your the thing you're building doesn't work as specified?)

That's the question that must be answered by any development life cycle in any project domain, in any product context. Doesn't matter if you're planning a mission to Mars or planning a summer picnic, if you don't have some measure of physical percent complete against the planned physical percent complete, you're late before you start, and probably over budget as well.

The reason serial lifecycles are useful for executives is they bound the exposure. The critical success factor for serial lifecycles is to set the time boundaries appropriate to the work rhythms. To make blanket statements about the appropriateness of one lifecycle over another in the absence of the business, technical, and financial rhythms is to basically say -

"I don't really know what your problem is, but I have a solution for you"

So ask and answer the "waiting" question first, then choose a project lifecycle that "fits" the needs to know that answer.

There are other attributes of lifecycle that cannot be generalized as well:

• Risk reduction
• Product production cost
• Resource utilization and absorption
• Cost of Goods
• Supplier capacity to deliver

Quote of the Day - Thinking In Statistical Language

Statistical thinking will one day be as necessary for efficient citizenship as the ability to read and write.
– H.G. Wells

When we speak of cost and schedule estimates, we must learn to speak of the statistical nature of the activity networks that produce those estimates. When we speak of a probabilistic activity network (a Bayesian network) we must learn to speak in terms of probability.

The first question asked of the network is – “ what is the probability of completing this task by a certain date?”

A second question asked is – “what are the underlying statistics of the activities of the network?”

A final question asked is “what is the inherent uncertainty in these estimates?” In other words – how good is our ability to guess in the presence of a statistical process?

If we don't learn to speak in these terms, we will be disappointed in the outcomes. Our managers will be disappointed in the outcomes. And we'll subject to Johanna's prophecy:

a serial life cycle provides a prediction that’s almost guaranteed to be wrong

and not even know why this is the case.

The Real PM 2.0

Working to determine the Ordinal Risk Ranking (Borda) for a flying machine IMP/IMS for a client. Came across some needed attributes of a collaborative project management environment. For example

• Project Management – Coordinating budgets, personnel, schedule, and products to meet requirements and mitigate risks
• Product Management – Transferring, storing, translating, and configuring within the context of a product breakdown structure that spans all levels of a program
• Process Management – Defining workflows, enabling approvals and concurrence, changing a products status, and notifying participants via e-mail
• Archiving – Aggregating designs, software, and data files into configurations and or compressing collections into files with indices and product descriptions
• Collaboration – Capturing comments, markups, revisions, discussions, and teleconference support
• Searching and Filtering – Finding information via key words, synonyms, and context within indices, product structures, and semantic information models
• Report Generation – Producing tables, spreadsheets, schedules, and diagrams that present data and relationships among people, products, and processes
• Information synthesis – Integrating data from multiple sources, plotting data, creating visualizations, and displaying results via portals and dashboards

When someone speaks of using light weight web tools (Web 2.0), email, twitter, and IM for managing projects, ask if the processes of project management can be supported in that way?

Now most projects don't have 1,000's of requirements. Ops, I forgot about Enterprise class software projects, large construction, organization change, commercial software intensive products, and things like that. OK, most project in the "long tail" paradigm probably have 100's or maybe even dozen's of requirements. Bet you the Google Phone has a 5,00 requirements in the end.

So if the requirements population becomes more than can be handled in an email, then something other that talking to each other through a 128 character pipe and collecting emails to guide the work of distributed teams, then more thought is needed to actually "manage" the project in the absence of any simple and simple minded tools.

Quote of the Day - Approaches to Uncertainty

It is moronic to predict without first establishing an error rate for a prediction and keeping track of one’s past record of accuracy

— Nassim Nicholas Taleb, Fooled By Randomness

Taleb argues people constantly delude themselves because they do not understand probability and are programmed to find reasons for optimism or pessimism where none exist.)

Definition of the Day

Uncertainty: A state of knowledge – measured by probability – represented by aleatory and epistemic elements.

NASA-SP-2009-569, Bayesian Inference for NASA Probabilistic Risk and Reliability Analysis

Managing in the presence of uncertainty is what successful project managers and their project management methods do. Denying there is uncertainty, failing to plan for this uncertainty, and employing tools and processes to identify and manage in the presence of this uncertainty leads to disappoint for all.