Project Management (Macro)

Dec 17 2017

Going Live In Healthcare (the Four Function Command Centre)

The following is a very brief overview of how we support our project go-lives here at Island Health. This Command Centre model has grown up over the past 10 years into a fairly well oiled machine that improves every time we use it. Each of the four functions has a specific purpose in the model which compliment and reinforce each other.

Key Drivers in Supporting Project Implementations 

  • All staff impacted by the change must be supported at the front line (e.g.: Onsite Support) and have a way to report problems (hardware, system, education needs etc.) to the go-live support team.
  • To reduce delays in responding to problems, the go-live team must have a single way (e.g.: Central Support) to receive and report out on the volume/themes of incidents that staff are experiencing.
  • The go-live team must have a way to bring the appropriate resources to bear on urgent issues as they emerge (e.g.: Rapid Response) to ensure interruptions to front line staff are kept to a minimum.
  • To ensure the right decisions can be made by the right people in as short a time as possible, there must be clear escalation paths for operational leadership (e.g.: Situation Room) to address urgent incidents as they emerge.

Onsite Support

Made up of inter-disciplinary teams (typically a project/technical analyst and a nurse/medical informaticist) who round on the units, providing at the elbow support/education and addressing issues in the moment. They can also be dispatched by Central Support to address high priority items (e.g.: Physician is having trouble logging into the system) and finally, they act as the “eyes and ears” of the Command Centre on the ground.

Central Support

An inter-disciplinary team that staffs a 24×7 Call Centre which is in addition to our regular Service/Clinical Solution Desks. Central Support answers calls from both Onsite Support and front line staff, logs them in an incident tracking system and then triages/dispatches to the appropriate team (Onsite Support, Service Desk, IM/IT Operations, Biomedical Engineering, Facilities/Maintenance, Housekeeping etc.). The Central Support lead(s) produce twice daily (10AM and 2PM) reports (placemat dashboards) for the Situation Room showing all incidents, themes and escalation points.

Rapid Response

Inter-disciplinary teams brought together at the request of the Central Support leads to work particular problems and will co-locate to collaboratively work the issue through to completion. These teams follow the Information Technology Information Library (ITIL) Framework for systems incident/change/problem and release management to ensure the fix is not worse than the original problem.

Situation Room

Consists of an inter-disciplinary operational leadership team who provide overall direction, serve as the highest escalation point and can provide in the moment decision making when needed (e.g.: if a system downtime is required). They also review the twice daily reports (placemats) from Central Support and guide resolution for any emerging themes.

By • 03 - Delivering •

Apr 10 2016

Supercharge your solution design with a little genchi genbutsu!

Have you ever seen a project implementation go sideways because the solution didn’t solve the problem it was intended to? Have you ever encountered a product that didn’t properly address the use for which it was designed? It was probably due to neglecting genchi genbutsu, a Japanese term which roughly translates into “go and see for yourself”. For more information see the wiki entry here: https://en.wikipedia.org/wiki/Genchi_Genbutsu

How can applying genchi genbutsu help project teams develop better solutions?

When we gather solution requirements through current state, future state and gap analysis we need to ensure that going and seeing for ourselves is incorporated as a key activity. How else will we be able to confirm that:

  1. the problems/drivers articulated are factually correct?
  2. the solutions designed to solve the problems will work?

Consider the following scenario:

A project team books a series of meetings with our subject matter experts to gather requirements by documenting the current state, followed by mapping out the future state and finally arrive at the solution design that will address the problem that the project is responsible to address.

One of the project solutions incorporates a new multi-function printer that has four extra large trays added to it with different types of media to support the new workflow. Furthermore, this new printer will replace three separate printers in the workspace that were dedicated to single use roles. This printer will be located where one of the existing printers is because the staff member most responsible for this new workflow is there.

There is a delay with the new printer shipping and the project team is unable to deploy it until the day of go-live. When they show up to install the printer they discover that the existing printer is situated on a counter three feet high. The new multi-function printer is four feet high. So the new printer is seven feet high and the staff member is unable to read the status LED on the top of the printer without a step ladder.

The team had never actually gone and seen what the space looked like. They assumed that the SMEs had given them all they needed to know during the requirements gathering sessions. The swimlane diagrams/process maps etc. all identified the printer but not the physical space it would go into.

Now the above scenario is s simplistic example but I hope that project teams can see how genchi genbutsu can really make a difference in the completeness and accuracy of the solution design. The earlier you catch something like this in the project, the less it is going to cost to course correct.

Some people may argue that it is too expensive to always practice genchi genbutsu but I would suggest that the cost of not doing it is even greater. After all, if you don’t have time to do it right the first time…you must have time for all the re-work!

By • 02 - Planning •

Jan 8 2015

Framework VS Methodology

I often come across misunderstandings in what a framework is versus a methodology. Which is quite understandable as there is precious little agreement even in the literature available on the internet. I have found a couple of definitions below that I believe adequately capture the essence of the difference.

Framework:

In general, a framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.
Source: http://whatis.techtarget.com/definition/framework

Framework = WHAT (and perhaps WHY)

Methodology:

A documented approach for performing activities in a coherent, consistent, accountable, and repeatable manner.
Source: http://en.wikipedia.org/wiki/Treasury_Enterprise_Architecture_Framework

Methodology = HOW

Key Distinctions

  • Frameworks are high level (high enough that all organizations could see their work in it) while methodologies are specific to the organizations they are developed in.
  • Frameworks can be applied anywhere (are interchangeable) while methodologies tend to only work where they were developed.
  • Methodologies are step by step instructions and are developed based on frameworks.

The PMBOK is a framework applicable to all projects.


 

The Island Health Project Management Methodology is specific to the organization.

By • Key Terms •

Jan 7 2015

What is a Project Methodology?

Project Methodology

Project Management Methodology is a strictly defined combination of logically related practices, methods and processes that determine how best to plan, develop, control and deliver a project throughout the continuous implementation process until successful completion and termination. It is a scientifically-proven, systematic and disciplined approach to project design, execution and completion.

The purpose of project methodology is to allow for controlling the entire management process through effective decision making and problem solving, while ensuring the success of specific processes, approaches, techniques, methods and technologies. Typically, a methodology provides a skeleton for describing every step in depth, so that a project manager will know what to do in order to deliver and implement the work according to the schedule, budget and client specification.

Source: http://www.mymanagementguide.com/basics/project-methodology-definition/

By • Key Terms •

Sep 14 2014

What is Portfolio Management?

Portfolio Management

Portfolio Management comes into effect when there are multiple programs & projects that can be standalone or interlinked and there is too much work to be effectively managed by one program manager. Portfolio managers guide and oversee the processes and procedures (also known as methodology) that govern the programs and projects. The program manager manages their program of projects while the project managers manage the projects within their responsibility. Portfolio management is typically seen in only the largest of organizations with dozens of active projects.

The purpose of portfolio management is to reduce the risk of related & non-related projects and programs of projects introducing something new into an existing system or systems.

Key Role Distinctions

  • Portfolio Managers are responsible for methodology development/improvement as well as training, support and oversight (audit and compliance) of the programs and projects.
  • Program Managers are responsible for supporting the projects within their programs while ensuring they stay in step with the project methodology.
  • The Project Manager is responsible for all delivery activities of their project.

By • Key Terms •

1 2 3