Project Assurance - 7 Critical Factors

Richard Mulder expands on the steps involved in a Project Assurance Review and asks whether your operation could benefit from an overhaul

during the limbo of lockdown.

Project Assurance Process

In our last article, we spoke about the strange times in which we find ourselves and the benefits of utilising the present moment to prepare for post-COVID project activity.

We introduced you to Project Assurance Reviews, a process which critically assesses the health and feasibility of a project and proposes measures to close any gaps to unify the project performance moving forward.

In this article we take you through the 7 critical factors Siecap applies in their review process which ensures project readiness and viability.


We invite you to consider these, and see if this is something that you can practically apply in your space to ensure project success.



Critical Factors

1: Choosing the place and time for Project Assurance application

Depending on a business’s approach, they may be running a two year or five year strategy that captures projects within their pipeline up for consideration. Typically, internal reviews start at portfolio level when senior executives begin the decision-making process, how they fill that pipeline, how money is allocated and what return on investment is expected.

Unfortunately, at this point many organisations do not undertake an independent assessment through a review process; quite often the pipeline ends up filled with pet projects and not the projects that align the business with its strategy. It’s a critical stage when there is often the temptation to focus on short term immediate benefits without challenging what the project is actually going to deliver long term and asking how it integrates within the suite of projects within the rest of the business.

Project assurance, could start at project selection ensuring the business cases supporting those projects that make the initial grade will align with organisational strategy and have the highest possible chance of delivering project success.

The scale of the project has a significant impact on when Project Assurance reviews are undertaken. Larger organisations with more complex projects may apply the review several times, say, for example, at the gating of the feasibility phase or definition phase. They might repeat it at execution and follow up with a peer review post execution.

With smaller projects there might only be one review at the point where the project gates from definition into execution (after the analysis, feasibility and design process is done). At this point, the critical component to challenge is - are we set up for success?

Project Assurance reviews have the flexibility to be undertaken throughout the project lifecycle and can be scaled on the requirements of the organisation, project size and complexity.

2: Project Assurance Independence

This factor addresses the issue of conflict of interest, something spelled out clearly in the Prince2 manual.

Imagine engaging the services of an architect to create a new building. When the project is completed and you wish to test the effectiveness of the design, engaging the same architect to complete the review would be madness. You would approach a reviewer, independently of the project, to objectively evaluate the design.

The same is true with project assurance. Project managers and those in support roles will undoubtedly work effectively whilst the project is in process but are too involved to review objectively. They are, after all, being asked to review their own work! Another pitfall worth avoiding is asking project managers to carry out a project assurance review of another project manager, an exercise which can lead to tit for tat activity and unnecessary competitiveness between teams.

Having an independent reviewer avoids these pitfalls and adds a different perspective towards the project, maintaining an unbiased, objective view of a project’s status.

3: Project Assurance Experience

Quite often organisations think that having someone with an auditing background is best suited for a Project Assurance review. However, contrary to this notion, project assurance experience relies on strong knowledge of project function and the ways in which component parts of a project interconnect. Project functions overlap, one part being reliant on another and may be midway as a project gates to the next phase, so this is not a cut and dried linear process. In addition, the ability to identify risk and potential exposure, even though a project may appear compliant at a particular point in a review, is vital. The Government sector has recognised this and engages industry independent experts that first need to undertake Government approved training in order to perform any type of project assurance review.

Expert project assurance reviewers, like those at Siecap, have a strong, broad knowledge base and an understanding of international and Australian standards coupled with a holistic picture of project structure, governance structure and program management, including decades of experience as functional project management professionals. Their role is to constantly adjust the lens on a project, so the individual parts are not viewed in isolation. Whilst a project manager or SME might, for example, sign off on project compliance, they are not always considering the impact on the future phase of the project.

Siecap Project Assurance teams pride themselves on providing the wealth and breadth of experience, and the ability to jigsaw all the pieces together to provide the ‘big picture’.

4: Clearly Articulated Assurance Scope / Terms of Reference

Each time a project assurance is undertaken, the terms of reference (scope) must be established before the review begins, in order to clearly articulate the intent of the exercise. Depending on the phase of a project, the terms of reference will be tailored to capture specific 'in phase' requirements as opposed to a complete all encumbering review.

To illustrate, Engineering Discipline will be reviewed at definition and again in execution. However, at execution phase of a Civil / Construction project, a project assurance review would not be looking at the quality of an Integrated Basis of Design as this would be done within the definition phase. At Execution, the integrated basis of design would have needed to be incorporated within the project execution plan and form part of the engineering management plan.

Once the Terms of Reference are created, both the Project Team Leader and Review Team Leader would need to sign off on this, so the review is not derailed.

The reviewers would typically look at:

  • governance of the project,
  • outputs and outcomes,
  • appearance of the project as it develops and its adherence to the business case,
  • project management methodologies,
  • the rhythms and routines adopted by the project teams,
  • execution of procurement and contract management and its compliance with the business requirements
  • interdependence and interfaces with stakeholder engagement in other projects
  • risk management and governance
  • team make-up and resource capability
  • resources and project execution plan
  • costs and benefits

Projects are bench-marked against either an internal or external standard for each discipline area, and part of the reviewer’s job is to ensure standards are identified and being met. Consistency in bench-marking can also help streamline compliance and prevent a fragmentary approach across different areas within the same project.

5: Clearly defined Timeline and Project Assurance Milestones

There are typically five time segments to a project assurance review which neatly align with the Milestones.


 The 5 Timelines and Milestones explained:

1. Terms of Reference

TimingTerms of reference were discussed in Critical factor 4, so we will not add anything here other than do not underestimate that getting this right is fundamentally important. Terms of Reference for small projects can be defined quickly within a day or days; however, large complex projects can take weeks to arrive at an agreeable Terms of Reference. Factor this in when planning.

MilestoneThe outcome of terms of reference is an agreed approach between the Project Team (organisation) and the Project Assurance Team on what will be assessed as part of the review.

2. Project Team Evidence

Timing: The Project Assurance review would not be asking the project team for anything that they should not already have, or work with. This being said, the scale of documentation can sometimes be large, so collating the information in a logical evidence structure and ensuring the project team are aware of the process to submit evidence may take a bit of time. A standard time frame would be 3-4 weeks considering the project team has day jobs as well.
Milestone: At the end of the evidence gathering period, there should be a repository of all documentation that the review team will be given access to for assessment and should neatly align with the various project disciplines.

3. Review Team Evaluation

Timing: As the review team are normally independent to the project and do not have the contextual background or history of the project, factor an allowance in for familiarisation to occur. For experienced project assurance professionals this could be as little as ½ day. The desk top review process will take approximately 3-4 weeks, again depending on the size and complexity of the project
Milestone: At the end of the desk top review there will be a workpaper that articulates the findings, compliance gaps and positive practices undertaken by the project team.

4. Project Assurance Review Day

Timing: As the title suggests, it is a Project Assurance Review Day so should only take one day. Both project team and review teams will need to be available for the entire day as the review team works through the findings for each discipline area.
Milestone: The point of the Revi

ew Day is to have integrated discussions on the potential issues and challenges observed by reviewers. Discussion are normally run by functional area. At the end of the review day, the aim is to have a consensus between the project and review teams on the extent of compliance gaps, recommended actions and time frames on when those identified actions will be closed.

5. Project Assurance Report & Recommendations

Timing: A seasoned project assurance review team should be able to document the outcomes and preliminary report within 5 days.

Milestone: There are typically sub-milestones within this last point. The process involves having both teams align on review outcomes, with the review team drafting the report. The Project and Review lead then undertake a joint review of the draft report to ensure the correct messaging and compliance gaps are agreed. Once this is done, the Project Assurance Review Lead will finalise the report and then issue to the organisational executives.

6: Communication through the Project Assurance Process

Communication can be a challenge to manage, as the more lines of communication open the more discrete messaging and perceptions need to be aligned; you wouldn’t want the review team talking to every single person within the project team.

As illustrated, as you add a single person into the mix the number of communication channels increase exponentially.

Lines of Communication

A structured approach for Project Assurance Reviews on larger scale projects would include Functional Assurance Reviewers and Project Team Functional Representatives for each discipline. There would be a Lead nominated for the Review Team and another Lead for the Project Team allowing communication to be funneled between these two single points of contact. For evidence clarification, it’s advised that communication between functional Assurance Reviewers and their respective project team representatives are implemented. However, the role of the Leads enables them to formalise and monitor any queries/suggestions which are logged and reviewed. When responses to queries are closed, they too are logged along with supporting evidence providing clear articulation of resolutions. This formalises the channels of communication and allows the workforce to engage in the process.

Obviously, smaller projects would have a scaled version of this process, though the linear progression of actions would be similar.

7: Project Assurance Outcomes Accountability

The outcome formalises the Assurance Work-paper into a report which outlines how the project currently measures up to the relevant standards. It highlights the positive practices of the team and identifies whether the project and the team are set to deliver on original intent. This is followed by a list of gaps identified by the Project Assurance team, and a series of actions, referenced against a standard, which will help to address said gaps. The report will also be used by the organisation to feed into the project learning repository. The report itself pushes for accountability ensuring any identified actions are date assigned to get the project in line with the recommended standards.

At this point, the Project Assurance Review Process is complete, leaving the client with a number of options. They might simply choose to pick up the baton and run with it, using the report to guide their project governance. They might engage Siecap to work alongside them to enact the recommendation or simply provide ongoing ‘health checks’ to guardian the project.

If you would like more information regarding Siecap’s Project Assurance Reviews or the process itself, please feel free to contact me, Richard Mulder, directly at

Related Topic: The Ultimate Guide to Project Assurance

We welcome your feedback on these critical points of interest.