THE MASOCHISTIC PROJECT MANAGER

So, since we all agree (?) beyond reasonable doubt (?) that Risk Management, or the finer granularity of Threat Mitigation and Opportunity Exploitation are what Business is all about, let me venture another thought: the Project Lifecycle should be based on Risk Management principles.

Even the most inveterate “seat of the pants” Project Managers do by now grudgingly accept the value in some form of progress reviews, or gates, for a project – just so that everyone is convinced that the project actually is at the stage where it claims to be on the schedule. But these same “seat of the pants drivers” will usually add a few caveats: no cost impact (i.e. “I’ll give no support – pay me” ); no new deliverables (i.e. “what, you want me to actually create some deliverables that PROVE my claims?”); no schedule impact (i.e. “let’s do it over lunch”); and the standard “What do you mean independent reviewers? These guys have their own agendas” (i.e. “they might disagree with mine!”).

Let us review WHY do we have these “gates”, or “reviews”?

In most engineering projects, a “gate” is called for after a meaningful, important piece of work has been completed. At that stage, an internal, or better yet, independent review of the outputs of this phase is to be conducted to provide an appraisal of the progress, quantitative and qualitative that the project has made in meeting its requirements. Most “gates” are also used to decide whether, based on the progress and the compliance to the applicable requirements, the project can proceed into the next phase.

Major gates (Milestone Reviews) are usually set at significant decision points in the Project, and usually involve (or even require approval of) the Stakeholder or Customer, and might have payment release pending on the outcome. On many projects, minor gates are spread throughout the project (peer reviews, code reviews, test readiness reviews, etc.), and are being used to ensure the quality of the work and the readiness for the next task.

Many project managers take the short-sighted view that “gates” and reviews are wasteful and useless exercises and therefore should be minimized (guess I’ve tipped my hand here, didn’t I?). Well, they can be, but only if that is what you make them to be. If gates are treated properly, with good review and feedback from knowledgeable outsiders, and with the proper focus, then they can be of immense value. See Chapter 12 for more on that… sort of.

Getting back to our gates – we have one to ensure the project has reached the point on its schedule it claims to be at, while remaining compliant to its original requirements. The gate then becomes a review of the veracity of that claim – (1) quantitative progress, (2) compliance to requirements, and (3) qualitative.

In a perfect world, we then KNOW what should have been achieved leading up to that gate, and so we review (1) whether the stuff has been done, (2) whether the quality of the work products presented to support the first two claims is adequate and inspiring confidence, and (3) whether the results show the emerging widget still meets the requirements to the level expected for the phase – also called “compliance”,. If we are from a smart project organization, we add one additional question: (4) Does the emerging widget still FIT within the original allocated budget and schedule?

Still in a perfect world, if the answer to the first 4 questions is YES, we declare victory and move on. If the answer is NO, we redo (or finally do) whatever needs doing, knock on the gate, and try again, ‘till we pass.

Of course, reality is just slightly different – there are schedule pressures, the items “failed” might be … not so major, the Customer and Stakeholders push to “keep going” and catch up with the missing stuff later… And in most cases, that is what we do – we chug along, and either recover, or not, and hit the next milestone, where the accumulated problems are just too much to overlook, and we get the accusing glare of the boss with the standard “you always have time to do it again, but never to do right!” ....

So what was missing out of this picture?

Risk Management of the “incomplete pass”, integrated into the overall Project Risk Management approach, that’s what! The fifth question that must be asked therefore is: (5) What is the Risk status of the project?

Say we “pass” the first gate with some issues – those issues are Risks! They must be mitigated in an organized fashion to allow the work that was to be done after the gate to be performed with confidence.  In other words, a Risk Response must be drawn up (even if it only means completing some tasks, or documents, or tests, or fixing them up to pass the quality requirements). Then these tasks must be put on the schedule, staffed, costed. Then, and only then, can we go back and attempt (again) to answer the infamous FOURTH question: (4) Does the emerging widget still FIT within the original allocated budget and schedule? All previous answers are null and void!

Now, if we have a complex system, made up of multiple subsystems, we usually tend to review the subsystems separately, and then the system status. Imagine if and each of the subsystems “pass” their respective gates with “minor issues”, deemed to be acceptable for the respective subsystems. However, shouldn’t we be looking at how all those “minor” issues stack up at the system level (i.e. Project level) and see if the total is still “minor”?

Take the example of a hardware subsystem in which a certain board design is late, but in the overall scheme of things, the board is but a small part of the overall thing, so it is deemed to be acceptable to postpone the design and build to a later stage, after some major issues elsewhere (or maybe on another project pulling priority) are addressed.

But what if the piece of software designed to run on that board is a new, risky bit, and needs extensive testing, which means they absolutely must have their board so as to run their tests as early as possible? Obviously, the drivers for the two teams are different, and the project manager must select the best approach to meeting the overall project priorities.

The overall gating process for a project must therefore always include a review of the Risk the totality of the “incomplete passes” at all the levels (below the system one) is adding to the overall project risk. This risk must then be compared to the acceptable Project Risk Threshold (remember, that thing that just might get your project cancelled?), and the various risks responses recommended at the lower levels must be reviewed and optimized of the best interest of the Project as a whole.

Let us look at the example of a Critical Design Review (CDR) for a theoretical system. By the CDR, all requirements should have been complete (waaay back when…), preliminary design should be done (also way back..) and the detailed design should be ready to be handed over to manufacturing (for the hardheads) or detailed coding (for the softheads out there). Other things must be in various stages of readiness, such as having your test procedures and test equipment defined and built (or not), as defined in the Project Plan and on the project schedule.

Once the subsystem gates are completed, an overall System Risk Chart can be updated to display the results of the subsystem risks identified, and thus visually display the overall accumulated risk on the project.

 (see Risk Map below)

What would you decide in this highly hypothetical example? Me, I wouldn’t move until I have nothing in the red zone, and I am convinced I can afford the ones in the yellow.

If we review closely the five main questions a project gate should be based upon, we should by now see the risk assessment value of each:

(1)   1 - Has the stuff (on the schedule) been done?

In other words, what is the risk that the work required up to this point is incomplete and must be re-done, which would increase the unplanned workload in the next phase?

Multi-tasking is the biggest killer of schedule

In the simple example shown in the "Multitask" picture (see album to the right), an employee gets 10 days each to complete a task for each of projects A, B and C. The first example has the schedule allocated by each project for this task also at 10 days, with the projects scheduling their tasks such that the employee can perform the tasks consecutively. Being a good employee, in example 1 she performs the tasks in 10 days each, and on schedule, so her CPI is 1 and the SPI is 1. Great!

In the second example, the projects schedule the tasks such that the single resource is overloaded and insist she must start work on all projects more or less simultaneously, and of course they all want their jobs done NOW. Again, our employee performs her task as given, doing her best to please and support everyone more or less equally, and by the way performs each project task in 10 days each. CPI = 1! Her reward – being called to the carpet by two of the three Project managers for having missed her schedule!

Was it the employee’s fault? No! Multi-tasking is the biggest killer of schedule. And of course the examples above ignore setup/wind-down time, not negligible even in engineering tasks, and multi-tasking related “unplanned” interruptions (e.g. questions, meetings, status reporting).

Given the constrained resources of most businesses today, the constant drive to do more with less, dedicating key individuals to a project full time until it is complete is easier said than done. In most organizations labour is expensive and often scarce, with projects competing for resources, especially the more skilled, expert resources. Consequently, managers will split critical individuals between two or more projects to make fullest use of any gaps in their workload.

As for as resource utilization is concerned, it is logical to assume that a person will have gaps in any task – waiting for inputs, for a peer-review and such comes to mind. So having another project handy to fill in the gaps makes sense, if we do not overdo it. There is survey evidence showing that to maximize productivity, key engineering resources should handle two projects, but if they have more, productivity drops again.

However, if the schedule is the critical driver, then dedicated staffing is a must. Just as the simple intuitive diagram at the top hinted, the survey showed that splitting an engineer’s attention between two (or more) projects does not make both those projects get there in half the time, or at least not if they both required a full time person to get it done..

I am happy that a controlled survey confirmed after surveying close to 10,000 engineers the gut-feel conclusion I had, but the simple numbers game is not all there is to it. I am opposed to multitasking in all but the direst situations for other reasons as well – accountability, team-building, communication, and so on. You can’t build a team of part-timers, communication requires presence, and of course, a dedicated person is much more accountable. Not to be nasty, but I did encounter one or two people playing one project manager against another and getting away with not doing much for either in my time. When the resource is dedicated to one single project, that “degree of freedom” is gone.

In summary, the only Risk Management worth the term, and the money, is one that proactively reduces the impact of negative risks on a project, while also proactively maximizing the impact and probability of occurrence of positive events. One that brings the project a clear Return on Investment – less unexpected problems, more windfalls from previously unexpected opportunities. If you do not do this, or if you don’t demand this, you are dealing in Risk Mismanagement.

In many companies, it is Goals definition and Succession Plan update season!

Succession plans are important tools for planning the career development of high-potential individuals to serve the long term development of the company leadership. Properly planned and implemented, succession plans ensure that people that move up through the corporate layers had exposure and been successful in various areas of the company’s operations, and thus are ready to assume leadership roles with a good understanding of how the many bits fit together and have to tick such that the overall system works better.

However!

Succession plans are also interesting reading (not that any of us ever gets to read them, as they seldom are “public domain”) for someone wanting to analyse the leadership dynamics of a company. Examples:

1. Successful, dynamic company, great leadership team and a succession pipeline full of energetic new faces. Great! However, it also means that unless the company grows, and fast, thus creating new senior positions for the upwardly-mobile, these guys will have to leave to move ahead. Hothouse for talent, yes, but the best seedlings will get exported – plan for it.
2. Stalled company, full succession pipeline. Hmmm…. Well, there can be two problems with the leadership team: (a) they failed and the people below, good as they might be, are powerless to change that, or (more likely) (b) the whole bunch is stalled but they do not yet have the will to recognize that and clean house, bringing new blood in.
3. Any company, very scarcely populated succession pipeline. Translation – the existing leadership does not trust the next layer(s) down, or no leadership development has taken place, or (most likely) both. Or, there is new leadership, and they took one look at what they have and decided to go outside for some new ideas.

Of course, you don’t need to be privy to a succession plan to see these behaviours play out – just look at how top people get promoted, or leave, at whether musical chairs is the game or only new, external hires get into the best jobs. There are hints aplenty in these moves as to how your company’s leadership is thinking.