Tag Archives: Management

How to handle Project Risks that become Realities

Do you see yourself as a realist?

It’s impossible to foresee the future, so why waste time trying…

Or do you see yourself as a compulsive planner, constantly considering a range of possible events that could impact your project?

Apollo 13 or Titanic?

Some project “events” will causally walk up and bite you. No warning growl. No alerting bark. Just a nasty event with its teeth sunk deep into your project’s leg. These are what I call “Apollo 13 events”. Regardless of the planning and preparation, there they are … with an evil grin, standing in the way of your project team … just waiting to explode.

Luckily, most project “events” evolve slowly and, for the observant project manager, provide some time to react before they actually become a reality. Some might retroactively classify the Titanic disaster as an “Apollo 13 event”, but I challenge that. The Titanic’s “unsinkable” myth, created in marketing of the ship, initiated a false sense of security among the crew and passengers. The resulting risks grew in impact as they became linked together.

The Titanic-iceberg event may look similar to the Apollo 13 explosion at its trigger point, both were sudden, dramatic and unexpected events, but the Apollo 13 event had a much more positive outcome.

Why?

“Houston, We Have a Problem”

In “Apollo 13”, the movie, the project managers are seen sweeping their work tables clear of charts and tables, to “start over” when the significance of the on-board explosion was understood. Such a dramatic clearing-of-the-decks may have been a realistic reenactment of the scene, it glossed over the “foundation work” upon which the support teams built their success. I agree that risk analysis and planning are not much for The Big Screen and that “foundation work” is often downright boring. But it was the years of planning, training and preparation that went into the management structure supporting that Apollo mission that brought those astronauts home. While the management team did not expect the explosion, they were prepared to act and respond in an organized manner.

To be successful when project risks do become realities, a project team should proactively build a foundation for risk management including risk definition, analysis (of probabilities, impacts) and mitigation/response plans. Working without risk management could be viewed as working without a safety net. You might survive a small misstep, but a fall could prove fatal.

In my project management experience, maintaining the risk register (risk management documentation) is not a popular project task. We all know that it’s important, but few of us particularly like to perform it. It’s not flashy and few people (outside of QA) seem to care much about it, until something goes wrong.

Managing Risks instead of Reacting to Them

Instead of using the risk register as a “QA check off” item, I strongly recommend that teams take its maintenance and update seriously. As noted above, proactive risk management often reduces risk impact and negates the need to react radically.

A single action taken early enough in a risk triggering sequence can completely avoid an event occurrence. The challenge is to see the initiation of the triggering sequence, not the end of the sequence (aka the event trigger). The observation of that initial change can most easily occur if the risks are routinely monitored and updated. (Risk management may be boring, but it can be extremely effective.)

When Your Ship Does Hit an Iceberg …

This is where the preparation pays off! Depending on the event, pre-positioning contingency resources can turn an “impending disaster” into just a “significant event”. Obtaining additional staff resources or additional funding to handle an event takes time. Reacting slowly to an event generally intensifies its negative impact. Preparation and planning are not glamorous tasks, but completed properly, they can plug a hole before “the ship” begins to list.

Clear understanding of the relative importance of project targets and goals can also turn a “major event” into just a “missed target”. When confronted with a the prospect of a missed timeline target, experienced project managers will often drive their teams harder to deliver. In a 2008 Harvard Business Review article, “The Experience Trap“, an international team of researchers highlighted how experienced project managers are often so tied to common delivery constraints (especially budget & time) that they ignore solution options before it is too late to employ them effectively.

though the managers had encountered similar situations on their jobs in the past, they still struggled with them in the simulations

The experienced managers still selected solution paths that maintained cost and timeline targets, in spite of the significant and probable risk to product quality or HR issues. The managers overlooked the option of working with stakeholders (and the project sponsor) to revise a project’s initial targets. A quality product delivery with a missed timeline target can still result in an effective delivery. It just means that the project manager cannot claim achievement of the Holy Trinity (on-time, on-scope, on-budget). A project that delivers on-time and on-budget, but with poor quality can rarely be called “successful”.

While we may not be able to predict the particular iceberg or explosion that might impact our projects, we can identify general risks and prepare accordingly. We can routinely monitor risks (scanning the horizon) to see if probabilities or potential impacts increase. We can prepare (pre-positioning resources / funds) for potentially high impact events and reduce the “surprise” of active triggers with monitoring (setting a bow watch while sailing across the North Atlantic).

As project managers, we don’t have control over everything, but with risk management processes, we do have significant control of our project’s destiny.

++++++++++++++

Related Articles:

  • The Experience Trap“,  Kishore Sengupta, Tarek K. Abdel-Hamid, and Luk N. Van Wassenhove, Harvard Business Review – February 2008

5 Steps to Becoming a Volunteneur

Entrepreneur + Volunteer = Volunteneur

There is no question that the World, the United States, your City has problems. Some are Big Problems; some are Small Problems.

So what are YOU doing about them … Today?

Complain to City Hall!

“Somebody should do something!” While being incensed about a problem  may have been enough to get some action in the past, it’s just not an effective course of action today. Tax revenues down. Public services are being cut. Finding more than a sympathetic ear might be difficult to do.

Volunteer to Help

Now you’ve got the idea! “If the City is short on resources, then I could volunteer to help. But what’s the plan? Can I realistically work as an unpaid volunteer for the City … addressing the problem that is bothering me the most today?” It’s possible, but unlikely.

Perhaps you could join others as a volunteer in their private sector initiative…

Strength in numbers! More hands make work light! Excellent!

There are numerous organizations that you could join. Perhaps one of them addresses your specific complaint/problem and you could get some muscle behind the solution.

But what if there isn’t someone or some organization that is addressing your particular issue? What if your problem is too small to be on someone else’s priority list but still too big for you to ignore?

Become a Volunteneur! 

“A what?” We all have an idea of what an “entrepreneur” is … it’s someone who sees a problem (or an opportunity), collects various resources/processes and (with a lot of hard work) creates a solution or product. Sometimes the solutions or products are a little unconventional. Sometimes they don’t work as planned. But when they work, the entrepreneur is a huge success!

As a “volunteer”, you show up somewhere and someone hands you a shovel or a paint brush or a soup ladle and you get to work. You become one of the rowers on someone else’s galley. If the planning was good (the galley is pointed the right direction) and the resources adequate (there are enough rowers), the initiative is a success.  There is nothing wrong with being a volunteer, but you rarely get to select the target problem or the solution.

Entrepreneur + Volunteer = Volunteneur

Part entrepreneur, part volunteer, a volunteneur looks at a problem from the perspective of a business owner who must solve it, given the available resources and constraints. No one else is going to step up and “fix” what’s broken, so YOU have to take charge.

Five Steps to Becoming a Successful Volunteneur

1. Identify / Define the Problem

This is also known as requirements definition. Document all of the problem components. (Write this down.) If you can’t define the problem, your success at solving it is greatly diminished.

2. Consider your Available Resources, Constraints and Problem Details

If you don’t know what you have available to you, you’re likely to overlook solution options or try to build something that can’t be completed. The “problem details” would include the “root causes” and any “triggering conditions”.

3. Look for Solution Options

This is the brainstorming session. No solution is too wild or too impractical. Don’t worry about the completeness of any single solution option. Several solution options might work better when combined.  This exercise often yields additional constraints or problem definition details.

4. Assess / Compare the Solution Options … Build a Plan

Identify the resource “costs” of each solution. Consider the pro’s and con’s, along with their potentials for success. Consider solution option combinations that might enhance each other. Select optimal solution(s), build implementation plan. Establish success metrics.

5. Execute the Solution Plan

Just because this is an unpaid effort, doesn’t mean that it will require less management. Use your business/project management skills to track work according to plan. Encourage your team along the way. Monitor success during and after implementation. Modify solution, as required, to improve the outcome. 

Volunteneurism — It’s All About Getting It Done

In business, project structure is commonplace. In civic or volunteer environments, good ideas can become lost long before the problem is properly defined. It’s so much easier to complain than to do. As a volunteneur, bring your business (get it done) expertise with you and get folks moved off that first square.

Step up, define the problem, identify your resources/constraints/details and get solution options on the table for discussion. Solution discussions can build a sense of decision ownership for volunteers, but keep them moving. Combine and eliminate options to end up with that single direction that you can all pull toward together.

People willing to help with projects that look successful. They just need a leader to get them started and a manager to help them be successful.

Don’t leave your expertise at the office. Share your coordination and management skills. You may find that the rewards from your community work far exceed those from your paycheck.

You Can’t Always Get What You Want…

While some say that Rolling Stones‘ “You Can’t Always Get What You Want” is a song about love, politics and drugs, I understand that it is the lyric ballad of a 1960s project manager. (Is it true that Mick Jagger is still PMI certified?)

+++++++++++++++++++

As a Project Manager, I am commonly provided a high-level project scope and expected to “flesh out” the requirements. While this is not an unreasonable request, as an IT Consultant, my role also includes a consultative / Socratic component surrounding scope definition.

You can’t always get what you want

In a time of tight budgets and low, internal resource, availability, not everything is practical, much less possible. Before heading down the road of requirements gathering, I make a point of performing a “sanity check” related to the business case behind a project initiation request.

That business case doesn’t have to be a formal, 10-page, single-spaced document, but it does need to exist in some tangible format. If the business case exists only as words spoken across a conference room table, then the first task of the PM should be to translate those words into writing. (“If you can’t print it, it isn’t true” or so my first IT manager used to say.) The business case includes functional description of the project and why its delivery is important to the business. It provides the basis for expending funds. In PMI terms, the business case becomes one of the source documents used to create the Project Charter.

Documenting the initiating business case, even if only a single page effort, solidifies the primary goals of a project and often, an initial description of they might be accomplished. It provides a project manager, who might later be “up to his elbows in alligators” a better understanding of “why we began to drain the swamp” in the first place.

But if you try sometimes you just might find

The business case documentation process may allow a review of solution options that had been previously overlooked. (This is where the “consulting” comes into play …) How many times have you looked at a problem and quickly convinced yourself of the answer, only to find out later that there had been a much better solution available to you had you just taken the time to consider the options.

Understanding (or documenting) a project’s business case may provide the PM and the requesting business unit with just such an opportunity. Instead of taking a build-it-now-and-ask-questions-later approach, ask those “Why?” and “Why not” questions before significant project funds have been spent. Even if you just hold a brainstorming session with your own team, the process may yield unexpected and positive results. Those results can then be shared with the project sponsor and the requesting business unit in a low-key manner. Remember, a project concept usually is somebody’s “child” and no one likes it when their child is called “ugly”, even in a well-intended manner.

You get what you need

The end result of this project process is that the sponsor gets what she or he needs. That might be the original scope / approach or it might an approach that delivers the same results but in a more effective manner. The important point is that the project initiation process now includes a business case that explains “Why”.

Both the project’s sponsor and the project manager “get what <they> need …

[… and, no, Sir Michael Philip “Mick” Jagger does not hold an active PMI-certification, I checked.]

+++++++++++++++++++++

The song, “You Can’t Always Get What You Want”, was originally performed by The Rolling Stones and released in their 1969 album Let It Bleed. It was written primarily by Mick Jagger with assistance from Keith Richards. [http://en.wikipedia.org/wiki/You_Can%27t_Always_Get_What_You_Want]