• 10% to 15% for small systems, 
• 30% to 35 % for large systems.

This “scope creep” or expansion of the functionality usually occurs because either:

• The systems users are able to persuade the systems developers to add various “bells and whistles” enhancements, or
• Parts of the specifications were vague in the first place, and full exploration of their implications causes significant additional work to be added project.

The solution to scope creep has three parts:

• Develop sufficiently complete and detailed specifications in the first place, to remove vagueness, ambiguities and room for misinterpretation,
• Ensure that the customers (users of the future system) participate meaningfully in development of the specifications, and fully understand them and their implications, and
• Carefully manage the change control process.

We will discuss what constitutes “sufficiently complete” specifications, meaningful participation, and management of the change control process in future posts.

• A risk is an event that may occur on a project that will have a negative impact (for example increase the time or cost to complete a project).  Note that a risk may occur. It is not a certainty (it has a less than 100% probability of occurring).  From a theoretical standpoint it is possible to have a risk that will have a positive impact on the project (shorten the time or cost of a project) but in quality assurance we typically don’t assess risks that could have a positive impact.  Optimizing project outcomes are left to project management.

• An issue is an event that the project will or currently faces that will/does have a negative impact.  That is, an issue has a 100% probability of occurring.

The key differentiator here is risks are something that have some likelihood (probability) of occurring in the future.  An issue is something that will occur or is occurring.  Issues “will happen or are happening” and risks “may happen”.

A concrete example:

• There is a risk a project may lose staff.  We may even be able to assign a probability this risk will occur based on expert opinion or past experience.  We can build a plan to address this risk should it occur.  The plan might dictate by staff position what we will do if a staff member leaves the project.  For example if we lose the project manager we will temporarily promote the deputy project manager to manager and begin the search for a replacement.  We can also do some things to lessen the likelihood a risk will occur.  In the “loss of staff” risk example above we might offer project completion bonuses to increase staff motivation to stay with a project through completion.

• There is an issue if a staff member leaves the project and we have to act now to replace her.

Obviously identifying risks before they become issues and having plans in place to address them is preferable to having an issue arise for which we are not prepared.  In some cases it is even possible to lower the probability a risk will occur or even completely avoid the risk.

Here is an overview:

• The project was authorized by the State Legislature to find a more precise way than client/staff ratio to determine the number of staff needed to provide services (although truth be told they really wanted to prove that the agency had too many staff) and to identify process improvements and other cost savings (who wouldn’t want that).
• We studied Food Stamp and Medicaid Eligibility, Adult Protective Services, Case Management in Long Term Care and TANF, Vocational Rehabilitation Counseling and Employment Related Day Care and Medicare Part D.
• Our methodology was rather innovative. Historically staffing or workload studies are often done to determine federal reimbursement and use Random Moment Time Studies where workers carry a beeper and record what they are doing when the beeper goes off. This produces a lot of data but only quantifies what workers are doing now -  not what has value or what could be done differently and how much time could be saved. We developed a “triangulation” method – using multiple sources to quantify workload and improvement opportunities. We typically used site visits with staff interviews, direct observation and process mapping (much of the site visits protocols we now use were developed here); electronic surveys of all program staff (with “reasonableness” checks); best practice searches,  and focus groups.
• Our results were presented as high level process maps that showed tasks, how long each task took, and how often the task would be done each month. For example, we calculated how many minutes it takes to process a food stamp application multiplied by the expected number of applications and divided by the number of minutes available per worker to give us a staffing level. We could demonstrate the savings in time and dollars if tasks were done differently. We also proposed some major changes in the model for doing case management and vocational rehabilitation counseling – using the case manager as a team leader with para-professionals doing tasks that did not require case management credentials and expertise.
• Much to the delight of the legislature -we showed the  expected cost savings for process improvements. For example, one of the easiest process improvements recommended and subsequently implemented was to synchronize eligibility redeterminations for clients. Clients were typically receiving multiple services from the agency (Food Assistance, Medicaid, etc.) but the time periods for re-determining eligibility for each service was different. Agency staff would review the same information for a client for one service and then later review the same information for the same client for a different service. By synchronizing the time periods for these reviews the agency could save approximately 2.6 million dollars per biennium (one-half of which was the state’s share).

We have used this methodology in both large (as noted above) and small studies as well such as a study of clerical services for a county senior services office and found equally successful results.

Leo Laporte (of the “This Week in Tech” podcast) also has a video segment with some interesting discussion (he includes several government technology leaders in this discussion) here.

Sooner or later your stakeholders are going to get wind of this (if they haven’t already).  You’ll begin to hear questions like “Why aren’t you using open source to lower costs?” and “How can we get access to your data?”.   We’ll be examining some of the “Government 2.0″ initiatives, how it might be used in your agency, and some of the the challenges to this movement in future posts.

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.

We recently ran across this article from stateline.org which describes how Vermont sat down with their unions to jointly resolve part of their budget crisis. A little outside the box thinking went a long way. Kudos to Vermont for thinking creatively and turning a potentially adversarial situation into a win for both parties.

Are you applying creative solutions to your problems?