PROJECT MANAGEMENT TRENDS
healthcare landscape. But, something is missing; some familiar
topic is not being addressed at these industry forums.
The answer is technology but what was the question? So
many brilliant minds, experts and technology gurus started
their conference presentations with the results—almost everyone was demonstrating their essential gadget and yet some
vital jigsaw piece was missing. You had to ask one very simple
question: so how are they delivering all these technologies?
So much information was published on“what” the solution is
and so little information on “how” to do it. And that’s what
was the missing jigsaw piece—the descriptions of underlying
methodologies and supporting project management practices
to deliver these technologies.
So it is with this background that we look ahead at the project
management trends for 2017 with a particular focus on the med-tech and pharmaceutical industries.
CONTINUAL GROWTH OF AGILE
PROJECT MANAGEMENT PRACTICES
About 15 years ago, the software industry was confronted with
similar problems to those the medical technology and pharmaceutical sectors are facing today. Nowadays, university students
across all disciplines complete projects in an agile way—
splitting into cross-functional, self-organizing, self-responsible
teams; consisting of scrum masters, product owners and development teams. Traditional requirements are now delineated
into user stories and burn down charts, or“show and tells” are
used to report progress.
There is a lot of deliberate misinterpretation by executives of
the agile manifesto—that team members stop producing documentation; that scrum is an excuse to do whatever you want; that
it is too loose to pass tougher regulatory controls; and that the
quality of the delivery will be jeopardized.
In a recent interview entitled, “Agile Insights,” Frank Balogh of
AOL was asked about agile practices. “In a sense,” he said, “agile
is like jazz. It’s like improv in a way. It’s not sheet music. We tend
to now work in a world which asks us to deliver products quicker
than maybe traditional models allow us.”
But what does that mean for medical device and drug devel-
opment? Given the proven success of agile development, an in-
evitable question for companies in medical and other regulated
industries is: can we adopt agile approaches in our environment?
While medical device or pharmaceutical regulations do not pre-
scribe a fixed lifecycle model, activities are still presented in a se-
quential manner, which naturally drive organizations back into
waterfall development. However, several medical device manu-
facturers have adopted agile practices while keeping develop-
ment in compliance with regulations, but conflicts still arise and
decisions have to be taken in favor of agility or formality.
Scrum team members have to master technology and know
their regulatory guidelines, e.g., FDA/IEC regulations, security or
technical aspects. Of course, there are agile guidelines or stan-
dards available. In 2012, the Association for the Advancement of
Medical Implementation (AAMI) released the TIR45 that guides
medical device development companies on how to use agile un-
der stringent quality regulatory processes. TIR45 is a prime place
for novices or hardened agile veterans to gain insight into using
an agile framework in the medical device industry. It’s a good
reference point and demonstrates clear alignment with the IEC
It became very clear over the past few years that scrum is not
only an agile software development method. Rather it should
be seen as a framework that reduces the complexity of prod-
uct development into short cycles, called sprints. In scrum, you
document only what has to be documented, the difference with
other methodologies is the efficiency of the documentation. Daily
scrum meetings should be viewed as a communication or a col-
laboration tool where transparency on what activities each team
member carried out yesterday and what the team plan should
achieve today are discussed and agreed. In many ways, it is 21st
century Athenian democracy—communities of people with dif-
fering skill-sets working together to build the right solution in a
timely fashion. Be careful, however, as anarchism is democracy
In scrum, clients and users are a part of the product de-
velopment process from project inception, for example, by
taking part in the“show and tell” reviews at the end of each
sprint. One accusation that is often being made is that with
agile methods there is no planning. This is simply incorrect. In
reality, there is constant real-time planning. Each user story is
agreed during sprint planning sessions with new insights on
requirements taken into immediate consideration. Team mem-
bers and regulatory activities are mapped into the agile cycle
in a time-boxed sequence.
Undoubtedly, we’ll continue to see the growth of agile
practices in non-software based projects. Don’t be scared of
it—agile is merely a logical way for teams to self-organize and
deliver product functionality in pre-agreed, bite-size chunks.
It’s that simple or that complex—the challenge lies in the or-
ganization’s readiness to accept this simplicity. The principles
are straightforward but as we all know; the cultural and be-
havioral changes are not. One of the most difficult aspects of
applying agile is about gaining trust between executives, the
PMO (project management office) and project team members.
As the saying goes: trust takes years to build, seconds to break
and forever to repair. To refer back to Frank Balogh’s visual de-
scription of agile being similar to improv jazz—in agile, senior
managers get to choose the instruments for the jazz session.
They even get to choose the musicians that will play, but once
the session begins they need to sit back and enjoy the music.
Let’s just hope they like jazz!
To conclude, agile is a way of working that relies heavily on
having a good tool for managing workflow. Find a suitable tool
and be prepared to invest in customizing it.
REMOTE TEAMS ARE THE NEW NORMAL
Geographically dispersed teams can offer huge benefits—
efficiency, cost savings, and the ability to choose team members with
the best skills, regardless of their location.
Recently, while working on a resource plan with a large, U.S.-based pharmaceutical, a strange if not somewhat embarrassing
situation quickly arose. We discovered an experienced pool of
remote resources readily available to work; that the centralized
PMO didn’t even know existed. How did we find this resource