With the July 13th release of the Final Rule on Meaningful Use and the Medicare / Medicaid Provider Incentive Program we’ve been pretty busy around here. Here are a few resources we’ve found valuable in helping States learn about the final rule and HIT and HIE in general. We thought you all might benefit from having them gathered in one place:

HHS Webpate on HIT (this includes a link to the final rule document)

CMS Factsheet on Meaningful Use

CMS Fact Sheet on Medicaid EHR incentive Programs

We’re working on an overview for clients that we’ll post soon.

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.

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.

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.