HI540 Unit 8 Seminar Reflection Example

Bad Luck Has a Calendar: A Unit 8 Seminar Reflection on a Vendor Release That Cost Thirty-Four Working Days

[Student Name]

Purdue University Global

HI540: Project Management of Health Information Systems

Unit 8 Seminar Reflection

[Instructor Name]

[Date]

The seminar case, the classmate and Ashby Valley Health are composite; the sources cited are real.

The Case

The seminar case was short. A regional hospital eight months into an electronic record build learned that its vendor had declared a release mandatory, with support for the prior version ending within the year. The release changed the framework behind many configured screens, and the build team spent weeks reworking 212 of them. Go-live moved thirty-four working days, the training schedule was rebuilt, and the project's contingency was largely spent before the first patient was seen on the new system.

My First Reaction

My first contribution to the discussion was that nobody could have seen it coming. I said that vendors change their plans, that a hospital cannot control a software company, and that the project manager's job was to absorb the hit as well as possible. I believed this. Our own register for the Ashby Valley perioperative rollout lists a vendor release as R-02, rated low probability, and I had written the response myself: monitor vendor communications.

The Turn

A classmate who works for a software vendor answered that releases at her company are published on a calendar about a year ahead, that customers receive the calendar on request, and that mandatory releases are announced months before they land. The hospital in the case, she said, had not been surprised by the vendor. It had simply never asked. That changed the question. The delay was not bad luck; it was a dependency the project did not track. I had treated the release as weather, something that happens to a project, when it was really a scheduled event in someone else's plan. The release was only unforeseeable to a team that had not looked at the one document that would have shown it.

Looking at My Own Register

After the seminar I reopened our register. R-02 was there, but its response was passive: watch the inbox. Nobody had asked the vendor for its release calendar. Worse, the register had no category for dependencies outside the project at all. The laboratory upgrade that double-booked our interface analysts had been found by accident, when the resource plan was loaded against the enterprise calendar. If that calendar had not existed, we would have discovered the conflict during integrated testing. Reflective practice is described as the habit of stopping to examine the assumptions behind one's own routines when a situation surprises us (Schön, 1983), and that was the uncomfortable part. My routine for building a register was to brainstorm what could go wrong inside the project. It never asked what other plans our dates depended on. Kolb (1984) frames learning as a cycle in which an experience is examined, turned into a general idea and then tested in action. The general idea here is that the dates I protect are only as reliable as the dates I do not own.

What I Changed

I asked the vendor's account manager for the release calendar the following week. It arrived in two days. One release, not mandatory, falls during our integrated testing, and we have chosen to defer it. R-02's response now reads: release calendar reviewed monthly by the application services director, with any mandatory release inside the build window escalated to steering the same day. I also started a dependency log, separate from the register. It lists every date our project relies on that someone else controls: the vendor's releases, the laboratory upgrade, the materials team's inventory project, resident changeover in July, the archive vendor's delivery and the anesthesia group's contract renewal. Each line has an owner on our team who checks it every two weeks and records the date it was last confirmed. The sociotechnical view of health information technology treats external rules, regulations and pressures as one of the dimensions that shape whether a system succeeds (Sittig & Singh, 2010), and the log is a practical way to keep that dimension in view.

What I Will Do Differently

On my next project the dependency log will exist before the register does. Writing it first forces the question my brainstorming missed: whose calendar are we standing on? I will also stop using the phrase bad luck in status reports until I have checked whether the event was published somewhere in advance. Most of the time, I now suspect, it was. I also plan to bring the dependency log to the next seminar, since a classmate from a laboratory background said her team had been caught the same way by a reference laboratory's contract date, and comparing logs may show categories neither of us has thought to track.

References

Kolb, D. A. (1984). Experiential learning: Experience as the source of learning and development. Prentice Hall.

Schön, D. A. (1983). The reflective practitioner: How professionals think in action. Basic Books.

Sittig, D. F., & Singh, H. (2010). A new sociotechnical model for studying health information technology in complex adaptive healthcare systems. Quality and Safety in Health Care, 19(Suppl 3), i68-i74. https://doi.org/10.1136/qshc.2010.042085