Chicken or Egg

The Big Itch

It is that time of the year. Restructuring fever is in the air and many an I.T. Professional will look into the change abyss and consult its gods: “Restructure, restructure in the fall, am I a realignment survivors this time at all?”

The annual restructuring itch returns closer to the end of the year, and we take stock of achievements and failures for the period. It is a phenomenon quite familiar, where we shuffle the deck, make a cut, divide, align, realign, focus, refocus, and fix problems that seem to be recurring with clockwork precision every year.

Just how should we organize ourselves effectively for the job on hand next year? What have we learned, and what can we improve?

It has also become the time when most I.T. Professionals reevaluate their commitments to their current assignments and employers. They take the opportunity to decide if they should stay or should they move on to the next bold step in their career.

In this Blog entry, I will spend time contemplating why the restructure itch returns so frequently to some I.T. Organizations, and what should be done about it from an organizational and from an I.T. Professional perspective.

Wasted Planning

Execution of any good idea requires a good plan with some commitment and action. It is no different than if we want to succeed in our delivery of Projects or I.T. Services, that we have to have our planning in place, and have it regularly reviewed. We also need the right person in the right position to execute these plans.

Project and I.T. Service Managers include several matters into their planning like: scope, schedule, finances, quality, resources (people and tools), communication, change, risk and procurement planning. (PMBOK).

However, before a plan can be formulated and successfully executed, one must be clear on the business model and the requirements for the main parts of the business, for which the planning occurs. The Business Architecture needs to be in place.

“Business Architecture" is an architecture that structures the accountability over business activities prior to any further effort to structure individual aspects (like people, processes, data, functions, organization, systems, applications, etc.).

A Business Architecture arranges the accountability around the most important business activities (for instance product or service design, delivery sales, production, distribution, marketing, etc.) and/or the economic activities (for instance: manufacturing, assembly, transport, wholesale, etc.) into domains. It then defines the boundaries, priorities and relationships between these domains to effectively deliver on the business' strategic objectives.

All too frequently, management of an I.T. business are not clear on what Business Domains to include, and how these business domains need to interact prior to them coming up with the next "realigned" and "refocused" organization structure. If this aspect of the Business Architecture is not in place and well understood, then planning for execution is mostly wasted on aspects that may not be significant to the success of the venture in the first place. Any proposed people structure (which is merely one part of the Business Architecture) will then also fail on a regular basis.

Merely shuffling people around in an organization unconscious of the demands of the intentionally designed Business Architecture does not fix Business Architecture problems. This assumes that the Business Architecture were consciously considered in the first place. In fact, frequent restructuring of people is a tell tale that a company does not have a grip on its core business domains that support its business model and the execution thereof.

The I.T. Machine

The I.T. Organization is a product in its own right. If the Organization is a department in a company or a vendor business, it is in itself a product tasked with the delivery of key outcomes for its stakeholders. It is a product delivering benefits and outcomes to its customers. I often refer to the I.T. business as a machine that needs to be designed for its purpose. It is a machine with key Business Domains or functions aligned with its service offerings, and supported by a process and people structure that make effective execution possible for each of these business domains. The effective execution of the business domains allows the Organization to be successful in its purpose.

In prior blog entries I gave insight into the typical services offered through this standard I.T. Services machine. I have also included an I.T. Services Framework or Business Architecture in this site that illustrates how the organizational process, people and pricing components supports the service offerings within such a framework.

What remains to be addressed is the non I.T. typical Business Domains such as sales, marketing, finance, and procurement. How do we sell the services from this machine, how do we bill for it, and lastly how do we find the people to do the work (how do we procure for it).

If the Business Architecture is well understood and aligned with the purpose of the organization, then the need for frequent people restructuring disappears. The organization's structure will be bedded down enough to allow for a process of continuous and incremental innovation instead of a routine disruptive structural intervention.

This is an intervention that typically takes two months to agree. A further two to three months to execute. Four more months to allow the people to do their forming-storming-norming-performing in their new groups, before they are one hundred percent effective. This leaves you with less than four months effective productivity before the next seasonal restructure is initiated, with no effective clue of why the previous one did not produce the intended outcomes.

Your Business Architecture

Who's in charge of your business today?

In the following section I am highlighting some of the main Business Domains that should be included in your I.T. Service Organization's Business Architecture. It is important that you have one accountable party (preferably a person) for each of the following Domains to oversee its planning and execution.

These domains vary in importance depending on your business model (cost or profit center), and the role your company plays within the industry (internal company department or vendor).

The I.T. Service Execution Business Domains include:

• Operate Business Domain delivering the Operating Services: These services include solution administration, availability, capacity and continuity management and is typically executed by repetitive and continuous processes. The people structure operating in this domain is usually largely a static organization with growth in capacity as more solutions are added to the domain.
• Support Business Domain delivering the Support Services: These services include problem and incident management and is typically executed by repetitive and continuous processes driven my events. The people structure operating in this domain is also usually largely a static organization with growth in capacity as more solutions or event frequencies are added to the domain.
• Minor Modification Domain delivering the Minor Modification Services: These services include analysis, design, construction, implementation on existing solutions, and is typically executed by repetitive and continuous processes. The people structure operating in this domain is usually a static organization with growth in capacity as more solutions or modification requests are added to the domain.
• Major Modification Domain delivering large Projects and Programs of work: These services include analysis, design, construction, implementation on new solutions, and is typically executed by processes with a defined start and finish. The people structure operating in this domain is dynamic and for the purpose of the engagement. Growth is obtained through additional projects added to programs of work.

Other Standard Business Execution Domains include:

• Sales and Marketing Business Domain that creates demand for the Organizations services: The main objective of this business domain is to grow the business by adding new customers, or increasing the service reach within existing accounts.
• Financial Management Domain that controls the financial functions for the Organization: This includes time recording, invoicing, collections, asset management, and other typical financial functions.
• Procurement Domain that sources resources for the Organization: The purpose of this Business Domain is primarily to staff and equip the service organization. The focus should be on finding cost effective procurement means to staff the more static business domains, and flexible cost effective means to staff the Domains with more variable demands. Additionally, cost effective tooling is sourced to equip staff for their jobs.
• Innovation Business Domain that designs, determines and executes the future state of the Organization: This Business domain should work on improving the current organization, and also invent the future organization in line with market and customer demand. Functions such as training and development of staff should reside in this domain. It should also find ways to improve the productivity of current resources through improved work practices and better tooling.
• Governance Business Domain that sets policy and ensures compliance with regulation and standards: This business domain ensures that the Organization effectively executes within the rules of the industry, law and commercial terms with customers and suppliers.

Please note that these domains span geography, technology and infrastructures. There is little to be gained anymore from dividing an I.T. organization along technical, and geographic lines.

It is increasingly hard to distinguish software functions from infrastructure functions therefore a technology divide is becoming more and more complex and ambiguous. Also, with new Service Oriented Architectures, it will become more and more challenging to even separate the platform from each other for alignment into separate business domains

Given that I.T. service functions can be delivered from remote locations, one will find the need for geographic business domain separation also disappearing. A support service can be provided from multiple international geographic locations spanning continents and time lines.

There may be a case made for customer or account segregation to protect conflicts of interest or the integrity of the business operating in a small market with customers competing against each other.

Set up your business' metrics aligned with the Business Domains. In this way you will have not only accountability, but also visibility of the effectiveness of the Organization's execution within each domain, and also interactions spanning domains.

In Conclusion

What came first? Was it the chicken or the egg?

Does the Business Architecture come before the restructure or do we restructure for an improved Business Architecture?

I hope from the above that I have convinced you that the reason why we restructure is primarily as a result of a deficient Business Architecture, and that we are bound to continue this ritual until we clean up our Business Architectures. If we know how the I.T. machine is supposed to work, it becomes a lot easier to build and operate it along these lines.

Therefore, first look at the way your business is architected. Then decide on your people structure. After that, only small incremental improvements should be required for as long as your business remains relevant to the market and your customers, or your Business Architecture remains appropriate. The only real change should be to promote, replace or grow.

Go forth as Business Architects. Attack and conquer pointless, routine, disruptive, unproductive restructuring for the sake of keeping senior executives occupied. Design your business. Stick with it, and stop shuffling the deck. You will keep more of your good staff as a result too.

As always, your ideas and comments are welcome.

Hendrik van Wyk