Case Study: Who’s Even Running This Clinic?

Written by on October 23, 2014

The senior leadership team at a large primary care clinic had reached the final phase of an I.T. implementation. They were about to implement a new system to automate their patient files. As the early development phases of the project were completed largely by the technical team, with sporadic interaction with the user group. As the prototypes for the users were developed, it became clear that the practical needs of the users had not been fully anticipated as the system was developed.

An Unhealthy Problem

Because the community of users who would use the new system most frequently had not been consulted, over time they had become disengaged, even completely distancing themselves from the final version of the product to be installed. Some were openly declaring that it did not meet their needs, they would simply refuse to use it.

How could a project intended to benefit everyone in the organization have gone so far astray?

Identifying and Resolving the Problem

Recognizing that to proceed under these circumstances would almost certainly guarantee failure, management brought in a coach to advise the leadership team, and evaluate where and how the project had gone awry. A moratorium on implementation was declared while the project was re-evaluated from the fresh viewpoint.

  • Identifying the Source of Dissatisfaction – In discussions with the leadership team, it was quickly determined that the new system had been developed with an I.T. user in mind, not from the perspective of the actual users (the healthcare practitioners) of the system.

  • Clearly Establish Roles and Responsibilities – Using the RACI (Responsible, Accountable, Consulted, Informed) model, which is used for determination of roles and responsibilities during organizational change, it became clear that the project should have been headed up by the Operations director, not the I.T. director.

    The RACI model for this process change clearly showed that there needed to be mutual accountability between Operations and I.T., but that I.T. should not be in charge. Furthermore, it was apparent that the over involvement of the company’s financial experts were compromising the end product in an effort to achieve short term cash savings. The responsibilities model made it apparent that Finance really should only be involved to monitor the budget for the project and ensure that the appropriate savings were achieved post-implementation.

  • The team worked with their coach to very carefully refine the RACI model, and achieved consensus on a practical and workable approach for the ongoing management of the project.

  • Correct the Process – As a result of this review, some development components were altered to reflect the users’ true requirements, and the order of implementation during roll-out was significantly revised to support the optimum Operations perspective, rather than the original I.T. view.

An Approach Everyone Can Agree With

While the new system has not been fully implemented, the results from the first phase of rollout are very encouraging. System reliability has been reported to be very high, and the user community has demonstrated their acceptance by having a very high adoption rate.

This was a project that may have been headed for disaster in its original state, because it had actually been headed up by the wrong department, and was not consistent with users’ true needs. This is not uncommon, and it can be very difficult for someone on the inside of a leadership team to step forward and concede that they are perhaps not the right person to lead a project.

In such instances, a team coach can be extremely beneficial. As a neutral 3rd party, a coach can challenge assumptions made thus far, see the problem, express it clearly to all concerned, and work with the team to get the project back on track.