Eight keys to better project governance

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.

Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada

Featured Download

Featured Articles

Cybersecurity in 2024: Priorities and challenges for Canadian organizations 

By Derek Manky As predictions for 2024 point to the continued expansion...

Survey shows generative AI is a top priority for Canadian corporate leaders.

Leaders are devoting significant budget to generative AI for 2024 Canadian corporate...

Related Tech News

Tech Jobs

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Tech Companies Hiring Right Now