Consulting engagements that don’t end (that is, they don’t have clearly defined end criteria) are not consulting engagements but on going operations. Consultants that don’t have a clear end to their project are employees not consultants.
Having a set of criteria that defines when your consultant’s work is done is crucial to a successful project. It helps provide you with a sense of progress against plan, assess the performance of your consultant, and offers the psychological relief that you will indeed one day have accomplished something in collaboration with your consultant.
What should mark the end? We can think of at least 4 kinds of criteria that are used to define the “end” of a project. Three for successful projects and one for unsuccessful projects:
- The project end might be tied to a certain date. An example of this type of project is the year 2000 enhancements that had to happen to many computer systems. All work had to be completed by December 31, 1999. Projects with date certain endings do exist but are less common (and beneficial to you) than you might think. Typically having a specific end date benefits consultants more than clients. I’m sorry to say consultants will focus on getting whatever they need to get done to get paid rather than results that benefit you. Quality can suffer.
- The end might be based on the consultant completing some set of “deliverables” (end products). This might be a report or study of some kind, a computer system, or a building. This is some product resulting from the the consulting engagement that you can see, listen to, or touch. Typically you are the judge of quality on this deliverable and approve that it meets your needs. While better than a date certain project, deliverables based projects may have downsides as well. Consultants can get so focused completing deliverables that they ignore your needs and expectations. In some cases (constructing a road for example) this probably doesn’t matter. In other cases (assessing if you have adequate staff to do your work) it does. Overall the burden is placed on you, the client, to assess if the quality of end results meets your expectations.
- There is also a performance based end to projects. More specifically, the project ends when something measurable and agreed upon is accomplished (claims back log decreases by 10% or toll road revenues rise by $100,000). This is generally the most beneficial to you as a client because it defines the end in terms of benefits you want to see. However this is often difficult to operationalize (for example how do you measure a study of the use of WIC funds in your state?).
- Unsuccessful projects end because you or your consultant come to the conclusion the work cannot be finished by a certain date, deliverables of acceptable quality cannot be produced, or one or more performance measures cannot be met. This is obviously not optimal. I’ll mention there’s a version of this that isn’t necessarily “unsuccessful”, a project ends because the original purpose of the project no longer exists (e.g. on a personnel review the individual under review quits).
Successful end criteria can be combined as well. For example a certain report (deliverable of acceptable quality) must be completed by the beginning of the legislative session (a certain date).
Do you know when your project is over? If not sit down with your consultant and hammer out the criteria that defines the end of your project. You and your project will be better off for the effort.
This is part of a series of articles designed to help clients and their consultants have more effective and efficient engagements.
No Comments
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.
No Comments
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.
No Comments
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.
No Comments
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.
No Comments
