‘This is not an IT project’

In order to gain buy-in and support for an important software application implementation, some IT leaders announce: This is not an IT project!

But is such a declaration sufficient to generate a successful implementation or high levels of adoption? Can the IT leader really expect operations users and senior leaders to know what is expected of them when you announce the project is not IT driven?

Don’t just say what it isn’t – say what it is

For many software application implementations, IT leaders are right to position the project as non-IT led. But they must not stop short of providing a definition of what the declaration means, why it is important, and everyone’s responsibility in the implementation project. If a project is truly not an IT project, it should exhibit these basic characteristics:

1. Operationally owned
2. Operationally led
3. Operationally staffed
4. Operationally measured for success
5. IT supported

Many experienced IT leaders have learned that when operational leaders think a project is IT led, they are apt to be less engaged or assume a hands-off approach, waiting for IT to magically solve their problems with an on-time, on budget software application go-live.

When such is the case hard working, well-meaning IT professionals might find themselves in a difficult situation, falling short of user expectations or running aground of mixed expectations.

Leadership matters

Without adequate operational ownership IT leaders could even find out too late they have been solving the wrong problems or solving the right problems the wrong way. Software applications are built upon assumed processes, procedures and workflows. But without the vital leadership of operational subject matter experts, IT implementers may believe the delivered application will meet users’ wishes only to discover after go-live that some of their assumptions about users’ desires were wrong.

Additionally, without senior operational leaders being held accountable for implementation success they may not be willing to commit adequate operational resources to the effort, especially if they are struggling with scarce resources.

How this works in practice

Leaders of a large health care organization applied the above principles of non-IT led this way. The CIO and CEO came together as a dyad and developed their plan to lead the implementation of an electronic medical record.

Before the project was introduced to the organization, the two leaders had already mapped their plans, protocols, and communications strategies. The CEO positioned himself as the executive owner of the project and established a steering committee of his top direct reports. The CEO became the chairman of the steering committee and the CIO sat by his side as the meeting facilitator. The CEO assigned each vice president responsibility for the efficiency and effectiveness of one macro process.

For example, he made the CFO responsible for revenue cycle go-live success; the Chief Medical Officer for Clinical Orders and Results; Admission Discharge and Transfer processes went to the Vice President of Clinical Operations; Lab, Radiology, and Pharmacy processes fell to the Vice President of Ancillary Services; and so on.

The CEO informed the team that the CIO was available to support them, but was not responsible for success. In addition, he assigned the CIO responsibility for technology readiness and performance, support, and budget management.

With all assignments made, the CEO required each leader to establish the metrics by which success would be measured, and required them to adhere to the principle of defining success by operational measures. Some examples were:

• Low complaint noise level during go-live
• Physicians trained and ready
• Patient throughput loss prevention
• Low number of emergency application changes required
• Preservation of billing and collections rates
• Preservation of patient satisfaction

The CEO/CIO dyad established a process team around each macro process. Each process team included:

• A process sponsor, typically director level
• An operational project leader
• IT project leader
• A LEAN Six Sigma internal consultant
• Operational subject matter experts
• IT applications experts
• Support specialists from the application vendor
• A resource pool of special skills and cross functional personnel

These process teams easily swung from go-live planning, to go-live support, and then post-live optimization activities.

The net result of this structure was a remarkably smooth go-live that moved far quicker than expected from go-live to steady state. The team enjoyed a very low noise level related to problems, less negative impact to operations than the projected metrics, came in way under budget, and achieved very high marks on user and patient satisfaction.

The moral of the story? Make ‘not an IT project’ more than a proclamation by giving it operational teeth.