However, in Phase 2, when further
specifying the new system, the project
management and supplier representatives were faced with the immense complexity of translating existing systems
and working processes into one new
working system. The supplier appeared
to be unable to compose a system in
accordance with the specified requirements and preferences by the user
departments. As a result, the project
management was faced with the reality
that a Big Bang in the fall of 2015 would
not be feasible. After intense deliberations in September 2014, the board
decided to postpone the go-live date to
“sometime in 2016,” and to distinguish
three implementation levels. The Big
Bang now only referred to the “going
live” of Level 1. Level 1 essentially
amounted to basic functionality in order
to establish a working system. Later,
after proven success at Level 1, and
after having developed learning capabilities, experience, and confidence, the
next two levels would be developed and
implemented. These levels addressed
more advanced functionalities, external links, and customized processes. As
a result, the project management had
implicitly proposed moving from a full
Big Bang launch to a more incremental
three-level implementation approach in
which the first-level “Bang” would have
a smaller scope (Tension 2).
The user departments had expected
that their requirements, which they had
defined in “design books,” would be
translated into a working system. These
expectations increased the required
system complexity and created difficul-
ties for the developers in meeting the
time schedule of the proposed Big Bang
implementation. Although three of the
four departments did not explicitly criti-
cize the Big Bang approach, they did
so implicitly by asking for functional-
ities that could not be delivered within
time. A representative of Department
B said: “If we would have asked for a
tailor-made product that could be deliv-
ered by the supplier, a Big Bang might
have been an appropriate approach”
(Department B, interviewee 3). A col-
league added “Transition periods with
two systems in place are very cumber-
some for users. So we are in favor of a
Big Bang. I can imagine that the proj-
ect management had to postpone and
downsize the scope of Level 1, but this is
not good. This leads to uncertainty and
reduced confidence in the project as a
whole. These three different levels actu-
ally imply an incremental and unstable
approach, which means that we spend
too long in a transition phase” (Depart-
ment B, interviewee 2). As a result, we
saw that the extended time frame and
the prospect of only a basic function-
ality in Level 1 raised the awareness
of the substantial impact on the work
organization that could be expected
(Tension 3).
Tension 7: Balancing between a
differentiated and an integrated program
organization
This tension relates to the project organization’s degree of differentiation versus integration. A project organization
is differentiated when the various tasks
are segmented into subprojects or teams
that independently and fairly autonomously contribute to the project goals.
Integration, on the other hand, reflects
a degree of unity of effort and consistency among the various subprojects in
accomplishing the goals of the project.
In the first phase of the project, a
steering group and a project management team managed 15 core teams.
These core teams focused on particular
project dimensions, including the EHR
tendering procedure, technical infrastructure, process design, system migration, digitalization of nursing, patient
participation, and change management.
Each core team was chaired by an expert
from the hospital and was made up of
between three and eight team members.
The chairs were expected to share their
insights with one another and to contribute to a cohesive implementation. However, as one project member observed:
“it is very difficult to fit the pieces of
the puzzle together” (Project Manager).
Project management balanced this
differentiation by colocating project
members in one part of the building to
encourage informal communication, by
weekly internal newsletters intended to
share information within the project,
and with a communal lunch on Thursdays to create an integrated culture and
establish a space to share and discuss
the project’s progress and outcomes.
In the second phase, after the vendor selection, the number of project
members increased substantially—for
example, with the entrance of vendor
consultants. A new project structure
was established. This structure was
divided into functional and technical
design teams, plus coordination teams
for education and support. These three
categories of teams were connected
with different layers within the hospital:
a high-level “leading coalition,” medical
professionals who informed the functional design teams, and EHR medical
department teams including coordinators. In this second phase, the implementation organization thus became
even more differentiated in order to
address the range of challenges. The
project management stressed that EHR
implementation was only partially an
ICT project. The booklet about the project says: “This project is also related to
process optimization, quality improvement and patient safety.” In this phase,
the sheer scale and multidimensionality
required the inclusion of many experts
with different backgrounds working in specialized teams. Linking pins
had to hurry between different meetings that required their inputs. A newly
appointed project leader observed an
imbalance in the strong focus on the
technology, while ignoring dimensions
such as the work organization. She
observed a lack of coherence between
the subprojects: “During a presentation
of intermediate products I asked: where
is the coherence in all of this? Then
there was silence” (Project Manager).
She argued that the project organization was compartmentalized with too
much overhead, and proposed merging
