As the management framework within which project decisions are made, project governance differs vastly from corporate governance, and unlike the King III legislation that presides over South African businesses, it needs to be fit for purpose per project and organisation.
It is widely accepted that project governance is fundamental to ensuring project success and control. Nevertheless, there is a delicate boundary between too much and too little governance. Too many processes being inflicted on a project team can be just as harmful to project delivery as putting too few processes in place.
The most desirable scenario is creating a project governance framework that allows projects to be fluid and move ahead – as opposed to those that are hindered by too much red tape and unnecessarily scrutinised at every opportunity – but to implement this framework together with a mechanism that provides visibility on current projects and their governance status, so as to understand and manage risks.
And, although I advocate that project governance should be simple and straightforward in order for projects to flow, its importance must not be underestimated.
Project governance is underscored by the overall strategy of a business, and consequently, project managers must understand the objectives and vision of a business in order to understand and appreciate the governance framework.
That is, analyse what the governance processes should be delivering and measure these against the business value that the implementation and monitoring of these provide. The bottom line is, a project governance framework is dependant on the organisation‘s holistic requirements, and should thus be business- and not technical-oriented.
In other words, a governance framework should match the organisation‘s strategy. If the company is a risk-taking and still growing-type of a business, then the framework will be more flexible in order to allow projects greater freedom and accept more risk. However, if the business is a listed, conservative-type financial institution then, likewise, the framework will reflect this. Some of today‘s most successful companies, which were innovative IT start-ups a few years ago, probably did not even have a framework for the first couple of years, as they were experimental, ready to try anything and take the risk.
To create an innovative business environment, a business would ideally like to create a company culture where all employees are responsible for raising ideas and suggesting improvement or change. In order to enable this, the business would need a process in place that is responsible for the logging and review/analysis of each idea. Those ideas that pass the initial screening or feasibility should be moved forward, followed by a high level project proposal or business case so that the project can be evaluated.
It is also critical to review potential projects against each other, as there is always a constraint on time, money and resources, resulting in organisations not executing every project they want to. Projects have to be approved based on their merit in relation to others and when considering the risks, effort and costs versus the benefits the project will deliver.
Only projects where the business case is approved move into “initiation” and the project governance framework will then typically dictate that a project charter be completed.
Determining when to implement a governance process – that is either during the ideas or pipeline phase or only at the true project initiation phase – is completely up to each individual company and is dependant on the type of organisation. The ultimate key is that a business decides where the governance framework begins and how the entry into the funnel is managed.
In addition, it is important to be aware that project governance is not a part of IT governance, but is a set of rules and regulations under which projects fall, irrespective of their type.
Although, in general, project governance adherence is the role of a project portfolio office, in most cases corporate organisations allow various departments or divisions to have their own project offices. This has led to a large number of corporate organisations now introducing project audit teams that typically reside in either internal audit or compliance or risk divisions, and are responsible for the review of the larger, riskier and strategic projects in order to ensure these projects are aligned to the project governance framework and meet the required standards.
Whether or not a business should have one central enterprise project office or departmental project offices? That‘s another debate altogether.