Roles and Responsibilities of a Steering Committee

If you read part 1 of this series you realize a steering committee really does have a legitimate purpose (if you didn’t read it stop now and go read it).  So the purpose is really important but what are you actually supposed to do as a steering committee? A Steering Committee typically performs the following roles and fulfills these responsibilities:

• Develops an operating charter formalizing these roles and responsibilities
• Develop and maintains a set of project “Vision and Goals”.
• Manages scope. The steering committee is directly responsible for determining what features, end products, or scope the project will include.  The project manager is responsible for informing the steering committee what the requested scope will cost and how long it will take to deliver and then managing project resources to deliver that scope within time and budget constraints.
• Manages costs.  Again the steering committee is directly responsible for reviewing and approving all costs associated with the project.  The project manager is responsible for providing accurate cost information to the steering committee.
• Arranges funding.  The steering committee is directly responsible for arranging secure permanent funding for the development and operation of the project.
• Manages project operational and political issues and risks.  The steering committee is responsible for managing and resolving major politics and operational issues brought to them by the project manager.
• Champions business process improvement.  During the project, invariably ways to improve portions of business are found.  It is the steering committees responsibility to act to determine the feasibility of these improvements and, as justified, make them a reality.
• Coordinates with related projects and programs.  Projects do not exist in a vacuum.  Most will touch many other projects or programs in ways that may or may not be envisioned at the outset.  The steering committee is responsible for coordinating with these efforts.
• Develops policy.  The steering committee reviews and officially creates all policy related to the project.  Typically, a sub-committee at the request of the steering committee does policy research.
• Obtains support/agreement from stakeholders.  The steering committee is responsible for obtaining the support and cooperation of all stakeholders by both formal (e.g. intergovernmental agreement) and informal means.
• Resolves obstacles.  Both the steering committee and project manager are responsible for resolving obstacles as they arise.
• Communicates to the stakeholders.  The steering committee takes responsibility for communicating status and needs to all stakeholder agencies.

That’s it.   We hope you found this series of value and use the tools we outlined here as a starting point for your next project.

Part 1 – Purpose of a Steering Committee

Part 2 – Apparent Causes

In this second part of our series on why public sector IT projects fail we’re going to discuss who or what commonly gets blamed for failure.  In our unfortunately all too many postmortems of failed IT projects here’s what we typically find people saying:

Technology

Technology failed us. ”We didn’t have the right tools, We needed different software/hardware/network/programming language and we would have been ok.”  The assumption here is there is some magic technology bullet that would have pushed us over the threshold of success.  It’s possible but highly unlikely in our experience.

Methodology

Our methodology failed us ”We used ABC (insert CASE, SCRUM, Agile, Waterfall, Information Engineering – we’re old enough to have seen them all) system development and XYZ method of project management. If only we had used 123 project management and 456 system development methodology we would have been okay.”  Similar to technology the idea is that there was some magic technique that if followed would have guaranteed success.  This is usually a specious claim as most projects follow little or no real methodological discipline.  Even if followed to the letter a methodology won’t save a project that’s destined to fail.

Staff

The staff failed us. “ We used contract staff instead of state staff. If only we had used our own staff we would have been okay” or “our staff just don’t have what it takes to do a big project like this.”  Most developers are, in our experience and with good hiring practices, very competent.  Same holds for program staff.  Though there are occasions when a slick salesman provides bad resources these are usually weeded out quickly by competent management.

Vendor/Consultant

The vendor/consultant failed us.  “They said they could build a rocket ship but it turns out they couldn’t”.  OK Vendor’s do over commit.  They are in business to make money and will often promise more than they can deliver.  Was this the cause of a projects failure?  Possible but unlikely, the root of the problem was in place well before the consultant was hired.

Senior Leadership/Politics

Our own leadership sabotaged us.  “They never supported this project from the beginning!” or “The political winds were blowing against the project so they case us adrift.”  In our post mortems we’ve simply never found this the case.

The Project Manager

The project manager didn’t understand technology.  ”The manager really didn’t get the consequence of the decisions s/he was making, if only someone technical was in charge!”  or “S/he micro-managed us the whole time!”  Our reviews of failed projects have revealed many a PM who wasn’t a good project manager – but we’ve yet to see a project fail because the manager wasn’t technical enough or spent too much time with the project.

Oddly enough we rarely hear “our Quality Assurance vendor (QA) failed us.”  QA has failed on these projects.  However, their contribution to failure is rarely recognized, after all it was QA that pointed out the failure in the first place.  However, as a buyer of Quality Assurance services you need to ask where was the QA vendor BEFORE failure began, why didn’t they recognize the seed of the problem before it sprouted?…but that’s a topic for a different time.

You’ve probably guessed by now we don’t believe any of these are the root cause of project failure.  At best they might be contributory.  No matter what they are certainly a diversion from finding the real cause and instituting practices that will save the next project.

Next we’ll give you a few ideas about what the real cause of failure might be.

This is the second in a multi-part series of posts analyzing the causes of failures in public sector IT projects and proposing some pragmatic solutions.

Part 1 – Overview

Part 1 – Overview

All major public sector enterprises have an increasing investment in software (and IT in general) and a growing need to earn a better return on their investment.  Recent studies have shown that software projects are often over budget and behind schedule.  Although studies come up with differing numbers, generally statistics show that:

• Over half of all medium and large software projects do not deliver their expected benefit, and exceed their schedule and budget.
• Over half of the medium and large software projects either fail completely (management pulls the plug) or require big recovery efforts to get them to completion.

Software projects, due to their scale and scope present special problems.  Management often over estimates the business improvements with optimistic delivery dates before there is a good understanding of the cost and time it will take to complete the project. User needs change, staff members move on, and the scope, schedule and budget begin to grow. The software development project soon becomes a black hole, into which the organization pours dollars and people. Agency management hears nothing but good news from project management and contractors until it is too late.  The problems start to surface and “blame game” begins; management blames the project staff, the project staff blames the contractor and the contractor blames the project staff.  The end result is a software project that is over budget, delivered late, and the business needs and quality expectations are not met.

So what to do?

This is the first in a multi-part series of posts analyzing the causes of  failures in public sector software projects and proposing some pragmatic solutions.