Risk in the IT Environment

Project Post-Gazette, November Issue, Volume 2013, Issue 11. http://projectgazette.com/ppg_201401a_003.htm

by Cheryl Wilson, PMP, PMI-RMP, CCEP Risk yesnoIt was once said that insanity is: “doing the same thing over and over again and expecting a different result.”   We may laugh at this saying and half-heartedly tell ourselves that this type of insanity does not pertain to us; but as Project Managers (PM) if we continue to use the same methodology over and over again to manage our projects but we do not see any difference in our outcomes. Many statistics have shown projects are still failing at a rate of 70%, but PM continue to use the same traditional methodologies to manage their projects, over and over again.  Is this not insanity? Let us take a look at exactly what is Project Management?  A common definition of project management is the planning, organizing, motivating and controlling assigned resources to product fit-for-use deliverables that are defined by the customer or project sponsor. So what is the role of the PM in project management?  The PM that has been selected for each project has the responsibility to plan, execution, and close the projects they manage. The primary goal of the PM is to ensure the production of the project’s fit-for-use deliverable(s).  This includes the challenge of the PM achieving this goal while managing the project constraints of time, scope, cost, quality, and risk.  These constraints are defined at the project’s initiation This article explores the concepts of PM managing risks on IT projects under the other project constraints.    After looking at the history of why many IT projects fail, we have found that most IT projects have the same concerns surrounding their project constraints. Yet PM continue to manage their IT projects the same way over and over again. As we explore the management of risk on IT projects, it is important to understand how to correctly identify project risk.  Where most PM get bogged down in risk management is in the initial stage of risk identification, because PM do not limit project risk to what will impact the stated business objectives – their deliverables.  Project deliverables are defined in the Statement of Work (SOW) or project charter.   A risk is not a risk to you unless the occurrence of the risk impacts your deliverables. The question should not be, what are my risks, but the question should be, what are my deliverables and what are the threats to my deliverable(s)? Step One. The first step to identifying risk on your project is to identify your deliverable(s).  Risks are tied to your project’s deliverables.  To miss this step is actually missing the whole purpose of risk management.  Many PM list everything they can think of that is a problem in their project and label these “problems” as risks.  They are not risks; they are exactly what the word means, problems or concepts needing management attention. Just because something needs the attention of a trained, experienced project manager does not make it a risk. A project deliverable is the agreed upon fit-for-use output that must be produced to complete a project or task. MCLMG has developed a concept for managing projects called: Deliverable Centered Project Management (DCPM).  The focus of DCPM is to focus project management on the production of the deliverables which then removes many obstacles in the way of most PM and simplifies the concept of project risk management. Samples of deliverables could be:

  • A product
  • A design document
  • A prototype, or a
  • A business process

Samples of sub-deliverables could be:

  • Software requirements,
  • Technical or security standards,
  • Database schema or design,
  • Technical procedures,
  • Assessment report, or
  • User interface module or screen.

Some guiding principles for deliverables under the DCPM concept:

  1. All projects have one main deliverable, but are sometimes combined into programs with several deliverables,
  2. All work (tasks) produce a deliverable or sub-deliverable,
  3. Deliverables define the project: no deliverables, no project,
  4. Deliverable quality is defined by the customer or sponsor as “fit-for-use,”
  5. Completion of project is acceptance and sign off by the customer/project sponsor for the production of “fit-for-use” deliverables.

Many risks listed in the Risk Register (RR) are causes of the risk itself and not risks themselves.  Remember, risks are tied to our project deliverables.  Understanding the causes of project risks and their associated triggers (events that turn a risk into an issue) will increase the value of information your RR will provide to the project team. Step Two. Understand inherent roadblocks to most IT projects and ensure the management of these impediments under the PM umbrella and NOT under the risk environment as risks.  IT projects have common and related activities that should be managed as part of the project being an IT project – activities that stem from the project producing informational artifacts. These activities even though they are in the future do not constitute risk, but activities that an experienced and skilled IT PM understands are part of their project environment and they should be managed as such, not lumped into the RR to hopefully provide some coverage if the PM is not able to manage his/her team to the achievement of the activities within the project constraints. Some examples we have seen called risk, but are actually typical IP project activities are:

  1. Vague requirements due to:
  • Limited knowledge of project deliverables at project initialization,
  • Incomplete or unfocused project business case development by sponsor or customers,
  • Misunderstanding of the business problem or underlying dissatisfaction of the status quo by project sponsors and/or customers

An experience PM will understand that vague requirements are normal for an IT project and act or manage accordingly without the need to call them risks. He/she will understand how to PLAN, EXECUTE, and MONITOR their completion as project actions that lead to the production of “fit-for-use” deliverables, not uncertain future events – the definition of project risk. Labelling vague requirements a project risk is making the mistake of attempting to manage your project through the risk register. Skilled IT PM know that vague requirements are signatures of any IT project, but then also know the solutions for their completion such as:

  • how to define them,
  • how to plan their implementation,
  • how to execute their achievement, and
  • how to sequence these activities into the actions needed to produce the contracted deliverables all without using the RR as a crutch.

Risks are those potentials that negatively impact a project if they become reality – they are not normal project activities plopped into the RR in order to provide coverage for possible future project failure. If the creation, definition, description, and approval of project requirements are considered risks then the PM must also include themselves and their BA as risks as well since these should be skills already within the toolkit of any IT PM or BA. One cannot have it both ways. See this issue’s Project Whisperer column for when it is not in your best interests to take a project engagement where one of the major reasons involves the inability of the customer or sponsor to clearly define their business problem.

  1. Request for additional requirements or the dread ‘scope creep’.
  • Unanticipated request for requirement changes.
  • Customer or sponsor deciding they want more than originally contracted.

To minimize scope creep, ensure the customer or sponsor has signed off on the project charter or the Statement of Work (SOW) to determine the project boundaries well defined.  Any requirements identified as non-contracted work will need to be discussed as to their applicability to the current project as the work defined by these additional, out of scope requirements, may increase the potential of project failure due to scope creep.  A request for additional requirements is not a risk; it is a normal part of project management that needs to be managed under the PM umbrella.  A PM worth their weight in gold understands that the customer requesting additional work is always a possibility, but managing this under contracted project constraints is what the PM is supposed to do.  While many say “never say no to the customer,” a smart PM knows when to suggest, “not no, but not now.”

  1. Project duration estimates are not initially accurate.  This actually is very common due to the fact that most projects are defined by those not accomplishing the work.  Project durations are chosen for a variety of reasons, but usually not for their accuracy or precision as to the actual work effort that will be needed or the acquisition and assignment of needed resources. These durations or deadlines are defined by politics, business cycles, funding constraints or simply on the whim of the business sponsor without subject matter experts or historical data being applied to the project time frames.

Again, an experienced PM will ensure adequate duration buffering without overly expansive with respect to the project schedule or deadline. We know this is against everything you learned from the traditional bodies of knowledge teachings, but if this is a known problem then PM need to handle this as part of their management expertise and not rely on listing them along with other project management aspects in the risk register as a way of “covering one’s assets.”  PM need to work with the business case developers at the start of a project’s initialization process to prevent such imprecise or unworkable project constraints making to the project’s charter or SOW which then become unfortunately part of the project’s contract thus setting the project up for early failure. In this article we have covered a significant number and breadth of topics surrounding the correct perspective of project risk management. A PM that has spent any amount of time “beating their head” against the proverbial brick wall of project failure comes to the conclusion that doing one more project in the same way, using the same tools, thinking the same mindset, but this time expecting success is, well, you know… Use some or all of these suggestions on your next project, and you will be surprised how more easily you can deal with the twin “horn of the dilemma:” success and uncertainty without calling everything in a project – a risk.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s