Standards, in this context, include methodologies, policies, tools, approaches, agreed quality or other standards, and so on. These (should) exist solely to enable, support and help deliver successful projects. But too often they can become ends in themselves and the PMO becomes the enforcer. This is never a good role for a PMO.
Here it is important to remember the strategic intent of these standards -- to enable both the successful delivery and adoption of the projects’ business outcomes, benefits and value. But notice there are two dimensions here -- delivery and adoption. The need for successful adoption means that there are some disciplines that projects need to be comply with over and above their delivery operational needs so as to allow the organization to successfully plan, prepare and adopt the project’s outcomes.
Standards compliance should be measured as a means to an end not an end in itself. If a project team follows the recommended approaches, etc., this should make their life easier while ensuring the necessary controls and measures are in place for the project, program and portfolio to be managed.
Non-compliance raises issues such as
- are they aware of the standard? If not make them aware of its nature and purpose.
- is it applicable in this situation? If not, why not? Is this an aberration or a sign that the standard is deficient?
- does the team understand why it exists and should be used? Non-compliance can be a leading indicator of poor understanding of key project delivery dimensions.
- will what they are doing deliver the same results, reports and measures? If not, they need to change -- not because they’re not complying, but because they cannot generate the necessary outputs using their approach.
- the risk approach the organization used did not help projects manage risk
- risk management had been presented as one of 100 project management tasks and therefore got ‘lost in the wash’ and was not seen a important
- few of the project managers could correctly differentiate between issues and risks and therefore saw ‘issues management’ as covering risk management
- this lack of a risk focus meant that the risk profile of the projects and the portfolio overall was invisible -- the organization was flying blind when it came to project risk.
The answer needed from the PMO was not to insist on compliance (which it had unsuccessfully been doing for many months) but to revamp the whole risk management approach and re-implement it to achieve the strategic intent -- known, classified, managed risks that generate a comparable risk profile for each project and the portfolio overall, while enabling selected risks to be progressively managed to acceptable levels or outcomes.
Standards are about enabling outcomes and do not exist to just be complied with.
Further support and useful tools to help you manage your investments, projects and portfolio are available from valuedeliverymanagement.com.
For the previous article in this the series visit "PMO role 1: constraints management".
For the first article in this the series visit "PMO: What’s in a name?".
Jed Simms is CIO magazine's weekly project management columnist. Simms, founder of projects and benefits delivery research firm Capability Management, is also the developer of specialised project management and project governance Web site valuedeliverymanagement.com
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.