Process Improvement via Organizational Change, Part 1 - What Doesn't Work
- Implementation Strategy
- Initial Implementation Assets
- Measuring Adoption Progress
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This is the first part of a three-article series based on lessons learned from organizational change initiatives used to implement a new SDLC process framework. In this article, I’ll discuss three of the most common problems that I see in the software industry while working with clients:
- No "real" implementation strategy
- No foundational implementation assets on which to build
- No mechanism to measure how well the adoption is going
Implementation Strategy
I often engage with new clients after they’ve embarked on an initiative to adopt a new software process engineering framework, such as the Rational Unified Process (RUP), OpenUP, Scrum, and so on. These organizations haven’t reached the anticipated value or return on investment, and they’re struggling.
My first questions revolve around the strategy that’s currently in use, as these types of initiatives generally are more about organizational change than anything else. You may be surprised to learn that, more often than not, the "implementation strategy" is a Microsoft Project "plan" with dates, milestones, and high-level presentation materials. There’s no formal strategy to take the organization from its current position to its goal—no map to the pain points that are causing inefficiency and waste, no vision of what the end state will look like. Worse, the "project plan" typically covers the current calendar year, ending on December 31.
The environments in which I work usually have anywhere from 1,000 to 5,000 IT resources, all of which need to adopt the new process framework. I can assure you that this doesn’t happen in a 12-month period—far from it—and has little chance for success without a real implementation strategy. Over the last decade, I’ve worked with a variety of organizations to help them with these types of initiatives, and I’ve learned that key components are critical success factors:
- Mini-assessment and business case for change. The mini-assessment identifies the key pain points that the current development project teams are facing. Analysis of which process and tool functionality solutions from the new process are available feeds into an estimate of return on investment, as well as the business case for change. The solutions from the new process are weighted and ranked according to the potential value they’ll provide to the organization, and become the focal point for the initial adoption teams.
- Mentoring and adoption team. The mentoring and adoption team strategy component formalizes the team model that will be used as well as defining roles and responsibilities.
- Training and mentoring assets. Training and mentoring assets need to be produced, including the approach to training and mentoring, development of training content, establishment of mentoring frameworks, and the engagement process.
- Pilot-project and program-level adoption assets. Pilot-project and program-level adoption assets are the building blocks that the implementation initiative will use to reach broader coverage of process adoption throughout the organization. The piloting phase determines focus areas that represent a cross-section of your organization and identifies the types of projects (duration, number of resources, budget level, complexity, criticality to the business, technologies used, and so forth). Building a foundation on assets such as domain-specific examples, process-content tailoring, and templates that are based on lessons learned provides the mechanism to reach successively broader coverage throughout the entire organization.