Herding Cats

Going to the Dark Side

    I'm not a PMP. I'd like to, but I'm not motivated. Besides, I'd have to unlearn several things in order to pass the PMP.
    BUT, there is a PMI-RMP that I've signed up for. And there is the PMI-SP, the Scheduling Professional. Both I could get into. But the Risk Management Certification will be the first. Chapter 11 of PMBOK is about risk management. There are a few flaws in Chapter 11. Multiplying probability of occurrence with outcome to get a risk rank is one problem. The two variables are probability distributions and multiplication is not an operator on an integral equation representing the probability distributon function.
    The second issue is the Department of Defense has a Risk Management Work Flow. PMI has process areas. These areas have a linear relationship and a single feed back loop. The DoD PMBOK version has all the same chapters, but much correct guidanmce in many areas. It's also FREE. DOD PMBOK Chapter 11 has a diagram showing the process flow and has words around how to develop a "risk value" that does not involve doing un-allowed mathematics.
    So I've bought the study guide, reading the PMBOK Chapter 11 again and this time making notes and filled out my application. Maybe by the end of the year I'll be a Certified Risk Manager.

Project Management Impresarios

    I've been watching (and even helping out with advice) on several projects close up in the past weeks. They have "issues" as all projects do. But one thing that strikes me in these cases as well as a side bar discussion with a project management impresario is there is a lot of professional amateurs out there. Those claiming to have "magic beans," when in fact the beans are just beans.
    There are some simple questions a project manager should be asking everyday:

1. When will this project be done? And what's the confidence interval on that date?
2. How much will it cost? And what's the confidence interval on that value?
3. Do we all agree on what "done" looks like when we get there? And what are the units of measure of "done?"
4. What are the risks to getting done on time and on schedule?
5. How will we mitigate or retire these risks so we can get "done?" And do these activities have budget and schedule?

Now when that project management impresario starts talking psycho-babble about the theory of how projects "should" work in his "best selling" book - self actualized staff, acknowledging your blindness and topics best reserved for the marriage therapist office, there never seems to be a discussion about the 5 items above as prerequisites to a project's success?

1. We're self actualized - but late and over budget
2. We acknowledge the things we don't know about - but are late and over budget
3. We have great trust in each other and our vendors - but are late and over budget

    Not being late and over budget is necessary but not sufficient for project success. But the inverse makes no sense.  It's not a reciprocal relationship.
    Project Management is not Business Management.
    Project Management is not Personnel Management.
    Project Management is not ...

    Project Management is about managing projects. Yes there are people involved and people must be considered. But this focus on "people" cannot add value if we're late and over budget.
    Both are needed, but which one is more important? I have my choice. Others have theirs. The customer - from all my limited experience in the past 30 years - has been asking the 5 questions above before they ask about self-actualization and self-fulfillment. Just a data point, that's all.

If you can't be famous, at least stand by someone famous

The Aerospace and Defense track of the Denver PMI Symposium had two special speakers. The partner of our firm (and my boss) and I had the privilege of standing next to Gene Krantz and Jim Lovell for a photo op. Not because of us, but because of the A&D breakfast where they spoke to a smaller audience before the keynote. Our next Denver PMI Symposium will have Wayne Abba - who led the Earned Value efforts at DoD, Paul Solomon - retired EV lead at Northrup Grumman (B2), Steve Garfein - retired Apache Helicopter Program Manager and Enterprise Portfolio Management expert, plus some local talent and the very popular After Burner training team, which presents a fabulous session on "getting things done in the presence of chaos" with their Flawless Execution model.

The quote of Krantz "failure is not an option," was trumped by Lovell with "success is our only option." The discussion revolved around adapting to emerging situations while staying true to the Plan - get everyone home alive. Adaption within Rigor - what a concept. 

Scrum and CMMI

Here's a recent report on assessing Scrum inside a CMMI framework

http://www.sei.cmu.edu/cmmi/adoption/pdf/Canditt08.pdf

This was an embedded control system domain with high innovation needs, 40 developers all at one location. As well the assessed project was a sub-project of a larger project.

You mileage may vary.

SEI Membership

    The Software Engineering Institute (www.sei.cmu.edu) is a source of the Capability Maturity Model Integrated (CMMI). CMMI is the basis of a process improvement framework used with success in many domains. There are other Matrity Models, including OGC's Project, Program, Portfolio Management Maturity Model (P3M3).
    SEI used to have a free membership. Now it costs. But there is still a free membership for veterans. You need to go to LinkedIn, look for the SEI Group, sign up. You'll get a message back - "this is a members only group," with a link to the applciation.
    Fill out the application, attach your DD214 and fax or mail it in. You'll receive a very nice email with the account information. Thanks to a work collegue who is a Marine - Semper Fi Mac - for pointing this out to us old guys.

Project Performance Management

A colleague pointed me to May 2007 presentation of a candid review of the F-35 program given at a Support Equipment Conference. Some items include:

• First Pass Success never happens – Not reserving schedule time for delays, failures and other negative events create an overly optimistic and thus, unrealistic, program schedule. Determining how much schedule margin is part of the continuous analysis of the dynamics of the schedule. Monte Carlo Simulations is the preferred approach to this margin analysis. The Fix: Plan on repairing the plan as the program progresses as part of the "natural" evolution of understanding. Use Rolling Waves (a small number) to take corrective actions.
  
• Failure Of Current Management Systems To Predict Performance – program metrics and feedback systems that do not predict problems until it was too late do not server any purpose. Integrating programmatic and technical risk management with the Master Schedule is required to connect cost, schedule, and technical performance. The Fix: To Complete Performance Index (TCPI), Indepednetn Estimate to Complete (IEAC) and of course Monte Carlo cost and scehdule forecasts are in the tool bag for predicting performance. A PMI Global Congress paper this week provided other means of forecasting future with delays, reject rates, and other adjustments for reality.
• Poor Supplier / Team Performance – the prime contractor didn’t make the level of progress to stay on track.  No visibility was present because of multiple re-baselines that obscured their true performance and allowed requirements creep and thus scope growth. The Fix: Integrated Product Team (IPT) means what is says.
• Insufficient / Ineffective Intervention – By the time prime contractor realized how badly off course they were, they were in a position we call "too little and too late." The Fix: Knowing at all times how long you are willing to wait before you find out you're late.
• Inadequate Staffing / Budgets – the prime contractor did not plan for program complications and thus did not plan for the right resources at the right time. The Fix: Managing resource assignments is a full time job - period. And this job is not assigned to HR. It is a program management job.
• Inadequate On-Site Assessments - 1st & 2nd Tier Suppliers – the prime did not employ a systematic supplier surveillance process to assure supplier truly making progress. This missing element creates the basis for over runs with not method of measuring physical percent complete. The Fix: Integrtaed Product Team means integrated. There is no level where knowledge abotu performance becomes uninteresting.
• Near-Term Focus Obstructs Downstream Impacts – the prime contractor had too many cycles dealing at the Rolling Wave level and denying the reality of a larger program slip. The Fix: Both near term and long term perfomance management is required. There is no simple way out of this.
  
• No Defensible Integrated Master Schedule (IMS) – lack of an integrated master schedule masked the deficiencies of the total program’s performance. With a measure of physical percent complete using cost, schedule, and technical performance - only the passage of time and consumption of resources can be measured. The Fix: The units of measure of credible must be defined up front. Then tested every reporting period.
• Slow To Recognize Impacts To Missed Milestones – failure to integrate schedulers directly into functional teams made forward predictions of meetings milestones impossible. The Fix: As General Powell says, "bad news is not wine, it does not get better with age."
• Earned Value Of Work Performed Not Accurately Reflected In Financial Reporting - need we say any more. The Fix: There is simply no excuse for not applying EV to the fullest extent possible. In the absence of EV you're driving in the rear view mirror at best. At worst you driving blind. Never ever let a persoan opinion be the measure of progress.
  

This issues are common in many programs in the commercial world as well. Dealing with them takes discipline, leadership, and application of known and proven methods.

PMI Global Congress - Software and Construction Closer Than WeThink

David Anderson once vehemently argued (as only David can) that software development and construction have nothing in common regarding project management. Too bad he was not sitting in the presentation today at the PMI Global Congress here in Denver.
    There was a research paper presented by two professors from Boston College about using Earned Value to manage schedule forecasts. EV is a cost forecasting tool that converts dollars to time to produce the Schedule Performance Index (SPI). There are know problems with this approach as the project nears completion. At the end SPI always equals 1.0.
    But that's not the interesting thing. The research shows that when the SPI and CPI are plotted as a cumulative curve versus an instantaneous curve, the graphs of construction projects and the grpahs of software projects are indistinguishable. This implies the undrlying behaviours of the project's performance variables are indistinguishable.

• Cost absorption rates
• Rework
• Feature postponement
• Delays resulting from feature postponement
• Labor efficiency

are some of the independent variables. From the point of view of project controls  - software and construction have similar behaviors.
    Maybe knee jerk reactions to suggestions there are similarities are appropriate. Maybe not.

PMI Global Congress 2008 – Day 1

    The PMI Global Congress is being held here in Denver today (Sunday), Monday and Tuesday. The key note speaker was General Colin Powell. A nice survey of his life and how project management was related to what he did. From project managing a dozen infantry to managing 30,000 infantry. It's all project management. Several thousand people in attendance this afternoon.
    Tomorrow starts the real thing, with many session catching my eye. For those wondering what happens at something this, it's straight forward. Lots of presentations on a variety of topics - some interesting, some important, some no so important and not so interesting.
   One of the critical concepts from the Powell talk is "what are the greatest focus for today's politics?"

1. Wealth creation - with ownership of the means of production (stock) and the wealth created by those production sources, the economic discussion becomes part of the political discussion.
2. Energy - without reliable energy, production cannot be sustained
3. Environmental protection - if we kill the planet while making money, that's not sustainable
4. Education - if our internal resources are being replaced by outside resources, that's not sustainable

Creating these sustainable processes is a project management problem, along with political, social, etc.

Why is it called Project Management?

    I'm filling in for a Project Manager from our firm for several weeks. The job is downtown. I normally drive around downtown when going going to our office in the suburbs. Downtown is like any other major metro downtown. Lots of nice buildings, some a 100 years old, some new, and some being constructed. The parking lot is next to a new construction site for some kind of condo complex with commercial offices. 40 stories or so.
    They're on the 10 floor, by my count. Lots of hammering, cranes moving, concrete being pumped and workman in hard hats all scurrying around the site. Two trailers share the parking lot, with the construction management companies logo on the side. Inside are foremen and of course the project managers. I'm filling in for a Share Point based enterprise content management project for an Oil & Gas company. Several dozen project members, a couple million dollars of labor and hardware. Not a huge project, but not a small one either.
    What struck me this morning was the echo of an email conversation I've been having with a "project management" consultant. This person conjecture is project management fails for esoteric reasons around the participants not understanding their personal goals, not possessing sufficient self-actualization to be able to contribute to the success of the project. All that "Blind Man and the Elephant" approach to life.
    While starting in the parking lot looking up at the high rise be "assembled on site," it dawned on me the "project management consultant" has got a much different view of the world regarding project management than I do. Assembling parts into products - in this case the high rise - is what we do. Assembling Share Point Web Parts, that talk to Oracle and the myriad of other legacy systems is what we do. Assembling software into avionics systems that fly on flying machines. Stuff like that.
    It dawned on me, while listening to the "project management consultant," that there is a critically missing concept in the pop-psychology approach to project management.

Good Engineering Prioritizes Boundary Conditions

It's the good engineering that is missing from the conversation. Good engineering guides the assembly of the high rise. The workforce is not "discovering" the steps to laying the floors. Oh of course there are screw ups, changes in the drawings, even changes in the the sequence of work. But the engineering of the building is "good" other wise it would fall down.
    The good engineering of our Share Point based ECM system is laid out up front. The system architecture, the Information Architecture, the Meta Data, the Work Flow processes, the regulatory compliance fulfillment's, all that "engineering" stuff around an IT project. Of course there are screw ups. We're on the 3rd hardware architecture layout and the 2nd set of inter-system interface definitions. The first ones did not scale. But "engineering" - systems engineering, information engineering, cost accounting engineering, are the basis of the boundary conditions.
    In the high rise and on the ECM project, the people know what they are doing. A few of PhD's in library science and are guiding the Information Architecture. A few have deep regulatory compliance experience. All developers are experience Share Point, Oracle, legacy system people. This is an on-going business. No one is confused about their role, what done looks like (ok, they are confused at times, that's what the project plan is for), and certainly they don't come to work looking to be self-actualized.
    So back to my conversation with the "project management consultant." I'm convinced now that pop-psychology has a role in "project work." But not a role in the "management" of projects. That may not make sense, but here's why:

• The people on the high rise have a "plan of the day." They have a measurable goal for moving the building to the next step in its construction. They start the morning - long before I arrived at 8:00AM - with the plan in mind. In fact the plan is in the master schedule for the day.
• The people on our ECM project have a plan of the week. A description of the deliverables for that week. A description of what done looks like. A Deliverables Based Plan.
• When the self-actualization approach overwhelms the deliverables based planning approach, people sit around and gaze at their navels. This is probably a good thing to do in a workshop, conducted outside the project, possibly even outside the business. This is a HR role, not a project management role.

And that's when it dawned on me the problem.
    When we mix execution and delivery with HR we get off track. Fix the HR issues first and outside the project. Worse case when they occur on the project, take them outside the project and fix them. Project work is not the place to repair interpersonal issues with staff.

    Get the right people, in the right seats on the bus (Jim Collins), and execute the project. Especially  since the project is of finite duration. Stop polluting the "management" of the project with the theory of how pop-psychology is the same as project management.

    One final thought about the "blind man and the elephant" paradigm. If the "blind men" could see, they'd see that it is an elephant. Since they can't - and that of course is the basis of the analogy - we really need to consider getting other people to tell us about the elephant, not blind men. Trained, professional project managers, might be a good start.

OK, now everyone back to work

Status Reports

Bas de Baar always has an interesting view of the world. A recent post was about deviant behavior and status reporting. Status reports always seem to be a thorn in the side of many project managers and managers in general. Status reports tend to be "wrong headed" in general. Here's how to fix this and get back to adding value.
    The status report must:

1. Describe in some graphical or simple textual form how the planned work was measured against the completed work. Earned Value is one simple tool. A graph of BCWS versus BCWP is the simplest way. Agilest would have "burn down" charts. But these do not show the "value" of the delivered items, just that they are delivered.
2. Some graphical means of showing a color status for the work streams. RED, YELLOW, GREEN is a good one. By work streams I mean the obvious deliverables from the project. If something is YELLOW or RED, there must be a plan to "get to GREEN."
3. The report must show the risks, mitigations, and retirement of risk for all the items that threaten the success of the project.
4. The report must do this on a single 8 1/2 by 11 piece of paper.

Now doing this can take several forms, but each form MUST not contain some rambling on narrative about all the gory details of the project. The only way out of "status report tar pit," is really simple:

State before hand what is expected to be delivered in the form of measurable, tangible, assessable outcomes. Deliverables. Then state in the status report that you either produced these deliverables of you didn't. If you didn't when will you? If you're having troubles delivering, what will you do to remove this trouble. How much will all this new work cost?

This is the basis of Deliverables Based Planning.

Tell what you're going to deliver. Tell that you delivered it. If not, tell me when you will deliver it.

That's it. It's that simple. It's done every two weeks on multi-billion $ programs.

Managing Projects as a Profession

    In the previous post I mentioned Paul Ritchie. Paul works for SAP and is Head Global Project Management. I came to Paul's site through a reference. A quick read put him on the list. But now that I've started reading more of Paul's materials, my view has changed.
    I rarely suggest that someone take a deep dive into a topic in the way I'm suggesting you do with Paul's Blog. This is not one of those self serving endorsements. Paul's Blog is a source of professional grade project management advice.
    That's all I can say. A new found voice of reason, experience, and practical advice in the sea of confusion, conflict, self serving opinions, and over sold methods.