July 3, 2010

Vermont: Creative Thinking in Handling Budget Crisis

Vermont is using some creative thinking to handle its budget issues. Pensions (as you all know) are becoming one of the biggest burdens on State budgets. Legislatures are either cutting existing pensions (which is likely not legal) or creating multi-tiered pension systems where newcomer’s pension benefits are significantly reduced (This will have the effect of driving new people away from government). State employees we’ve talked to (and the unions that represent them) feel both undervalued and infuriated by these moves.

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?


June 23, 2010

Client Survival Guide: Communicate!

If you only take away one piece of advice from our Client Survival Guide make it this: make sure you are communicating regularly with your consultant. If you feel you aren’t, STOP your project and call the consultant in for a face to face meeting to discuss how and when you’re going to meet face to face in the future. After having conducted hundreds of project post-mortems we can tell you the single thing most often responsible for a project failing is lack of communications between client and consultant.

We’re not talking about written communication (emails, status reports, consulting deliverables etc) but face to face interaction that occurs in both formal (status meetings) and informal (water cooler talk) settings.

Formal (in person) status meetings should occur regularly and always include discussions of:

  • Project risks and issues;
  • Status;
  • Resources;
  • Scope;
  • Mutual expectations; and
  • Consultant performance.

Informal communication should occur more frequently. We’re not necessarily talking about an hour long conversation. A 5 minute clarification (“hey I was thinking about this…what do you think”) can suffice. Informal talks serve to strengthen the relationship with your consultant, establish an atmosphere of trust, set an expectation that regular informal communication will occur, and provide minor course corrections that keep the project on track with your expectations. You can hold informal conversation via telephone (or video conference) too but these are not always a substitute for face to face conversations.

How frequently should you meet? Well that depends on the size and pace of your project. With very large projects where things move very fast (e.g. IV&V on a Medicaid system during the testing phase) formal status meetings should occur weekly and two to five informal contacts per day. On smaller project spread out over time (e.g. executive coaching projects) perhaps a monthly status meeting is sufficient and expect a few informal contacts a week. There’s no hard and fast rule except you, as the client, should never feel out of the loop regarding your project.

Don’t ever be afraid to “bother” your consultant with requests to talk. You should have several ways to contact them and know when the next formal meeting will be (if you don’t time to call them in).

Good consultants want lots of communication with you because they know it helps make a project successful. They will hound you for time. If you have a consultant that doesn’t want to meet or you find communication occurs only at your repeated request, honestly, you’ve hired the wrong people – throw them out.

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


June 18, 2010

Who Should be on Your Steering Committee?

These past few weeks we have been assessing a very large multi agency project.  As part of our review of project governance we attended a few steering committee (SC) meetings. Here are some of our observations:

  • The project manager (PM) chaired the committee;
  • The PM spent a great deal of time discussing minute details of the project schedule, detailed technical design decisions the project had faced, and each and every risk the project faced (upwards of 100 risks in the meetings we attended);
  • The meetings were scheduled twice a month for four hours;
  • When time was running out the PM (committee chair) read faster to get through the agenda;
  • No steering committee member asked a single question in either session we attended but they all took notes;
  • Several attendees were delegates for someone else (when we asked why, we were universally told “well the actual member is a very busy person…”);
  • Most of the members were people who would be impacted by the project but did not have the authority to make a final decision about project issues;
  • When decisions were called for long debates ensued on even the most trivial items and ultimately few decisions were made;
  • When issues of importance (things effecting scope, schedule, cost, quality, or project resources) were brought up decisions were always deferred for another time;
  • All members reported they took their notes back to their respective agencies and e-mailed them to their “boss”.  It was unclear what, if anything, happened as a result of this e-mail.

Behind the scenes, when the need for an important decision reached a critical state (i.e. the project couldn’t continue without some joint decision being made), the PM would take this issue to his agency director who in turn would call the other agency directors and jointly make a decision.

The steering committee here is what we refer to as a “shadow committee.”  They don’t have the authority to do much and when large decisions are required the people really steering the project have to step in (in this case the group of agency directors).  There are several issues that arise with shadow committees including:

  • Decisions tend to get made only when the pressure to do so is very high.  This generally puts projects behind schedule;
  • The decision makers never have all the information they need (in this case for two reasons: They didn’t attend the SC meetings and the information disseminated at the meetings was at too low a level);
  • Gathering the real decision makers can be difficult and time consuming because it is done ad-hoc;
  • The meetings waste the time of shadow committee members and they know it; and
  • Shadow committee members become demoralized because they really are not contributing to the project and they know it.

We’ve talked about what the roles and responsibilities of the SC should be (here and here).  But in order to fulfill these roles and responsibilities, steering committee members need some authority.  This leads us to the question “Who should be on your steering committee?”  Here are a few simple criteria for choosing steering committee members:

  • Members must have some skin in the game.  Generally, the larger the stake they have the better the fit they are (there are some exceptions to this).  Members need to have motivation for the project to succeed;
  • They must represent project constituents. As a whole, the committee should represent all those impacted by the project;
  • Members need the authority to make decisions on behalf of their constituents and authority over the project team itself (more on this below);
  • They must be willing and able to work with other committee members (having members who constantly clash violently about the project is a no-win situation);
  • They must be able to perform the roles and fulfill the responsibilities of the steering committee (see our previous discussion mentioned above); and
  • The committee should have a clear line of authority over the project team.  Committee members should not be part of the project team (note the project team might attend the SC meeting – just not be a voting member of the committee).

Choosing the right members for your steering committee will greatly increase the odds of your project succeeding.  Go look at the criteria above and ask yourself:  “Do I have the right people steering my project?”

Note: The particular steering committee mentioned above still has some issues.  They include inappropriate agenda, excessive number and duration of meetings, and the lack of a decision process.  But we’ll save a discussion about those issues for another time.

June 9, 2010

Client Survival Guide: When is it over?

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.


June 2, 2010

Client Survival Guide: What’ll be different when you’re done?

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.


May 25, 2010

Client Survival Guide: Who’s in charge here?

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.


April 30, 2010

Client Survival Guide: Downside of Full Time Consultants on Your Project

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.


Read More →