Choosing the Right Delivery Model

Selecting the right delivery model will accelerate business outcomes and reduce errors. Here’s how one UK bank used an iterative approach to transform its business processes, improve customer satisfaction, and reduce operating expenses.

The Chinese philosopher Laozi is not known as a project delivery guru, but he was on to something when he said that a journey of a thousand miles begins with a single step.

For organizations looking to undertake any type of large-scale project, that first step is usually determining which project delivery model to use. Getting it right can mean the difference between success and failure.

Take, for example, the experience of a major UK-based banking conglomerate.

The bank had grown through mergers and acquisitions to become the country’s largest financial services organization, boasting 30 million customers. Problem was, each of the acquired businesses had their own way of doing things. This was confusing for customers, and inefficient and expensive for the parent company. The bank set out to reengineer and reconcile the patchwork of business systems to increase customer satisfaction and reduce the cost of doing business.

Beware “Analysis Paralysis”

Because of the scope and complexity of the project, the team brought in to lead the transformation felt it was best to think through all project scenarios, milestones and action steps. This “waterfall” delivery model has a certain appeal, as it lays everything out in advance. But it can be tough to get traction—as indeed was the case with this bank. Three months into the three-year project, the team was still collecting documents and figuring out options and priorities.

The team took stock and acknowledged that an iterative approach might work better. The beauty of this more agile delivery model is that it allows for quick wins, the results of which inform subsequent initiatives.

Small, Iterative Wins Add Up to Big Gains

Using this iterative approach, the team was able to identify, design, build and test several priority requirements in just four months, and dramatically accelerate delivery of the entire project. Key wins include:

  • 200-plus projects completed in 18 months, with 3-4 projects running in parallel
  • 700 “Line of Business” work types reduced to 23 core processes 
  • Errors reduced by more than 50%
  • Manual process time cut from 30 minutes to 3 minutes
  • Customer complaints dropped by 75%

Pegasystems Best Practices

For those companies about to set out on their own journeys of a thousand miles, I recommend these guidelines:

  • Break large programs into smaller, more manageable components—each with a defined business benefit, and each with the ability to go live quickly and provide value on a sliver-by-sliver basis.
  • Leverage show-and-tell sessions frequently to gain user feedback. For projects using an agile methodology, this should occur as part of each sprint. For projects using a waterfall methodology, this should happen multiple times during both the elaboration and construction cycle.
  • Test early in the project lifecycle to drive higher levels of product quality and gain additional user feedback beyond the show-and-tell sessions.