• 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.

They had constructed their procurement around a typical strategy: Identify the 3 or 4 categories of things that mattered to them (for example: solution provider experience and viability, solution fit with requirements, and cost), weight those things, and score the vendors on them. In this case here was the problem: in these tight economic times cost was viewed as critically important and given a high weighting. Vendor’s know this and game the system by offering a minimally acceptable technical solution and low-ball the costs. They do this fully expecting to get further revenue through the change orders they know a customer will request (because they understand their proposed solution doesn’t meet the clients real needs). In the case of our client so much of the score was based on cost that the process resulted in a clearly inferior product “winning” the procurement. So what are some strategies for avoiding having an inferior product come out on top?

• Having well defined requirements will help. This will allow you to better compare the solutions vendors propose. It is however, difficult and time-consuming to develop a detailed set of requirements. Because you don’t typically do requirements you will probably not have the skills in-house to develop these well. A third party specializing in developing requirements can pay dividends in the end.
• Unless you are purchasing a commodity item, like pencils, consider a “value” based procurement instead of strictly a “cost” based procurement. There are multiple ways of evaluating value, for example, score the “value” of a proposed solution by considering the cost per technical point. This will mediate “cost” based gaming of the procurement.
• We’re not suggesting total cost doesn’t matter. In your procurement strategy leave yourself room to negotiate total cost. Pick the vendor with the highest “value” but leave yourself room to cut the total cost of the proposal by cutting scope. Have a pre-contract negotiation phase where you can negotiate scope (and therefore total price) with the vendor.
• If your local procurement regulations prohibit pre-contract negotiation consider a best and final offer (BAFO) solution. In a BAFO, you give the vendors a chance to sharpen their pencil’s (and scope) and come back with their best offer. This doesn’t always steer procurement to best value but it can help lower total costs.
• Lastly, test your procurement strategy. Consider all possible scenarios (e.g. A vendor has a low total cost and high technical scores), document them, and run an evaluation of the results. Are the results what you thought? Perhaps you should revise your scoring strategy.

The most import lesson here is HAVE a strategy before you release a systems procurement. If you don’t procure major systems regularly (and who procures multi-million dollar systems regularly?) get some assistance with your procurement.

• 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.

We base our advice on empirical data.  The most conservative stance (from a business perspective) we can take based on the data available to us is that our clients should continue to prepare for the implementation of the law.  We’re in for a long road ahead (both the legal battles associated with and work required to implement the ACA) and the deadlines are looming

• Many of these initiatives are falling on state insurance commissions to implement because of their knowledge of state insurers. The interface for an HBE is required to determine eligibility and enroll eligible participants on the spot. This part of an HBE makes it more like an entitlement or grant program (Medicaid, TANF/SNAP etc). There are two technical challenges here. First, insurance commissions don’t have experience running large scale eligibility and enrollment programs. Second the IT staff of insurance regulators is typically quite lean, i.e. they don’t have the staff necessary to build and run the infrastructure required for such programs.
• States will need to make a decision early if they will support a single solution for all HBE needs or have separate solutions for individuals and small businesses. The needs of these two groups are different and alternatives must consider requirements for both groups.
• Developing an effective user interface (UI) to compare plans will be difficult. Insurance plans are not developed in a manner that promotes easy comparison. Different insurance companies often use variations in the way plans are presented to market their strengths. In addition to the policy implications associated with this there are also technical development considerations: How can plans be displayed and prepared? Should there be other features on an HBE site (e.g. health education information)? And, what are the best ways to design sites focused on consumers?
• The Federal Government recommends that states have a common web based front end for HBE Subsidies, CHIP and Medicaid programs (section 1413 and 2201 of the ACA). This includes both determination of eligibility and enrollment for these programs. Developing effective web front ends for any application is challenging. Finding an effective means of utilizing other state information services (eligibility determination and enrollment for these other programs) represents a challenge few states have conquered. Collaboration between agencies running entitlement and grant programs and the insurance agencies technology divisions will be a must to make an HBE work.
• Related to eligibility and enrollment, the volume of potential enrollees in an HBE supported plan will dwarf the current number of Medicaid users in a state. They will enroll over a relatively short time period. Insurance providers will need to be in the system. HBE projects need to plan an approach that gets insurance providers in the system and can screen a large number of applicants in a short time.

We are working with our clients to address these challenges. As common solutions emerge we’ll share those with you (along with other challenges we find!).

Thanks to all our clients who have helped make this one of the best years ever for us.  We appreciate you and the work you have entrusted us with.  We look forward to continuing to serve you in 2011.

From a consultant’s perspective it’s much easier to write a long complicated document than a concise one. Simplicity is hard. But by providing clear, concise, and short reports we’ve found the odds of adopting and implementing the results of a consultants work significantly improve. It’s a sign your consultant really understands the material they are presenting (it’s easy to hide flaws in a big complex document) and you are getting a well thought out solution. Further, a report written clearly and concisely can be shared with broad audiences without a lot of accompanying explanation.

The take away here is pretty simple. Sit down with your consultant and discuss your expectations for written reports. Think about who will be reading the report. Will it be the Governor, legislature, governing council members, senior or mid level agency executives? Will they read a 300-page document? Doubtful. Simple and concise will win the day here.

Should every report be simple and short? Of course not. System requirements or design documents will tend to be long and fairly complex (though they should be as clear and concise as possible). But a greater level of detail is expected by and required for the audience of these types of documents.

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