Our website uses cookies. By continuing to use our website you are agreeing to our use of cookies.
Close this message.

eLearning Log in

Login here using your username and password

Forgotten login?

How do I identify and analyse project obstacles ?

Introduction

 

There will almost inevitably be obstacles that the project will need to overcome to achieve its goals. The sooner these are identified, recognized and understood the better, as this will help to set expectations of what can be achieved at a reasonable level.

‘Obstacle’ is a generic term that, in this context, identifies anything that could get in the way of delivery. Obstacles could include hard deadlines, costs, problems, supply chain difficulties, organizational standards, dependencies and assumptions that are being made about the capability of your organization to deliver this project.

As all projects are likely to be unique in some way, there are likely to be obstacles that are individual to the project. The main aim at this point is to document the things that could get in the way of project success.

This extract has been reproduced with permission from A Practical Guide to Project Planning, TSO 2016.  If you’d like to read more you can purchase the copy of the book here.

Technique

The main techniques for handling obstacles are techniques for issue management (where there are known problems) or techniques for risk management (where there are problems that might occur). To start with it is helpful not to be too concerned about what type of obstacle it is, but to make sure that the obstacle is recorded, and the potential understood.

The following is a checklist for identifying obstacles:

  • Lessons:  Has your organization undertaken a similar project in the past? If not, are you aware of a comparable organization (a reference site) that has?
  • Deadlines:  Are there deadlines that must be met and cannot be moved?
  • Costs:  What expectations have been set on the costs? Is there a defined budget in place or money set aside?
  • Resources (capability and capacity):  Are there suitable and sufficient resources available in-house to do this? (The resources may be committed elsewhere – or just not there.)
  • Priority:  What level of priority does this project have against other initiatives current or planned?
  • Stakeholders:  Are the majority of stakeholders supportive? How powerful are the blockers?
  • Problems:  Are there any known technical problems that may obstruct the projects?
  • Dependencies:  Are there any external dependencies on other initiatives that could undermine success?
  • Prerequisites:  Are there any outstanding decisions needed either inside or outside the organization?
  • Supply chain:  What is the level of dependency on partners (private or public sector) delivering a significant component of the work?
  • Change context:  If the project is part of a programme, what issues or risks will affect this project?

A workshop of key individuals within the project (including stakeholders and sponsors) is a very good technique for reviewing the checklist and identifying potential obstacles; however, this can be expensive in terms of management time. Speaking to people individually and researching similar projects is an alternative approach.

As mentioned earlier, there is a danger that people get distracted by considering whether an obstacle is a risk, an issue or something else, so while drawing up a list of obstacles just try to identify the challenges that could be faced or the problems you already know you need to resolve.

Once all the challenges and problems have been identified, then they need to be carefully reviewed to decide whether they are:

  • A threat
  • An opportunity
  • An issue
  • An event that triggers a threat or opportunity
  • A consequence of a threat or opportunity.

If it exists, the organization’s guidance on risk and issue management to capture and manage them should be used.

TIP

Focus on the cause of a threat as this will keep the number of risks down to a manageable amount. It is common to find risk registers overloaded with items that are not actual risks, but events that could trigger them.

Example

Most organizations have a standard approach to managing issues and risks. If not, a simple log, such as that shown in the table below, would probably suffice. The log should include the following items:

  • Obstacle:  What is the potential problem?
  • Effect:  What will be the effect on the plan?
  • Owner:  Who is the person responsible for dealing with it?
  • Type:  What type of obstacle do you think it is?

Log of possible obstacles to the training course project

Maintaining a log such as the one shown above will help to moderate expectations as part of the planning process. It is the lack of visibility of obstacles that leads to optimistic bias in planning.

To manage obstacles there are two approaches:

  • Make someone responsible to resolve the obstacle
  • Collectively assess the most likely scenario and develop plans around this.

 

On this page