There have been several posts on LinkedIn recently about IT Steering Committees—what their charter is, what information they should have available and how they should interact with IT implementation project teams. The Steering Committee is one component of IT governance and how it interacts with other components can determine whether the Committee is performing properly, or not. Mark Moore recently posted an article entitled “Asking the Right Questions,” in which he recommended that the Steering Committee focus on two questions in discharging its responsibilities: “Should we do this?” and “Can we do this?” These are certainly important questions, but there is even more to good governance that must be addressed.
Before, During and After
In many cases, the Steering Committee is focused exclusively on the “Should we and can we?” prior to funding a prospective initiative and then its involvement in IT governance stops there. This classic role provides only a wisp of governance and misses the opportunity to consolidate it into a robust force that integrates information and expertise to exert control over IT investments and project execution practices more fully. In order to reach its potential, the Steering Committee must have an oversight role:
- Before: Projects must be fully vetted before they are funded. This includes assessing how the completed project will contribute to the enterprise’s strategic and operational goals, how feasible the project is, what the risks are and how well they will be mitigated and what the time required and costs are expected to be. It is also crucial that projects’ sponsors and stakeholders identify and commit to realizing promised benefits as a precondition of approval.
- During: Projects’ progress must be closely monitored for execution progress and quality and for continued validity. If execution runs into roadblocks that change the cost/benefit ratio sufficiently to diminish the return below an acceptable level or if exogenous events invalidate the strategic value, then a project should be terminated. It may also be that opportunities to change or expand an initiative are identified while it is in progress and there must be a defined path to make these changes, as well.
- After: Way too many organizations never revisit completed projects after the fact to assess whether the expected value was received for the time, effort and money invested. Needless to say, it is impossible to improve decision-making capabilities without retrospective assessment of past successes and failures and elaboration and dissemination of lessons learned.
Components of the IT Governance Structure
Given the broad scope of competences required, how can the Steering Committee discharge its responsibilities? It has to integrate the knowledge and experience of a number of other disciplines.
IT governance should include the Steering Committee, the Enterprise Architecture group, the Project Management Office (PMO), the IT Audit function and, of course, IT, itself. Companies may not have all of these disciplines broken out into separate organizational groups but the functions they perform are necessary to good governance. Here’s what each of the components do:
- IT Steering Committee: The Steering Committee sets priorities for IT. It is, in essence, an investment oversight committee, reviewing potential investment in IT initiatives. It should also be, but frequently isn’t, charged with monitoring IT performance on executing projects.
- Enterprise Architecture: This group should maintain an “as-is” and “to-be” views of the enterprise, comprised of its people (organization structure), processes (workflows) and technology (its ICT infrastructure.) It works to improve or optimize the enterprise’s ability to execute its strategy, developing “to-be” models that will produce better operational results and identifies transformation paths from the as-is to the to-be. When an IT initiative is brought to the Steering Committee for funding, the EA function should be consulted to ascertain where and how the project is expected to contribute to the company’s current or future Enterprise Architecture.
- PMO: The PMO is responsible for establishing, publishing and training project teams in project management practices and for providing expert oversight of projects in progress at a technical level. The PMO should provide the steering committee with guidance on issues such as the validity of project planning and risk mitigation and in-depth assessment on projects’ progress while they are live. The PMO is also usually charged with compiling lessons learned and communicating good practices to project managers and teams to promote continuous improvement in project management practices.
- IT Audit: More often than not, IT Audit is subjugated to matching invoices to purchase orders and administering contracts for IT-related services. While this is important, IT Audit could and should be doing more. Specifically, it should be assessing whether the benefits on which initiatives were approved are actually realized. As hard to believe as it may be, most of the companies that I have worked for never conducted post-execution project audits, never identified systematic errors or opportunities to improve and never found out whether value was received for the projects they did. They just blindly went from one initiative to the next, winning on some and losing on others.
- IT: IT must also play a role in its own governance by providing requested information but also by educating the Committee about the decisions it needs to make so that the Committee’s instructions can be structured in a constructive way. Issues such as projects’ feasibility and fit with the company’s technology strategy, dependencies among projects and departmental competencies should all influence Committee decision-making and must be understood by the Committee for it to function properly. It is IT’s responsibility to establish a common understanding in these areas with the Committee.
- The Organization’s Operating Units: Ultimately, it is the operating units that should receive the benefits from end products of IT’s work. The operating units should be the ones making funding requests and it is imperative that they provide their share of the information required for the Steering Committee to review and approve or decline requests for funding.
Before, During and After
In the expanded view of the context in which the Steering Committee should operate, we can see who should be involved in answering “Should we?” and “Can we?” in the context of the lifecycle of an initiative.
Before:
- Should We?
- Business Operating Unit: Project Funding Request—WHAT (in terms of Technology, Organization and Processes) is needed and WHY? What assumptions underlie the proposal? What are the benefits and what do we estimate the costs will be? Has the operating unit taken ownership of the project and assumed responsibility for realizing the projected benefits?
- EA: How do the project’s work products fit into the company’s strategy or operating models? Are there any facets of the project, as proposed, that should be modified to account for dependencies on or needs for integration with other existing or planned systems or technology? What elements of this project may be reusable or sharable?
- IT and PMO: What are the major assumptions on which the technical design is based? What is this going to cost, how long is it going to take, how risky is it? What are we doing to manage risks?
- Can We?
- IT: What are the risks in the technological solution we propose? What alternatives were considered? Do we have the expertise in-house to do this?
- Business Operating Unit and EA: What plan is in place for organizational changes that may be required? What are the costs and risks associated with making those changes and how well are the risks mitigated?
- PMO: How comfortable are we that the project can be executed as planned and that the risks are properly managed?
- IT Audit (and/or Purchasing): Are the unit costs budgeted for the various elements of the project in line with our current best market prices?
During:
- IT and PMO: Are we progressing as planned? Are the issues to be addressed? Is the project’s risk profile changing and are newly-discovered risks being managed properly? What adverse or opportunistic events have occurred and how were they dealt with? Are change controls operating properly?
- IT Audit: Are costs in line with expected progress?
- Business Operating Unit: What is the status of any organizational transformation necessitated as part of the project? Are there any issues requiring senior executive attention? Is there any potential schedule impact to the project?
After:
- Business Operating Unit: Is the work product what was expected? Has it passed QA and UAT? Are the benefits planned for being realized? Have organizational and process transformations been accomplished?
- IT and PMO: Did the project complete within the baselines (scope, time, cost)? Were there significant variances in PM performance from the company’s standards? What have we learned from this project that can be useful to future projects?
- EA: Have the results from this project been added to the new “as-is” company model?
- IT Audit: Ultimately, what were the actual costs of this project? Objectively, are planned the benefits being realized?
- ALL: For any element of the project that did not go as planned, or for any element of benefit that is not realized, why and what do we need to do to ensure that we do not have the same shortfall on future projects?
As you can see, there is a lot to IT governance. Getting the right people involved and setting the right scope of influence can enable the Steering Committee to have a very positive impact on the success of your IT projects.