10 Commandments for Large Business and IT Transformation
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.
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."
Most budgets include a cost contingency, but few plan for an explicit time-contingency, or time-buffer, at the program level. Not having an explicit time-contingency at the program level forces all tracks within the program to build buffers that will result in longer duration for the program as a whole.
Part 1 of this three-part series looks at a real-world case of IT transformation breakdown and explores the causes for the failure.
There are 10 basic principles that can have a substantial influence on the successful implementation of a large IT transformation program. These recommendations, or "10 Commandments," will help direct energies toward the most fundamental aspects of program management.
This installment explores the first five recommendations in detail.
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.
All large programs are driven by some form of PMO or the other. In most cases, PMO serves as the administrative arm of the program lead. The general perception of a PMO member is that of a person who follows up with the track leads for status reporting. It's true that the PMO is responsible for defining and implementing the processes, tracking progress against schedules, and providing status reports to the steering committee. What makes the PMO effective, however, is its independence and empowerment.
The PMO should be independent of business or IT delivery and validation teams. The business team is responsible for defining the requirements and acceptance criteria. The IT delivery team is responsible for design and development of the solution. The validation team is responsible for testing the solution and certifying conformance to business requirements defined by the business team.
An independent PMO enables objective analysis of the status and options for course correction, when needed. A PMO that is controlled only by either the business or the IT delivery team will not have the mandate needed for objective analysis.
The PMO should be staffed by full-time members who are charged with the success of the program. The PMO should have the authority to request status; define, enforce and audit project management processes such as change management, risk management and issue management; and negotiate with all the stakeholders.
Subordinate everyone involved with the program to the PMO. It's the responsibility of the executive sponsor to ensure that all teams report into the PMO, so the PMO does not end up as an administrative body churning out reports.
2. The methodology of execution and exit criteria for each phase of the program should be clearly defined at the beginning of the program.
It never pays to plan the entire program in great detail at the beginning. In most cases, it's not possible to get into the level of detail required to come up with an exhaustive list of tasks or accurate schedule. However, the methodology to be followed MUST be defined and agreed upon before embarking on the program.
An implementation methodology and gating criteria (entry and exit criteria for each phase) MUST be defined. The criteria should be specific (unambiguous), measurable and verifiable. It's important to follow gating approach and make explicit Go/No-Go decisions at the end of each phase.
In the real-life example illustrated in Part 1 of this series, the methodology and gating criteria were not clearly defined and signed off. The generally accepted sequence of phases in a typical IT implementation program is as follows (actual terminology may vary from organization to organization): scope definition, requirements definition, business process design, solution design (functional design, technical design), solution development, validation and deployment.
In the example, the functional solution design was dependent on the business process design. The team was fully aware of that. However, the methodology and gating criteria were loosely defined and were not enforced. The program team proceeded with solution design before completing business process design. Detailed solution design documents based on a loosely defined and incomplete business process design formed the basis for subsequent development efforts.
The result, as you can imagine, was a solution that was developed on business processes that were neither accurate nor agreed upon by the business team. In the end, the program was delayed, resulting in significant cost overrun.
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.
Fig 2: Timeline with and without program-level time-buffer
It's not uncommon to budget for a contingency in any project and especially so in large programs. Most budgets include a cost contingency, but few plan for an explicit time-contingency (time-buffer) at the program level. Not having an explicit time-contingency at the program level forces all tracks within the program to build buffers that will result in longer duration for the program as a whole. Figure 2 is a simple representation of the concept of program-level time-buffer.
The argument can be made that having a program-level time-contingency will not prevent individual track leads from including buffers. However, having a program-level time contingency at the end of the program schedule, coupled with incentives to meet the schedules -- rather than punishments for not meeting the schedule -- will motivate teams to work collaboratively.
Leaving the decision to use the time-contingency with the steering committee allows for greater control to manage the variations in schedule slippages of various tracks and across project phases. Re-planning at the end of every phase is the key to ensure that the schedule is relevant, realistic and achievable. Commercial agreements with service providers need to be reviewed and firmed up at the beginning of every phase.
4. Involve end-users throughout the program and not just during requirements gathering and deployment phases.
It's a common practice to involve end-users actively during requirements gathering and acceptance testing phases. However, the users need to be actively involved in other phases as well, namely prototype design, solution development (application walk-through) and test planning phases.
Change control is an inevitable aspect of any large program. The end-users need to be actively engaged as part of change control process. The PMO should ensure that the long-term impact of each change request is clearly understood and accepted by the end-users.
Active involvement from end-users comes at a cost. Trying to save this cost will cost the entire program dearly.
5. Not all resources are equal. Identify bottleneck resources and manage them closely. Re-assign tasks to other non-bottleneck resources where possible.
Human factors greatly influence the outcome of any project more than any other factors -- more so in programs involving IT service delivery. In the real world, you may not always have the resources with the right skills in the right numbers at the right time. There are always some resources or roles that are more critical than the others, either because they have unique (niche) skills that are hard to find, or the roles are highly knowledge-intensive and need longer training to develop the expertise.
Whatever be the reason, it's important to identify critical (read bottleneck) resources early in the program, and manage their time and monitor the progress of tasks assigned to them diligently. It's easier said than done, but not doing it is a sure recipe for failure. As with any tracking, managing bottleneck resources requires additional management focus and bandwidth.
Any activity that can be carried out by non-bottleneck resources should be taken away from bottleneck resources. For example, an SME (subject matter expert) is expected to define the business process, but documentation tasks are a sub-optimal use of the expert's time. Assigning a more easily available resource to shadow the SME and do the documentation will not only expedite the deliverable but also help train a new resource as a backup.
The third and final installment in this series will explore commandments six through 10 for implementing a successful large business and IT transformation.
Though there are no foolproof methods to uncover all the risks, it is important to reach out to lower levels of the management pyramid and not rely solely on reports from the track leads/project managers. The main advantage of reaching out to lower levels of the management pyramid is increasing the chances of uncovering and qualifying risks early.
Part 1 of this three-part series looks at a real-world case of IT transformation breakdown and explores the causes for the failure. Part 2 explores the first five "commandments" for successful management of a transformation program.
Those guiding a major IT transformation will find their jobs easier -- and be rewarded with better results -- if they adhere to 10 best practices, or "commandments," along the way. The first five: 1) The program management office must be independent and empowered; 2) Methodology must be clearly defined from the start; 3) Build a time-buffer into the schedule and re-plan after every phase; 4) Involve end-users throughout the program; and 5) Identify bottlenecks and clear them.
Following are the next five "commandments" for IT transformation success:
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.
A lot of effort goes into progress tracking and reporting. As there are many teams involved, tracking the progress of the program can be an arduous task and definitely a full-time job. However, what we are referring to here is the accuracy of status reporting. How often is a project reported to be progressing smoothly until someone realizes that a critical task is behind schedule, thereby pushing back the end date by a few days or weeks?
It's a very common occurrence to see a task at 90 percent completion level, but delayed by more than 100 percent of the planned duration. The common mistake is to compute the progress based on an arithmetic average of individual tasks without due regard to critical path activities.
This is especially true in a large program. A slight delay in one project (track) may have a cascading impact on other tracks, thereby putting the entire program in jeopardy. It's important to collect details on critical path activities from various tracks in a consistent and uniform manner, so that the real status at the program level is visible to all stakeholders. It's more important to know the "expected completion date" of tasks in-progress rather than just percentage completion.
7. Be aware of the organization's risk appetite.
The risk appetite varies from organization to organization. It depends on several factors, such as the industry that it operates in, the type of product or service it sells, the maturity level of the product or service it sells, the competitiveness of the marketplace, and the inherent culture of the organization. Risk appetite of an organization is also driven by time-to-market considerations, particularly in the high-tech industry.
What is considered an acceptable risk in one organization may be unacceptable in another. Take the banking industry, for instance. Within a bank, the risk appetite of the retail banking business unit is lower than that of the investment banking business unit.
While evaluating the options to address the risk, it's important to take into account the risk appetite of the organization.
8. Reach out to all levels to identify risks. Do not rely entirely on reports from track leads.
Most large programs conduct risk assessment at the beginning of the program, and many have formal risk review boards to review the risks periodically and manage them. However, the key is to identify the potential risks proactively.
Though there are no foolproof methods to uncover all the risks, it is important to reach out to lower levels of the management pyramid and not rely solely on reports from the track leads/project managers. The main advantage of reaching out to lower levels of the management pyramid is increasing the chances of uncovering and qualifying risks early.
At lower levels of management, where the accountability is limited in scope, the risks are freely discussed and therefore have a better chance of getting the attention of the risk review board.
9. Keep an open mind, and be ready to make course corrections.
As many of the business transformation programs run into several months (12-18 months), the team is confronted with many changes -- changes to business requirements, changes in team composition -- not to mention the technological challenges that surface during the execution phase.
Keeping an open mind and following a rigorous change management process are critical to ensure that these changes/challenges are addressed as objectively as possible.
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 expression "time is money" is an old cliche. It's more apt in project management, as it is the only common unit of measure that ties all the three dimensions of a project -- namely scope, schedule and cost. Here, the term "time" is referred to as the "elapsed time" for the whole program.
Every change or delay needs to be looked at from the program standpoint. Any issue or change that impacts the elapsed time of the program not only increases the project cost, but also delays the business benefits expected to be realized by the program. Everyone needs to ask the question, how does this affect the elapsed time of the whole program?
Everyone may not have a direct or easy answer. However, probing the impact of every issue or every delay from a program standpoint allows the team to differentiate local issues from global issues, as well as to prioritize resources so as to minimize the impact to the overall program schedule.
Institutionalizing this culture in the team helps the team make short-term compromises while minimizing the impact to the long-term objectives.
In Conclusion
Finally, every program is unique, and several decisions need to be made during the course of the program.
While we can't predict the numerous challenges we may encounter along the way, the fundamental principles discussed in this article will help the team stay on course toward meeting the objectives.
These are from my personal experience and by no means an exclusive set. As they say, excellence is a journey, and learning is a continuous process. The journey continues.
revamp /ˌriːˈvæmp/ v. 改变；修改；（通常指）改进外观，翻新
finger-pointing 指责 e.g. a lot of time was spent finger-pointing.
proximate /ˈprɒksɪmət/ a. （时间、顺序等）最接近的，最邻近的
meticulous /məˈtɪkjələs/ a. 细心的；小心翼翼的 meticulously ad. 极注意地,极细心地,一丝不苟地
sanitize; -ise /ˈsænɪtaɪz/ vt. 去除…中使人不快的内容；净化;（用化学制剂）消毒，使清洁 e.g. This sanitized account of his life does not mention his time in prison. 这份生平记述对他的不光彩之处略而不表，没有提及他在监狱的日子。
disparate /ˈdɪspərət/ a. 由不同的人（或事物）组成的; (两种或两种以上的事物)迥然不同的；无法比较的
commandment /kəˈmɑːndmənt/ n. 诫条（尤指《圣经》中上帝给犹太人的十诫之一）
contingency /kənˈtɪndʒənsi/ n. 可能发生的事；偶发（或不测、意外）事件 e.g. We must consider all possible contingencies. 我们必须考虑一切可能发生的事。
perception /pəˈsepʃn/ n. 知觉；感知; 洞察力；悟性; 看法；见解 e.g. a campaign to change public perception of the police 改变警察公众形象的运动
churn /tʃɜːn/ v. 剧烈搅动；猛烈翻腾; 反胃，恶心（担心、忧虑、厌恶或恐惧的强烈感觉）;（使）感到不安，心烦意乱;用搅乳器搅乳（制作黄油） n. （制作黄油的）搅乳器;（旧时）盛奶大罐，奶桶 churn something↔out （粗制滥造地）大量生产，大量炮制
slippage /ˈslɪpɪdʒ/ n. 延误；逾期; （微弱或逐渐的）下降，降低，贬值
foolproof /ˈfuːlpruːf/ a. 使用简便的；完全可靠的；万无一失的
arduous /ˈɑːdjuəs/ a. 艰苦的；艰难的 an arduous journey across the Andes 翻越安第斯山脉的艰苦之行
push back 把...向后推 push something to the back of your mind 刻意忘掉（不愉快的事）；把…丢到脑后 push something back 推迟；延迟
reach out to sth. 接触 reach out to somebody 表示对某人感兴趣；表示愿意提供援助
cliche [ˈkliːʃei] n. 陈腐的说法;陈词滥调
standpoint /ˈstændpɔɪnt/ n. 立场；观点 a modern/political/theoretical standpoint 现代╱政治╱理论观点
359
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
