Why no less?  This one is kind of obvious.  If your consultant is doing less than you need you won’t get what you require.  Consultants will do this consciously if they are behind schedule and/or over budget.  We see it when we are providing QA for large system projects.  For example, the development vendor is behind schedule/over budget and they try and convince the client that they don’t need as much system testing or that the bugs can be fixed after the system is implemented.

Why no more?  There are really a few reasons here.  First if your consultant is being paid by the hour – it’s costing you money!  The more subtle but important reason is even if your consultant is on a fixed price contract doing more costs time.  Your projects won’t finish on time.  Allowing your consultant to do more may also distract them from doing their best on more critical tasks.

How do you make sure your consultants are within scope?  Here are a few simple suggestions that will go a long way to making sure what you need is delivered on time and within budget:

• First every project no matter how small should have a work plan.  This can be something as simple as a to-do list or as complex as a full blown task plan identifying task, task dependencies, timing, work effort, staff assignments etc.  Don’t worry the technicalities; your consultant should make their task plan available to you.
• You should review the plan before work begins and clearly understand how each to-do or task contributes to the end product you need or want.  If there are tasks that don’t appear to contribute ask your consultant why they are in there.  If something appears missing ask why it’s not there.  Remember every work step should contribute to the end result you hired the consultant to produce.  Be persistent until you get an answer you can understand.
• You should review the progress against plan on a regular basis with your consultant.  Regular status meetings are a good place for this.  Get them to tell you what they’ve done from the plan.  Be careful they’re not doing work that isn’t listed on the plan.  If they do things not on the plan ask them “why?”  If they are skipping tasks on the plan ask them “why?”  There may be very legitimate reasons.  Perhaps they forgot something that should be in the plan (have them add it to the plan) or there are things in the plan that really don’t need to be done (have them explain why and then remove it from the plan).  If there is work you think should be on the plan but isn’t raise the issue with your consultant.
• Last, as your project closes an easy way to verify your consultant has done what they promised is to review the plan to verify that each task is complete.  This doesn’t guarantee what they did meets your needs – just that they did what they said they’d do.

Shouldn’t managing the work plan be the consultant’s responsibility?  Absolutely.  We’re not suggesting you manage your consultants plan – what we are saying is you need to continually verify the work being performed will get you what you need.  Believe it or not consultants don’t always think about whether the work they are doing is leading to the result you want.  Many consultants get bogged down in the day-to-day work and loose sight of the big picture.

It is prudent for you as the buyer of consulting services to verify the project scope will lead to the result you want.

This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.

At the start of every engagement you need to develop a clear set of expectations describing what you think will be different when your consultant is finished. An expectation can be something as simple as you’ll no longer have to deal with a specific personnel issue or something complex like you’ll have a fully functioning Medicaid system. You’ll likely have more than one expectation.

How do you go about figuring out what your expectations are? Use your imagination and pretend it’s 6 months after the consultants have completed their work. Everything is, of course, perfect from your perspective. Now ask yourself “What’s different now than when we started? What changed?”. Write down your answers. These are your initial expectations.

You need to share these expectations with the consultant at the start of the project (note: good consultant’s won’t wait for you to share it – they’ll try and drag your expectations out of you the first time you meet).

Does this mean the consultant will meet all your expectations? Of course not. When you present your expectations good consultants will inject their experience and knowledge into the conversation (that’s the reason you hired them right?). You’ll jointly develop a set of mutual expectations for your project. This is a good thing – it gets both you and the consultant bought into a common set of outcomes for the project. The jointly developed set of expectations should be written down used to regularly assess project progress and ultimately the success of the project.

Projects without a set of shared expectations wander ending up “somewhere else”. The question for you is “do you and your consultant know what will be different when the engagement is done?” If not perhaps it’s time to develop some mutual expectations.

This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.

The graph shows most of the effort in large system development goes into removing defects. Defects can occur in the feasibility, requirements, analysis, design, and coding phases of a project. The sooner a defect is detected in the development life cycle the less expensive it is to correct. So, defects detected in requirements are relatively inexpensive to correct whereas a defect in code is significantly more expensive to correct. Once a system is in operation defects are very expensive to correct. Think about it: not only do you have to fix the code but potentially you fix documentation, retrain users, etc.

So this all begs the question – where do you put your effort and resources during the development of a large system like an MMIS? Focus on quality early (rather than waiting for the testing phase of a project) saves money.  A modest investment in quality assurance or independent validation and verification up front results in real dollar savings down the road.

The graph points out some interesting things:

• 72% of large projects (MMIS and TANF systems fall into this category) are late or fail (about half FAIL)
• Only 28% of these systems are delivered on time
• Virtually none are delivered ahead of schedule

Based on these statistics there is a high probability that your next project will at least be late. In the coming weeks we’ll analyze some of the reasons why.

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

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

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.