PMI-ACP Case Study

1. INCREASING THE SPEED OF
DELIVERY VALUE
A case study for the ACP Certification Course

2. 1 | P a g e
Contents
Introduction ..................................................................................................................................................2
Challenges.....................................................................................................................................................3
Solution.........................................................................................................................................................3
Final Outcome...............................................................................................................................................6
Critical Success Factor...................................................................................................................................7

3. 2 | P a g e
Introduction
In 2004, British Telecom (BT), one of the largest Telecom companies in the world,
embarked on an initiative to transform its IT software delivery process.
BT employed some 8,000 IT professionals in a variety of roles, including project &
delivery management, architecture & design, software engineering, integration &
testing, operational support, and service management. Much of its internally-
focused development work has traditionally been channeled through a number of
business-focused delivery projects or programs, ranging from small, simple
initiatives to large-scale and complex business solutions, the latter tending to be
the norm.
Despite successfully delivering a number of large, complex solutions in a dynamic,
competitive, and yet highly regulated business environment, many significant
transformation programs were struggling to deliver any notable results in an
acceptable timeframe. As part of an organization wide improvement strategy, a
waterfall based software development process had been developed as part of
BT’s standard delivery methodology. In 2004, this standard methodology was in
the process of being rolled out when the new CIO made it clear that an entirely
new agile approach was needed.
Although BT had a comprehensive and detailed software development lifecycle, it
was challenged by poor requirements, fragile design, and integration problems.
Soon, these problems manifested themselves into a more significant issue, and
the average delivery time for a new software solution began to exceed twelve
months. In the fast-paced Telecom market, this development cycle was
preventing BT from being competitive, and hence change was required. Their
new CIO saw the value of Agile as a solution to many of their problems.

4. 3 | P a g e
Challenges
Although BT had a comprehensive and detailed software development lifecycle, it
was challenged by poor requirements, fragile design, and integration problems.
Soon, these problems manifested themselves into a more significant issue, and
the average delivery time for a new software solution began to exceed twelve
months. In the fast-paced Telecom market, this development cycle was
preventing BT from being competitive, and hence change was required. Their
new CIO saw the value of Agile as a solution to many of their problems.
Solution
As BT experienced greater demands for new systems and updates to existing
systems, they resorted to increasing the rigidity and formality of their existing
waterfall software development processes. They introduced more detailed
requirements processes to ensure that all requirements were elaborately
documented before the project could move into design and development.
Extensive sign-offs from a wide variety of stakeholders were required to ensure
that there was consensus on what was going to be developed. All of this was
intended to control change and increase the likelihood of delivery success.
However, almost the opposite was happening.
By ensuring that requirements were elaborately detailed, projects were taking
longer as huge requirements documents were being created. Departments began
to ‘gold plate’ their requirements as they were concerned that their next IT
project opportunity could take several years before being approved. As a result,
the business value of many of these requirements was poorly understood, and
the most critical requirements were diluted by the vast array of requirements.
Therefore, even though requirements were detailed, they did not adequately
capture the business value required. Even the effort of prioritization turned out
to be counter-productive as almost all requirements were given a high priority

5. 4 | P a g e
due to concerns that anything less important would be cut from the project
scope.
Given the large number of requirements, the design of BT systems became
cumbersome. Requirements analysts were rapidly reassigned to other projects
and architects and designers lacked access to the original authors of most
requirements. As a result, the design of most of these systems was fragile and
had difficulty scaling and adjusting to any changes. The sign-off required to
proceed to development was often delayed as stakeholders required frequent
revisions to documentation since they were uncertain if the design would
adequately support the requirements.
Since the design phase of almost all BT projects exceeded original plans, the
development phase was shortened to try and bring the projects back to their
original schedule. As a result, development teams worked extremely long hours
and often substituted testing time to complete more development. This became
particularly apparent when integration with other systems was required. As a
large enterprise organization, almost all IT projects had extensive integration
requirements and these would often stretch into months as teams addressed a
large number of defects.
By the time many BT projects were finally ready for deployment, 12-24 months
had passed post their approval. To make matters worse, the requirements and
design of these projects had little in relation to what had been originally
anticipated.
To address these issues, BT implemented a new 90 day delivery cycle. This was a
radical change from their previous delivery model, and it was intended to ensure
that only the highest value business requirements would be delivered.

6. 5 | P a g e
To assist with this, a Scrum framework was adopted, and a Product owner
determined the priority and business value of requirements.
The sign-offs and formality of the old processes were replaced with a lightweight
series of sprints, with each sprint demonstrating value through working software.
BT also implemented an agile team approach for its projects. Instead of rigid roles
and organization structures, teams were
encouraged to collaborate and manage
their activities to meet the schedule to
which they had committed for each sprint.
Business participation was now required
with the shorter delivery timeframes with
the result that detailed requirements
documents were no longer required.

7. 6 | P a g e
BT teams also started leveraging unit testing and automating builds and testing
frameworks. The result was a much higher quality code base that was also more
flexible as any design changes that caused defects could be identified by the unit
tests. Teams began to introduce agile techniques like paired programming and
continuous integration, which resulted in higher development output with less
time spent on managing defects.
Agile also provided the flexibility and adaptability that BT needed. The old
waterfall approach was a one-size fits all structure. However, not all projects
benefited from its many checks and balances. Using an agile approach, project
teams could determine how much governance and process they needed to deliver
their requirements.
Final Outcome
Agile was instrumental in helping BT substantially reduce its project delivery times
while increasing the delivery of business value. Had BT not adjusted to a more
agile delivery model, its competitiveness would have been undermined and it
would have struggled to retain its relevance. Now BT is a multinational
telecommunications company with operations in 170 countries.

8. 7 | P a g e
Critical Success Factor
BT’s application of agile techniques contributed to its success in several key areas.
Shorter delivery times focused business and IT teams on the highest value
requirements. With more focused requirements, design activities were better
managed, which allowed for more robust designs. Development efforts
emphasized more testing and test automation which created a more stable
software solution and permitted design adjustments to accommodate any future
changes. Finally, ensuring smaller collaborative teams of both IT and business
representatives improved communication and reduced the need to rely on formal
documentation. As a result, BT internal customers not only experienced shorter
delivery timeframes but also received solutions that more directly reflected what
they wanted in their original solutions.