IS / IT Horizontal View

f4312dde9a87261acefda8f3_1920Abstract & Background

This framework discusses a horizontal view of IS/IT organizations. It is intended to be used in conjunction with the IS/IT Organization Vertical Framework to form a model (framework) of individual IS/IT Organizations. This model can then be used to identify several organizational needs & responses, for example:

  • organizational structure re-engineering
  • skill set requirements
  • methodologies

This framework has developed over an extended period of time beginning with work done for the Canadian Standards Association. It developed as an attempt to analyze the functioning of IS/IT organizations as a stage in the implementation of methodologies such as ISO 9000.

The Framework

A Horizontal View of IS/IT Organizations

One of the first views a process analysis of an IS/IT organization usually looks at is a task view or process view. Typically, this becomes untenable very quickly. However, as the analysis progresses a summary view develops.

This summary typically reveals combinations of tasks which are common to all projects and tasks which are which are unique for a particular type of project.

If we continue to examine these tasks we reveal a structure similar to this.

isorghoriz

The first group of tasks is project management. This group is responsible for initiating, planning and controlling a project. Normally it consists of some common tasks (e.g. request management/initiation) and some unique tasks (e.g. resource allocation). This is the area which is often considered common to many project oriented industries. It is central to methodologies such as the Project Management Book of Knowledge (PMI), ISO 9000-3, and Software Engineering Institute’s Capability Maturity Model (SEI/CMM).

The second process group is development and delivery. This group of tasks are directly responsible for the development of the product and for its delivery to the client. They describe the flow of the process through the various life cycles encountered by the organization. This group is typically referred to by people developing IS/IT specific development methodologies such as Waterfall, Rapid Application Development (RAD) and Extreme Programming (XP).

The third structure really belongs as a separate view of IS/IT organizations (similar to the Life Cycle in the Vertical view). However, there is a limit to the number of dimensions which can be illustrated in a two dimensions media. This structure are the tools which are used. These tools can be hard (e.g. programming languages) or soft (e.g. object oriented). They can be focused on development, or delivery or on people. However, they have two properties in common. First, they tend to be most suitable for certain points in the life cycle for certain products. Second, they tend to be the focus of extreme loyalties. However, this is like two carpenters — one screaming that a hammer is better, the other screaming that a screwdriver is better. This is also the structure which is often mistakenly called a methodology. However, while tools such as Data Flow Diagrams or Object Oriented Analysis have proper and improper methods of use, they are not methodologies. On their own they are incapable of producing a product. To continue the hammer analogy, a nail gun has a place and method of use. No one would suggest you hold the gun with the barrel pointed towards you or that you use it to hang a picture. And it definitely won’t work for a screw. Neither could you build a house solely with a nail gun.

The fourth and final structure will initially appear as either a member of the first or second levels. However, any organization has a number of essential but internally-focused non-product/non-client oriented services. These services are often considered as overhead items. For the purposes of this framework they are referred to as Administration and Other Stuff. Generally, when examining an IS/IT organization they will not be considered as part of the scope.

Consistency is a key element to producing quality. Without consistency of product consistent quality is not possible. Using this framework it is possible to identify when and where to be consistent without restriction to a single inappropriate methodology. Essentially, once a methodology or technique is selected it should be used consistently (i.e. in the same way). However, one can expect to use multiple tools during a single project. One can expect that certain development & delivery processes will be more appropriate for certain project types. Finally, one can expect that the project management methodology will be applied consistently for all projects producing a particular type of product.

Posted in Reference Materials, Structural Frameworks