Yogi Berra said “If you don’t know where you are going, you will wind up somewhere else.” This certainly applies to consulting engagements. If you don’t begin with a picture of where you want to end up you won’t get what you want (or need).
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.
A simple fact: you need someone to manage consultants to get your money’s worth out of them. We have seen, and been in, situations where no one was in charge of consultants. These projects were chaotic from both the perspective of the consultant and the client – and clients didn’t get much value out of their hired consultants. Some consultants will even take advantage of this situation. They unilaterally expand the scope of their work and run up excessive bills. In most cases unmanaged consultants leave clients with a bad feeling about consultants and consultants with a bad reputation.
It significantly benefits both client and consultant if a single individual, from the client, is responsible for overseeing the consultant. Typically this “client manager”:
- Gets regular status updates from the consultant;
- Coordinates the consultant activities within the client organization;
- Ensure any products the consultant delivers meets agreed upon timeframes, standards, and need;
- Communicates relevant information to the consultant and within the client organization;
- Handles any issues and problems that occur during the consulting engagement;
- Reviews and approves consultant invoices and manages financial issues;
- Handles contractual issues (or takes issues to the contract manager); and
- Fires the consultant if they are not performing.
Who this individual is depends on the nature of the engagement. Sensitive organizational assessments or reorganization projects might report to the head of HR or the agency director. On our QA projects we typically report to the project sponsor. For coding projects it makes sense to have your consultants report to the development or project manager. One way to think about this is to think about who will pay the price if the consultant (or project) fails – that is the person that should be in charge of the consultant.
Some common mistakes we see in setting up a client manager include:
- The client manager is him/herself a consultant rather than an agency employee;
- Consultants report to a “committee” of some kind (we’ve found this has the same result as having no one in charge); and
- The client manager is a low level staff person with little or nothing riding on the engagement outcome.
So the question for you is who is in charge of the consultants around your organization?
This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.
We’ve seen a trend lately of potential clients requesting we devote staff full time to projects. This seems particularly true of our IV&V and QA projects. We think the reasoning is probably based on at least three factors. Clients:
- Are tired of consultant bait and switch strategies where superior resources are bid (and may even start) on the project but less experienced staff show up and do the bulk of the work;
- Want rapid access to known consulting resources for projects; and
- Want to make sure there’s continuity on project issues and tasks provided by the consultant.
There are however downsides to having consultants devoted exclusively to your project. Consultants:
- Become myopic over time and miss critical issues and solutions a fresh pair of eyes might catch;
- Are costly resources that should only be on board when they are needed, when they’re not fully utilized (and there are always those down times on projects) you don’t want to pay for them;
- Stop bringing in new ideas and experience gleaned from other projects that might be just what you need to thrive; and
- Become viewed as staff and their unique experience and voice is no long heard.
Of course we’re not suggesting the elimination of consistent consulting staff on your projects. You do need continuity and responsiveness. And we are also not suggesting consultants should be swapped out regularly. Just be aware there are hidden costs to demanding consultants be devoted full time to your project (particularly on longer projects) and benefits to having “fresh legs” in the marathon that projects can be.
Medicaid Management Information Systems (MMIS) are some of (if not the) largest and most complex systems states have to deal with. We’ve been around long enough to know they need to be replaced every 10 to 15 years and are costly to develop. What most states don’t know is when developing systems of this size the bulk of the work goes into removing defects, problems that keep the system from functioning as it should. The graph below is based on information from Capers Jones (from his book “Applied Software Measurement”) for MMIS sized systems.
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.
Large public sector projects are almost always late, we’ve already asked if this matters, today we’re going to show you just how many big projects fail or are late. We ran across some interesting data from Capers Jones (from “Estimating Software Costs” – 1998) that we turned into this graph:
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.
