presentation by gaurav sapra

Mantra for Innovative Project Management

Gaurav Sapra Programme Manger

TCS

TCS Confidential

Title – Never too big to fail: How a fusion approach can improve chances of project success

Theme – Mantra for Innovative Project Management

Keywords – Fusion Approach for Project Success

Abstract

Big projects fail at an astonishing rate.

This paper looks at some of the reasons why projects, whether major technological installations, infrastructure

upgrades, or new growth initiatives, don't deliver in spite of advances in project management capability, access

to data, and lessons learnt from previous failures. It assesses the relative strengths and weaknesses of

traditional ‘waterfall’ models of project management and ‘agile’ methodologies.

The paper considers the fusion of the strong, comprehensive framework that conventional project management

favors with processes from agile methodology such as Scrum and extreme programming (XP).

Citing real world examples of technology migration and infrastructure upgrades for European clients in the retail

and banking sectors, the paper looks at the way such blended processes can improve the chances of project

success. Additionally, it identifies variables that project managers can look to in order to assess the potential of a

fusion solution. It touches on the role of organizational structure and culture in the success of business

transformation and considers how project managers can reimagine some of their traditional approaches.

Never too big to fail: How a fusion approach can improve chances of project success

Contents

1 Introduction: Why Projects Fail ......................................................................................................................4 2 Conventional Approaches: Strengths and Weaknesses ..............................................................................5 3 Fusion - Solution Approach ............................................................................................................................7

3.1 Waterfall Delivery in an Agile Package .......................................................................................................7 3.2 Waterfall Project with Agile Execution ........................................................................................................9 3.3 More Flavors of Fusion ............................................................................................................................ 11

4 Variables to Consider When Looking at a Solution Approach ................................................................. 12 4.1 Organizational Structure and Culture ...................................................................................................... 12 4.2 Risk Appetite ............................................................................................................................................ 12 4.3 Corporate Governance ............................................................................................................................ 13

5 Conclusion ..................................................................................................................................................... 14 6 References ..................................................................................................................................................... 15


1 Introduction: Why Projects Fail

Large scale technology projects fail at alarming rates despite huge investments in management structures,

governance, methodologies, and frameworks.

In 2012, a study by Oxford University and McKinsey & Company revealed the high failure rates of large projects:

on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less

value than predicted.1

There are varied reasons for these failures. Common causes include: communication gaps or the lack of proper

stakeholder management; poorly identified requirements and the resultant creep in scope; inadequate resources;

and a lack of executive support.

Failure to adopt the proper project management methodology is also seen as an impediment in project success or

a contributor to failure.

In my experience, upgrade or migration projects present the highest failure rates in the portfolio of IT projects.

Reasons for this include: the lack of a clear upgrade path or migration strategy; requirements that grow

increasingly complicated due to demands for added functionality and features to compensate for perceived

limitations; poorly scheduled project plans; users’ lack of familiarity with the new environment; failure to plan for

tuning and stabilization phases.

Innovation – not necessarily major breakthroughs, but often just the smaller adjustments leading to successful

and early outcomes – can be a key differentiator between success and failure. So too can the ability to unlearn

and relearn as we ensure that false beliefs and assumptions do not inhibit project success. Relearning allows us

to view the world from a different perspective rather than being limited by standard techniques.

That different perspective can involve fusing some of the best parts of the established models of project delivery.


2 Conventional Approaches: Strengths and Weaknesses

Focusing on the relative strengths and weaknesses of ‘predictive’ and ‘adaptive’ SDLC methodologies, we can

consider how and when to leverage the appropriate aspects of each to meet our development goals.

Waterfall Model - Proponents of a structured approach to software development argue for creating a sustainable,

disciplined, and repeatable development process that results in a sequential set of phases to design, construct,

and deploy the application. The waterfall model is also referred to as the predictive methodology. In this model,

each phase can begin only when the previous phase has been completed and the stage gate crossed. See Table

1 for a detailed description of this model’s strengths and weaknesses.

Strengths Weaknesses

The waterfall model requires upfront agreement on the

requirements and scope, which makes the design

exercise easier and robust.

It does not offer easy alignment to changing business

requirements.

Stringent processes and heavy documentation may

lead to time and money being wasted on non-value-

adding tasks.

Progress tracking and measurement is straightforward

since the entire scope of work is known in advance.

The waterfall model does not offer visibility to users,

since the actual working software is not visible until

late in the cycle.

The customer only needs to be involved in the review,

approvals, status meetings, etc.

The delivered product may not be in line with the

customer’s expectations.

Resources can be planned as and when required at

any stage of the project.

No/little active collaboration between the team

members and directions coming top down may lead to

misaligned work and re-work.

Table 1: Strengths and Weaknesses of the Waterfall Model

Agile model – This incremental development model is often referred to as the adaptive methodology. It

emphasizes the discipline of people instead of process, and offers flexibility. It fosters customer collaboration and

tries to minimize documentation while delivering software incrementally and allowing the customer to introduce a

change at any point. Table 2 lists its strengths and weaknesses.

Strengths Weaknesses

This is newer than the waterfall model, and typically

has higher success rates and better satisfaction.

There is low awareness of and experience in the true

implementation of Agile practices.

Close collaboration with the customer makes it more

likely that the application meets customer

expectations.

It requires a high level of customer interaction, which

may not always be possible.


It fosters active collaboration within the team, which

empowers employees and encourages quick resolution

of issues.

Agile practices advocate having the team present at

the same location for better communication; but this

may be a challenge in terms of cost and acquisition of

resources.

Changing business requirements can be aligned to

business priorities.

It is difficult to make clear commitments on the scope,

time, and cost of agile projects.

It ensures that each member of the team contributes

and continuously learns and improves.

The principles of the agile model allow small teams for

active collaboration, which may not meet the needs of

large projects for large organizations.

Table 2: Strengths and Weaknesses of the Agile Model


3 Fusion - Solution Approach

By blending the usable and effective processes from these two established methodologies, we can produce a

‘fusion approach’ underpinned by the principle of ‘adopt and adapt’. The Fusion approach can be used as a

framework and adopted for specific projects, and customized as necessary.

We present two examples of how such a framework can be used in migration and upgrade projects with the

ultimate goal of enhancing the success rate.

3.1 Waterfall Delivery in an Agile Package

This framework is depicted in Figure 1. Salient characteristics include:

● A prioritized set of backlog – the high-level prioritized product backlog (services to be upgraded or

functionalities to be migrated) is created and owned by the business manager or product owner

● Iteration – each time-boxed iteration picks the priority items from the product backlog and runs the waterfall

cycle to put the output into production

● The selected set of agile processes underpins the whole framework


Case Study 1 – Oracle Upgrade Program for a Banking Giant in the UK

A global investment, retail, and business banking (RBB) organization embarked on an upgrade of the Oracle

database from version 10g to 11gR2. The bank has separate capital, corporate, and wealth management

functions, which are further segregated into multiple services provided in each business area. Each service runs

as a business entity and owns the supporting technology infrastructure, while the plan is to host some specific

critical services on a corporate platform.

The bank’s Oracle department initiated the upgrade program. The upgrade would be paid for by the Oracle

department and not charged to the service if the service allowed the upgrade to be completed by end-2013.

The program management and the technical upgrade was outsourced to TCS, and the client gave us a free hand

in choosing the delivery model. After some consultation, the client agreed that an innovative fusion methodology

would best meet its needs, and this would be adopted with the parallel and integrated assessment project

reporting into the upgrade project. (See Figure 2)

The fusion method used for the upgrade proved worthwhile: the upgrade was completed successfully with a 98

percent Customer Satisfaction Index, and the client asked us to take on other upgrades in the UK and in

continental Europe.


3.2 Waterfall Project with Agile Execution

This framework is depicted in Figure 3. Key characteristics include:

● Distinct stages of definition, development, testing, and deployment are included in the lifecycle of the project

● The development stage is conducted iteratively and incrementally using processes from different agile

methodologies

Case Study 2 – SAP R3 Upgrade for a Retail Giant in the UK

The finance department of a leading retail company was using disconnected and disparate finance systems,

leading to problems with data reconciliation. Multiple versions of files created on different computers meant that

no single version of the truth existed. A program was planned for upgrade of the SAP system to ECC6.

The company’s IT team was traditionally focused on managing projects with the Prince2 based EPM methodology

with little flexibility to innovate on the delivery methodology. The projects landscape is depicted in Figure 4.


The finance team in the IT department needed the problems with data to be resolved before the end of the 2013.

A quick wins project was agreed on; it involved configuring the SAP solution while keeping it in line with the

upgrade program from SAP 4.3 to ECC6. The upgrade impacted multiple business areas of the organization

including: procurement, finance, accounting, and projects.

As depicted in Figure 5, a force field analysis was used to identify the right delivery methodology. The whole

project was run innovatively with a fusion approach focused on business operations from day one.


The business requirements document and high level design for each business area were created via multiple

conference room pilot (CRP) sessions.

Each business unit development was competed iteratively by a different Scrum team. During the development

stage, the features code was always ready for testing and there was continuous integration. A go-live every 2-3

weeks produced early and incremental business benefits, and the business requirements document evolved to

capture the functional specifications. Daily Scrum meetings were held to align progress with business priorities,

and plans for the support stage were created during development. The pair programming practice of the extreme

Programming(XP) methodology was used to ensure the code/configurations were consistently reviewed and

written in alignment with the bigger picture of integrated solution.

The project was completed successfully with a Customer Satisfaction Index of 99 percent. The approach was

acknowledged as a prospective framework that could be used to deliver and manage similar projects without

disrupting the existing culture and governance of the organizational projects and programs.

3.3 More Flavors of Fusion

In addition to the frameworks described above, there can be multiple shades to the fusion approach, each

designed to suit a number of operating variables. These could include a delivery model that combines waterfall

hardware infrastructure with agile software or a ‘mix and match’ of different waterfall processes with agile

practices.


4 Variables to Consider When Looking at a Solution Approach

As with any methodology or delivery approach, the fusion approach may deliver more efficient and effective

results if aligned and tweaked appropriately to suit the operating environment. Several factors may impact the

implementation and use of the fusion delivery approach.

4.1 Organizational Structure and Culture

The structure and culture within the client organization may be a propelling or restricting factor for the delivery of

projects, particularly in upgrade or migration projects where one of the requirements is to retain a stable and

competitive technical state. The following organizational structures may prove conducive to the implementation

and operation of a fusion model.

● Organizations where core business companies act as customers to the IT services sister company: The

projects landscape is seen to be much more receptive to innovation-led models if IT services are segregated

into portfolios supporting the operations and projects of specific business units within the organization.

● While it may be desirable to have the same team operating through the waterfall and agile stages of the

project, some organizations will have separate centers of excellence and will prefer to have specialist

resources conducting the respective stages of the project. In this instance it is essential that the specialist

resources for each approach share the global vision of the project and understand their role within the

organization. Simulating operating training and team exercises during the kick off or on-boarding phases has

been found to be useful in such situations.

● A culture of genuinely recording and later studying the lessons learned from past projects enables project

management teams to choose the best delivery model. This culture, if well integrated, will also help project

managers tweak the fusion model appropriately, within the risk framework of the organization and the

program.

● The fusion approach may also promote the importance of generalist project managers/leaders with fresh

perspectives and non-judgmental thought processes rather than specialists who come with strong opinions

about particular ways of delivery.

● The security team and review and audit committee of an organization need to be aware of this flexible yet

well-monitored model of delivery.

4.2 Risk Appetite

The risk appetite of an organization will influence the potential to introduce innovative methods of project delivery.

● There may be little or no awareness or experience within the project organization of delivering projects using

new methodology or frameworks.

● The risk management strategy for a project will define the particular thresholds for the waterfall stages and

agile stages in accordance with the risk appetite of the organization.


4.3 Corporate Governance

Projects need to comply with a range of corporate governance protocols, so bodies such as audit committees

become stakeholders that will need to agree on the monitoring and control structure around the new framework of

project delivery.

● The fusion approach will need to be aligned to quality management policies. Appropriate QA and QC

processes and checks need to be embedded in the framework’s governance.

● The fusion approach should comply with the corporate risk management processes. The risk threshold along

with the escalation triggers will need to be agreed upon and appropriately tweaked in accordance with the risk

appetite of the organization.


5 Conclusion

Blending some of the best features of existing delivery models in a fusion approach is one way of mitigating high

failure rates in upgrade or migration projects. Such methodologies need to be flexible in order to handle the

complexity and uncertainty involved in projects of this nature. However, as with any other innovative approach or

model, acceptance tends to be low if there is lack of awareness, expertise, or proven ability to succeed within the

organization.

The suitability of a fusion approach depends on the adaptability of the client organization. Consulting

organizations wishing to implement the project using the innovative fusion approach may not be able to make an

upfront commitment about timelines and costs until they study and understand the variables and adaptability at

the customer’s site.

We have executed variants of the fusion approach in large-scale upgrades in retail and banking organizations.

There are many variables to consider, and some scenarios will lend themselves better than others to such an

approach. When applied appropriately in the right circumstances, a fusion model can deliver a range of benefits. It

can ensure successful completion of the project on time and within budget. For upgrade projects in particular, the

compatibility and scalability of the overall technology stack can be increased. A fusion approach also minimizes

other business risks during the upgrade by limiting the amount of unsupported technology and the resources

required to support legacy services.


6 References

1 Gartner Blog, ‘McKinsey Report Highlights Failure of Large Projects: why it is better to be small, particularly in

IT’, October 29, 2012, http://blogs.gartner.com/mark_mcdonald/2012/10/29/mckinsey-report-highlights-failure-of-large-projects-why-it-is-better-to-be-small-particularly-in-it/

http://blogs.gartner.com/mark_mcdonald/2012/10/29/mckinsey-report-highlights-failure-of-large-projects-why-it-is-better-to-be-small-particularly-in-it/

http://blogs.gartner.com/mark_mcdonald/2012/10/29/mckinsey-report-highlights-failure-of-large-projects-why-it-is-better-to-be-small-particularly-in-it/

presentation by gaurav sapra

Documents

waterfall project

project managers

project management capability

migration projects

fusion solution approach

abstractbig projects

flavors of fusion

highest failure rates