Quashing accidental organization design in technology projects


Isla Bragg

Investing in a major software implementation carries the promise of reduced costs and greater agility, but if it doesn’t fit within the organization, those benefits are quickly undermined. I believe that ERP and other major software implementations should always be approached with proactive consideration of how the organization design might need to adapt to best achieve the intended business outcomes.

In the last several years, much emphasis has been placed on maturing technology implementation methodology to concurrently address broader business processes and articulate outcomes in terms of business events rather than technical inputs and outputs. On this front, consultants and their clients are making strides. Yet, in my experience, organization design changes on many initiatives remain passive rather than proactive, often discussed only in a granular and disaggregated fashion during workflow design, security profile allocations, or training development. When the reality of determining who should be doing the newly designed work with the newly designed tool suddenly rears its head, organizations are often unprepared.

Quickly conversation transcends any strategic lens and turns to question, “Who does it today?” Or, only slightly better, “What swim lane was the activity mapped to?” Back to front, accidental organization design is everywhere and is fast to become a go-live issue when senior stakeholders disagree on where the work has moved to or what access various groups will have.

By proactively assessing what aspects of the current organization design might need to change alongside processes and technical changes, a more cohesive and operable solution will come into focus.

Specifically, the following should be assessed as part of the planning phase of any major software implementation:

  • Structure: Does the current structure support the effective use of the new software implementation? Will the tool help reduce silos across functional structures or necessitate changes (e.g., a more integrated, process-oriented organizational structure which mirrors the internal structure of the ERP)?
  • Roles: At a high level, who should be responsible for which activities? An intentional up-front RACI tied to actual client-specific roles can prevent random allocations of process steps to fictional or generic roles, in turn minimizing disjointed or undesirable jobs that will be difficult to fill or retain employees within.
  • Governance: What new decision-making authority and cadence is needed to make the new processes and tools operable? For example, does the standard workflow approval process truly represent where decisions are made within the organization, or does it need to change? Without appropriate decision-making empowerment, workflow becomes an administrative pass-through likely to achieve little efficiency in outcome, while the “real” approvals happen offline.
  • Sizing: Will the new technology or broader processes likely impact the volume of work allocated to various teams? Often transactional work efforts are migrated to back-office roles, leaving excess capacity on the front line but swamping those in administration with new responsibilities and volume.

These factors can be viewed as another set of business requirements for resolution, and are just as important to consider as functional or technical specifications. Whether the answer to each is a “fit” or a “gap,” explicitly addressing these factors up front can help drive not only tactical project activities such as security and workflow design, but ultimately drive implementation success. Taking a holistic, strategic view of the required organization design changes will drive adoption of the intended tools and processes, setting the precedent for a more effective organization.

Dealing with role, structure, or governance changes should never be a surprise on any significant IT initiative and can be anticipated with tactical and systematic review of the current organization’s key attributes. Back to front, accidental organization design needs to be a thing of the past.

About Isla Bragg
Isla is currently a Solution Architect leading the Organization Design offering as part of Slalom’s Organization Effectiveness practice. Isla has eight years’ experience of applying her deep strategic consulting skills together with detailed operations and implementation expertise. She has held prior roles in driving process design, organization design, project management, change management, training, and post “go-live” solution support. Isla has extensive analytical and problem-solving ability with excellent communication, interpersonal, and team working skills. She has experience working on a range of large and small scale projects involving organizational transformation, continuous improvement initiatives, shared service deployment and technology implementations (including SAP, PeopleSoft, Oracle).

3 Responses to Quashing accidental organization design in technology projects

  1. Red Stick says:

    What are some KPIs to monitor through the blueprint phrase to ensure organizational design is at the forefront and intentional, rather than accidental?

    Red Stick

    • Isla Bragg says:

      Great question. I think the key is to focus project leadership on setting some upfront goals and scope on what needs to be addressed from an OD perspective, similar to how you would set scope around the breadth and depth of process change or the scope of applications being replaced. That information could be used to create KPIs or guiding success criteria/factors to then proactively measure the design against and help avoid falling into accidental or reactive OD changes.

      If the areas for organizational realignment are not boldly apparent, then first of all you could take a holistic assessment of the current state organization and understand whether or not that current state is a “fit” or a “gap” in enabling the project goals. This might sound a little lofty, but can quickly be made tactical by reviewing each of the key design elements (Structure, role, etc.) to identify key pain points. Slalom uses an assessment tool made up of focus-group style questions to produce a ‘score’ of health in each area – which you could also view as “KPIs” against which to then re-assess score improvements retrospectively to ensure each has been addressed. Though, note this kind of scoring/KPI approach (and the composite questions) is really relative to the individual organization and their goals, rather than something that you might benchmark as standard indicators or target scores across companies.

  2. Nice article.

    One of the core challenges for a company of any size is the agility to cope with the volume of change. Multiple software implementations are underway at the same time and there is rarely a holistic view of how these affect one another, let alone their total organisational impact.

    Any implementation should consider all aspects of the delivery into the business. My experience is not that people aren’t willing, it’s that there’s limited information available leading people to tightly control scope for reduced risk. This may enhance the ability to deliver a given project but it affects their value and long term success potential.

    It also limits the capacity to deal with organisational change, data and information impacts etc, as these are wider than a single implementation, however large it might be.

    What’s interesting is that there are many disciplines and functions working on each facet (org design, governance, process, architecture, data, regulation etc), but the collective knowledge of the business is fragmented and difficult to leverage.

    I work in Data but the underlying challenge is the same. We work to solve the collaboration problem. With a complete community and connected information about how the business really functions we can stop searching – and start solving.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: