OBSERVATIONS ON PROJECT STRUCTURES AND DECISION MAKING
By Melani Ruiz-Pyland
When working with hospitals that are installing their first automated ordering system, it is important to
determine project status, streamline decision making, and validate the system and process decisions. From the
start of a project through the testing and go-live phases, these tips and tricks are designed to help an
implementation move smoothly.
Getting Started
The first step in reviewing the efficacy of a project is to obtain a clear understanding of the scope. Reviewing
the project scope document will allow you to become more familiar with the project, validate what
features/functions were included in the project, and confirm the content. Some projects hold true to the
original scope, while others have major and minor exceptions. The exceptions that impact the project budget
and timeline should be managed through the Change Management Team. After any approved changes, revisit the
project plan and adjust the scope as needed.
After reviewing the project scope, it is necessary to assess the IT and operational team members. Determining
the knowledge base of each in relation to their assigned work effort is an important step. In one case, a
challenge presented itself when constant changes were made to the Project Team and the Executive Team
responsible for daily operations. Organizing work an approved timeframe becomes more complex when new team
members, such as Project Managers (PMs), are introduced to the product and the organization. In this case, both
the Project Team and Executive Team were new; it took months for the new team members to fully grasp the
details of the decisions they were being asked to make. The project — and the organization — lost momentum
which delayed the timeline for months. Knowing each team members strengths and expertise at the outlay of a
project eases reorganization stress and makes it obvious who can make what decisions, and if a team member
changes, what type of person to replace them with.
Decision Making
In projects involving the implementation of a computer-based ordering and charging system, there are multiple
stakeholders, including: Executive Management, Subject Matter Experts (SMEs) or the User Acceptance Testing
Community, the Project Management Office, and the IT analysts.
In order to have all the stakeholders represented, large projects should have a Steering Committee. This
committee is comprised of senior management and directors who have implementation experience. The committee
should meet regularly through the pre-activation period of the projects. Their project charter and
responsibilities are to manage scope, schedule, budget, project objectives and outcomes, change tolerance, and
impediment removal.
The Steering Committee members are typically not engaged in the minutia or details of daily operations.
Therefore, asking them to approve design decisions is not practical. Providing the committee with the
appropriate and concise recommendations provides more successful outcomes. Recommendations, also called
Decision Requests, are best communicated through the SMEs. Organizations that do not have a communication line
between the SMEs and the Steering Committee have more challenges when dealing with Decision Requests. Using
middle management to research and discuss details of the build and the Decision Requests, then presenting their
findings to the Steering Committee is the most effective use of resources.
Holding system design sessions with the SMEs (a.k.a. User Acceptance Team) are another helpful
recommendation. The purpose of these sessions is to be informational and create a decision-making environment.
The SME assists the IT Team Leads by providing in-depth knowledge of their daily operations. They must: review
system functionality, determine system design, assist in the development of future state workflows, validate
training curriculums, and participate in User Acceptance Testing.
One aspect of having a successful project is to include the right decision makers in the design sessions
where changes in practice and processes are being decided. The SME must be able to articulate the decisions and
the recommendations to their Directors and to the Steering Committee.
In addition to the SME meetings, IT analysts should attend staff meetings with almost every constituency of
the facility (e.g. monthly Inpatient Nursing Managers meetings, weekly HIM and Patient Financial Services
meetings, monthly Ancillary staff meetings.) The IT Analysts are responsible for: interpreting future state
process flows, incorporating system functionality to support the business rules, configuring the system to
support the business, unit testing the order items and charge capture, integrated testing of the results and
charge interfaces, and activation support.
The most successful use of the IT analysts is in a larger facility where the SMEs drive the changes to
practice and processes, and eventually the system build. The analysts in those facilities are able to focus on
building and testing the system, while the SMEs focus on obtaining approval for practice and process changes.
Project Structure
In one large hospital, SMEs consisted of 100 front line and middle management staff from the Inpatient Units,
Ancillary Departments, and Ambulatory Care areas, as well as twelve to fifteen IT Team Leads on the project. In
another, the IT department augmented their team with users from various departments within the organization. The
most successful projects moved the SMEs to the project implementation team. With some cross training, the end
users became proficient analysts and were able to configure their orders and charges.
In large system design sessions there are usually too many disparate disciplines in full day sessions where
discussion topics engage only 10% of the attendees. While the working sessions were well researched, and the
presentations were properly prepared for the target audience, the challenge is engaging the non-participants
(Ancillary Departments, Patient Financial Services, etc.) in inpatient patient care discussions and vice
versa.
Topics in the working sessions should not overlap. To reduce the risk of redundancy, develop a list of the
prioritized decisions and their dependencies, before scheduling the working sessions. Related topics should be
discussed in another working session in order to keep on topic. Unrelated topics should be placed on a “parking
lot” list and scheduled for other meetings.
Because of everyone’s workload, it is often difficult to schedule meetings and bring the appropriate
representatives into the same room. One way to assure that team members are available when they are needed; is
to send the agenda out to the managers of the various departments, three to four weeks in advance of the
meetings. Then the department managers can determine who the most knowledgeable member(s) of their team are.
This can save time and money in the long run, as long as decision makers are present at every meeting.
Frequently, IT analysts and operational staff working on the projects are very familiar with current process
flows. New projects often cause one of two things to occur; either the participants have a difficult time
envisioning the future state or they can see the system enabling their processes but want to take advantage of
the change to drive improvements in daily operations. It is better to separate non-system, and non-project
related operational improvements, from the scope.
Operational improvements can move forward by assigning the non-system related operational improvements to
other members of the organization. Be aware though, that reporting structure is necessary to keep the
operational and system-related working sessions communicating with each other. If the Operational Team reports
to a different manager, or if the communication is not bi-directional, then changes in operations impact the
project and the system build because the legacy systems needs to be modified. If the order and charging
configuration changes on the legacy system, then it becomes necessary to modify the orders and charges
configuration in the new system; which in turn adds additional testing time to the project.
Limit the amount of change in the organization; focus on those changes that impact the implementation of the
new system. Most importantly, implement operational improvements prior to, or after the activation/go-live.
Change tolerance must be assessed during the implementation of a new system. Creating too many changes is also a
risk that needs to be managed.
For longer term projects, take a step back periodically and review the budget, timeline, and burn rate of the
teams. The latter is one that is not frequently reviewed but impacts the project. If any of the teams are
overloaded for months at a time, costly mistakes can be made, because the teams are burnt out but trying to keep
a strong pace.
For more information on project structures and decision making please visit our website at
www.getvitalized.com or contact us at 610.444.1233. You can also email
vcs@getvitalized.com.