Dec 142010
 

Too often IT projects are initiated on the basis of the “who shouts loudest” syndrome, dominated by the biggest egos in the business management arena. Another form of this malaise arises when internal politics, with business unit managers jockeying for position, sidelines the needs of the organization as a whole. If demand management is to be applied effectively to help align IT with business needs, then a certain objectivity must be achieved.

Older readers may recall the idea of egoless programming advocated by Gerald Weinberg nearly 40 years ago [1]. Simply put, the concept of egoless programming advocates that a programmer should review the code of another programmer in an objective way such that personal feelings are put aside. That way programs develop and progress much more productively in line with the needs of the organization as a whole.

We need to apply this same thinking “in the large” to align IT with business needs. While this may seem like common sense, it is remarkable how often organizations seem to drive their IT projects much less on the basis of a common rational plan than on the dictates of certain individuals. An organization that suffers from this syndrome will need strong and responsible leadership to change its culture as well as its business and IT practices. And, as we all know, cultural change is hard! At the same time there are organizational shifts that can be made, which will have a beneficial effect.

The Portfolio Management Trap

Some thinkers advocate setting up a portfolio management function that coordinates development requests between business units and IT suppliers and across the business units themselves in order to achieve greater economies of scale. However, while IT project portfolio management is an important part of demand management, it is much more than that, as readers will have gleaned from our earlier discussion of the funnel. In particular, do not fall into the trap of thinking that IT portfolio planning tools will solve your demand management problem.

Demand management depends on a good, well-defined relationship with its partners in the organization if the organization is to progress beyond the “who shouts loudest” mindset outlined above. A convenient place to begin to outline the organizational context for demand management is to briefly consider the organizational model for EA.

The Organizational Model for EA

An effective model for EA requires a collaborative approach, not only with other IT practitioners, but also with the business itself (see the figure below). This model must specify the roles, responsibilities, and collaboration points of EA. Let’s take a brief look at the interfaces with the other organizational units shown with particular reference to demand management.

The EA organization reference model.

IT Business Management

In broad terms, IT business management is driven by business demand and is concerned with ensuring that IT meets desired business outcomes. EA must therefore integrate clearly and cleanly with IT business management. EA must provide roadmaps of available assets that enable demand management decisions to be clearly made.

The Market

The market covers all potential providers and consumers of IT — both internal and external to the organization. EA must enable clear decision making on both asset sourcing and asset usage. The primary vehicles for doing this are sourcing and usage policies, which have key parts to play in helping to structure the EA and the overall provisioning process [2] that controls both the certification and publishing of assets and the consumption of assets.

Solution Delivery

Delivery refers to the end-to-end solution development and integration process, from business requirements analysis to deployment, including both business and IT elements. The primary vehicle for achieving a good interface between EA and delivery is the solution architecture in which assets are modeled and declared at different levels of reusability, such that assets local to delivery projects are clearly distinguished from cross-project assets. Solution architectures effectively build on and extend the foundations of the EA.

IT Service Management

IT service management centers on effective measurement and control of runtime operational software. EA must set and maintain quality of service (QoS) policy alongside EA models and specifications. The EA policy, models, and specifications form a key touch point with IT service management. Conversely, monitoring data from IT service management should be “fed back” to EA in order for the EA to adapt to the realities of the changing runtime situation. This in turn means setting up and maintaining operational management dashboards and policies that define runtime procedures, such as problem and incident management.

This way of organizing for demand management supports and encourages a much more rational, much less emotive, view of the business-IT relationship.

Notes

1. Weinberg, Gerald. The Psychology of Computer Programming. Van Nostrand Reinhold, 1971.

2. Allen, Paul. “Joined-Up Service Sourcing and Usage.” Cutter Consortium Enterprise Architecture Executive Report, Vol. 11, No. 12, 2008.

avatar

Paul Allen

Paul Allen is a Senior Consultant in Cutter Consortium's Business & Enterprise Architecture practice. With more than 34 years' experience in most areas of IT, he has earned international recognition for his pioneering work in the application of component-based development (CBD) and service-oriented architecture (SOA) to achieve practical business value.

Discussion

  2 Responses to “Organizing for Demand Management: Egoless Requirements”

  1. […] The referenced Cutter article can be found here Feedback […]

  2. Dear Paul, this is a very good and helpful article. But i am interested to go in more detail.
    How , a beginner , need to build up a demand management unit? Steps that needs to pass in order to create a well designed unit in the organization and also functional one.
    Thank you

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)