Watts Humphrey has died. He was one of the most important names in Software Engineering, along with others emerging out of TRW in the late 70's.
Principles, Practices, and Processes to Increase Probability of Project Success
Watts Humphrey has died. He was one of the most important names in Software Engineering, along with others emerging out of TRW in the late 70's.
There is a cultural approach of waiting till the last minute, the last day, the last week or month to do something. This is a generally BAD idea in principle. In practice it means you're going to be late most of the time. But there is more to this just avoiding work until it is needed. It goes deeper than that. It's like that person who always shows up late for a meeting or rushes through the airport to catch a plane - although I met my wife because of being late for a flight.
If Schedule is King, then the King needs margin
The understanding that "margin" is a rare commodity on every project, we need to take extra effort to acquire some. Without cost and schedule margin, the project is late and over budget before it starts.
The management of "margin" is in the same class as "managing risk." This is how adults manage projects - they manage risk and they manage margin - both cost and schedule.
Margin erosion is the killer of most project success
Let's assume we have schedule margin, but now we need to know how to manage it. The margin management process starts with knowing what the margin "should" be at a point in time, and how much margin we have "burned" at that same point in time. A simple picture of this margin erosion is show by the "burn down chart." The units of measure here are days of "margin" in along the critical path. If the critical path is defined in the naive way most project management book do - the path with zero (0) slack, then you've got a "zero slack" schedule and you're late before you start. The schedule MUST have margin. The critical path is the network path with the LEAST margin (slack on the foreword pass).
Here's the picture used in the domain we work. This picture is reported in the Monthly Management Review (MMR). Float and Margin are used interchangablily here.
What is the Motivation Here?
Constructing a credible Integrated Master Schedule (IMS) requires that sufficient schedule margin be placed at locations in the schedule needed to protect key deliverables. This margin can be selected using company policies. 20 days per year is a typical value. This margin can be selected from “best engineering estimates” from past performance.
A better approach is to use a Monte Carlo simulation tool to assess the needed schedule margin based on a “zero slack” Integrated Master Schedule (IMS) and the known or modeled variances of task durations. This margin analysis starts with the construction of a “best estimate” IMS. Program Events, Significant Accomplishments, Accomplishment Criteria, and their supporting work activities are arranged in a “best path” network.
While there is likely “slack” in some of the activities, a Critical Path exists through this network to each Key Deliverable. This network of activities must show how each deliverable will arrive on or before the contractual need date. This “best path” and the associated Critical Path is the Deterministic Schedule. This is the starting point for the Monte Carlo analysis of the needed schedule margin. Assigning a duration variance for each class of activity, a Monte Carlo model can show the confidence of meeting each contractual delivery date.
This model should show if the probabilistic delivery date occurs on or before the deterministic date with an 80% or greater percentage of the time. With the needed margin for each deliverable indicated by the Monte Carlo simulation, the network is referred to as the Probabilistic Schedule. With the schedule margin inserted in front of each deliverable it may be that the Deterministic schedule cannot be the basis of the Probabilistic schedule. A cycle of rearranging the Deterministic schedule to allow the needed margin is the next step.
The final result is a baselined Deterministic schedule submitted with the proposal – the foundation of the award and the starting point for the Integrated Baseline Review (IBR). This schedule contains the needed schedule margin, revealed through the Monte Carlo simulation, and the assignment of margin tasks to protect key deliverables. As the program proceeds, this schedule margin is managed through a “margin burn down” process. Assessing the use of this margin for the remaining work becomes part of the monthly program performance report.
Here's some past posts on the mechanics of this topic
Risk Management is Project Management for Adults
This quote comes from Tim Lister, in an article titled Risk Management During Requirements. With this in mind what are risks during all phases of the project. There are a set of Risk Taxonomies at Mitre's System Engineering Program Office site.
This can help guide you in the development of a risk management strategy. There is a "community of practice" (CoP) for risk at the Department of Defense (DoD).
Derek Huether has a post at The State of Agile that crystalizes the discussion of Agile Projecy Management (at least for me).
I surprisingly discovered that customers really didn’t care how I managed the project, as long as they got what they wanted, when they wanted it, at the price they agreed to.
This is a completly logical approach to project management and the use of a method (any method) to mangaginf other peoples money.
But what if the customer DOES care about how the project is managed? Now what? Care is needed to seeprate the argument. In the world where the customer does care about the method, the customer getting what she wanted AND staying on schedule and budget, AND knowing how the project is going weekly and for sure monthly in units of measure meanigful to the customer just may require folliowing a processes.
Now - once again - PMBOK is NOT a method or a process - no matter how many times some try to paint is as one. And things like PMBOK provide guidance to what activities need to be performed somewhere in the process.
So keep this in mind when you hear "the customer doesn't care how I manage the project, as long as they get what they want." Really? How big - or small - does the project have to be for this to be the case? What business or technical domain has to be present for this tp be the case?
Latley I've had success with our programs of focusing on simple and concise questions. This moves the conversation for all the handwaving and technical solutions back us to the core issues of success.
These 5+1 questions need to answered with a credible set of artifacts that show that the project team actually understands whatr DONE looks like.
If you can not answer these in the afferimative, then the project is in trouble before you start.
When there is a discussion of Risk, there are four Risk Handling opportunities identified in nearly ever handbook or paper.
But there is rarely advice on when or how to apply which risk handling strategy to the risk. Here they are from a recent program:
The most common mistake with briefing memos and point papers to a four star is not to think who it's going to, and to over explain. With four stars comes a certain amount of baseline knowledge. - Commander, The Naval Institute Guide to Naval Writing.
Project Management is a VERB. Project Managers "manage" projects. No matter what anyone tries to tell us, projects don't manage themselves. There are many styles of project management. Even some where the role of the project manager is distributed - self directed teams for example. But in the end projects are human activities that require some form of bounded guidance.
Along the way there are many questions that needed to be answered. Here a short list.
Each answer can be a document (and is a document on any non-trivial project). The contents of the answer can vary depending on the complexity of the project. From some notes on the White Board to 100's of pages of detailed narrative and diagrams, to a multi-million dollar ERP system containing the data for the program.
But in the end if you don't have some grip on the answer - in a way that can be produced when someone asks the question in the right column with some artifact in the left column, you're headed for the ditch and may not even know it.
So when we hear about all the failures of projects, especially in IT, let's ask of those failed projects had answers to these questions before concluding that the project management approach was flawed and needs to be replaced with an even more flawed project management approach.
Managing successful projects and programs depends on knowing what DONE looks like. One of the views of DONE is the Work Breakdown Structure (WBS). The WBS describes the products or services delivered by the project and the processes that produce those products or services. These process are NOT things like "design," "test," "code." They are the manufacturing, fabrication, testing and evaluation processes. Many outside of the MIK-HDBK-881A work confuse (sometimes intentionally, sometimes just to be different) the differences between a functional breakdown structure with the WBS. There is only ONE definition of the WBS that worth anything and that is the MIL-HDBK-881a description. All others, including the PMI advice is derived and should be considered a secondary source.
As well, there are domains, where the WBS - a good WBS - is seen as an option. This "optional" approach is coming to an end. Standardization of Work Breakdown Structures to Support Acquisition Management, will change the 881 Handbook to 881 Military Standard and make the development of a "good" WBS mandatory for all programs.
Many in IT project management business woudl be well served to learn how to build a WBS and use it to describe DONE. That way when DONE arrives it will be recognized.
On a recent visit to a client in Seattle, there was an article in The Seattle Times, on the forn page about the current troubles at Boeing with the 787. The CEO of Commercial Airplanes had a wonderful quote.
"There are certain elements we need to gain control of."
A wonderful understatement of the problems with the 787.I remember a very vocal voice in the Lean community describing all the attributes of the 787 as a "lean" approach to flying from point to point, which of course was nonsense in itself since all airline routes always go point-to-point by definition and the whole concept of flying on LUV (Southwest) the example used for P-t-P but stopping in 3 locations on my way from Denver to Alabama.
Later in the article was another great PR written quote. The Rolls-Royce engines that will power most of the initial 787's are having a spot of trouble as the Brits would say.
The ground test conducted at the Rolls-Royce facility in Derby, England (I've been there selling triple redundant control system in the days with RB-211's powered gas compressor in the North Sea), in August resulted in an "un contained" engine failure. That means pieces of the engine's inards broke apart and escaped the casing around the power plant, a potentially catastrophic event if it were to occur in flight.
Another wonderful understatement. Yea that would be BAD. So is the notion that "certain elements need to be gained control of."
The complex issues of building commercial airplanes is reflected in military aircraft as well. For example the de-certification of Lockheed Martin's F-35 program's Cost Control Management Process. Yow-ee, that's gotta hurt. And the continuous increases in cost for the program don't seem to help the cause.
Anyone proposing a solution - and there some favorite self proclaimed feral project management types out there that do - are completely out of their minds (nonsense is a nicer word) to suggest simple fixes for these types of things. These types of programs may simply have our-stripped the capabilities of the processes. It has been mentioned recently that we in the US have out-stripped our ability to Govern in a similar manner. BTW the previous link is a good source of defense news outside of Aviation Week & Space Technology and it is free, which AW&ST is not.
BTW, a colleague Steve Garfein, has used Boeing versus Airbus for awhile to speak about the Strategic Portfolio Management process. Steve has another presentation that is a "must read," titled Project Management in Howard Hughes Hobby Shop. Steve was a neighbor in California many years ago and a member of the Project Management team for the AH-64 Apache Helicopter. Unlike those suggested in the last post, people like Steve and the 1,000's of others "walk the walk" regarding management of complex programs.
Seth Gordin has a nice post about Deliberately Uninformed. We had a conversation today around the conference room table, while working the cost and schedule integration for an upcoming Integrated Baseline Review.
One topic, while taking a break from the arduous work efforts of keyboarding all the gory details of $87,000,000 worth of work into the various database repositories, started like this...
Hey, there is this guy that says he's an expert at Earned value Management.
Really? Can we find him through Goggle? Has he written anything on the topic that we can find that might help us? How about speaking at the local PMI, AACE, or other professional chapter? Or maybe does he have a paper that we can find somewhere? Where has he worked that they used EV? Did this EV work include being "validated" by the Defense Contract Management Agency? Does he have a process for applying Earned Value to our specific problems we're trying to solve around this !@#$'ing table all day long? Has he actually worked a program recently where EV was the "killer process," that took the program out of the ditch and put into back to GREEN?
You know silly questions like that?
No, then why are we thinking this guy is an expert? Not that not having all these things doesn't make you an expert, but it sure would be nice to find some reference to a person's credentials on a topic. OK, he only worked on classified programs, never joined PMI, never spoke or wrote a word about his domain, happens all the time. But then the final question.
Anyone know somebody who knows this guy?
No, not even with 2 or 3 degrees of separation? How can he be an expert without SOME visible evidence of expertise that we could check out? Might happen. But Seth's got a point. Access to knowledge is largely unimpeded. Forget the middle class (not really sorry). We use it all the time. But access to knowledge leaves breadcrubs. Comments on Blogs, emails, conference attendee lists, stuff like that.
We're going to have a "high level expert" vistor next week, A guy from the government, who was introduced as an expert on a program controls topic. 45 seconds we found him on Google - after correclty spelling his name. Found his presentations, credintials, papers, and job history. Yep, he's a heavy hitter. Ah crap, we've got to get our PMB (Performance Measurement Baseline) in better shape to impress him, we want to look good.
Never heard of the other guy caliming to be an expert? Maybe a self proclaiimed expert is just that "self proclaimed?
Project Management and Program Management depends on "corrective actions" at the granularity needed to "keep the project inside the white lines." This means sampling the progress to plan at intervals needed to make corrections. To answer the question
How long am I willing to wait before I find out I'm late?
When the measurements of project performance are reported as "good," then there is little information available to make corrective actions. So when we get "good news" all the time, there is little or no information to make corrective actions. The project cannot be "managed" in the sense of the verb "management."
We need variance to make corrective action. We need variance to discover root cause failures. As program managers we are expected to:
...assess & control program performance in order to better anticipate and prevent potential failure conditions.†
† DEVELOPING EXTRAORDINARY LEADERS: RE-SHAPING EXPECTATIONS OF LEADERSHIP CAPACITY, Robert M. Tobias, Director, Public Sector Executive Education, American University and Patrick K. Barker, Technical Director, Project Solutions Group,Senior Program Manager Certificate Program MCR,LLC.
When we hear of methods of project management that do not include, measures of varaince to plan, then we should be skeptical they are in fact "management" processes and more along the line of "observing" process. This is called Level of Effort in our domain. "Train Watching."
There's not enough juice for the squeeze
USMC quote for the return for the investment. In this case the investment of good Marines. The quote came from a Platoon leader on the decision NOT to engage a potential enemy.
When moved to the context of Project Management, the quote is applicable to any conjectured method that has not been "field proven," in the domain and context in that domain.
The discussion on risk, certainty, uncertainty, and variability on projects has many starting point. Some make claims that certainty is not possible. Others than chaos is all there is.
But the concept of Uncertainty is core to all project activies.
Uncertainty in plain English is about the “lack of certainty:”
Discovering the known and unknown sources of bias and ignorance helps define much effort it is worth to clarify the uncertaint:
As well, uncertainty arises from the basic processes of work
Both of these sources of uncertainty impact cost and schedule
I got a response to a recent post from James Graham of Training4Change.com. James has a great quote on his site.
Hard Times = Focus on Details
My response to James pointed out a paradigm we used at a large Department of Energy site:
We currently use the Plan of the Work process on our DoD and NASA programs. It's a simple concept - as always. "What does DONE look like for this week?" By DONE I mean tangible evidence agree on the previous Thursday as to what would be "done" by the Close of Business (COB) the coming Friday.
I found the chartering document for our Plan of the Day. The PoD was used as we approached the end of a multi-billion $ environmental cleanup program, that was once one of the top three toxic waste sites on the planet. Here's a redacted version from 2003, that still serves us well to this day "in hard times," and for that matter "all the time."
The Plan of the Day Paradigm
In the coming weeks the POD will evolve to more closely match the system used to report labor, materials, and subcontractor invoices on CH2M HILL’s invoice to Kaiser Hill. Our first change will be to use the POD as a “true” Plan of the Day and assign the weekly planning, task planning, and long range planning activities to separate meetings. The Plan of the Day will be structured in the following way.
The First 15 Minutes of a 30 minute meeting:
1. On the previous Thursday, the Plan of the Week meeting will be held for Site activities. These meetings will be lead respectively by "Bob" and "Sally." In these meetings the activities for the coming week will be verified and captured on a spreadsheet. This spreadsheet will be extracted from the Project Server (PS). “The usual suspects” will be invited to plan the next week’s work.
2. For the sire process group and the “Level of Effort” group a “to do” list will be prepared. This list will be maintained in the PS (shared folder in Share Point Team Services). In the coming weeks the POD will be extracted from a “to do” list, but for now let’s use STS as a public folder for the spreadsheet.
3. During the first 15 minutes of the Plan of the Day we will all report the activities scheduled for the day from the respective spread sheets, ordered by the current Project sequence.
a. Line items on the spreadsheet will be used to direct the discussion.
b. We will make every attempt to hold the discussion to the items on the spreadsheet and avoid discussing “off topic” items.
c. If there are items planned for the day that are not on the spreadsheet they will be noted and added AFTER the first 15 phase of the meeting.
d. Let’s make every effort to hold the discussion to the “plan of the day.”
For the second 15 minutes:
4. After the Plan of the Day items have been reviewed, and any additions, changes, or deletes made, we can move to “new business,” which will include a. Items that need to be discussed in support of the Plan of the Day. b. Items that did not complete yesterday but are now rescheduled for today or some future date.
5. At the conclusion of the previous section (15 minutes) any remaining issues will be resolved in an off line meeting.
Some Guidelines for Moving the POD Forward
Next POD Steps
My Personal Opinion
Much of the difficulties I see on projects where "The Lazy PM" comes in is where there is no clear and concise mission, there is no "do or die" culture," no promise made to the US Congress to "get the job done." Programs like "Fly to space station, dock, stay for 6 months, return, don't kill anyone on purpose." "Clean up a contaminated site, stay under budget, stay ahead of schedule over 7 years, and don't kill anyone." Or, fly to Hubble, change the batteries, and wide field camera, anbd don't break the telescope."
Projects like that don't have time to waste in meetings that don't produce tangible measureable outcomes, they don't have the 80/20 problem.
EVERYTHING is important. If it's not important it would appear in the Integrated Master Schedule, it would not be funded, there would be no staff assigned to un-important work.
One of our mentors had a great piece of advice.
When he called a meeting (he was a SVP at a large telecom firm), he'd ask each person coming into the room to state "what value they were going to provide to the meeting when it was over. How were they going to move the problem foreword?" If they could no answer the question with a clear and concise answer, they had to leave - "you're wasting my time!"
That approach, the Plan of the Day, Plan of the Week, and Plan of the Month, all anchored in the Integrated Master Schedule, could replace all the chatty stuff in most of the PM books of "how to be a better PM."
What have you done for me lately, what are you going to do for me next week? everyone get back to work, was the mantra of a Program Manager on a multi-billion coal gasification program in South Africa. He showed us how to manage as young managers. I never forgot those words.
The Defense Acquisition University has an Earned Value Management Gold Card, showing all the components of Earned Value and how they are connected.
Here's a nicer one from Fermi Lab. The EVM Pocket Guide.
I've got a burr under my saddle about the concept of the "lazy project manager." The core concept is the Pareto principle, and the 80%/20% rule. One quote from the Lazy Project Manager site says...
The value of the Pareto Principle for a project manager is that it reminds you to focus on the 20 percent that matters.
Why on God's green earth would a project manager being spending 80% of hetr time doing things that don't contribute to the project?
While the notion of improving the processes of Project Management are always welcome, there are some issues. One is that BAD project management practices is not a good startiing point for process improvement practices. Just stop doing BAD project management processes first, then look for improvements. If that what the "Lasy Project Manager" is all about, then stop doing stupid thing on purpose and get back to managing.
Well let's see how this works on a DoD weapons system project? What 80% of the project management processes and for that matter 80% of the program itself should I ignore? What 80% of the daily processes of managing a large ERP deployment shoudl I ignore? Do I really have 80% inefficiency in the DoD IMP/IMS based Earned Value Management reporting processes for the monthly CPR, supported by the weekly EV, the Risk Management Board, the measures of Techncial Performance against the intergated test plan?
If it is the case that I could not perform 80% of the activities I do each day, each week, each month, with the 15 to 20 Program Planning and Controls staff plus the Program Manager and her 4 deputies, then we shouldl be looking for work elsewhere.
What project has an 80% inefficiencyin the project management processes? Show one of those and I'll show you truely BAD project management at work.
Here's the final straw. The author states...
I really mean that we should all adopt a more focused approach to project management and to exercise our efforts where it really matters, rather than rushing around like busy, busy bees involving ourselves in unimportant, non-critical activities that others can better address, or indeed that do not need addressing at all in some cases.
This is one of those "doctor, doctor it hurts when I do this." "Then stop doing that." style of advice. We know. But how did you get to be a PM in the first place. Maybe you're not cut out for this job. So a refreash of the poster hanging in the lobby of our building at Rocky Flats.
is a post that reminds PM's that starting with BAD processes and then suggesting improvements, is a great way to restate the obvious.
Everyone is entitled to their own opinion, but not their own facts. - Daniel Patrick Moynihan
The recent post about complexity, size, and location having no impact on the productivity of a PM and previous posts about how PM 2.0 is the "next big thing" in PM and numerous other conjectures in the absence of a domain and a context inside that domain, bring to mind Moynihan's statement.
When book authors make generalized statements in the absence of facts from the field, it's establishes the basis of my "nonsense" responses. I'm biased by my science background (physics and the practice of digital filters searching for particle collisions), my program management experience in defense and space systems where people die if the product doesn't work and contracts are canceled when the programmatic side doesn't work.
This is a bias I fully acknowledge. But when there are statements made in the absence of any field evidence to support the conjecture it's call nonsense in our world.
Go get some evidence that the statement has any hope in hell of being anything other than personal anecdotal experience. Come back and we'llsee if we can make a connection outside personal experience that can be applied to a broaded set of problems.
Dave Garett has an interview on Andrew Filev's post about his book "The Lazy Project Manager." While much of the discussuion is outside of my person interest, there was a quote that struck my in manner that appears to be nonsense.
Does a project manager’s productivity depend on a project size? The size of his team? On the fact that the team is distributed across several locations?
The answer was
I don’t believe that it does. All of these factors complicate the process of project delivery but the principals of Productive Laziness remain the same.
I work primarly defense and space programs as the program controls lead or enterprise ERP programs in the Program Management Office. My current assignment is a $300M Army program, but our teams work flight avionics ($600M), an Air Force infrastructure replacement programs ($37B), and several other moderate to large programs.
It would be breathtaking to believe that that size of the program, size of the team, and location do not have huge impacts on the style, processes, tools, and skill sets don't have impacts on the success of the project?
Why do people beleive this? Have they worked a $7B environmental reclamination program? How about a $7B manned space flight program? Maybe even a small to moderate $175M ERP program? Why do they say things links this? Is it because they don'r know? Maybe because they don't know what they don't know?