Scribd
Upload
24 views

Cap 1 - P2

This document discusses methodology and its relation to analyzing business problems. It begins by defining methodology as a structured approach to problem solving that requires judgment in its application and structure. Methodology provides guidelines to stimulate analysis rather than guaranteed solutions like methods or techniques. The document then contrasts "hard" and "soft" problems, with hard problems having agreed upon definitions and soft problems having problematic definitions. It uses systems engineering and soft systems methodology as examples to illustrate the differences. The document emphasizes that methodology involves thinking about how to think about a problem situation. It stresses tailoring the methodology to the specific situation and making the thinking process explicit.

Uploaded by

OSMAR JOSHUA VALENZUELA MENDOZA
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
24 views

Cap 1 - P2

This document discusses methodology and its relation to analyzing business problems. It begins by defining methodology as a structured approach to problem solving that requires judgment in its application and structure. Methodology provides guidelines to stimulate analysis rather than guaranteed solutions like methods or techniques. The document then contrasts "hard" and "soft" problems, with hard problems having agreed upon definitions and soft problems having problematic definitions. It uses systems engineering and soft systems methodology as examples to illustrate the differences. The document emphasizes that methodology involves thinking about how to think about a problem situation. It stresses tailoring the methodology to the specific situation and making the thinking process explicit.

Uploaded by

OSMAR JOSHUA VALENZUELA MENDOZA
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

METHODOLOGY—WHAT IS IT?

Introduction

The purpose of this section is to answer the above question and to discuss
methodology in terms of its relation to the analysis of business problems in general. It
is a bit of a buzzword and every analyst will claim that they have one or several
(including me), but do they all mean the same thing and does it matter? To go back to
its origins and to say that it is the ‘logos’ (study) of method isn’t very helpful so here,
at least, is a useful interpretation.
It is probably easier to describe what methodology is by first illustrating what it is not.
It is frequently confused with method or technique, but it is much less prescriptive
than either of them. Both of these approaches to problem solving may best be
described by the ‘cookbook’ analogy. Their characteristic is that they provide precise
definitions of ‘what to do’ and, if followed, will produce a defined outcome.
Methodology, on the other hand, will not guarantee a solution. The nearest equivalent
phrase is ‘a structured approach’. However, it is an approach which requires
judgement; in terms of both its application and the structure itself. A particular
methodology is a set of guidelines which stimulate the intellectual process of analysis.
To appreciate this last statement and to understand fully what methodology is it is
necessary to return to the distinction between ‘the real world’, i.e. the source of the
problem or problems to which the methodology is to be applied and the process of
thinking about the real world.
It is in the latter domain that methodology resides. Technique, method and
methodology are all ways of thinking about problems and hence represent structured
ways of undertaking the intellec- tual processes involved in analysis. It is only the
degree of prescription that differentiates between them and because methodology is
the study of methods, any methodology may contain methods and/or techniques.

Methodology and Problem Solving


The degree of variety in real-world problems is enormous, but it is useful to see them
as lying within a spectrum which extends from ‘hard’ to ‘soft’. There are a number of
ways in which ‘hard’ and ‘soft’ can be defined but the definition I wish to take is in
terms of the degree of agreement about what the problem is among the particular
population of individuals to whom ‘the problem’ is of concern.
Thus, the design of a piece of software to meet a given specification is a hard
problem (as long as the specification is ‘a given’) whereas the specification of
information requirements to meet business
needs is a soft problem particularly if the needs as specified by potential users are at
odds w ith those required to support the business, or if indeed the business
requirements themselves are problema- tical.
At the hard end of the problem spectrum Systems Engineering (SE) methodology is
applicable and essentially consists of the following stages.

1. Define the problem


2. Assemble the appropriate techniques
3. Use techniques to derive possible solutions 4. Select most cost/effective solution
5. Implement the solution

At the soft end of the problem spectrum the first of the above stages ‘Define the
problem’ is itself problematic since it usually depends upon who defines it. Given that
there will usually be a number of people concerned with or involved in ‘the problem’
there will be a number of legitimate definitions. Thus SSM has to start by defining, not
a problem but a situation that is problematic.
Thus at an equally broad level SSM could be characterised by the following stages:

1. Define the situation that is problematic


2. Express the situation (top mapping, rich picture, etc.)
3. Select concepts that may be relevant
4. Assemble concepts into an intellectual structure
5. Use this structure to explore the situation
6. Define changes to the situation (i.e. problems to be tackled)
7. Implement change processes.

In SE the techniques contain both the concepts and the structure and are w ell
defined. In SSM the concepts and the structure are independent and need to be
specified separately. This may involve greater iteration around the stages indicated as
progress is made in learning about the situation. Two examples of SSM relative to two
general types of problem are illustrated by Figures 1.6 and 1.7 using the concepts of
human activity systems (see Chapter Two).
At the hard end of the problem spectrum the methodology (or perhaps method) is
being used essentially to answer a ‘how’ type of question. ‘What’ is required is not
problematical, it is only ‘how’ to achieve it that is the problem. At the soft end ‘what to
do’ is problematical as well as ‘how to do it’. Once stage 7 is reached in Checkland’s
SSM ‘hard’ methodology may be used though it is usually the case that managing the
change process is also taken to be soft.

Intellectual Planning

As stated in the introduction, methodology is a description of how to think about the


process of analysis prior to doing it. Hence the intellectual process of choosing
concepts and deciding how they might be structured in a methodology is really
concerned with thinking about how to think; an unusual process. It has the advantage,
however, that the resultant methodology is tailored to fit the particular situation, and
the analysts know why they are doing what they are doing and how and what they
are doing relates to what they will be doing next. Given the great variety of organisa-
tional problems, considerable flexibility must exist in the concepts and structures
available to the analysts. Unless the particular methodology is assembled as a
conscious part of the analysis it is unlikely that the changes and/or solutions
identified will represent an effective output of the analysis. Additionally, the specific
methodology needs to be explicit in order to provide a defensible audit trail from
recommendations back to initial assumptions and judgements.
Thinking about how to think about a problematic situation can produce the most
powerful and defensible application of the range of intellectual tools available to an
analyst, yet there are still managers around to whom intellectual activity is anathema.
It is seen to be ‘academic’, not practical. ‘Don’t sit there doing nothing, get on with
the job’ is still a prevalent attitude. Let me conclude this section by borrowing a
quotation about planning by Sir John Harvey-Jones and rewriting it in terms of
thinking. Thinking about how to think is about planning the intellectual process:
Thinking about how to think is an unnatural process and nobody knows that you are
doing it. It is much more fun to get on with doing something and, besides, you can be
observed doing it. The nice thing about not thinking is that the eventual disaster
comes as a complete surprise rather than being preceded
by a period of worry and depression.

THE CONCEPT—HUMAN ACTIVITY SYSTEM

Returning to Figure 1.4 but expressing it in the context of a range of organisations,


(i.e. Figure 1.8) indicates that the characteristics of such organisations are equivalent to
the characteristics of the real world as illustrated in Figure 1.4.
However, to these I have added the characteristic of ‘uniqueness’. This means that no
two organisations can be identical. Even two companies in the same line of business
and of a similar size will be different. This is because the people who make up the
company will be unique to that company, there will have been different generations of
them, different behaviour histories and resultant cultures. These features are unlikely
to be replicated elsewhere.
Thus, in relation to general problem solving a solution that is found to be appropriate
in Company A is unlikely to be appropriate in Company B. It is unfortunate that a
number of managers ignore these cultural characteristics when wishing to improve the
performance of their own organisations. It is not uncommon to make visits to see how
the other company undertakes its business processes and then to attempt to
introduce such new practices at the home base. It is not too long ago that attempts
were made by a number of British companies to introduce Japanese meth- ods;
without significant success. In this example there were national cultural differences but
the differences are still there within a single nationality. ‘Benchmarking’ is a modern
tendency to define ‘best practice’ and companies seek to introduce it without
questioning what ‘best’ means for their particular organisation.
If each company or organisation is unique, what do they have in common? The
assumption upon w hich SSM is based is that: Whatever the nature of the organisation,
assume that the individuals within it are pursuing purposeful activity. They may well be
pursuing different purposes but they are not acting randomly.
Purposeful activity therefore represents a common feature of all organisations. The set
of possible purposes stated earlier for a police force could all be legitimate definitions
of purpose and therefore each could be the source of a business model.
If we can define purpose then we could derive a description of what the organisation
must do to achieve that purpose. However, these single statements of purpose are not
a description of the real- world organisation but describe a particular perception of it.
It is therefore better to see the defini- tions and the resulting model as a concept
relevant to the organisation which can be used in thinking about the organisation.
Within SSM these concepts are called Human Activity Systems (HAS).

They are systems because they represent a set of purposeful activities together with
the relationships (logical) between them. The activities, in principle, could be
undertaken by human resources if the system were to map onto reality. Checkland
now calls these constructs ‘holons’. This conveys no meaning and therefore I will retain
the terminology of a HAS. However, it does not matter which label is used as long as
the underlying concept is understood.
An everyday definition of the systemic paradigm is that the whole is more than the
sum of its parts. If the concept was merely a set of purposeful activities it would be an
aggregate since the whole would equal the sum of its parts. The set becomes a
system by the inclusion of the relation- ship betw een the parts. The set plus the
relationships produce w hat is know n as an emergent property , (see Checkland 1981;
Wilson 1990). Thus a system may be defined by its emergent property. In relation to a
hard system the emergent property becomes its specification of purpose or design
specification.
A system whose specification of purpose is to have the capability of transporting
passengers over intercontinental routes at speeds greater than that of sound can be
represented by the real-world manifestation of that system (i.g. Concorde). This
purpose would not be achieved by its component parts alone, they would not achieve
anything. Each part must have its appropriate relationship to the other parts (i.e. the
assembled Concorde) in order to achieve its designed purpose.
The emergent property in relation to a HAS will also be its definition of purpose. Thus
for the police example given earlier six potential emergent properties have been
identified which would lead to six different models relevant to a police force.
The notion of emergent property for a HAS is captured in the technical term—Root
Definition. The formulation of Root Definitions and their relationship to HAS models are
discussed in detail in Chapter Two.

You might also like