Herding Cats

The Biggest Project Management Job in the World

There are several jobs titled "The Biggest Project/Program Management Job in the World"

• Admiral Craig Steidle - Associate Administrator, Exploration Systems Mission Directorate. Joint Strike Fighter Program Manager. The Exploration Mission Directorate Program Management Handbook is a "bible" for large technical integration efforts.
• Skip Hatfield - Orion Program Manager. Attending the win party for Orion, my wife asked "who's that guy in the NASA Polo shirt?" "He's the Program Manager for $7B worth of design and development work." "Oh, he looks like an engineering geek." "He is, but he's still the Program Manager for $7B worth of work and our customer."
• Cleon Lacefield - Program Manager, Orion, Lockheed Martin. I worked for Cleon (one level removed) on the Orion proposal. Awesome Program Manager, with full understanding of the technology and mastery of the people doing the work.
• Rocky Flats Environmental Technology Site had several Program Managers. Nancy Tuor was the last. The concept of closing a nuclear weapons plant on time, on budget was unheard of. Kaiser-Hill did it ahead of schedule and under budget. I payed a minor role as one of many program managers.

These type of Program Managers are typical in the space and defense business. But I came across a person:

• Paul Ritche - Head Global Project Management Operations at SAP. I don't know Paul, but I know that managing SAP projects is tough and not for the faint of heart. Paul's also a PMP.

Paul is the type of project manager we need to model in the enterprise domain.

More Silly Season

"As democracy is perfected, the office of president represents, more and more closely, the inner soul of the people. On some great and glorious day the plain  folks of the land will reach their heart's desire at last and the White House will be adorned by a downright moron" – H. L. Mencken (1880 - 1956)

Agile Thinkers?

    I was flatered and a bit taken aback when Clarke Ching asked if I'd like to be interviewed for his Agile Thinkers blog. The subtitle for that Blog is "great thinkers in the Agile community." Well that's news to me. I do "think" a lot about a lot of things. Being agile might be one of them. Figuring out how to convey the simplicity of using Earned Value is another. How to apply our Deliverables Based Planning method is the may one, since I'm the Practice Director for that portion of our business.
    I wrote responses to Clarke fine questions and made up one of my own. Reading them tonight, after having discovered the posts, I think my impluses are pretty close to what I feel with some distance between writing and reading.
    See what you think
    Question 1
    Question 2
    Question 3
    Question 4
    The notion of an interview is actually brillant on Clarke's part - good work and thanks for opportunity is be in fine company of some I know and have met - Alistair, Jerry, Johanna, Tom, and others I've discovered have much to say.

Agile does Project Management for Real

Check out Joel's article on scheduling. We got:

• 100% completion criteria, just like IMP/IMS and Deliverable Based Planning,
• Measures of Physical Percent Complete, just ANS-748B Earned Value
• Decomposition of the work, just like MIL-STD 881A
• Tracking of effort versus value, just like ANSI-748B BCWP
• Estimating future performance from past performance, just like DID-81650
• Simple descriptions of work, just like Work Package, Planning Packages and Control Account programmatic architecture
• Active project management, just like Program Planning and Controls IMP/IMS processes in every aerospace and defense contractor
• Managing scope, just like every Change Control process found in aerospace and defense

Three Core Processes of Project Management

    In a recent response, Lalit suggested the notion of "resource management," somehow demeans the human aspects of project management. That possibly PM should go to a Human behavior class before the PMP study class. While the "human element" is a critically important aspect of project management, it is one of three core areas
    The authors of Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation, Aaron Shenhar and Dov Dvir describes three "Views" of project management:

1. Operational / Process - What work must be done to deliver the business value from the project? What is the sequence for this work? What risks will cause the project to be in jeopardy and what actions are needed to mitigate or retire these risks?
2. Team / Leadership - what organizational elements are needed to deliver this value? What skills and experiences must be provided by these organizational elements? What leadership and management processes must be in place to successfully apply these skills and experience?
3. Strategic / Business - how is this project connected to the business strategy? Can these connections be defined in some unit of measure meaningful to the stakeholders?

    In these "views" Human Resources are one of many aspects of managing projects. To focus on any one of the aspects to the exclusion of others would be poor project management. This is the challenge for project managers, project management methods, and the training and mentoring of project managers.

How to engage on all three views at the same time with equal skill, experience and appropriate beneficial outcomes

    Without the ability to engage in all three views, the project is in jeopardy missing the goal - deliver value to the CUSTOMER. If along the way the project participants are "self actualized" in some way, that's good them and possibly good for the project. But the inverse is not acceptable.

The participants are self actualized and the project fails.

    There is no evidence I can find that self actualized project participants that do not EQUALLY engage in the two other "Views," deliver successful projects. Since I hold a somewhat  narrow point of view about the processes of project management - Number 1 and Number 3 are my primary focus. I understand Number 2 is equally important. But it's not a focus for me. I've leave that to those better equipped to deal with the "soft" side of Project Management.

    It's not a failing so much, as a recognition of strength. This leads me to the defense and space domain, where Number 2 is 3rd on the list, with Number 1 being 1st and Number 3 having been defined by the Department of Defense, NASA, or other government agencies.

    The real rub comes though, when some thought leaders fail to acknowledge one or more of the three Views are not present or are somehow "wrong" in their world view. That's usually when the conversation arond Project Management goes in the ditch.

Useful Project Management Quotes

Many times I'm sitting in a meeting or driving along thinking about projects I'm working on, or even better riding my bike far away from home and a thought comes to me about how to wrap up a complex concept in a simple phrase.
Here are some that have come to the surface lately...

• In theory there is no difference between theory and practice. In practice there is - Yogi Berra. Yogi has lots of PM quotes. But this is one of my favorites. I can''t tell you the number of times I've heard someone speak about how "we could do this," or "we could do that."
• Never Confuse Effort with Results - if you're measuring effort as your progress, you're not measuring the right thing
• Brevity is the Soul of Wit — Lord Polonius to Hamlet. Keeping it simple works for all forms of communication. Just as well for project plans, presentations, and all things related to delivering outcomes from projects. But it must be "simple enough" and not too simple.
• Trying is just a noisy way of saying no progress — Warren Bennis. I hear this all the time. "We'll try to have that server up and running by Tuesday." "I'll try to get that order closed by month end." This goes along with Hope is not a Strategy.
• Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat —Sun Tzu. You need both a Plan and a Schedule. The Plan tells you what  deliverable are needed to produce the needed business or technical capabilities. The Schedule tells you when the work to produce those deliverables needs to be performed.
• Plans are nothing; planning is everything — Dwight D. Eisenhower. This is a famous, often misused and mis-quoted quote. It is not a excuse for not planning. It is a direct order to plan. The Plan is the Strategy for Successfully delivering the value from a project. Plans changes. That's the role of a Plan. Anyone suggesting otherwise is not a Project Manager.
• When planning for a year, plant corn. When planning for a decade, plant trees. When planning for life, train and educate people — Chinese Proverb. Know your planning horizon.
• It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be — Isaac Asimov. "What is Plan B?"
• The facts are always friendly, every bit of evidence one can acquire, in any area, leads one that much closer to what is true  —Carl Rogers. Measure progress ONLY with measures of Physical Percent Complete. The passage or time, the consumption of resources, and the estimates of progress from the provides of progress are NEVER credible assessments.

A Little Book of f-Laws

Cleaning up my desktop tonight, I came across the "13 Common Sins of Management," by Russell Ackoff and Herbert Addison in a PDF file I received from somewhere unknown.

1. The lower the rank of managers, the more they know about fewer things. The higher the rank of managers, the less they know about many things.
2. Managers who don’t know how to measure what they want settle for wanting what they can measure.
3. There is nothing that a manager wants done that educated subordinates cannot undo.
4. The less sure managers are of their opinions, the more vigorously they defend them.
5. The more time managers spend trying to get rid of what they don’t want, the less likely they are to get what they do want.
6. A bureaucrat is one who has the power to say ‘no’ but none to say ‘yes’
7. The legibility of a male manager’s handwriting is in inverse proportion to his seniority.
8. The less important an issue is, the more time managers spend discussing it.
9. The more important the problem a manager asks consultants for help on, the less useful and more costly their solutions are likely to be.
10. Managers cannot learn from doing things right, only from doing them wrong.
11. The amount of irrationality that executives attribute to others is directly proportional to their own.

The collection of 80 Laws is found in Management f-Laws: How Organizations Really Work, Russell L. Ackoff and Herbert J. Addison, http://triarchypress.co.uk/.

More Thoughts on Risk Management

I'm preparing a paper for the 2009 NASA PM Challenge conference. Walter Majerowicz is a constant contributor to the professional of project and program management. I finally met Walt at the PMI College of Scheduling conference this year.
In a previous PMChallenge presentation, Walter mentions several sources to project and program risk that are worth restating.

• Poor or unrealistic activity duration estimates - the "art" of estimating is largely overrated. Using probabilistic estimating techniques where the upper and lower bounds of the cost or duration is the starting point. With these estimates, classified is a geometric expansion series, the sensitivity of the cost and schedule model can be exposed. The traditional estimating process of asking for "high" and "low" estimates has been to shown to be seriously flawed.
• Deterministic / single point activity durations in logic network not based on expected value of 3-point estimates - "no single point estimate can be correct," is the starting point for programmatic risk reduction. All cost and schedule values are random variables. Without understanding the statistics of these random variables, the schedule and cost models will be wrong.
• Not capturing 100% of total work scope in schedule - no side bar work, not under the covers work, no work can be performed on the project that is not scheduled to be performed.
• Inadequate or incorrect resource planning - the notion that people will sort out the sequencing of the work for themselves is nonsense. A resource assignment plan at some level of granularity is needed.
• Inadequate or poor project logic - in what order the work is to be performed is the basis of utilizing resources and producing increasing value. This sequence is held in the Schedule.
• Insufficient schedule reserve - with cost and duration values being random variables, schedule and cost "margin" is needed. How much margin needs to be determined by some analytical means. Guessing and using some standard (20 days per year) usually is wrong. Knowing where to put the margin is the next step. Solving this problem is the role of Monte Carlo Simulation.
• Multiple convergence paths / merge bias - this is a subtle but critical issue. Parallel work tends to drive the delivery date later. This is counter intuitive but it is a fact. Look for the term "merge bias" to read about the theory.
• Overuse of directed constraints that override true schedule logic - a good schedule has all the tasks marked "AS SOON AS POSSIBLE." All other constraints need to be "real." The START NO EARLIER THAN and FINISH NO LATER THAN approaches are the kiss of death for analyzing the impacts of schedule slippage on the outcome
• Unrealistic schedule baseline – if the schedule is not credible to begin with, it never gets better
• Poor performance – late starts mean late finishes. No completing on time – as planned – simply pushes all the work to the right. The developers (or any project content provider) MUST start on time in order to finish on time. Late finishes usually mean late starts for the next collection of tasks. You can't make this up by working harder. That just spends more money.
• Uncertainty in work scope (e.g. new design, advanced technology, new processes) – adding more variance to the schedule cannot improve its credibility.
• Inexperienced project management – nothing succeeds like success. You’ve got to start somewhere, so start as a deputy to a good project or program manager and learn the ropes from her success.
• Improper or poor change control – the baseline is just that. Making changes in the absence of an impact analysis is nonsense. “Emergent” anything needs to go through a change control process. Simple, informal, formal – it doesn’t matter in the end if the right questions are asked and answered.
• Complex organizational interfaces – the more touch points the more places things go wrong. Managing the interfaces is a Systems Engineering discipline. Learn from the profession of Systems Engineering how to do this right.

It's the Silly Season - Again

    Unlike the British, we drag out the national elections until everyone (mostly) is simply worn out. The result seems to be that we become susceptible to professional messaging. Advertising works, otherwise they wouldn't spend money on it.
    Along the way the hype and hyperbole continue to rise. To provide some actual information in this "silly season" I've come to rely on "fact check sites."

• FactCheck.Org
• PoltiiFact.org
• Washington Post Fact Checker
• OpenSecrets.org
• ProCon.org

Proceed at your own risk, many "facts" don't align with the messaged being broadcast - on both sides

Risk Management is How Adults Manage Projects

If your project management method does not start and end with Risk Management, you're whistling in the dark, hoping things will work out.

• Hope is not a strategy - hoping to get things done on time, on budget, on specification is not the same as having a plan to get things done. Having the plan does not mean it will happen. But not having a plan assures is will not happen
• All point estimates are likely wrong - cost and durations are random numbers drawn from an underlying probability distribution
• Follow a risk management processes - the DoD process is probably the best. There are others.
• The connection between cost, schedule and technical performance is inseparable - there is a lot of noise about "breaking the Iron Triangle" of project management. It is just that "noise." These three independent variables are inseparable. These re three of the irreducible elements of project management
• Communicating all this information is not an option - having a risk management plan (RMP), a risk communication plan (RCP) and all the other artifacts of risk management is important. But most important is showing the risk, their mitigations and retirement in the schedule

In the end is the risk mitigations or risk retirements are not in the schedule, with dependencies, resources, and funding - then when the risk become an issue - you will have already failed.

The Best Risk Management Sites on the Web

• Risk Doctor
• DoD Risk Management
• PMI Risk SIG
• Mitre Risk Management
• APM Risk Management SIG
• UK Institute of Risk Management
• OGC Guide to the Management of Risk