Project teams have always been constrained by traditional variables such as cost, scope, quality, and time. Today, many project teams must deal with another constraint: Audit and Compliance.
Largely due to the influence of Sarbanes-Oxley legislation (aka SOX), organizations are keeping closer tabs on IT projects. Given the risks associated with many of today’s projects that are globalized and/or Web-enabled and/or have significant financial exposure, increased governance is appropriate. However, it is critical that the organization defines a project governance model that allows projects to move forward at the required pace (note that in today’s world the required pace is often the speed of light; e.g.: we need it yesterday!).
This article points out eight factors to consider when developing or reviewing the project governance model. The objective is a balanced model that protects the organization and its customers and satisfies regulatory requirements, yet allows project teams to deliver their products on time.
1. The governance model should be flexible such that it can be customized based on project risk.
2. Some tolerance for deviation from the governance model must be allowed. It is almost impossible to deliver perfect systems – why should it be possible to deliver a perfect execution of the governance model? The traditional project constraints often exert tremendous pressure on projects; on occasion the project response may require some deviation from the governance model.
3. The governance model must be applied in a collaborative fashion with constructive participation from all. The project manager has to deal with enough natural threats to the project: scope creep, competition for resources, new technologies, concurrent development, managing virtual teams, etc.
4. The governance model should be consistent with modern IT project management methodologies. Some organizations have governance models in place that are based on the traditional waterfall, document-centric development methodologies. However, many development shops have moved away from the waterfall methodology to the iterative model or a hybrid model with a flexible document strategy. Where the newer methodologies are in place, it is not reasonable for the governance team to expect all deliverables to be delivered sequentially in a fixed order, nor is it reasonable to expect every project to deliver a fixed set of intermediate products.
5. With respect to the document-centric approach to governance, consider the 50/50 rule: if 50 per cent of a document is read by 50 per cent of your audience then you are probably doing well.
Some project stakeholders are empowered such that they can stop the project. This empowerment, combined with the 50/50 rule, introduces risk. An appeal process should be in place to ensure that any attempt to stop a project is based on legitimate issues and not noise. Consider making it the responsibility of the dissenting stakeholder to obtain a consensus with several other stakeholders that there is a project issue that is a potential showstopper.
6. Consider an alternative to the document-centric governance approach. Regular approval by a control group and/or steering committee should be enough to ensure that the project is moving forward and that the appropriate process is being applied.
7. Often project audits are done long after the completion of the project as part of some arbitrary audit cycle. Project stakeholders have moved on to another initiative and are pushing hard to deliver their next product. Consider developing a governance model that allows the audit to be done as part of the project’s post-implementation review; this is a point in the project lifecycle where the material is still fresh and the project team is eager to acquire insights that can be applied to future projects.
8. One argument in favour of more governance is the need to ensure that only work authorized and prioritized by the business is undertaken. This is based on the concern that, if left unchecked, IT departments will invent and pursue initiatives on their own without consulting the business. This is a myth. Project governance in the form of Audit and Compliance is required; but projects must move forward every day. A day spent dealing with Audit and Compliance issues is a lost day that will never return to the project. A balanced development/governance model is required.
Al Taylor is a long-time researcher in the field of IT project metrics. A veteran Canadian IT professional, he is the developer and administrator of www.itprojectstats.com, a Web site that gathers statistical information around real-world IT projects.
