needs. As a result, a lot of IT project managers end
up getting into customized feature development,
which leads to a lot of scope creep.”
Mr. Sarojani experienced this firsthand on a proj-
ect to introduce EHR and new healthcare practice
management systems across HCL Avitas’ clinics in
2014. “When we started, the expectation of changes
from the vendor side was not very high,” he says.
“But as we tried to implement, we realized that cus-
tomization requests are very high.”
To prevent that reality from driving scope creep,
project managers should take a more agile approach
to planning and execution, Mr. Sarojani says. “Start
with a much smaller baseline and plan for incre-
mental releases,” focusing on one or two useful
features at once instead of trying to introduce a
complete system, he says.
In the case of its EHR project, for instance, HCL
Avitas could have delivered a system that tracks a large
number of patient health variables and alerts physicians to potential complications. Instead of incorporating every alert requested by every provider,
however, Mr. Sarojani’s team focused initially on only
a handful of high-priority medical alerts, such as drug
allergy interactions. That helped the project team
maximize value while also managing expectations.
Scope creep can hinder not only the project’s delivery, but also its utility, says Jebi Miller, PMP, director
of the project/product management office, Children’s
Hospital Association (CHA), Overland Park, Kansas,
USA. Her organization discovered that after working
on a multiyear project to create a database to improve
care and outcomes for a specific pediatric population.
Given the objective, the project team was led by
physicians. One of the challenges, Ms. Miller says,
was a disconnect among stakeholders on goals defining overall project success. The physicians were
focused on individual elements that they felt were
critical to collect from a clinical perspective. IT was
focused on ensuring they built a tool that would support the physicians’ data collection requirements.
The result was a database architecture that did not
support the most important and relevant objective:
data extraction. The project team quickly realized
that because the database was so large and complex
( 1,200 data elements), it was difficult for analysts (and
clinicians) to make sense of the data.
While the situation was problematic, it was not
insurmountable. The team took a step back to better
understand what data physicians needed to move
their work forward and then identified opportunities for corrective action. In parallel, projects were
spearheaded to make some fairly significant changes
to the database architecture, which improved data
extraction results and streamlined the data collection effort. A key lesson learned, says Ms. Miller, was
ensuring the right staffing mix on future projects that
require both clinical and technical expertise.
“You need to be able to ask yourself: What are
you going to do with the data? What kind of reports
are you going to generate? What are you really trying to achieve?”
A consultation room
at a HCL Avitas clinic
An electronic health
records project at
Brigham and Women’s
Hospital in Boston,
Massachusetts, USA,
came in US$27 million
over budget in 2015.
