AGILE

T he d e m a n d s o f a re g u la te d e n v iro n m e n t s h o u ld n 't sc<

AUDITOR
n a relatively
short span, agile
approaches
have gone from
the margins of
project
management
to decisively in
the mainstream.
But even within IT and software development,
there’s one area in which agile still has to fight for
a foothold. Regulated industries—financial services,
pharmaceuticals, healthcare and the like—have
proven to be less receptive to agile, even as more
fields beyond IT take the plunge.
To be fair, regulated environments seem ill-suited
for agile at first glance. Its iterative approach seems
at odds with the rigorous validation, documentation
and assessment requirements that projects in such
industries must meet. Couple that with the increased
consequences of failure—where a software failure
can crash not just a computer but an entire financial
network—and the reluctance to move away from the
waterfall model is understandable.
“Agile methods are focused on delivering a
large amount of business value to the customer,”
says Denise Canty, PMI-RMP, PMP, senior IT
project manager at Cenden Company, Washing­
ton, D.C., USA. “Regulated industries are more
focused on safety first and may not be the best
candidates for agility.”
 f t
1
respondents to VersionOne's State of
Agile survey credited implementing agile
for improvement in their ability to man­
age changing project priorities.
However, done correctly and under the right
circumstances, agile can both decrease project cost
and shorten schedule. A whopping 92 percent of
respondents to VersionOne’s State o f Agile survey
cited improvement in their ability to manage chang­
ing project priorities. In industries where regula­
tions often change, the ability to better adapt can
mean the difference between project success and
scrapping the project. Agile also gives teams more
flexibility to tailor their verification and validation
tests to the actual product and adjust as needed—a
critical concern in regulated industries.
Crucially, there’s more transparency with burn-
down charts and agile’s focus on velocity, says Bryan
Berthot, PMI-ACP, PMP, a San Diego, California,
USA-based IT systems development life cycle proj­
ect manager at Verizon, a PMI Global Executive
Council member. “In waterfall software develop­
ment, there’s a great fiction when using percent
complete to estimate task completion, because
you’re often relying on ‘happy path’ estimates from
developers,” he says. “In agile, the task is either done
or it’s not, and this is reflected in daily changes to
the burndown chart.”
Reaping the benefits of agile requires balancing
its rapid iterations with the often extensive testing
and documentation inherent to regulated indus­
tries. It can also mean compromising with a hybrid
"Agile methods are
l
focused on delivering
a large am ount o f
^ I^ business value to the
customer. Regulated
industries are more focused on
safety firs t and m ay not be the
best candidates fo r agility."
— D e n is e C a n ty , P M I-R M P , PM P, C e n d e n C o m p a n y ,
W a s h in g to n , D .C ., U S A
approach—and recognizing that sometimes water­
fall really is the best way to go.
THE STARTING BLOCKS
The first step to understanding how agile can help
organizations in regulated industries is knowing
the nature of those regulations. Though the word
implies rigidity and consistency, regulations are ever-
changing—and agile lets project teams shift along
with them.
Marcus Glowasz, PMI-ACP, PMP, PgMP, senior
IT project manager at Credit Suisse, Zurich, Swit­
zerland, manages anti-money-laundering initiatives
on which the requirements are largely driven by
auditors and regulators. The issues they raise rarely
come with much warning or time to get full sign-off
from stakeholders.
“In that field, I have rarely experienced an imple­
mentation of the initial requirements, due to fre­
quent scope changes,” he says. “A strict waterfall
method can therefore not be applied to such proj­
ects. Agile approaches ensure that deliveries can
adapt to regulatory deadlines that were unclear or
not known at the beginning of the project.”
Project leaders can leverage those benefits to help
persuade stakeholders to shed the comfortable but
sometimes cumbersome scaffolding of traditional
approaches. To win over skeptics, Mr. Glowasz’s
JANUARY 2015 PM NETWORK 63
 mkliiC ' ' ■r V : . ' WM = ■"

"In waterfall software development, there's

a great fiction when using percent complete
to estimate task completion, because you're
often relying on ‘happy path' estimates
from developers. In agile, the task is either
done or it's not, and this is reflected in daily
changes to the burndown chart."
— B ry a n B e r th o t, P M I-A C P , PM P , V e riz o n , San D ie g o , C a lifo r n ia , U SA
 team performs retrospectives on previous projects
and identifies where change requests caused over­
runs. That gives the client a quantifiable, real-life
look at agile’s potential.
As with any significant change in processes or
approaches, starting small is a must. Mr. Berthot
adopted a staged approach when, in a previ­
ous position, he introduced agile to a healthcare
firm. He began with a small, sunk-cost proj­
ect—in which money had already been spent and
couldn’t be recovered—where the company could
learn about agile, then followed with a larger
US$100,000 software implementation project. Sev­
eral lessons emerged from these efforts, including
the organization’s risk threshold and the agile
project team’s velocity.
“One thing we learned was that this core te a m -
seven internal IT staff members—could do a good
job when they could focus on one project at a time,”
he says. “When they were split between two or three
projects, velocity on all projects slowed consider­
ably. When we took these lessons learned from the
second project retrospective, the team was ready for
its real challenge.”
The next project was a US$2.5 million software
implementation to replace legacy homegrown soft­
ware with a commercial electronic medical record
(EMR) product. Because Mr. Berthot’s team had
established data on the team’s velocity, the com­
pany was not overly aggressive in its time con­
straints; the EMR was successfully implemented
under its baseline budget.
Even the most enthusiastic agile evangelists rec­
ognize that there are some times when it’s simply
not the right choice. Several red flags signal the
potential for failure, says Ms. Canty. She identifies
four situations where waterfall may make more
sense and agile should be kept on the bench:
■ Inexperienced teams
■ Inadequately defined user requirements
PHOTO BY LUIS GARCIA
■ Projects involving third-party vendors
■ Projects that use legacy systems where the code
is highly dependent on other code
And she notes that even projects that use agile
approaches should consider using more traditional
L
The View From
the Starting Line
Introducing agile approaches into a regulated environment is a
daunting prospect in part because o f the unknowns th a t come
w ith the transition. Bruce Cilland, PMI-ACP, PMP, in Denver,
Colorado, USA, has gradually been integrating agile processes into
projects. Teams have started using sprints and iterative devel­
opm ent on projects, and plans are in place to introduce other
aspects, such as daily stand-ups.
Even w ith years o f experience in software development and the
PMI-ACP® certification under his belt, Mr. Cilland faces a host o f
unknowns th a t underscore the challenges o f regulatory projects.
The U.S. Food and Drug Adm inistration's regulations are designed
w ith w aterfall in mind, he says, so adapting them to agile pro­
cesses raises questions.
“ For example, if we bite o ff 20 requirements fo r a given itera­
tion, do we need a new requirements document fo r those, or just
add to the existing one?"
he says. “ Do we need a new
“S e v e ra l m e m b e rs o f
design document or ju s t add
sen io r m a n a g e m e n t a re
to the existing one? For test­
ing, do we need a new test
in te re s te d in try in g agile
plan? New protocols? New approaches, b u t th e y Y e
reports?" s tu c k in th e m in d s e t
Similar issues around o f having f u ll fe a tu re
financial tracking and sets d e liv e re d b y a
gathering end-user feedback
p re d e te rm in e d d a te ."
w ill also have to be resolved
along the way. An upcoming —Bruce Cilland, PMI-ACP, PMP, Denver,
software-heavy project w ill Colorado, USA
give Mr. C illand’s team the
opportunity to ramp up its
agile efforts, since it's the
hardware aspects th a t s till are implemented using w aterfall. The
e ffo rt w ill not only help answer the aforementioned questions,
but may also convince curious stakeholders.
"Several members o f senior management are interested in
trying agile approaches, but they're stuck in the mindset of having
fu ll feature sets delivered by a predetermined date, often set by
marketing and w ith o u t much input from the R&D team about
how long it w ill really take to create those features," he says. “ It
w ill take a few small successes w ith projects th a t im plem ent more
agile features to make them com fortable w ith going fu ll agile."
JANUARY 2015 PM NETWORK 65
 methods at key times. “Critical components of
software should be developed under more formal
software development methods,” she says.
WRITE THIS, N O TTH A T
One of the biggest sticking points to agile adoption
in a regulated environment is the question of the
testing documentation required by auditors, says
Vasudeva Sharma Mallavajhala, PMP, associate
director of quality, Novartis Healthcare Pvt. Ltd.,
Hyderabad, India.
It’s an obstacle that manifests itself in different
ways with different people. “System developers think
that agile means no process and no documentation,
so when they are asked to prepare documentation
required for regulatory compliance, they think there
is no benefit for them,” he says. Meanwhile, “the
business people think agile cannot enable regulatory
compliance because it means no documentation.”
The confusion comes from the misconception that
using agile approaches means throwing out all docu­
mentation. Ms. Canty notes that agile values working
software over comprehensive documentation, but
still leaves plenty of room for necessary paperwork.
“Only create documentation that is requested by
a project stakeholder,” she says. “If it’s not asked for,
then don’t create it.”
Mr. Mallavajhala notes that while there’s no way
to totally circumvent necessary documentation,
teams can meet requirements without bogging
down the process. These span:
■ Including the completion of documentation as
"[In th e a n ti-m o n e y -la u n d e rin g fie ld ] I h ave ra re ly
e xp erien ced an im p le m e n ta tio n o f th e in itia l re q u ire m e n ts ,
du e t o fre q u e n t scope changes. A s tric t w a t e r f a ll m e th o d can
th e r e fo r e n o t be ap p lied t o such pro jects. A g ile approaches
ensu re t h a t d eliveries can a d a p t t o re g u la to ry d ead lin es t h a t
w e re u n c le a r o r n o t k n o w n a t th e beginning o f th e p ro je c t."
— M a rc u s C lo w a s z , P M I-A C P , PM P, PgM P , C r e d it Suisse, Z u ric h , S w itz e rla n d
PM NETWORK JANUARY 2015 WWW.PM1.ORG
part of Definition of Done for each user story
■ Including documentation as a task in the user
story life cycle
■ Allowing documentation sign-off at the end
of release—before starting formal test execu­
tion—so that any changes to requirements do
not have to go through a formal change man­
agement process
Also, teams don’t need to spend time document­
ing tests and systems used only for internal pur­
poses or incremental developments that won’t be
reported to regulatory bodies.
LEARNING TO COMPROMISE
The need for substantive (if not substantial) docu­
mentation likely precludes the use of nonhybrid
agile in regulated environments. There’s no getting
around the fact that traditional waterfall approaches
will have to be integrated into any iterative process.
For example, Mr. Mallavajhala knows his team
members will have to submit a certain amount
of documentation and receive formal approval of
plans, tests and systems throughout the project life
cycle. But that doesn’t mean they sit around wait­
ing for sign-off before moving to the next stage.
Instead, they update their regulatory documenta­
tion throughout the sprints, and get sign-off just
before the formal testing. “This way, the method
avoids formal change management and approv­
als of specifications during development and thus
enables better productivity and turnaround time,”
he says.
 “As a p ro je c t
m anager you
need t o re c ru it
agile cham pions
a m o n g y o u r sen io r
m anagem ent
and k e y p ro je c t
s ta k e h o ld e rs .
U ltim a te ly , each
business u n it t h a t
has d e liv e ra b le s on
a p ro je c t m u s t be
o p e ra tin g on th e
sam e cadence."
P H O TO BY LUIS GARCIA

—Bryan Berthot, PMI-ACP, PMP

Indeed, an agile-waterfall hybrid can address a
number of industry-specific issues that agile alone
may not. Differences in regulatory jurisdiction and
data availability can preclude remote teams from
performing efficient testing, requiring a more tradi­
tional testing model, says Mr. Glowasz. Fixed-price
contracts with third-party vendors are often incom­
patible with agile methods, he adds.
"The best experience I’ve had so far is with an
incremental waterfall method that incorporates
some of the most important agile concepts, such
as embracing change, while considering external
vendor constraints,” he says.
Mr. Berthot warns that other business units
within the organization—such as regulatory,
purchasing, legal or medical affairs—can hinder
the adoption of agile if they continue to work
in waterfall. In such cases, he says, products
finished with agile go unreleased while the rest
of the enterprise catches up. “If this occurs in
your organization, as a project manager you need
to recruit agile champions among your senior
management and key project stakeholders,” he
says. “Ultimately, each business unit that has
deliverables on a project must be operating on
the same cadence."
An added benefit to a hybrid approach is that it
gives those skeptics a chance to dip their toe in the
agile pool before diving in, says Ms. Canty, and that
can mean both early buy-in and long-term success.
“A change in culture is necessary in order to
embrace change, and we know that this does not
happen overnight,” she says. And, she warns, as
more and more regulated industries adopt agile
processes and reap the benefits, those that lag
will increasingly be at a competitive disadvantage.
“Companies that don’t keep up and embrace agility
could be left behind.” pm

JANUARY 2015 PM NETW ORK 67

Copyright of PM Network is the property of Project Management Institute and its content
may not be copied or emailed to multiple sites or posted to a listserv without the copyright
holder's express written permission. However, users may print, download, or email articles for
individual use.