Advice on Successful Organizational Transformation

Every transformation has a unique set of challenges based on its particular context. We have noted the following top issues below, along with remediation activities. All issues noted below are based on our real experience on similar transformation engagements:

Leveraging a One-Size-Fits-All Solution

Many leaders within our client organizations are challenged by the fact that there is no commonality in the way that different teams and programs deliver and maintain software application systems. They justifiably see this lack of standardization as a symptom of an ad hoc organization that lacks the maturity to perform similar work in a similar manner. This lack of standardization increases risk, raises cost, slows down delivery, and makes it impossible to get to a higher state of performance. 

A natural reaction to this state of affairs is to create a process framework that covers all possible circumstances, often using a standardization approach based on a one size fits all process. Customization is typically done at the project size/cost level, if done at all. Elaborate processes are drawn up to cover the SDLC, along with detailed templates. Staff is then trained on the new method. Feedback is gained on the new method, and (eventually) that method is updated.

Unfortunately all too often this approach results in a delivery process that looks good on paper, but does not meet the diverse requirements of different teams, different programs, and different levels of delivery risk within the organization. The process is often adapted to the group of knowledge professionals that have the most influence, with the requirements of other staff and managers having less impact on the framework. Typical reactions from project staff range from ignoring the process framework to following it to the minimum level possible to avoid punishment from compliance watchdogs. In neither case is the desired behavior accomplished, knowledge workers leveraging the process framework to add value and reduce risk. 

Our approach is to take a different perspective on standardization. While it is critical is to define a common process architecture required for an organization to be successful, it is equally critical to ensure that those processes have unique policies based on the type of work being processed for particular types of work. A fundamental difference to our perspective is that we believe that standardization efforts should focus on the work itself, and that processes can only be a standardized to the extent that the problem domain and associated work can be standardized. 

We recommend starting the standardization effort with gaining an understanding of the different work types the organization must process. Work types can be thought of as a definition profile identifying delivery risk, size, technical skills required, and effort for particular category of work. Work types can then be associated with the exact policies required to facilitate maximum quality and better throughput/leadtime. This approach facilitates the development of a policy framework that is right sized to the work, and is flexible enough to change to meet the requirements of different categories of work.

Following a Big Design Upfront Approach

Stakeholders and managers tasked with running large-scale transformations face a great deal of risk. ROI might not be as high as anticipated, processes may not support certain scenarios, staff may resist change, and process components may be too lightweight or too heavyweight. A natural reaction to managing this risk is to try to come up with the perfect design. There is a desire to try to take into account every possible scenario, and develop the perfect target state solution. There's often a tendency totry to design any anticipated risks out of the solution. 

Unfortunately, the impact of locking down decisions before the right kind of information is available is just as risky as making a decision too late in the process. When a decision is made to early, it is largely based on assumptions. When the assumption proves to be false, it can be very challenging for a program to admit the error, and it can take many months to reverse the design decision. A program that has to much upfront design will be weighed down by unvalidated assumptions, these unfounded assumptions can cause the program to go completely off track. While it is important to do some upfront design, the key is to focus upfront design on decisions that are very expensive to reverse. Examples include overall organizational structure, process architecture, tool technology platform, and executive level processes. Even for these components, it is important to examine the underlying strategy, and separate fact from assumption.

Big Design up Front (BDUF) is also the antithesis of a Lean approach. Fundamental to Lean thinking is the notion that large amounts of inventory (unfinished work) causes waste. This waste materializes in the form of quality problems, unpredictable delivery lead times, and lowered throughput. When thinking about knowledge work, there is no physical inventory to remind us of how much unfinished work we have. In this case our unfinished work are all the requirements, plans, strategies, and design artifacts that represent a unit of change that has not yet materialized.

The more we try to create the perfect design the more we increase our inventory of unfinished work. Larger inventory delay potential downstream business benefits. More importantly, they reduce the feedback into the transformation process. Transformations are inherently variable, many things will not proceed according to plan. When dealing with something as ambiguous as the way people work, it is inevitable that designs will contain a large amount of assumptions. Our experience has shown that assumptions are only correct a small portion of the time. It essential that we test our assumptions as quickly as we can. This will tell us when we need to pursue a strategy, and when we need to pivot.

We recommend building the transformation vision and strategy in such a way that known facts are separated from ( well-intentioned) assumptions. A good transformation plan will contain explicit activities to validate each assumption through incremental adoption of specific process components using the piloting process. This approach forces working in smaller batches, allowing completion of smaller units of change more frequently. After each unit of change is completed, progress can be assessed, feedback can be gathered, and the overall approach and plan can be adjusted based on the latest information. We recommend running the transformation using a Just Good Enough Design approach. This implies implementing the design in small units using a testable approach, validating the results of specific tests, and then finally determining if any adjustments to the design needs to be made.

Centralizing All Design Decisions

Creating the perfect, standardized solution using a big upfront design approach is typically accompanied by the desire to centralize design decisions for the transformation program. In an understandable desire to gain the highest possible quality, many transformations assemble a dedicated group of very experienced experts, tasked with creating the perfect design. All design decisions are passed through a centralized stakeholder committee, where design elements are carefully reviewed, and the future target state is built.

Unfortunately, this approach does not scale to meet the diverse requirements of different groups. Centralizing design decision-making doesn't work for the same reason that a one-size-fits-all solution doesn't work, IT work is inherently variable, a unique mixture of technology, consumers, internal experience, and delivery risk exist across different IT departments, and even within different projects. Furthermore, IT work is not manufacturing, something slightly new is always being built. The above has two implications, for processes to be effective, they need to vary by context, and they need to continually adapt to changes in those contexts.

We have had great success following an approach that organizes processes and other design components as a hierarchical set of design elements. Centralized design decision-making focuses on the top of the hierarchy, on areas that truly need to be standardized across the organization. This includes the overall process architecture, overall organizational structure, role descriptions, and performance metrics. Lower levels of the hierarchy contain design elements that have a smaller span of scope. An example of the next level may be decisions and policies that affect individual departments. The next level down our elements that affect individual programs, and the bottom are elements that affect individual teams.

Policies and processes that only impact the individual teams can be designed, and followed by those individual teams. This also means that those teams are free to adjust those policies when they are nao longer supporting a high quality approach to delivery. Policies and processes that are project or departmental wide requirements appropriate manager intervention to modify, likewise design decisions at the top of the hierarchy require executive oversight to change. This approach, supported by a measurable and testable framework, insures that the organization is able to successfully adopt a continuous improvement approach while still providing a stable framework for the enterprise..

 

Transformation Demand Outstripping Organizational Capacity to process change

We have seen clients commit to transformation roadmaps without adequately considering the level of engagement required to successfully complete the plan. While a roadmap can look good on paper, it is important to assess the order and sequence of all activities against the capacity of internal staff to complete those activities and absorbed the change being asked of them..

Starting too many things at once will also lead to too much work in progress, which as stated previously is a primary source of waste for knowledge workers. We recommend putting a hard limit around the number of transformation activities that go on in parallel, and reducing that number if there is evidence that activities are not being completed in A timely fashion.

One solution is to operationalize the transformation engagement using Lean & Kanban techniques. This approach ensures that the organization will not start more work than they can finish, ensuring that the transformation team stops starting, and starts finishing.

Not Providing Adequate Support for Staff to Adapt to Big C Change Elements

Not all changes will be done in an incremental fashion. The targets may call for some larger, big bang structural changes to the organization and the way people work. This kind of change must take into account impacts to affected staff. This includes the time required for staff to acquire new skills, create new capabilities, bond with new departments, and otherwise absorb the change. Major changes to organizational capability, changes in job descriptions, and movements to new departments are tough on all involved. Is important to properly assess the impact of any of these changes on all staff and management before starting.

Focused, full-time expertise is required to provide communication and change management support to pull off these kinds of change. This includes appropriate communication, skills assessments, training, and organizational readiness. Dedicated professionals are required to take the time to ensure that the vision is communicated to all levels of the organization, areas of resistance are understood, enabling teams are identified, and that the change management approach follows a deliberate change management strategy.