Subscribe via E-mail

Your email:

Posts by category

Follow Me

Revolutionary Thinkers Blog

Current Articles | RSS Feed RSS Feed

Zombie Risks

 

The Webster-Merriam dictionary defines ZOMBIE as:   “noun \ˈzäm-bē\ usually zombi; the supernatural power that according to voodoo belief may enter into and reanimate a dead body.”  As a practical matter, those who work in the project management arena typically don’t give much thought to the supernatural and certainly not to zombies. It was with some interest then that the subject of zombies came up as I was talking to an experienced project manager who works for a U.S. government agency in the western United States. His organization utilizes project risk management as a key tool in the management of their projects.  They maintain, and aggressively manage, a Risk Register[1] for each project. And like most organizations they will close a risk (sometimes referred to as retirement) when there is no longer a need to monitor a specific risk. In this particular case a risk that was closed “came back to life”, was realized (the risk occurred) and the project team (much to their surprise and consternation) needed to manage the impacts from this “zombie” risk.

Most risk registers include a block for tracking the status of the risk. This is often marked as monitor (when the Risk Owner[2] is tracking a risk), realized (for when the risk has occurred), transferred (the responsibility for managing a risk has been moved to another project, or organization) or closed (when the risk is no longer judged to require monitoring). Since project contingency that was being held against particular risks can be released when a risk is closed, there can be significant interest in closing risks. Additionally, monitoring risks requires effort which might better be spent elsewhere if a risk is no longer pertinent to the project.

When should we close a risk? Potential answers include when the risk is realized and the impacts have been dealt with or when the probability of the risk occurring is 0. In general, the project team should carefully define the conditions when each risk can be closed. Some project teams will map individual risks to specific project activities. When work on an activity is complete, the risks associated with that activity may no longer requiring monitoring.

Importantly, risks that are transferred do not “go away” even though someone else is responsible for managing them. Until that risk is judged to be such that it no longer could impact project objectives, it should not be closed and the project team should continue to monitor that risk.

Project Risk Management is one of the most important tools that project managers and their teams have available to them. Being blindsided by a risk that the team thought was closed can certainly take the fun out of things, and if contingency associated with the risk has been reallocated to other needs, managing the impacts of the risk can be especially difficult. The best approach is to be very specific about the conditions/criteria for closing a risk and making the closing of a risk a relatively formal action so that both the project team and key stakeholders are aware a risk is being closed.



[1] The 5th edition of the A Guide to the Project Management Body of Knowledge defines the Risk register as “A document in which the results of risk analysis and risk response planning are recorded.

[2]  The Department of  Energy  DOE G 413.3-7A  Risk Management Guide  describes the Risk Owner as “ the team member responsible (1) managing a specific risk from risk identification to risk closeout, (2) ensuring that effective handling responses or strategies are developed and implemented, and(3) filing  appropriate reports on the risk in a timely fashion”

rexProfessor Rex Holmlin is a registered Professional Engineer and Project Management Professional (PMP). He has more than 35 years of hands-on experience managing a range of projects in several industries. His experience includes managing smaller projects such as studies, process improvements, and value engineering studies as well as larger projects in excess of $225 million. Over the course of his career he has successfully managed more than $1.4 billion in projects.

Project Success

 

What is Project Success? It turns out that determining what project success is may not be that easy. The answer may depend on where you “stand” in the organization and what your interest in the project is.

The study of project success extends back several decades (Baker (1974), Pinto & Slevin (1988) Lechler (1998), Crawford (2001) McLeod (2012)). De Wit (1988) suggested that there are three layers of project success. The first layer, project management success asks, “Was the Project Done Right?” The layer relates to more traditional measures of meeting schedule, technical scope and budget objectives. He also identified Project Success, “Was the “Right” Project done?” This level of project success is about what the clients and project stakeholders experience and focuses on whether the project generated the benefits it was suppose to. Finally, there is Consistent Project Success –“Were the Right Projects done Right, Time after Time”?

This is an enterprise layer and, from the perspective of the enterprise, getting consistent good results repeatedly is central to the decision to use project management. However, it is possible for success at one layer to not align with success at another layer. For instance, we might overspend the budget or be a little late on completion, but if a long standing client is ecstatic about the results, that might not matter, although the project team could see the project as unsuccessful since they were over budget and/or late.

As a junior Army officer I was the leader of a value engineering team that identified a specification change that would save one million dollars. This was my first experience leading an engineering team and in the late 1970’s one million dollars was a lot of money (or at least I thought so).

Consequently, I was pretty excited about the results. I can still remember the District Engineer putting his arm on my shoulder and saying, “The object is to spend it, not save it.” Needless to say, the air went out of my balloon pretty quickly. At the enterprise layer, the District Engineer was evaluated on meeting his spend plan. My million dollar savings did not help him meeting the spend plan, so from his perspective, doing the project right was not helpful.

The key issue is that as project managers we need to understand, and identify explicitly, what success looks like at each layer - the project management layer, stakeholder and user layer and enterprise layer. We also need to make sure that the definitions of success and the metrics we use are aligned at each layer. There are several other ways to look at project success and we’ll consider those in future posts.

rexProfessor Rex Holmlin is a registered Professional Engineer and Project Management Professional (PMP). He has more than 35 years of hands-on experience managing a range of projects in several industries. His experience includes managing smaller projects such as studies, process improvements, and value engineering studies as well as larger projects in excess of $225 million. Over the course of his career he has successfully managed more than $1.4 billion in projects.
All Posts