Frequently I'm asked how to set up an organization design project: who needs to be involved, what are the skills they need, and how much time/effort of participants will be involved? This is rather difficult to estimate in advance of knowing something about the project although I've worked on several proposals where we have had to submit complete 'Work Breakdown Structures' with time and staffing estimates several years in advance of any projected work happening.
In one case I remember I was asked how many change management workshops I would facilitate two years out and what would be the content of each. I said this was an impossible question to answer without having started the work and getting to know the context at which point I would design workshops appropriately. This answer was unacceptable.
However, whenever possible, and for the most part, I work as follows:
Pre-proposal: Usually, I am working with the CEO or COO or other leadership team member (at organization or BU level) to gain an insight into the context, what the purpose of the design is, and the rough scope of it. This person may turn out to be 'the client' as the project gathers life, or may turn out to be 'the sponsor', or sometimes he/she may bow out and hand over the project to some other nominated client and/or sponsor.
I explain to prospective clients that I work on a project in phases (though in practice it inevitably turns out to be more chaotic than a linear arrowed sequence moving smoothly from left to right as illustrated in a proposal graphic). Additionally I take the view that organization design is a collaborative, participative venture that must involve employees and other stakeholders. Over the years I've come to the view that the more senior someone is the less likely they are to know about the granular day to day operation of the organization and it is important to have this for a good design result. (Maybe I'm jaundiced, but I'll just casually mention the now outgoing Director General of the BBC, George Entwistle).
So in the five phases I work with following proposal acceptance I explain that each is likely to involve a different set of stakeholders, employees, and so on. I and the client are participants right through to the end of the transition phase (and sometimes into the review and evaluate phase). Roughly speaking the phases involves the following people.
Assess phase: This is where I am finding out the internal and external context of the organization and making a determination on the type of activity that will be needed to get to a couple of design options that meet the criteria and will deliver the business strategy and objectives. This usually means
a) Interviewing 1:1 members of the leadership team of the organization or part of it I am working with
b) Meeting with groups of staff representing all organizational levels either in teams or on an open call basis to find out their perspectives
c) Meeting with key other stakeholders that might include Board members, union reps, and customers of the product/services
Design phase: This phase opens with a 'kick-off' meeting explaining the scope and intent of the project. In this phase I am working with 'workstreams' to develop design options. Workstreams emerge from the assess phase and each is led by a member of the organization's staff. He/she may select appropriate team members but they should comprise a 'diagonal slice' of the organization so that all levels have a voice. Teams usually comprise 5 or so people. My role is to coach these groups through the design process. They are selected for certain qualities. (See tool of the month for October 2012)
In this phase I also set up a Steering Group with defined and agreed roles. You can find steering group role descriptions on various websites. There's a helpful summary of all project roles here.
Additionally I request that the organization provides a qualified project manager (actually, I specify this in the proposal). Without project management techniques and expertise organization design work can rapidly go off track, spin wheels, or otherwise lose direction and momentum.
I've found that it's important that people are aware that the work involves a time commitment and they will be recognized for their contribution. (And then to ensure they are recognized).
At the end of this phase, once the design has been accepted, the work streams disband and a planning team or teams is formed. To keep continuity often one or more design team members join the planning team(s).
Plan to transition: Planning team members, with a different profile from design team members, work with the project manager to develop the detailed implementation steps with critical paths, milestones, metrics and risk management. My role here is to work with the teams to make connections with other stakeholders, liaise with the Steering Group, do any co-ordination across the organization, and provide updates recommendations, and so on. Again the members are drawn from the business lines.
Transition: Here the detailed plan is handed over to the business area for implementation. Note that this is not a handover and good-bye but a well-orchestrated exercise that involves the project manager staying in post to monitor and track progress, provide a clear view on whether, in the project management terminology , 'benefits are being realized', and keeping an eye on emerging risks, or symptoms of things go wrong. My role in this is again as voice to the Steering Group, coach to the line managers implementing, and support to the project manager. Once transition is deemed complete there is a formal project shutdown, the Steering Group is disbanded, and the project manager moves on.
Review and evaluate: At a given point I recommend that the project is reviewed and evaluated against the original business case or project charter. This exercise can be done by internal auditors, by a contracted third party, or by internal personnel who were not directly involved with the original design and implementation. From this comes a report that is discussed with the sponsor and client, and with others who had a hand to play in the project. Ideally it provides lessons learned that will feed back into future organization design work. Sadly this whole phase is one that is frequently omitted which means that some of the investment in the project is lost to future projects.
One thing to bear in mind is that each organization is unique. So that what I do in each whilst following the framework above may be different depending on various things. As examples, I'm currently working with three organizations in three different sectors (and countries). The design projects for each are very different, but each of the three has a new CEO (often a trigger for a redesign). These leaders are setting a new strategic direction and want their organizations aligned accordingly to deliver it. Each assessment phase took a somewhat different form, and thus the subsequent phases also were set up slightly differently one from another. I don't think there is a one right way to do a design project:
Organization 1: 50 people head office (beyond HO 15,000 people)
Reason for design: to prepare for planned growth
Group meeting with the leadership team, including the CEO.
Individual meetings with leadership team
'Town hall' meeting with whole organization to outline project
Meetings with up to ten staff members by time slot that worked for them (to get random groups of employees)
Meetings with each work team (whole teams)
Individual meetings with staff who requested a 1:1
Meeting with board members
Desk review of documentation
Organization 2: 250 people
Reason for design: to expand into new market sector within geography
Individual meetings with leadership team members only
Individual meetings with middle management and some supervisors
Discussions with other consultants to the organization working on a related project
Desk review of documentation
Organization 3: 4000 people
Reason for design: to develop competitive advantage
Individual meetings with leadership team members
Workshop with leadership team
Workshop with pre-selected design team members
Desk review of documentation
The remaining phases of the projects will be different in each organization and will use the tools and approaches that are appropriate to them. I've found that the principle of 'Start where the system is' is a good one to follow in the determination of best method to initiate a design project. (See Herbert Shepard's Rules of Thumb for Change Agents).
Let me know who you involve in your design projects.
Naomi Stanford 