Conduct a Risk Analysis of Your Digital Project

Let’s get going with the project description phase, a crucial part of the risk management process. 

As you saw in the first chapter, describing the project is the first stage in risk management, and it helps lay the foundation for your risk analysis.

Before we can perform a risk analysis, we need to understand what tools we have available to properly describe and organize what we know about the project. In this chapter we will explore a four key methods that you can use to efficiently prepare for your risk analysis.

Things to Consider Before You do a Risk Analysis 

You probably already have access to project description material often used to share vital information with your client, manager, or team.

The most important thing is to provide a complete but brief overview, outlining the project's unique aspects and information about the context.

Describe a Project Using The Question Word Method

One of the most common methods for describing a project is using question words. You can use them to define a problem you need to solve or a specific scenario. In addition, it helps ensure that you don’t forget certain aspects.

In project management, you use this method in table form, listing both the questions and your answers. Here is an example (columns 3 and 4 demonstrate how to fill out this table. You wouldn’t include them in an actual project). Here is a standard template for The Question Word Method:

🛋We didn't do one for the SofiSofa project, but we can do it now. Let's explore what the Question Word Method would have looked like for the SofiSofa furniture project:

Use an Objectives Tree

You’re aware of the client’s needs. You’ve looked at the important characteristics of the project and now need to study the project objectives.

One of the ways to present the objectives is to create a tree. Work on this as a team, at a brainstorming session, for example. Then, use it during the project definition phase and for your risk analysis. If you don’t have an objectives tree, create one now.

Some people produce theirs after having made their problem tree. But there are enough problems to deal with in this course 😉 so let’s look at how this clear, simple design looks.

Start by defining the overall project objective. You should have already identified this before this step.

For the sofa project, the secondary and operational objectives linked to the overall goal "to allow customers to see a customized sofa superposed in their living rooms in order to help them to make the right choice," were as follows:

Depending on the project, you may also have intermediary objectives between your secondary and operational ones. Having a diagram helps you to define the project better and remain focused on your goals.

Once you have completed your objectives tree, you will have a better idea of what needs your project must meet. It’s the most efficient way of getting this critical information!

Use a Feature Scope

Sometimes you will have even more details about the project if you have initial cost estimates. At this stage, you may have a document for the scope of features.

The feature scope document contains two main pieces of information:

• The number of screens you believe are necessary for this project (the number of different mobile app screens or website pages). At this stage, only consider the sizes (or types) of screens and estimate how many times you will need to replicate these templates. Don't worry; the number of screens at the start of the project will probably change after the design phase.

• The document will also show the features you have identified (thus the document's name), thanks to your objectives tree. Each operational objective will lead to one or several project features.

The feature scope document will outline:

• How many types of screens you will have to create, helping to estimate the cost of the features (zonings, wireframes, etc.) and graphic design.

• What features you need to develop, helping to estimate the time. Make sure you consider the level of complexity.

The feature scope document may have different forms depending on the organization and the nature of the project. I often draft it in a diagram for simple interactive projects in terms of technical demands (with a user flow diagram, for example). I would use a detailed tree view for more content-oriented projects and use a table format for more complex ones.

Perform a SWOT Analysis

The last thing you will need for your risk analysis is a SWOT grid. Use the project management version to make sure it is relevant.

A SWOT analysis will complement your project description, providing more information about the context. For example, you can link risks to a project (internal risks: training, structure, cost estimates, etc.) and the context (external risks: subcontractors, suppliers, regulations, etc.).

A SWOT analysis looks at both the internal and external aspects, increasing your understanding before doing your risk analysis.

Go over the example project description again. You will see that you now have a clear idea of what it will involve, particularly for the mobile app.

Let’s Recap!

• Using question words provides a good overview of the critical project information and is a good starting point for identifying the generic risks.

• An objectives tree, including operational objectives, helps outline the project’s unique aspects and can be very useful for identifying the specific risks.

• A feature scope allows you to understand the size of the project and what you need to produce.

• A SWOT analysis for project management provides useful information about the context of the project.

• When combined, these methods give you most of what you need for your risk analysis. 

I’ll admit that this chapter was quite long! 😊 But it’s an important one as it helps you to understand the various dimensions of your project. So go grab a cup of tea and stretch your legs. In a couple of minutes, we’ll move to the second step: identifying the risks.

See you in a minute!