The Market Development business unit is responsible for creating new revenue opportunities by expanding solution coverage of existing products and developing new solutions in partnership with customers. The mandate does not include hardware / software development functions, but does involve collaborating with technical experts to develop solutions. The business unit has about 50 people.
A meeting of 5 executives was held to review the business organizational structure to improve its effectiveness. The boss's recent visits with customers had uncovered a number of dissatisfactions. He believed that we were not providing our customers with all of the leading edge solutions that we were capable of delivering. Some problems were:
We needed a dynamic organization that could understand customers’ real problems and put together prototypes and solutions quickly.
The meeting lasted about 1 hour. Many ideas were discussed, but no direction or pattern emerged. In the end, we were asked for proposals by the next morning.
The re-organization objective was to create a single point of ownership for customer feature definition. In the old structure, it was not tied to the customer facing teams in any formal way.
My immediate objective was to create a draft organization structure by the next morning and be able to explain the rationale behind it.
During the meeting, several items that the reorganized team needed to perform were discussed (figure 1). Some were familiar in the context of the discussion and some were not. (I am sure I missed some of the ideas discussed.)
After the meeting, I added other related functions that I thought were important (figure 2).
It was clear that none of our customer facing organizations covered these functions in an organized fashion.
To create an effective organization structure, the best option was to organize these functions in a logical fashion.
To create a logical linking and ordering of the functions, I entered the function ideas in Concept Star and experimented with a few relation phrases.
I settled on the phrase ...will significantly help to own the responsibility for... because the task was to develop a logical organization structure rather than understanding the interaction between the ideas in this case. In other words if a person or team is responsible for doing "A", will that make it easier for him/her or that team to be responsible for doing "B"?
I also re-worded the ideas as the tasks or duties of team members. This provided a better fit to the relation phrase and made the wording less distracting when voting on the relationship.
The revised list of ideas is shown in figure 3. Item 20 was reworked and broken into separate items. Item 8 was simplified to remove duplication with item 15. Item 19 was deleted due to duplication with item 12.
I revised the ideas in Concept Star and entered the control statements as shown below:
Title: | Organizational design |
Trigger Question: | Not used. The ideas were collected without formal brain storming. |
Context: | In order to design a better organization to deal with the current problems, owning the responsibility for... |
Relation: | ...will significantly help to own the responsibility for... |
Secondary Link Meaning: | Not used. Default values are shown in figure 4. |
Tool: |
Linear Interpretive Model
I selected the LIM tool because I wanted as much detail on the map as possible and I was working alone and not pressed for time. |
The Idea List view of Concept Star shows this information (figure 4).
Next I started the voting process used to organize the ideas in a logical fashion. Concept Star displayed the first Voting screen (figure 5). I chose a Yes or no vote to indicate whether or not the displayed relationship existed and then proceeded to the next pair of ideas. This process continued until all relationships had been analyzed. In this case, it took about one hour.
Figure 6 shows the completed relationship diagram initially displayed by Concept Star. The ideas are displayed in boxes with arrows indicating the relationships between them. When ideas are highly interrelated, they are displayed in the same box.
I formatted the diagram by adjusting the size and position of the Idea Boxes and adding color to indicate the categories of the ideas. These changes made the model easier to interpret (figure 7).
The two large boxes represent responsibilities that are highly interrelated and could be placed in the same sub organization. The business group (large box on the top left) can be sub-divided into strategic (green) and operational (blue) responsibilities. The technology group consists of two specializations: customer trials (orange) and implementation (yellow). The white set of 3 boxes represent common responsibilities that are applicable to both the business and technology teams. Finally, the bottom 3 boxes (pink) represent knowledge management and support functions that will be needed for both teams.
Figure 8 shows the organization structure drawn up based on understandings gained from the relationship model. It was accepted and implemented.
The people were assigned as follows:
Business Strategy: 7 people Business Operation: 10 people Solution Implementation: 22 people Customer Trials: 8 people Knowledge Management: 5 people |
Copyright© 2006, Sorach Inc.