INCREASING THE SPEED OF

DELIVERY VALUE
A case study for the PMI-ACP® Certification Course

Duration: 1 hour

1
Contents
Introduction 3
Challenges 3
Solution 4
Final Outcome 8
Critical Success Factor 8

2
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 around 8,000 IT professionals in a variety of roles, including project

and delivery management, architecture and design, software engineering,
integration and testing, operational support, and service management. Much of
its internal development work was traditionally channeled through a number of
business-focused delivery projects or programs, ranging from small-scale, simple
initiatives to large-scale and complex business solutions, the latter being the
norm.

Despite successfully delivering a number of large, complex solutions in a dynamic,

competitive, and 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, BT
introduced a Waterfall-based software development process as a standard
delivery methodology. In 2004, this methodology was in the process of being
rolled out when the new CIO made it clear that an entirely new Agile approach
was needed.

Challenges

BT had a comprehensive and detailed software development lifecycle, but fragile

design, poor requirements, and integration problems were the challenges. Soon,
these problems manifested themselves into a more significant issue, as the
average delivery time for a new software solution began to exceed twelve
months. In the fast-paced Telecom market, this development cycle prevented BT

3
from being competitive, and hence there was a need for change. Their new CIO
recognized Agile as a solution to many of their problems.

Solution

When 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 variety of stakeholders were required to ensure that
there was consensus on what was going to be developed. These were intended to
control the changes and ensure the successful delivery of the project. However,
the results were not as expected.

Requirements were elaborately detailed, and therefore projects were taking

longer to complete as huge requirements documents had to be created.
doneDepartments 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 ones were diluted due to the vast
array of requirements. Therefore, even though the requirements were detailed,
they did not adequately capture the required business value. Even the effort of
prioritization turned out to be counter-productive as almost all requirements
were given a high priority due to concerns that anything less important would be
removed from the project scope.

4
Given a large number of requirements, the design of BT systems became
cumbersome. Requirement analysts were assigned to other projects, and
architects and designers lacked access to the original authors of most
requirements. As a result, the design of many 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 in
the documentation since they were uncertain if the design would adequately
support the requirements.

The design phase of almost all BT projects exceeded original plans, therefore the
development phase was shortened to try and bring the projects back to their
original schedule. As a result, development teams worked long hours and often
substituted testing time to complete more development. This became particularly
apparent when it was required to integrate with other systems. As a large
enterprise organization, almost all IT projects had extensive integration
requirements. 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 were different from what was 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.

To assist with this, a scrum framework was adopted, and a product owner
determined the priority and business value of requirements.

5
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 approach for its projects. Instead of rigid roles and
organization structures, teams were encouraged to collaborate and manage their
activities to meet the schedule committed in each sprint. Business participation
now required shorter delivery timeframes. Therefore, detailed requirements
documents were no longer required.

6
BT teams also started leveraging unit and frameworks testing and automating
builds. Any design changes that caused defects could be identified during the unit
tests, resulting in a more flexible and better quality codebase. Teams began to
introduce Agile techniques, like paired programming and continuous integration
for higher development output, while spending lesser time 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. In contrast, using an Agile approach
the project teams could determine how much governance and process were
needed to deliver the requirements.

7
Final Outcome

Agile was instrumental in helping BT substantially reduce its project delivery time
while increasing the business value. If BT had not adopted an 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.

Critical Success Factor

BT’s application of Agile techniques contributed to its success in several key areas.
Shorter delivery time enabled the business and IT teams to focus on the highest
value requirements. With more focused requirements, design activities were
better managed, which allowed for more robust designs. Development efforts
emphasized on testing, and the test automation created a more stable software
solution that permitted design adjustments to accommodate any future changes.
Finally, the formation of smaller collaborative teams of both IT and business
representatives ensured 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 relevant solutions to their
requirements.