Mark Mullaly
April 14, 2008
Managing government projects is a unique challenge. The argument has been made by many (including me) that all projects are alike in nature. While this is true, it is only accurate to the extent that you maintain a level abstraction of the projects. At a summary level, the approach to managing projects is quite similar even if the process of building the results is very different. At 30,000 feet, all water looks drinkable as well. It's when we get into the details that differences emerge.
One of the single most significant attributes associated with government projects, however, is that they are unabashedly political. Government departments and organizations willingly concede that projects exist and are defined because of political demands, and that there are political expectations regarding their results. While private sector projects are often no less political in nature, they are much more likely to be wrapped in a veneer of rationality.
With the politics of government projects also comes the demands of stakeholders, and there are often a diverse number of them--politicians, executives, government staff as well as specific groups of the public and the citizenry at large--who have expectations of what projects are to deliver. The process of stakeholder engagement is a crucial one in managing government projects, but it is also one that is fraught with issues and challenges.
There are three major obstacles to engaging stakeholders in defining the requirements of public projects. The first is simply that there is often no consistent process for how stakeholders should be engaged. Even where there is a process, however, the next question is: Who should actually be considered a stakeholder?
One recent government organization I worked with had in place a 'public consultation process'. This document outlined the strategies, approaches and best practices that had been developed within the organization for consulting with the public. The process itself was actually a very good one. The issue for them was that "public" and "stakeholder" became synonymous--as a result of which only the requirements of the public tended to get reflected in project requirements, even where a much broader set of stakeholders may exist.
The final challenge in engaging stakeholders is the question of just who finally decides upon what the requirements of a project should be. The act of consultation often creates expectations in the minds of those from whom we solicit input. If I ask you what you want from a project, and you state your needs, you also develop expectations that those needs will now be fulfilled. In essence, because you have spoken it, you expect it to be delivered.
Does everything that everyone wants from a project always get delivered? Not by half. What becomes particularly unclear in a government context, though, is who calls the final shots in what a project will and will not produce.
Unlike other organizations, governments have two separate accountability structures. One is defined by the elected representatives--the politicians. The second structure is the administrative organization of government itself. Theoretically speaking, the elected representatives set policy expectations and the administration implements them. The practical reality, however, is that project managers in government often feel that they have two masters--one elected, and the other their boss.
There is an underlying belief that, by dint of being elected, politicians have a divine right to set requirements by fiat. At the same time, the structure of government is often extraordinarily hierarchical--far more so today than what is found in most private sector organizations. As a result, expectations are imposed from the top of the organization and are expected to become fact.
The imposition of expectations--by either the administration or the politician--is not always constructive, reasonable or even possible. One recent project I became aware of is a case in point. A commitment was made to establish a new facility. Approval of funds to proceed with the project was made by the elected body, the budget was established and the politician in whose constituency the project was to be built made the public commitment that the project would be completed that year.
This completely ignored the fact that the land on which the facility to be built had not been purchased, there was no access to the site and the construction of an access road would require traversing land owned by another level of government. Even if the land acquisition could be run through quickly (an unheard of event), there was a 12-month approval process for access permission along with a separate 12-month period required for consultation.
If the organization was lucky, construction might start two years after the project was approved. Under no circumstances, however, was it even remotely possible that the project could be completed in the year in which it was approved. It was simply not physically possible to complete a project of that nature in that short a period of time, and no amount of wishing, wanting or public commitment would change the outcome.
Improving the management of government projects is often presumed to start and finish with the project manager. If the project managers had a better process, or were more responsive, or were more responsible, then projects could be delivered successfully. The challenges discussed so far, however, are not management problems; they are governance problems. How we set expectations, who is able to set those expectations, and who should be included in the consultation process of identifying expectations are all ultimately a product of how the governance of a project is managed.
Arbitrarily defining when or how something should be done on a project or what should be produced, while ignoring the limitations of practical reality or reasonable management, is not the exercise of governance--it is the abdication of it.
In Canada, there have been two reports recently published that have explored the management of large-scale IT projects in the public sector. One, entitled "Report of Ontario's Special Task Force on the Management of Large-Scale Information Technology Projects", was published in July 2005.
In exploring the challenges of managing projects in government, the majority of findings in both reports did not deal with how projects were managed, but in how they were governed. In particular, the Alberta report pointed out the challenge with the comment "If senior managers and executives do not have a clear governance role, projects may not fully meet the needs of the organization, and the change the project is designed to create may not happen."
Common themes in both reports included the need to clearly define what was expected from projects, in terms of both project results and the business outcomes that should be realized in using those results. This incorporated the need to clearly define business cases, define and evaluate the risks associated with the conducting of projects and ensuring appropriate oversight of the projects while they proceeded. For projects to deliver reasonable results, however, they must start with reasonable expectations.
Getting to reasonability in a government context is a challenge. The hierarchical nature of government and the political influence of elected representatives both create significant challenges. Equally challenging, however, is the fact that government is inherently risk averse. The increasing accountability and transparency expected of government organizations, along with the media frenzy that seems to accompany every misstep and failing on the part of governmental organizations, only feeds this risk aversion.
As a result, government project managers operate under a level of scrutiny rarely imagined by their private sector cousins. The challenge is that the nature of risk aversion is not simply in taking bold or innovative approaches to conducting the projects that they are responsible, but also an aversion to disappointing those above them. Consequently, patently unreasonable expectations go unchallenged and conflicting requirements are frequently accepted as necessary imperatives.
Fixing this is not easy, and the answer is not to make government less transparent or to suppress the media, no matter how appealing some may find those solutions. Instead, government must change how expectations are managed. Projects need to fully recognize the full scope of stakeholders that they support, and requirements must be rationalized and aligned across all of these stakeholder groups. The commitments that result from projects must be reasonable, attainable and valued. Attainment of this goal is not something that is in the hands of project managers to realize, however.
As this article has already pointed out, this is a governance problem and it requires a solution at the governance level. Both the elected and administrative leaders of government need to recognize that they play a role in projects alongside their project managers, and that this role comes with not just authorities but also obligations. If project results are expected, then expectations need to be defined based upon what is possible to be produced. This means that sponsoring executives and project managers alike need to negotiate effectively in the context of the processes that define their roles. It might be a lot harder and less desirable to negotiate based upon what is possible rather than simply what is wanted, however reasonable results require reasonable expectations. And expectations start at the top.
http://www.gantthead.com/content/articles/242023.cfm
http://www.gov.on.ca/MGS/graphics/052929.pdf