Transforming your software development capabilities: A framework for organizational change

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Zoe Eason, Technical Consultant, IBM
Lynn M. Mueller, Senior Consultant, IBM
Maria Ericsson, Senior Process Developer, IBM

15 Sep 2005

from The Rational Edge: For organizations undergoing large-scale adoption of the Rational Unified Process or related tools, this article details a framework of activities, suggestions, and techniques that can be used to help leaders make the transition from “one-off” project implementations to company-wide standardization on the IBM Rational Software Development Platform.

Over the past few years, leaders in software development organizations have begun to recognize the benefits of standardizing on common processes, skills, and tools. Those of us working on the IBM Rational services team have seen the transition from project-level adoption of IBM Rational products to large-scale standardization on the IBM Rational Software Development Platform. This larger-scale adoption represents a big investment in new techniques, related tools, and skills transfer to software development teams. Therefore, organizations need the right focus to make this a successful investment.

Large-scale standardization raises enormous questions for CIOs and heads of development. How do organizations go about this? How, for instance, do you get a standard development platform rolled out to 3,000 developers on staff? How have other organizations done this? How can you minimize the impact on your development teams whose ongoing projects are often critical to the business?

In this paper, we will present a framework of activities, suggestions, and techniques that can be used to help leaders make the transition from "one-off" project implementations to company-wide standardization on the IBM Rational Software Development Platform. Our intended reader is the person who has the vision and willingness, as well as the influence, to drive this change across the organization. This person might be referred to as the transformation lead or something similar; this person is experienced in the issues around implementing process improvements, deploying tools, and increasing the skills of the project team.

We refer to this framework as the Development Organizational Transformation Framework, or the "DOT Framework." It contains much detail, but in order to explain the basic concepts, we will offer a high-level overview, leaving subsequent papers to drill down into the details and provide examples for key areas of the framework.¹

The paper assumes awareness of the IBM Rational approach to software development, the primary benefits of which are improvements to productivity and reduced time to market (or time to deployment) for software products under development. Ideally, before looking at large-scale organizational change you will have had some experience with IBM Rational products and concepts on a smaller scale, which resulted in seeing these benefits first hand. Or perhaps a higher level of standardization has been recommended for your organization as part of a strategic review, perhaps by an experienced third party.

We will take a look at some of the challenges of organizational change, introduce ways to address some of these issues through the Kotter framework, and present the supporting DOT Framework.

The challenges of organizational change

Have you ever tried to roll out an improvement initiative across your organization? Was it successful? What challenges did you face?

Here are some of the common problems with organization-wide rollouts that we have seen:

• No sense of urgency to change: Too often, the need to make changes is only felt strongly at a middle management level. There is no senior management commitment to making a change, and the culture itself accepts "ok performance." So why is change necessary? In addition, previous successes make you and your team victims of the "old way" of doing things.
• Internal sponsors have difficulty in articulating the value of change across the organization: In many cases, the need for change is recognized, but the team struggles to put a compelling business case together to highlight the value of the changes required.
• Piecemeal activities, the big picture is missing: In many organizations, the focus starts on one area of pain, which is looked at in isolation, rather than understanding the bigger picture and breaking it down into manageable interrelated focus areas. The deployment program is not focused on project success for a number of reasons. For example, there is no subject matter expert / champion in the project; ideally, someone on your team really understands and cultivates enthusiasm for process and tools that will improve software development success. But too often, this person is assumed to be a consultant from IBM Rational staff or some other consultant body. Yes, we can help, but the big picture needs to be understood at every level within your organization.
• Too much is taken on too soon: More process does not automatically lead to more success. Sometimes, too much enthusiasm for a new process leads to over-customization of software development tools and/or processes. In fact, process frameworks, such as the IBM Rational Unified Process®, or RUP®, should be carefully evaluated so it's applied only to the extent that it makes sense for your organizational capability and need to improve. Often organizations depend on heroic individuals to get the job done and this approach becomes part of the culture.
• No communication of successes: When teams do experience success, too often the success factors are not shared with the larger organization, which causes other teams to struggle or fail regarding challenges that might be overcome. If the success is not communicated, it becomes difficult to get continued support and funding.

The DOT Framework takes these challenges into account, utilizing activities or guidelines designed to overcome them.

In general, when any size organization begins adopting modern software development practices, it needs to accommodate a great number of changes, including the following:

• At the individual or project level, new skills must be attained, new roles defined, and existing roles changed. For a while, individuals undergoing these changes will feel some discomfort until they get up to speed.
• At the project level, the new approach may require, for example, migrating from printed, signed off documents to electronically maintained models. The transition from a waterfall method to an iterative method and phases requires new modes of project organization and understanding.
• Once you scale up to the organization level, there are additional challenges. It makes sense to structure the organization to reflect the architecture of the application, rather than the functional areas. Project managers must work with a different staffing profile. Fewer staff members are involved during the early project phases in which the applications architecture is stabilized. Only after this is complete is there an increase of additional staff. Testing is performed throughout the lifecycle. To accommodate these fluctuations in staff levels and workload balance, the project and organizational leadership styles must change as well. Primarily, the focus is on tangible evidence of progress, e.g. tested executables, rather than the production of documents.

The above list is hardly exhaustive. But it suggests the types of changes required. It is clear that in order to take advantage of the IBM Rational solution and realize its full benefits, you need to change the organization itself. To transform an organization requires planning and leadership.

Back to top

Kotter's eight steps for organizational transition

There are several models to help drive organizational change efforts, including the Software Engineering Institute's IDEAL model² and John Kotter's eight steps.³ There are strong similarities across these models, but Kotter is perhaps the best known and the one we will align with in this paper.

Kotter's model is based on extensive research to discover what behaviors are characteristic of organizations that have been successful in change efforts. This is the model we have been utilizing in most of our engagements. Kotter is an expert on business leadership, helping scores of organizations to adopt change successfully. He says that organizational change programs typically fail because people fail to alter their underlying behavior. He places an emphasis on leadership to make change happen and identifies this eight-step process that every organization must go through to achieve its goal.

The DOT Framework explained in this document is aligned with the following eight steps, which we present here briefly. We will discuss them in more detail as we go through each area of the framework.

1. Establishing a sense of urgency. Begin by asking: Why are you doing this? What is the urgency? These simple questions really help to establish how serious your organization is. If there is no urgency, you run the risk of wasting your time, as it will not be given the appropriate support -- primarily, resources and funding.
2. Creating the guiding coalition. You need to establish which people in your organization will help make this change initiative happen. This should be a combination of key players from the management team, experts in the subject, and those who have credibility within the larger organization.
3. Developing a vision and strategy. You need to create a clearly articulated vision for your change program and a strategy to get you there from where you are today.
4. Communicating the change vision. It is not sufficient to simply articulate the vision at a management-level meeting; it needs to be written down and communicated by the management team across the organization.
5. Empowering broad-based action. For this change to be successful, the team needs to be empowered to make the right changes and remove any barriers. Rewards and recognition are key incentives to encourage people into this new way of working.
6. Generate short-term wins. To get and maintain support, it is vital to attain some short-term goals and thus build confidence in the approach. These achievements need to be communicated.
7. Consolidation of gains and producing more change. You need to consolidate what is working, and extend this to introduce more capability improvements into the organization.
8. Anchoring new approaches in the culture. Ultimately, you want to anchor these new techniques within the culture of your organization.

As you go through each step, we recommend that you rate your ability to run a change program against these elements that Kotter outlines. Think about previous efforts and relate what worked and what did not work against these items.

Back to top

An overview of the DOT Framework concepts

The DOT Framework contains a number of scales of change.

Figure 1: Each wave introduces to the organization a number of new capabilities that lead to results which, in turn, contribute to one or more of the business goals of the organization.

At the first level, as illustrated in Figure 1, you are looking at an organizational change. You need to understand where the organization is today, and its vision of the future. It is not possible to implement the whole vision at once, but a roadmap -- a sequence of change initiatives to be implemented over time -- can be defined to get you there. We represent this sequence as waves of change, each of which represents one or more change initiatives. Each wave introduces to the organization a number of new capabilities that lead to results, which, in turn, contribute to one or more of the business goals of the organization. Once the first wave is accomplished, a second wave of change is introduced adding more new capabilities and results.

At the second level of change, you are working with a specific change initiative. Figure 2 depicts the phases used to drive the implementation of a change initiative across the organization.

Figure 2: Each wave can be represented as a change initiative that introduces a set of software development capabilities that get established over time within the organization. The timeline shown in blue here indicates initial activity for one project where new capabilities are introduced, and shows a wider rollout of these new capabilities to more projects later, until the best practices become part of organizational culture -- i.e., business as usual (BAU).

Each change initiative introduces one or more software development capabilities across the organization -- for example, the ability to capture requirements, and manage them along with changes over the lifecycle of a development project. These capabilities are introduced along with the necessary process, skills development, and tools to support them. For each initiative, as shown in the blue timeline in Figure 2, the implementation is broken down into four phases. In Phase 1, you agree on the scope, define the business case, and define the high-level plan and results that you require from the initiative. In Phase 2, these capabilities are piloted on one or two different projects. Upon success, the best practices are harvested and packaged appropriately. In Phase 3, this package is tested by rolling it out to additional projects in order to prove the approach. Finally in Phase 4, upon success, you roll out these capabilities to more teams and projects, on a wider scale, until it becomes business as usual (BAU).

This means that you gradually work with more and more development projects, each of which (ideally) enjoys ever higher levels of success as the new capabilities become understood and perfected. This is the third level of change, working with a development project.

The complete picture of the DOT Framework is shown in Figure 3.

Figure 3: The complete DOT Framework, showing that each wave of change introduces new capabilities, which are implemented in a pilot project, then rolled out to subsequent development projects until the capabilities are part of the organizational culture.

As described above, the DOT Framework governs change at three organizational levels:

• Level 1: Defining the overall organizational change you are looking for, which will be driven by waves of change. Each wave contributes to the achievement of specific business results.
• Level 2: Defining for each wave a specific change initiative. These change initiatives are run according to phases and milestones that help control the risks of change. Clearly defined results show the benefits of the initiative. Each change initiative should deliver value independently by establishing new software development capabilities. Once a change initiative is successfully adopted and well on its way to becoming a "business as usual" approach, the next change initiative, or wave, can begin.
• Level 3: Defining specific software development projects that will help you to implement the software development capabilities associated with a change initiative. Initially, you would impact one or two projects to refine the scope and begin to form the tooling architecture. It is often the case that one project is not enough, but different types of projects may need to be piloted, e.g. mainframe and distributed. Additional projects help stabilize the tooling architecture and prove the packaged capability is in a position to be rolled out wider. At this stage, you will also see a number of centralized activities that need to be addressed, e.g. defining and supporting the central infrastructure. Note that in this paper, we examine the project implementation as a subset of implementing a change initiative. However, the project implementation can be followed as an independent exercise and is often the first place an organization starts in order to prove a new approach.

It should be clear that the DOT Framework as described here does not represent a one-size-fits-all approach. Some organizations will only be ready for project-level change, others a wider initiative at Level 2, and still others will be ready to address change at the organizational level. Kotter's eight steps can be applied at all these levels and at different levels simultaneously. Breaking this down into manageable pieces also allows optional break points in the investment profile.

Back to top

Translating DOT Framework concepts into practical steps

Now, for each level of change, let's examine the phases, goals, and activities required to adopt IBM Rational solutions on a large scale across the development organization. As noted earlier, some organizations will not be ready for a full organizational change that uses all three levels of change described in the previous section. But we will present the DOT Framework in its entirety.

The activities are broken down into the levels of change discussed. The whole framework can be used to drive organizational change, or you can pull out of the framework the appropriate levels and some of the specific techniques discussed to help you in your situation. Each activity has an entry to align it with the Kotter framework so you can see what contribution it makes to your change program.

The activities listed are fairly generic. Your specific situation will no doubt require you to add comments and notes. As you move forward, look at what has been done to date, what you still need to focus on, and what other related parties may be working on. Add comments regarding the work you can do internally, and also where you might need external help from IBM Rational consultants or other consulting teams.

The aim here is to provide you a framework that can be tailored and used as a discussion aid. Every situation is different, so you may need to add some specific activities.⁴

When looking through this framework you will notice that it is not just focused on technical activities. A big aspect of change is convincing people, so you will also see a number of activities to help the people involved improve their skills, to influence them, to communicate, and to maintain and grow support within the organization. This people focus is a crucial factor to drive success in any kind of large-scale change.

Now we will examine more detail at each level of change. At each level we will look at the applicable Kotter stages, the phases and goals, and the activities and techniques that can be used. By the way, it is useful to align Kotter to each level of change because, although there are definite mappings, each stage continues to need support and backup throughout the lifecycle. For those experienced with RUP, you can imagine laying the Kotter stages on top of the RUP chart: as you progress through the lifecycle of the change, every piece is applicable, but its emphasis changes as you progress.

Back to top

First level of change: Defining the context of the organizational change program

In this preparation stage, you start to define the high-level change program. Initially, there are three key steps in the Kotter stages that you should focus on:

1. Sense of urgency. You and, more importantly, your team need to know that your organization is serious about making a change, and that there is an urgency to making it happen. Without a sense of urgency, the change program will fizzle out quickly. In our experience, organizations often realize that they need to do something, but cannot always pinpoint the urgency specifically. You may need to help to define this urgency.
2. The guiding coalition. This needs to be established right away so that the right people direct the change effort. This requires people with positions of appropriate authority, with broad expertise and high credibility. Those with prior experience of successful change programs should be part of this group. The team should include leadership and management skills. Once you have this team you need to create trust and develop a common goal.
3. Developing a vision and strategy. The strategy or roadmap should be shared across the organization to help focus the teams on the objectives and background reasons for the change program. The first steps in the DOT Framework begin to tackle these Kotter elements.

Goal: Establish opportunity for change, and understand the current situation and future vision

At this first, or highest level of change, you seek to establish the opportunity and agree to the viability of the approach. You need to understand the current situation and the future vision. You should get to know the wider organization, what works and does not work, so that you can put forward a baseline of where you are today and a roadmap of how to get to the vision. It can be beneficial to enlist the help of an external party familiar with industry best practice to help with these activities.⁵

It is paramount to build credibility in this phase with the management team and the sponsors. This phase prepares the foundation for the change program to begin.

The essential activities in preparing for a Level 1 change are provided in Table 1.

Table 1: Essential activities in preparation for a Level 1 organization-wide change

Results and activities

At the end of this phase, you will have a baseline of the current situation, a map of the future vision, and an agreed upon roadmap/strategy. A number of initiatives/waves of change will be identified. Figure 4 illustrates how these activities map to the graphical view of our roadmap.

Figure 4: Activities within a complete Level 1 organizational change

Once you have your vision and high-level roadmap defined, you will begin to work on your first wave, which becomes a change initiative.

Second level of change -- Implementing a change initiative

This section looks at the phases and activities required to implement a single change initiative, otherwise known as a single wave within the overall change program. Implementing a change initiative will involve introducing one or more new software development capabilities into the organization. These capabilities are grouped into packages, each containing the necessary process, skills development, and tools to support the capability. The phases examine how to move from planning the change initiative, proving the approach on pilot projects, rolling out to a wider audience, and the final roll out.

Phase 1: Planning the change initiative

Alignment to Kotter stages

In this first phase, the previous Kotter stages still apply, the focus transfers into the change initiative. A sense of urgency will be targeted through the first initiative, the vision and strategy will be fleshed out, and you will continue to work with the guiding coalition.

Goal: Agree on viability, scope, and value of the initiative

This initiative will drive the adoption of one or more software development capabilities. The goal of this phase is to scope, plan, and highlight the value of the initiative, as described in Table 2. This includes building the business case, identifying the technical results you will achieve, and putting a plan in place to achieve them. This phase shares many characteristics of what RUP calls the Inception phase in that it focuses on the vision, the business case, and the high-level planning.

Table 2: Essential activities in planning a single change initiative or wave of change.

This initiative should be run as a project, with appropriate management and coordination of efforts. In an IBM Rational consulting engagement, we typically appoint a Technical Engagement Manager (TEM) to be responsible for guiding and directing the activities described in this framework and to ensure the successful adoption of the solution. This person is responsible for all aspects of IBM consultancy in the execution and implementation. Their responsibilities include assignment of resources, development of schedules, identifying areas of risk, mitigation plans, developing appropriate training plans, plus direction and re-direction of activities as appropriate. Ideally, this person works alongside the Project Manager (PM) of the initiative, mentoring the PM in these activities.

Results

At the end of this phase, you will have defined the scope, the business case and associated buy-in for the case, the technical results, an agreed plan of activities, and specific projects to work on, including the pilot project.

Figure 5 illustrates how these activities map to the graphical view of our roadmap. Note that this set of activities falls during the first portion of the timeline, marked by "We are here."

Figure 5: Activities for planning the change initiative, as seen within the larger scope of the entire change program, indicated at "We are here"

Critical success factors

When considering the pilot project(s), bear in mind the following success factors that we have learned over the years:

• Use a business critical project, with the most skilled team members to make the pilot successful.
• Always focus on project success, which means achieving real results. For example, delivering a training course is not a result. But eliminating an architectural risk by building the architecture of the application and testing it is a useful result that contributes to the project success.
• Set the right expectations. It takes more than one project to be an expert in RUP and the various IBM Rational products that support it. All projects need mentoring support.
• Don't wait for the perfect pilot project; it will never appear.
• If you are paying for consulting support, make sure the consultants are coaching your project team and not doing the work for them. Identify who is going to be on the receiving end of these skills and give them time to do the work themselves.

People are a key factor in this transition; related success factors include:

• Theory is not the problem; the application of the ideas appropriately is what's difficult. The best way to learn is by doing and having the right mentoring support.
• Hand-select your champions on the first projects.
• People who are unwilling to learn will never learn. Make sure your project team members are motivated, which is more important than skills alone.
• Give positive feedback as the team starts to achieve results; you need the team to feel successful. Rewards and recognition should be used to drive the behavior you want to establish within the organization.

Phase 2: Proving the approach

This phase is focused on proving the approach by applying the techniques on real projects and building the tooling architecture to support these projects. The location of this phase is shown on the timeline in Figure 6 at "We are here."

Figure 6: The second phase in the change initiative

Alignment to Kotter stages

The key Kotter steps that come into play include:

• Communicating the change vision. It is powerful to have common understanding of the goals and direction of your change program across the organization.
• Empowering broad-based action. As the change program progresses, you need to overcome any resistance and obstacles that you meet. This might involve removing barriers and silos, changing measurements and associated rewards, and providing appropriate skills transfer. To support these actions, it is key to publicize success associated with these changes.
• Generating short-term wins (project level). This is often an area that is forgotten; the teams adopt new approaches well with positive results, but no one promotes them back into the organization. You need to provide evidence that the investment is worth it. Change agents should be promoted with a pat on the back, the management team needs to be kept well-informed as the change initiative builds momentum.

It is also important to remember the previous Kotter steps, since they pertain to this phase too -- the sense of urgency should maintain momentum, you need to start to look at how to realize the vision and strategy, and the support of the guiding coalition continues to be vital in this phase.

Goal: Prove the process and tooling architecture

In this phase, the objective is to prove the tooling architecture of your solution -- this is analogous to the RUP Elaboration phase. This architecture is proven by working with one or more pilot projects, introducing one or more software development capability packages. By doing this, the proposed change strategy is validated, and you can begin to build and consolidate the central tooling infrastructure. As in the RUP Elaboration phase, this phase of the change initiative focuses on reducing risk.

Essential activities

There are three essential groups of activities for this phase:

1. Working with pilot projects. (This relates to our third level of change, nested here within the change initiative.)
2. Performing central activities to support the initiative. Examples include setting up the tooling infrastructure and communicating the vision across the organization.
3. Activities to review the progress, harvest the project work, and to prepare for the next phase. These activities are done toward the end of this phase.

Each of these three types of activities are detailed in the tables that follow.

Working with pilot projects

This is perhaps the area of activity people are most familiar with, because it really focuses on the project level, which is why we treat it lightly in the framework, as shown in Table 3. You would customize this aspect to meet the project needs. IBM Rational consultants have a wide range of training and consultancy packages that can help a project team get up to speed.

Table 3: Pilot project activities

Most importantly, the project activities shown in Table 3 will help you to generate short-term wins. To maintain on-going support, these projects need to show the business value of your solution, clearly articulated by achieving technical results.

Centralized activities to support the initiative

Often in organizations there is additional work to be done outside the project teams, typically by a centralized group, such as a team of process engineers or a tooling team. This set of activities, as shown in Table 4, focuses on communicating your vision, and building a robust technical solution that meets the needs of the organization. These centralized teams should not work in "an ivory tower," rather they should work closely with the project teams to prove and refine the solution, harvesting the experiences as they move forward. Working closely with the project teams will help them to define a solution for the organization that is appropriate and supported.

Table 4: Activities of the infrastructure team

With these activities you are starting to prepare for the consolidation of change -- you need to get your architectural foundations right to support an organizational roll out.

Review, harvesting success, and planning

This last set of activities, shown in Table 5, are often the ones you forget about, yet they are key to your success. You should review the good work you have done with your project teams in the form of your short-term wins, harvest any best practices or usage models, and promote these back into the organization.

Table 5: Reviewing, harvesting, and planning activities

What is the value of having some great pilot projects but not promoting them? These activities aim to build continued support for further change.

Results

At the end of this phase, you will have proved the technical solution against the goals of the vision, with a proven infrastructure that is ready to roll out to a wider audience.

What about empowering broad-based action?

At this point, you may have noticed that there has not been any specific activities associated with Kotter's "empowering broad-based action" step. It is not easy to pinpoint a specific set of activities aligned to this, because this step tends to be more about the overall philosophy guiding the change initiative. But the principle is still important; here are some things you should be considering:

• Overcoming resistance and obstacles:
• From an organizational structure perspective, you can look to remove barriers and silos. The applications architect can also help to provide improved communications and collaboration.
• Cultural considerations:
• Change measurements and rewards should reflect the behavior you wish the team to focus on. You need to align the rewards with the vision and results.
• You should instrument processes to improve visibility of results. The combination of the case study encapsulating the benefits realization, the metrics framework, and the communication focus should all help in this area. The metrics used should be results-based -- e.g., the number of architectural scenarios implemented and tested.
• Skills development:
• Provide just-in-time training and mentoring. Notice the approach in the framework is to provide training and mentoring aligned with specific project adoption.
• Workshops should be used to reinforce and apply training. Although workshops are not specifically referenced, they should be a key part of the mentoring activity.
• Delivering real project artifacts, not exercises is key. The mentoring focused around skills transfer will help in this area.

In addition to these considerations, it's important to publicize all successes, marketing these wins to show the difference being made. Again, case study materials, metrics, and communication activities will all help in this area.

Phase 3: Validate initiative roll out to organization

At this point, you have a proven tooling architecture that has been tested on a small scale, and the work of the project teams has been harvested into the process and tooling framework. This phase is about proving the wider roll out. The location of this phase is shown on the timeline in Figure 7 at "We are here."

Figure 7: The third stage of the change initiative

Alignment to Kotter stages

Now that the tooling architecture has been proved on a small scale, this phase looks at proving the approach on a larger scale by rolling out the approach to a wider audience. The key Kotter steps that come into play include:

• Short-term wins. You need to continue to highlight the results, extend case studies, review the metrics captured, and report back your results to the management team.
• Consolidating gains. The activities in this phase are focused on validating the roll out approach on a larger scale and building on the experience gained from the pilots. This increase in scale across a diverse set of projects proves the ability to roll out the IBM Rational solution across the organization. You need to continue to provide on-going support for the projects, harvest experiences, and seed your future mentors into new projects. You are looking to build a critical mass of capability. You should also refine the initial work around measurements to capture on-going progress.

Goal: Validate the organizational rollout

This phase shares many characteristics of what RUP calls the Elaboration phase, here visiting the phase for a second iteration: with a proven tooling architecture from the previous phase, this phase needs to be proved on a larger scale through more projects. In the previous phase, you had two or three pilots. In this phase, you might widen the adoption to test the expanded scale by taking on, for example, five to ten projects.

The aim is to begin to embed improvements in development capability across multiple projects so that change becomes part of business as usual.

Activities

The activities have been broken into two parts: the essential project activities and the centralized infrastructure activities. These are described in Tables 8 and 9.

Table 8: Essential project activities in the third phase of a change initiative

The activities shown in Table 8 are similar to those from the previous phase; the whole idea is to prove the solution on a wider scale. Notice that there is less dependence on external help, because the internal mentors should be taking more of an active role in this phase. This ensures long-term sustainability.

Table 9: Centralized infrastructure activities in the third phase of a change initiative

Results

At the end of this phase, you will have proved the technical solution across a wider set of projects and are ready to roll it out across the organization.

Phase 4: Roll out initiative across the organization

In this phase, the proven changes are applied across the organization. There will be a growing number of projects using the new approach as this phase progresses, but at the same time there will be a growing level of stability across the development teams as this approach becomes business as usual. Due to the increased scale, there will be further training required and some level of support from the consultancy team.

The location of this phase is shown on the timeline in Figure 8 at "We are here."

Figure 8: The final phase of a change initiative

Alignment to Kotter stages

The key Kotter stage in this phase is to begin to anchor these new approaches into the culture.

Characteristics of the final phase

During this phase, there should be an increase from some ten pilot projects to an organization-wide adoption (200+ projects). Efforts and associated costs for this stage will be reviewed and agreed toward the end of the previous phase. Given the scale, you must ensure that you are ready to support the masses effectively; the tooling infrastructure and support mechanisms are crucial at this stage. At the end of this phase, a review should be conducted to evaluate 1) progress against your original business goals, 2) general success of the change initiative (this single wave of change within the overall change program), and specific technical results. Now this wave is complete and you can start to examine where you need to focus next. It should be noted that the waves of change can overlap -- once you have successfully established the first wave, you don't have to wait for its completion to begin a second wave of change with additional capabilities and results.

Back to top

Summary

This paper presents a high-level framework of activities that can help you to make the transition from project implementation to organizational adoption. Given that there are three levels of change, you should carefully consider which level is appropriate for your organization. You may not be ready for the large-scale (level one) organizational change aspects presented here. However, there is still plenty to gain by working at the initiative level (level two), or building up some initial skills and support at the project level (level three). This framework provides the bigger picture and a method of breaking it down into manageable pieces. These manageable pieces are also a beneficial way to break down the investment required.

There are a number of key aspects to successful change. In the first place, you should tackle all eight of Kotter's steps, as described in this paper. Avoid taking shortcuts, and always consider how your adaptation of the DOT Framework approach aligns with Kotter's recommendations. Remember, too, that success breeds success. The first initiative needs to be ambitious, but realistic. It should make a valuable contribution to a key business goal. Make sure you plan for results and publicize them when success is achieved. Most likely, the greatest success will be an initiative that delivers beneficial results that are measurable upon a first implementation. Finally, the results should drive the incentives. If team members are measured according to something else -- e.g., how many activities did they complete today? -- that is where their priorities will be focused. Real results should be the yardstick for measuring success.

Back to top

Further reading:

• Kurt Bittner and Saif Islam, "Adoption Through Execution: Project-Level Mentoring to Improve Software Capability," in The Rational Edge, June 2004. http://www-128.ibm.com/developerworks/rational/library/4866.html
• Stefan Bergström and Latta Råberg, Adopting the Rational Unified Process: Success with the RUP, Addison-Wesley, 2003.
• Be sure to look for a forthcoming book by Joshua Barnes on enterprise deployments of RUP and IBM Rational Tools, due out next year from Addison-Wesley.

Back to top

Notes

¹ If you would like to discuss the approach in more detail, the authors can be contacted at IBM Rational.

² Initiating, Diagnosing, Establishing, Acting, and Learning. For more on the IDEAL model, see http://www.sei.cmu.edu/ideal/

³ John P. Kotter, Leading Change, Harvard Business School Press, 1996.

⁴ If you identify any activities that should be included, please let the authors know and they will consider adding them into the framework.

⁵ IBM Rational has experienced consultants who can assist.

About the authors

		Over the past seven years, Zoë Eason has developed technical expertise in IBM Rational products and services, providing training in process and tools to a variety of financial services ogranizations. Today she coaches senior-level teams in improving software development capabilities across the organization, specializing in building the business case, developing the vision and roadmap for change, project assessments, results-based implementation planning, and mentoring.

		Lynn M. Mueller is a senior consultant and team leader on the IBM Software Group Rational Services team with a focus on process improvement across industry sectors. She is an IBM Senior Certified IT Specialist in business analysis, and she has held several senior management roles for IT consulting firms in her fourteen years prior to joining IBM (formerly PwC Consulting nine years ago).

		Maria Ericsson is a senior process developer at IBM on the team that develops the Rational Unified Process. She started working in the field of software engineering and object technology in 1990 at Objectory AB, and co-authored Ivar Jacobson's The Object Advantage: Business Process Re-engineering with Object Technology. She has just recently relocated to her roots in Sweden after four-and-a-half-years with Objectory and Rational in the USA. She can be reached at maria.ericsson@se.ibm.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top