28
Fail to Plan, Plan to Fail
Janette Gogler
Background
I applied for a position within the organization I worked for and got the job. It had a good title, sounded progressive, and was in health informatics. With this new position I inherited a telehealth project that had already been in progress for more than 12 months and proved to be immersed in problems. The local health department funded the project, which involved fourteen metropolitan hospitals and rural hospitals in a partnership. One organization was the lead, managed the project, and accepted all the responsibility for the project’s objectives. This telehealth project had to demonstrate savings from patient or clinician travel and revenue where possible. A steering com- mittee composed of seven members, a committee chair, the project manager, and a rep- resentative from the funding body was formed and met irregularly. In my opinion, the objectives were ambitious considering the resources, the time frame, and the change management involved. My initial assessment was that this was a technology solution looking for a problem.
There was no time to receive an orientation to the project, so all the corporate knowl- edge went out the door when the previous project manager and project officer left the organization. What I found was a lack of project documentation—including poor doc- umentation of decisions made at previously held meetings. I could not even find a project plan. A high-level project plan existed, but that was all. It appeared that much communication had occurred by e-mail; no regular project summary reports or even regular financial statements or updated issues logs were available. It is never easy walking into a project already under way, but a project without a documentation trail is even more difficult.
The Conflict
Poor project planning, lack of leadership, incredibly poor project documentation, a poor context in which to progress, a knowledge deficit among steering committee members, and an overall lack of trust between the rural sites and the metropolitan sites were all problems that I faced. There was also an assumption by most members of the committee that “If we build it, they will come,” but telehealth needs more than a positive outlook to work; it requires coordination, people at the other end, a patient, and so forth.
Early on in the project life cycle a major external dependency failed. This depend- ency related to being able to link two healthcare organizations’ networks. At this time
246
LTF28 10/11/2004 9:18 AM Page 246
one of the options was to close the project. However, the steering committee elected to work around the dependency, and further costs (not to the project) were incurred by one of the parties. This decision led to conflict, as an opinion existed that these costs should have been shared across the rural and metropolitan sites. I was not involved at the time, but I have the feeling that this was a difficult time for the project. There was a desperate desire for the project to survive, and as a result of the above investment, the party concerned wanted an early deliverable from the project.
I believe that this event was likely where the conflict started, and it continued up until the actual implementation. There always seemed to be a “them-vs.-us” attitude across the steering committee, between those representing the rural and the metro- politan sites. This attitude and suspicion continued throughout the project and made my job really difficult. I had to be careful not appear to be favoring one group over the other.
Stakeholders and Personalities
This project had many masters—the health department, the chief executive officers (CEOs) from the rural sites represented on the steering committee, and the metro- politan representatives.
Committee members
Unfortunately, the meetings held over the previous 12 months had focused on failed technical issues. The committee members did not have enough real knowledge about technical matters to understand the decisions; they were “guided” not by the project manager but by one or two members who appeared to have an understanding of the technical issues and tended to dominate the meetings. When I joined the project, this continued to happen, but as I gained more knowledge, I was in a position to challenge some comments and make recommendations. I was not always successful in getting the recommendations through either, as once again these personalities dominated the meetings.
The meetings became an attempt to keep one member happy with any decisions made rather than have equal representation and voting on decision making. He was a bully and was not “managed” by other members or the committee chair. Unfortunately, the committee chair was not strong enough to run a good meeting. She also had a knowledge deficit related to technical matters and did not request further information for the members or try to become better informed. The focus was always on the technical; the clinical protocols and policies were tabled without question and signed.
Because of the 12-month slippage, the health department was greatly concerned about the viability of the project. Were they ever going to see some deliverables from the investment they had made? The conflict became worse as more stakeholders became involved in different expectations of what the project could deliver.
Assumptions
I made assumptions that there would be clear project documentation, that a detailed project plan would exist, and that I would “just pick up” and continue on with the project management process. In retrospect, it seems that politics and conflict dominated 28. Fail to Plan, Plan to Fail 247 LTF28 10/11/2004 9:18 AM Page 247
the project and that no controls were in place because of lack of structure, inadequate planning, and poor project documentation and reporting. The telehealth proposal was written in a short time frame without adequate consultation and realistic clinical studies. Considering the diversity of the objectives and geographical areas, the medicolegal aspects and payment options all needed to be considered in a feasibility study prior to commitment. This would have confirmed if the objectives were realistic.
Very little time was allotted to project planning. I don’t believe that, once the pro- posal was prepared and the project initiation document written, any further planning occurred. It was a classic case of “fail to plan, plan to fail,” and getting a sign-off at each stage of the plan would have obtained the emotional buy-in of all concerned as they contributed and began to understand the project in its entirety.
Resolution
First, I stopped any further activity on the telehealth project until we had a plan signed off on by the steering committee. I broke the large project into parts. I worked with another “resource person” to develop the plan—commencing with a “test” of the tech- nical aspects followed by a pilot phase and then a rollout to lead sites and finally to all sites.
Next, I created some project structure to share the responsibility for this distributed work. I also formed a technical committee, to move highly technical discussions away from the steering committee, so only recommendations were made. This worked well.
I believe the committee just did not have any concept of the work involved in getting the project under way from a clinical perspective. They viewed this as a technology rollout rather than a clinical effort requiring change management, with policies and procedures based on using this technology for clinical teleconsultations.
I organized monthly steering committee meetings, where regular project summary reports were provided, issues and risk logs, scope changes, and exception reports. I also documented the exception reports and scope changes retrospectively. I had all these documents signed off by the committee. It demonstrated the poor minute taking and unacceptable lack of documentation and was an eye opener for the committee members.
Another area of conflict was the budget. There was concern that the project over- head was paying for other unrelated costs for the lead site. I began providing regular financial statements. This meant that the committee could make decisions to fund an extension to the project manager’s position for salary, increase a resource, or limit the purchase of equipment.
I also kept all communications within the steering committee meetings unless it was necessary to inform all the committee members by e-mail of an item or problem. The previous manager had e-mailed only some of the members to discuss issues and did not include others. I did not want to continue this as a form of project communication.
Conclusion—Lessons Learned
I learned that:
• Group conflict and poor decision making can result from a collective knowledge deficit and poor communication methods. It is worth acknowledging this, and pro- 248 Section VI. Organizational and Interpersonal Conflict
LTF28 10/11/2004 9:18 AM Page 248
viding the information required, so that committee members really are empowered to make decisions as a committee and not allow one member to dominate the deci- sion making.
• The most important phase in a project is the planning phase. It is really the make- or-break stage, and if not done properly, delays the project and creates conflict. I learned that unresolved conflict continues throughout the lifetime of a project and in the end is habit forming.
• Emphasizing a project’s structure, process, and outcome works. Imposing project structure and creating a reporting and documentation process achieve a better outcome—even if scope changes are made along the way.
• It is possible to inherit an out-of-control project and turn it around—and it comes at a cost.
28. Fail to Plan, Plan to Fail 249 LTF28 10/11/2004 9:18 AM Page 249
