I had a long discussion yesterday with a colleague on how to establish and document project context. I am not going to go into the many reasons for doing this, but as a project risk professional, it serves various purposes.
One can conduct these workshops as part of the project, but my suggestion is that it has to be created by the risk manager before the first risk workshop. It is then reviewed during the first workshop. It saves time and prevents the risk manager from asking very stupid project scope questions.
The first is that it is a communication tool. It helps the project risk manager to understand what the project is about. If I do project assurance work, and I cannot find the project context document, I immediately assume that project risk management is a compliance exercise only. Detailed context establishment also helps other project stakeholders to understand the project better, and serves as a communication tool which, when used in an open forum, helps people to think about the project and listen to what their colleagues' thoughts are. I have never facilitated a risk workshop where the context discussion did not cause the participants to sort out some misunderstanding or fill gaps in project knowledge.
It also is a way to capture potential project risks or the sources of risk. I will cover how this is used in a later post. It is important to review the context document from time-to-time as changes in the context might cause some risks to close and new ones to open.
The question then sits in what should be contained in a project context document. Based on my experience, the following is mandatory:
Project name and location: Obvious reasons.
Project manager: Obvious reasons. A list of project members and their telephone numbers is also very useful.
Project phase: The latter is important as is shows that there may be project development, execution and close-out risks. A project which I am working on now, has 78 development phase risks, and 30 execution phases risks. The latter will of course grow towards the end of the project development phase.
Project Sponsor Objectives: This talks about the short and long term project implementation and operational objectives, which might include objectives related to job creation, poverty alleviation and long term plans. I was reminded of this one by Viv Oates (https://www.linkedin.com/in/viv-oates-67024b75/).
Functional Objectives: For a project in execution phase, this relates to what the project must be able to do after implementation. Examples: (i) the Tank Farm must be able to handle a XX liters of fuel per year and (ii) the Breakwater must be able to withstand certain types of waves. This is used later during risk identification dealing with design risks. For projects in development phase, these relate to the deliverables of the design phase of the project, i.e. (i) Produce drawings for the Breakwater conforming to certain standards and (ii) Ensure that the appropriate geotechnical work gets completed in time to inform tank design. A good document to find this in, is either the Owner Requirement Specification, Project Schedule or even the Task Order placed on a company assisting the project Owner with the feasibility study.
High Level Scope: This gives everybody an idea of what the large building blocks will be. This can also be found in either the Owner Requirement Specification or Project Schedule.
Implementation Objectives: My colleague Simon van Wyk calls these "Critical Success Factors" and deals with how the project must be implemented. A detailed task order for the works, especially in the feasibility phases of the project, can help enormously with this. Typical examples of this is (i) the Procurement Plan should take lead times into consideration and (ii) Approval timelines should be built into the schedule.
Timing, milestones and cost: Obvious reasons. The question asked here is also "how did you made provision for contingency". If I hear "We normally use 10%", I want to shoot the person which originally came up with this very unscientific rule of thumb (and dumb). It also opens a discussion on some extra work to do a Quantitative Risk Assessment on the project.
Assumptions: This can be very interesting and may indicate risk sources as well. I have encountered some awesome "Executive Brainwaves" in this where completely impossible feats are expected by management. A good example was where a Chief Executive instructed the project team to "Ensure that the environmental approvals are done within 8 months." And we all know how long that takes.
Stakeholders (and what they want): Also a potential risk source, especially when dealing with large capital projects such as ports, airports and toll roads. Just ask SANRAL about the latter.
Constraints: This is also good to note as these might also be risk sources.
Opportunities: We tend to forget about these. Their impact might be bigger than those of the threats.
Contractor list: This is part of the stakeholders list, but closer to the project.
I have also seen a SWOT analysis being conducted as part of setting the project context. In this case, the S and W are "Statements of Fact" and the O and T are risks and opportunities. I suggest that one uses something like PESTEL (Political, Economic, Social, Technological, Environmental and Legal) inside each of the blocks as a checklist. It is less structured than the method described below, but also works very well.
Richards Bay Coal Terminal: Stacker Reclaimer.
Copyright 2020 Dr. Francois Joubert