Let’s work our way through ‘who makes decisions’ and ‘who is accountable for what’ through the lifecycle of a project from concept to outcome. It starts in the Boardroom where the Board, with the CEO and executive, sets strategic direction.
The interaction between business and IT delivers the Business IT Strategic Plan which outlines the key initiatives the company will implement over the next ‘strategic’ period. These initiatives will be converted into projects through the annual business planning process (see Fig 2).
In the boardroom, the longer term Business IT Strategic Plan and the Annual Plans are key. The plans are the roadmap for the Board. The plans set the criteria for Board decision-making and the framework for board focus, monitoring and measurement.
The board needs to be confident that governance structures (clear accountabilities and decision making frameworks) are in place throughout the life cycle and that the board focuses on the project outcomes and delivered benefits rather than specific project progress.
The bottom line is that, IT governance is not IT management and IT governance is not just inside the IT department.
IT accountabilities and processes cross all organisational boundaries and, from a Board perspective, we need to know that these processes and accountabilities are in place and are being rigorously monitored.
Nota bene!
There is a business decision behind every IT Decision;
AND
Business must be held accountable for these decisions.
Finally, in the context of IT governance, it is appropriate to talk about the relationship between projects and the board. We tend to put huge emphasis on getting IT Project Management right and project governance right on the IT side of the equation. Generally, IT project management reports to the CIO and, if the project has a large budget, then the CIO reports to the board. However, what about the management of and accountability for the 60 per cent of the costs and the delivery of the benefits on the business side of the equation? I agree with the statement often made that there is no such thing as an IT project – only business projects (see Fig 3).
Post mortems on failures tend to come up with common problems including:
project alignment with strategic direction;
poorly expressed business requirements;
complete underestimation of the business effort and impact;
untested benefits cases; and
no plan or project to realise benefits.
All of these problems stem from one root cause: poor governance and organisation on the business side of the equation.
In too many organisations we see the IT project manager doing the job of the business project manager and making business decisions he or she is not qualified to make. As I pointed out before, IT will fill the vacuum to get the job done.
I suspect the rate of project failure would diminish significantly if IT project management disciplines were implemented on the business side of the equation and business took on the accountability for the proper business management of the overall project as described in the diagram above.
So why does not this happen? Why is not the obvious solution often implemented?
I do not have a specific answer but here are three relevant observations:
Running projects is foreign to most business people and for the most part they are not rewarded for implementing a large business project, they are rewarded for achieving bottom line profits. Business management is put in a conflicting situation often short term (business profit) versus long term (sustainability and growth).
Taking people out of line roles to populate a project is an issue. Business managers accountable for the bottom line are loath to put their best staff into projects because the business suffers.
Generally a lack of business transformation skills in the business including process design and change management, the people who would effectively scope the strategic business project, and help business management understand what has to be done to achieve the desired outcomes – these people tend to be in IT.