Change Management & Healthcare IT Project

As a Project Manager in a healthcare IT project before, I worked with the project team comprising of  Business Analyst, Security consultant, Enterprise Architecture consultant, Standards consultant, Solution architect, a doctor and a nursing lead to establish the functional and non-functional requirements.

When I got involved, the clinically trained team have gathered the functional requirements from the private General Practitioners (GPs). However there were constant changes to the requirements and the project scope wasn't clear and evolving as well.

Hence I first established a change management or change control process (what-is-change-control?) which included regular and ad-hoc managment and project meetings to align and clarify the dynamic changes circling around the inter-dependent areas which were also evolving as well.

However I soon realized that in this particular project, change management from the organization management perspective meant the use of the following strategies to increase user adoption rate.

1. benefits realization- defining the qualitative & quantitative benefits as well as how & when the benefits are measured & implemented
2. business process re-engineering- stating the "as-is" state of the business process & defining the "to-be" state
3. education- e.g. seminars, workshops or web-minars that "sell" the benefits of the new proposed system
4. communication- e.g. e-newsletters, web platform, personal visits to inform the progress of the project as well as the migration approach of the data & the "to-be" business processes
5. training- e.g. classroom training as well as on-site refresher training during deployment

Detail change management activities that evolved from the above 5 strategies were factored into the project schedule.
The change management in this project was undertaken by a change management lead role and its aim was to ensure a smooth transition of the new system as well as a structured and well planned strategy to ensure increased user adoption.

Change management could mean the use of various strategies to "win" user over to increase user adoption as well as what is commonly used in the project domain which refers to the process of monitoring and controlling change- aka change control.

Downstream impact in a poorly communicated project

I am down with a very bad sore throat and some running nose. Saw a doctor 2 days ago and he was kind enough to give me 2 days of medical leave.

So I'm recuperating at home and was checking my company email (yes..some of us do that even while on medical leave) when I saw a series of high priority emails from my users and global counterparts sent to me saying one of my BI application system is down!!

I did some checks remotely and concluded the cause of the problem was due to changes in many of the database table fields structure that my application was accessing data from. These changes were part of the scope in an ongoing corporate datawarehouse enhancement project. This caused my application to fail.

To cut the story short, I liaised with my coverer and worked with my global counterparts to update the table fields my application is accessing and it fixed the problem.

After the problem has been resolved, I did some thinking on what went wrong in the datawarehouse enhancement project that disrupted my due rest and caused me to have to "fire-fight".

Well my conclusion was specifically zoomed down to the following planning process groups:
- an insufficient project communication plan from the Communication Planning process (Project Communications Management) and

- a poor risk register from the risk identification process (Project Risk Management)

A proper communication plan would be able to identify me as a stakeholder to be informed of the date/time where the database changes would be executed. This is so that I can align my impacted BI application to the changes and prevent any abrupt application issues such as what has happened.

A proper risk register would include my application failure as one of the identified risks involved. Even though my application failure does not affect the datawarehouse enhancement project directly, I feel the risk register should include downstream applications which will be impacted. Afterall, these downstream applications such as mine, affect the service quality of the users who belong to the same organization which the project is trying to render benefits to irregardless whatever they could be- lower maintenance cost, faster database access, etc.

So the above serves as a lesson learned for my future projects...lessons learned from a downstream application owner affected by a poorly communicated project implementation.

Now...time to go and have some rest.

Argh...this is not what I wanted!

Analyzing and determining accurate user requirements is one of the most critical task in a role of a project manager (PM).
Sometimes simple requirements may also end up being misunderstood resulting in the wrong item delivered.
Like in my case last week, I had asked my brother to buy my first watch winder for my small collection of automatic mechanical watches. Simple right? He got one that looked like this:
Yah it look alright but it is so different from what I had wanted. What I had wanted was a watch winder that is more compact....more stylish looking that does not look like a box......what I wanted was a watch winder that looked like the one below.

After I overcame my initial disappointment and regained my logical frame of mind, I knew this could have been avoided if I had been more pro-active in describing my requirements for my first watch winder to my brother.

Instead of just stating my requirements as a watch winder that cost $xx, that could hold up to 6 watches, I could have elaborated on my requirements like compactness, without drawer, etc. Instead of assuming all watch winders are like the one I have seen before, I could have provided a supporting picture.

As PMs, we can't allow requirements to be vague, whether its requirements from users or our requirements to vendors else we will risk ending up with the wrong deliverables.

In a huge project, the impact is rework and incurring more cost. At a smaller scale, the impact is ending up with a wrong watch winder.
Cheers.