Project Assurance for a Lean-Agile PMO
24.07.20
Certain Project Assurance functions expect to see documentation, plans, review points and, in fact, so do some Project Sponsors. What happens when project teams adopt an Agile delivery framework? What happens when the expectations, tools and techniques used by traditional Project Assurance don’t ‘fit’ the Agile model?
Project Assurance is a fundamental responsibility of the Lean-Agile PMO. In undertaking this role the PMO fulfils its obligations to internal Stakeholders and, in some industries, also to the external regulatory bodies.
Project Assurance is profoundly different in the Lean-Agile world and it is a primary means by which the Lean-Agile PMO adds value. While in this paper the Project Assurance principles are applied in an Agile project or programme context, we also find that they equally add value to organisations using traditional waterfall delivery processes.
In undertaking Project Assurance in the Lean-Agile world it is essential that certain Agile principles are respected, namely:
- that the Agile team is self-managing;
- that Agile follows the ‘just enough’ and ‘just in time’ norms with regard to documentation;
- that the team processes should be subject to continuous improvement;
- that working software is the primary illustration of progress.
Why project assurance?
Using the Disciplined Agile doctrine Project Assurance activities are goal driven. The goals of the effort spent by the PMO in Project Assurance, adds value by guaranteeing the health of the initiative for the Stakeholders and encouraging the team to improve performance. Occasionally across a number of Assurance Health Checks the PMO can identify systemic challenges or training development needs. An essential element of the Project Assurance Health Check is that the project is being reviewed and not the individuals.
Evaluating Project Health is largely a question of establishing if the project is likely to achieve the desired business outcomes. In Agile, documentation is a loose term and may include wall charts or a light-weight document. These statements are the essential kick-off declarations of intent and should exist on all projects. These outcomes or benefits were the reason why the project was undertaken and care must be taken to ensure that the project is executed in a way that preserves the targeted benefits. There are several different types of benefits, some financial others non-financial. In some projects there will be a benefits realisation plan to manage; in others the benefits will be realised by the deployment of the solution.
In evaluating the Project Health, Project Assurance needs to establish the likelihood of achieving the targeted benefits.
During Inception the project team will have assessed its impact on the organisation and identified Stakeholders who need to be engaged with or informed of the project and its targeted business outcomes.
Some Stakeholders, those with a high degree of interest in the project or a high degree of influence over the project, will likely be engaged by the Sponsor as part of the Project Steering. Others will need to be kept informed or engaged as part of the project’s Change Management activities. These activities include; awareness communications, mobilisation communications, provisions for training and the like.
The Project Assurance activity should consider the level of engagement with, and participation of, Stakeholders.
During the Release Planning the Project Delivery Risks will have been assessed and the Risk Responses developed. As the level of Project Delivery Risk falls so the probability of success for the team increases. Monitoring Project Delivery Risk levels is therefore as important for Agile projects as it is on Waterfall projects, although the nature of the Delivery Risks could be different.
In some industries during the Project Inception the potential impact of the project on the Business Risk levels and the Risk Control Environment will have been assessed.
Assessing the project’s attitude, awareness, and control over both sets of Risks are crucial components of the Project Assurance activity.
Engagement with planning for benefits, engagement with Stakeholders, and Risk Management will place tasks or Spikes on the Agile Task Board or Kanban Board. Sometimes, particularly with a technically orientated project team, these activities get deferred or overlooked. Part of the Project Assurance role is to ensure that these important aspects of the project remain at the centre of the Agile activity.
Project Assurance Process
Remembering that the essence of Agile project delivery is the self-managed team; Project Assurance should be a non-intrusive process that uses the Project Lifecycle and Agile Steps such as the Sprint Review, and Release Planning as opportunities for input, recommendation and review.
In addition, the Lean-Agile PMO will have defined a series of light-weight stage gates or checkpoints where the team either seeks a degree of synchronisation with other projects or is part of the way that funding is allocated. These light-weight stage gates also provide opportunities for Project Assurance.
It is essential that the Project Assurance effort is proportionate to the size and the level of business risk of the initiative. The activity should be based on mutual trust between the team and those involved in the assurance; and that it is open and transparent, with observations or recommendations available to everyone.
The Project Assurance Process has three elements:
- Observation;
- Diagnosis; and
- Recommendation.
Observation
The goal of the observation step is to fill in some of the gaps and to collect subjective information.
As an Agile project team is light on formal documentation the Project Assurance activity, by necessity, has greater emphasis on observation than documentation review. However, some project documents will exist and these will provide the foundations for the Project Assurance activity. The Agile Business Case, for example, was used to obtain funding and stated the objectives and benefits from the investment.
Some of the observations will concern the rigour and adherence to the Agile principles. Yet Project Assurance requires an understanding that the Agile team will be adapting and continuously improving its delivery practices. It is essential that the Project Assurance activity does not inhibit the team adapting and improving.
The observations should include consideration that there is:
- a clear vision of the future that is understood and shared by stakeholders;
- a strong focus on business benefits and any critical dependencies;
- an overall design in sufficient detail to plan and align the work of the Agile team with other projects and business changes;
- a release plan which will deliver benefits early, mitigate key risks and allow lessons to be learned;
- a clear strategy and plan for transitioning from current systems, operations, organisations and suppliers to new arrangements;
- an understanding and adherence to the Agile governance framework and processes; and
- an unambiguous indication from stakeholders during the Sprint review that the solutions being developed will meet the stated business needs and deliver the desired business outcomes.
As the principle indicator of progress in Agile is the demonstration of working software, the importance of the final observation in the list cannot be overstated.