Using Program Management and Architecture to Manage Fundamental Change in Business Organizations (Thinking of Business Organizations as Systems)

	Program Management Office

by Frank Winters

November 5, 2001

Part One will outline the use of program management and architecture to manage change; Part Two will describe how to do this in greater detail.

That we live in a time of rapid change would be a cliche, if it were not so important, challenging and full of risk and opportunity. For business organizations, the rapidity of change is relative to the age of the organization undergoing the change. This might be why the dotcom companies experienced what they came to call Internet Time. Change was the only force they knew. Getting to market quickly was the only goal, in a sense. This is one way of explaining why so many dotcoms burned out.

At the other end of the spectrum are companies that are 50 to 100 years old or older. For many years, change for them was almost imperceptible. Currently, many (if not most) older companies are changing much more rapidly. This is a response to the same forces that created the dotcoms--a fragmented market calling for much greater customer intimacy and awareness. The one-to-one marketplace is not a fad that will go away; it is the way business will be done from now on. Therefore, companies are changing the most fundamental principles of their operation. This is risky for older companies, in part because their success--up until now--has been based on strengths that might be weaknesses in today's world. How to keep the strengths generating profitable revenue so that the existing business can continue to fuel the change now needed is one of the more difficult questions.

In many instances, this means a shift from an internal focus to an external one. A shift from product focus to customer focus is a prevalent variation on this theme. Another shift is from a value proposition that is based on operational efficiency to one based on excellent service. Changes of this degree have a huge impact on the company. Every important aspect of the company is affected. So an important question is, how can this much change be managed? In a sense, the dotcoms changed from nothing to something very rapidly and--lacking sufficient resources to draw on--flamed out. Older, more established companies do have resources to draw on and should not crash and burn--if they can figure out how to manage in what promises to be a long period of continuous change.

What to Do If You're Managing Change and You're Stuck
Consultants love to hear clients say, "We're stuck. We don't know what to do." When clients who are changing their business don't say it, they are often thinking it. The question is, how can we change our company radically and still run a profitable, growing business? Sometimes the answer is, you can't. Something has to give, at least for a while. More often than not, however, it is possible to oversee change while the business continues to tick over. How can this be done? If a change team is commissioned to make the changes while an operational team attends to the business, what should they do? (Of course, for many the teams are the same people.) What tools are available to them?

As for what to do, there are some basics that apply in almost every situation:

• Define and document the current situation in the business--the "As-Is" state of affairs, including what's working well and what's wrong or in need of change.
• Define and document the desired state for the business--the "To-Be" state.
• Define and document a plan for getting from the As-Is to the To-Be state.

Strangely, this is good advice by itself. I say "strangely because while it's pretty obvious that these steps need to be taken, many management teams don't do it. There are far too many change initiatives that do not have adequate documentation of these basic elements of change. By itself, this advice may not help because most change teams don't know how to act on it. This is because they are not sufficiently focused on the change part of their jobs given that, in all probability, they also have a business to run, as they probably say all the time. I believe that if a change team develops a road map as suggested here, it will be able to both get ongoing business done successfully as well as the desired change.

Today's Business and the Desired Business: How to Define and Document these States
I suggest the use of architecture for documenting both the As-Is and To-Be states of the business. My frame of reference for this is computer systems development. To many business people this will sound like a "techie" answer to a business problem. But before dismissing the idea, please read on a bit.

Many companies are entirely dependent on their computer application systems and the Information Technology infrastructure that supports and underlies the applications. Banks, insurance companies and broker dealers are good examples of this. Even heavy manufacturing companies have become completely dependent on their systems. And yet a continuous problem has been that the IT staff and business management are not in alignment. The IT folks don't understand the business, and the business people don't understand what technology can do to help improve the business. This has been the state of affairs in some companies for 30 or 40 years.

If you accept the idea of business as a collection of systems, why not treat the entire organization as a system? This is one of the basic premises of Systems Architecting of Organizations: Why Eagles Can't Swim, the excellent book by Eberhardt Rechtin. If this article peaks your interest, reading that book will do you good. Rechtin's point is that organizations are very complex systems, so a systems architecture approach to managing them makes sense and--in fact--works.

What is TOGAF?
The systems architecture approach to documentation of the As-Is and To-Be states of the business provides a tool for integration of business and IT issues, consistent with viewing the organization as a system, enabling all stakeholders to see both their own concerns and how they relate to the concerns of others. Further, the integrated architecture will provide a roadmap for both business management and the development of the required IT infrastructure to support the business. The architecture approach I'm referring to is defined in many places like textbooks and how-to guides. My favorite place for this information is The Open Group (www.osf.org) and The Open Group Architectural Framework (TOGAF), a standard way of defining architecture for business systems. However, in order to use TOGAF to define the state of a business, I suggest the addition of a layer to the architectural stack as TOGAF defines it.

TOGAF's discussion of the architectural layers includes the following:

• Business Architecture
• Information Technology Infrastructure Architecture
• Data/Information Architecture
• Applications Architecture

TOGAF focuses its processes on the IT architecture, but it touches on the others because they are all interrelated. A missing layer is Organizational Architecture. I am suggesting the addition of Organizational Architecture and the use of the five layers as a framework for documenting where the business is and where it wants to go so that the management team can clearly define the situation. Of course, the approach to developing an architecture for an entire business will have differences from the approaches and processes used to architect a system, but not fundamental differences. Not if the organization or business is thought of as a system.

(Rechtin defines a system as, "A construct or collection of different elements that together produce results not obtainable by the elements alone.")

In Part Two of this article, I'll provide a way to get started. Right now, there is one more question to be dealt with in Part One: How can a change team get from the "As-Is" state to the "To-Be" state?

Program Management--Defining the Path
Fortunately, there is an additional tool to be used--program management. This tool is gaining acceptance but is largely misunderstood and therefore misused. If program management is used properly, it is a powerful tool for both business and systems planning. Organizations today need to be ready for change continuously. An organizational structure that takes advantage of program management will be able to do that. If you review TOGAF and other approaches to the use of architecture, you will see that many of the issues addressed by program management--governance, leadership and communications, return on investment, for example --come up in the discussion of architecture. However, these are action-oriented issues, not static or state-oriented issues such as those addressed by architecture itself: information mapping and interfaces, business processes being used now or needed in the future, logical and physical maps of computer processes needed to support the business processes, etc. All of these are in a given state at any point in time and therefore--by themselves--unchangeable. Program management provides a means of effecting and managing the required changes in state. It adds a dynamic tool to the more static one of architecture, giving a change team a complete set of change management tools.

One reason why program management is effective as a change management tool is because of the focus it places on business initiatives and value creation. Program management is a tool for creating value through business initiatives. This is a focus it shares with changes to the fundamentals of a business--the kind of change we are discussing here. For a more complete discussion of the elements of program management, please see gantthead's Program Management Office department.

This is the end of Part One. In Part Two we will explore the role of alignment in change initiatives, how to get the needed changes done while still making the doughnuts and how to use an architectural framework to define where you are and where you want to go.

Related Content

Using Program Management and Architecture to Manage Fundamental Change in Business Organizations (Thinking of Business Organizations as Systems) - by Frank Winters