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.
