Real-life Scenario: A Fortune 100 company decided to revamp its Information Technology (IT) application landscape as part of its business strategy to improve profitability. The company embarked on a mission to realize the vision, and a large business and IT transformation initiative was under way.
It was a massive undertaking, requiring hundreds of dedicated individuals not only from within the organization but also from external service providers. After about 18 months, the new application was ready to be validated by the business users. The first deployment was just two months away. Everything seemed to go as planned — until chaos erupted.
There was a surge in defects, and business transactions could not be completed end-to-end. As you might expect, a lot of time was spent finger-pointing, but the analysis that followed was instructive. Fig. 1 below shows the root-cause analysis for a couple of issues.
Root-Cause Analysis
The immediate causes (proximate factors) were 1) the application was not functioning with the “real” data extracted from the legacy systems; and 2) some critical business functionality was found missing in the new application. How could this happen?
The team spent significant efforts in documenting the requirements and meticulously translating them into detailed design documents. This was followed by validation using several thousand test scripts. It’s necessary to look at the root-cause analysis to understand the ultimate factors leading up to the issues that surfaced during user validation.
The next level of analysis revealed that 1) most of the testing done in previous cycles used new data or sanitized data from legacy systems, and the incompatibility of the application with the “real” data couldn’t be discovered till the end; and 2) the functional design indeed did not address some business rules that were found to be absolutely necessary.
Further analysis revealed that 1) the real business users were not involved while finalizing the test strategy or user acceptance test scripts; and 2) functional design was carried out without completing business process design.
Still further analysis revealed that neither the methodology nor the exit criteria were adequately defined or enforced. This brought up the question of how these steps were missed. Why did the PMO (program management office) not enforce best practices? The reason is that there was no PMO at the beginning of the program, when major decisions on methodology and exit criteria were made).
The PMO that was established later did not have the mandate to oversee both the business and the IT teams. The lack of adequate enforcement was attributed to changes in the PMO, which was controlled by different teams during the life cycle of the program.
The reasons (ultimate factors) for the apparently sudden chaos can be summed up as follows:
- The implementation methodology and gating (exit) criteria were not clearly defined and, more importantly, they were not enforced.
- There was no formal PMO structure in the beginning. The PMO that was set up later lacked the authority or independence to enforce best practices.
- Real business users (more specifically those who use the system and those who could make decisions) were not actively involved during critical points (such as application design, test strategy and data conversion). The people who made decisions during the design, test planning and data conversion planning were not the “real” business users. The real business users who were involved in the final validation were never involved in the previous phases of the program. That explains why the issues seemed to crop up suddenly.
Origin of Transformation Programs
The above example illustrates that the most fundamental aspects of program management have the most profound impact on the success of the program. Before discussing the success factors, let’s look at the business drivers and some of the more common characteristics of large transformation programs.
The dynamic and global nature of business requires organizations to be innovative continuously. They need to constantly unlearn and re-learn to stay in business and to increase profitability and market share. Getting ready to meet future business needs requires visionary thinking, strategic planning and thorough execution of plans. The key business drivers of any transformational initiatives:
- Streamline business processes of disparate units merged through an acquisition
- Improve operational efficiency in order to handle larger volumes faster and cheaper
- Replace outdated IT infrastructure or application(s)
- Roll out proven applications to other regions or other business units of the organization
Characteristics of Large Transformation Programs
The following characteristics apply to many, if not all, business transformation programs:
- Changes to business process
- Multiple interdependent sub-projects (tracks)
- Multiple business units — and therefore multiple stakeholders driving/influencing the outcome and/or execution of the program
- Multiple vendors/service providers
- Longer duration (typically over 12-18 months) and therefore the need to deal with changing goal post due to changing business environment during project life cycle
- Large number of end-users.
How can we manage the challenges?
As we have seen in the above example, a majority of problems experienced during the program execution phase are traced back to lapses in the planning phase or poor enforcement of agreed processes.
Following are some basic principles that have a great impact on implementation success. Some of these principles were learned the hard way (by failing to implement). These recommendations, or “10 Commandments,” will help direct energies toward the most fundamental aspects of program management.
- 1. The Program Management Office (PMO) must be independent of business and IT delivery teams with full-time empowered members responsible for the success of the program.
2. The methodology of execution and exit criteria for each phase of the program should be clearly defined at the beginning of the program.
3. Plan a time-buffer in the schedule that can be invoked only by the steering committee. Re-plan at the end of every phase.
4. Involve end-users throughout the program and not just during requirements gathering and deployment phases.
5. Not all resources are equal. Identify bottleneck resources and manage them closely. Reassign tasks to other non-bottleneck resources where possible.
6. Avoid tracking progress of the project based on arithmetic (weighted) average of individual tasks. Focus on critical path activities and continuously review the critical path.
7. Be aware of the organization’s risk appetite.
8. Reach out to all levels to identify risks. Do not rely entirely on reports from track leads.
9. Keep an open mind, and be ready to make course corrections.
10. Time is the only common unit of measure. While you may have to make short-term compromises, do not lose sight of long-term objectives.
The next installment in this series will take a closer look at the first five of these “10 commandments.”
10 Commandments for Large Business and IT Transformation, Part 2
Raghuram Putcha, a program manager with Infosys Technologies’ enterprise solutions group, has managed several large IT transformation programs. He has more than 18 years of experience helping define and implement CRM and ERP strategies for Fortune 100 customers in the manufacturing, logistics, high-tech, banking, insurance and financial services industries.
Loading ...
The best part of this article is that it is based on a true story. This helps people understad that these issues are real, and still happen in large companies.
The description you make of the methodology they followed looks very waterfall – get users to define the requirements, go develop for 18 months, and then come back with a "solution" to be tested.
Companies (of all sizes) should have learned by now that this just doesn’t work.
In 18 months everything changes. Not only the business and market change, but also the project teams, the users… and these changes happen not only to the company but also to service providers and consulting companies involved.
You said it best "The dynamic and global nature of business requires organizations to be innovative continuously."
There is no way you can pull of an 18 month project without thinking in this manner. You’ve got to involve end users every step of the way, test with real data from day one, and be prepared to change direction, include some features and remove others that no longer make sense.
This all spells "Agile" to me. Would you agree?
Cheers
Michel Ozzello