Operational risk includes people risk, technology risk, external event risk, and process risk. In this article, let's talk about process risk and how to reduce these risks through process mapping.

When employees leave organizations, these entities may loose daily operational knowledge. You know. The people that know how to get things done are now gone. And these organizations often lack process documentation. Furthermore, they fail to cross train other employees adequately.

So, who is impacted? Employees for sure. But most importantly, the customer is adversely impacted. 

IF. Have you thought about the use of this two-letter conjunction in risk management lately? Let's look at how to use the power of If-Then risk statements.

IF is a simple word that can open up new doors to writing clear risk statements. And it can be used to write opportunities as well as threats.

If-Then Risk Statements

Write Opportunity Statements

Opportunities are events and conditions, that if they occur, have a positive impact on your project objectives (e.g., schedule, scope, budget, quality). Here are examples of how you might start these risk statements:

• If you purchase ten or more computers from the XYZ vendor, 
• If you add an additional developer to task ABC,
• If you use quick-drying cement,

If you are looking for a great way to engage your key stakeholders and identify project risks, perform a SWOT Analysis. Project managers or other facilitators can use this powerful tool to identify strengths and weaknesses. Furthermore, strengths may give rise to opportunities and weaknesses may lead to threats. Let's look at how to perform a SWOT Analysis.

"Why am I still having problems with small projects?

This plaintive question is one I'm asked from time to time. I'd like to give a few brief reasons why project managers struggle with small projects.

Pitfalls of Small Projects

1. You think these projects are simple. In general, smaller projects have less risk. However, small projects may have a complex set of variables.

Be sure to analyze the complexity of the project. For example, you may engage your team to draw a context diagram and/or data flow diagrams early in the project. This exercise allows the team to understand the context of the project.

2. You don't have a project charter. Project managers are assigned projects at the last minute with a tight deadline. Rather than discussing the project with stakeholders and documenting the business case, problems, goals, and deliverables, the project manager hits the ground running. Later, stakeholders demand costly changes.

Make it a priority to engage your key stakeholders and develop a project charter. This exercise will provide a good foundation and reduce the changes later in the project. For smaller projects, the project manager should be able to create a charter in short order.

3. You are applying the wrong level of rigor. I see two extremes: First, project managers do not follow any methodology. 

Second, project managers undertake numerous tasks usually performed for large, complex projects.

Keep it simple. Determine the steps you plan to take and develop the planning documents that will provide real value. Execute and stay with the plan.

5. Your team has been poorly staffed. These projects often get the leftover resources. Any warm body will do or will it?

For all projects, define the required knowledge and skills. Seek to staff the project team accordingly.

6. You are not performing project risk management. Yes, smaller projects typically have less risk. This does not mean there are zero risks.

Risk management should not take much time, but be sure to integrate risk management in your project activities. Simple qualitative analysis should be sufficient for evaluating the risks.

7. You are not performing change management. A stakeholder asks for a change in the scope. It's not a big change. You say okay.

Users request additional changes over time. The cumulative effect becomes significant.

Decide up front how you will manage, track, and report changes. When is a change order required? Who has to approve it? 

What is the role of the project manager? The Project Management Body of Knowledge (PMBOK) says, "The project manager is the person assigned by the performing organization to lead the team that is responsible for achieving the project objectives (my italics)." Defining clear objectives and goals is the foundation of the project. Let's look at how to write SMART goals.

Many organizations have a Project Board that approves programs and projects resulting in a project portfolio. The Board chooses projects and programs that align and support the organization's mission, values, goals, and strategies. Today, let's look at five ways to improve your project approval process.

After publishing my article entitled Evaluating Risks Using Qualitative Risk Analysis, I received questions on how to determine project budget reserves. Here are my answers.

Project Budget Reserves: Questions and Answers

The success of a project manager largely lies in the individual’s ability to communicate. Some project managers have great oratory skills but don’t ask the right questions at the right time.

Here are some key questions for each of the project management process groups. This is not meant to be a comprehensive list; just some questions to get you thinking. Neither will you need to ask all of these questions for every project.

Keep in mind, the project process groups are seldom sequential, one-time events; they are overlapping activities that occur throughout the project.

Initiating Process Group

1. Why are we doing this project?
2. Is your project sponsor fully engaged and on board?
3. What is the authority level of the project manager?
4. What do we wish to accomplish?
5. What are the products and services we wish to deliver?
6. What are the budget constraints?
7. What are the schedule constraints?
8. What assumptions are being made?
9. Who will be impacted? Which stakeholders have the greatest interest and power?
10. Who will comprise the project team?
11. What are the most significant risks?
12. How will we know if the project was successful?

According to PMI, "47% of unsuccessful projects fail to meet goals due to poor requirements management." Wow! Requirements are a pretty big deal. Let's look at five things to start and five things to stop in requirements management.

5 Things to Start

1. Identify and engage appropriate stakeholders. Project managers who work in a matrix environment should seek resource approval from stakeholder's managers early in the project.
2. Ensure the requested software features will be used. Inquire (politely) why the features are needed. How does the requirement align with the goals of the project? The results of one Standish Group indicated that 45% of product features were never used.
3. If questionable, ask if a requirement is in the scope of the project. The project manager may wish to capture out-of-scope requirements in a parking lot for future consideration. Check with the Project Management Office (PMO) or other authority on how to handle these requirements.
4. Analyze requirements using context diagrams, use cases, stories, and other tools and techniques. Project managers or business analysts who use different tools help the stakeholders see things from various perspectives.
5. When requirements change, be sure to update the requirements under version control. Ideally, the project manager should be able to see the versions of the requirement from the initial version to the current version. Many of the requirement tools today provide this capability.

How many times have you experienced scope creep? You know the drill—you elicit and document the requirements. You receive sign off. You continue to see changes to the requirements. Many projects experience 10, 20, 25-percent change in requirements over the life of the project. Let's explore how to manage project scope.

Scope is Not a Mouthwash

You cannot manage what you do not understand. Let's get our arms around the concept of scope. The Project Management Body of Knowledge (PMBOK) defines scope as the sum of the products, services, or results.

When we use the word "scope", it is helpful to specify the type of scope—product scope or project scope. The product scope are the features and functions of the product, service, or result. The project scope is the work to deliver the product, service, or result.

Imagine that you plan to have a painter paint your living room. Here are some product scope questions:

• What color do you want for the walls, trim, and ceiling?

• What brand and type of paint do you want?
• Do you want a second coat of paint?

What are the tools and equipment that are needed? What work will be done to deliver the product? Here are some project scope questions:

• Will someone remove the furniture from the room before the room is painted?
• Will the painter clean the walls and trim before painting?
• Will the painter tape the trim before painting the walls?
• Will the painter use a brush or a paint sprayer?
• Will someone inspect each step before the painter moves to the next step?

Want more clarification on product and project scope? Read this article from Villanova University.

Manage Your Project Requirements

When it comes to requirements, I wish I could read my user's minds. Unfortunately, collecting requirements is challenging. Project managers should consider engaging an effective business analyst for large projects.

A critical part of projects is defining and managing the project requirements. Requirements are the capabilities or conditions needed in the product, service, or result. They are specifications of what should be developed or implemented.

Like the word scope, it is helpful to use an adjective when talking about requirements. There are different types of requirements. Check with your organization to see if there are standard definitions for different types of requirements.

I typically use the following terms. Notice the cascading levels of requirements. We begin with high-level requirements and progressively elaborate the requirements into greater detail.

• Business requirements - the high-level business goals of the project (e.g., Increase customer retention by 5% by the end of the year).
• User requirements - a task of a user group (e.g., Quote an insurance policy).
• Systems requirements - the detailed specifications of the features and conditions needed in the system (e.g., The system shall invoice customers at month-end).

WBS: Define Your Scope

How do you eat an elephant? One bite at time. We all know the saying. Project managers can use this principle for any size project. Use the Work Breakdown Structure (WBS) to break your projects into bite-sized pieces.

The WBS is a hierarchical decomposition of the work to be performed in order to meet the project goals and create the deliverables. The lowest levels of the WBS are the work products and deliverables used for scheduling, estimating, monitoring, and controlling the project. Learn how to build a WBS.

Use Prototypes to Analyze Requirements

Do not make the mistake of waiting until the end of a project to unveil the product, service, or result to your stakeholders. Periodically show the prototypes or deliverables to the customer(s) and the sponsor. When the deliverables are mature, seek formal acceptance. These steps can greatly reduce the risk of rework.

Monitor and Control Project Scope

Project managers should meet with their teams on a regular basis to compare the work completed to the project scope baseline (the defined deliverables, assumptions, and constraints). If there is variance, determine whether corrective or preventive action is required.

Manage the Changes

Many project managers think their job is ensure that no changes occur. Make no mistake about it—change happens. Expect it!

Our job as project managers is not to stop all the changes but to ensure the necessary changes occur in an organized and agreed-upon manner. Don't get me—project managers should not just add anything that is requested. Requested changes should support and align with the overall goals of the project.

Take changes through a change control process. Analyze and report the impact to the project sponsor. Seek approval when necessary before proceeding.

Your Turn

Project managers face a multitude of scope risks. Be diligent up front in your project to develop a scope management plan. Seek to understand your user's needs. Engage appropriate stakeholders on an ongoing basis. Regularly compare your work against your plan and make needed corrections.