Easy IT elements – Methodology Explained

A methodology provides a set of rules, principles and methods (I will explain the difference later), that turn best practice into a re-usable framework with supporting tools & techniques. All professions and fields of study have them, but in IT and business change projects they are particularly important to guide planning, organisation and management of complex tasks.

‘ology

Before I look at some examples, some definitions are needed.

Strictly speaking methodology relates to the broader area of practice, i.e. the systematic study and application of methods, similar to bio-logy (study of life) and psych-ology (study of behaviour). However, by usage – if not convention – people also refer to a single framework or set of methods as a methodology; in which case the methods become the specific techniques and procedures within the methodology.

I will look in more detail at Project Management Methodologies later as a theoretical model and examples of its application in real world situations. But first, here is a slightly left-field case study.

In the wild

I recently read a memoir and saw the film-of-the-book ‘Wild’ about a 1,000 mile trek along the PCT (Pacific Crest Trail) by Cheryl Strayed.

By way of preparation the author had read a guidebook, planned a route and various drop-off points for re-provisioning. She had bought all the kit; the shiny new boots, water carriers, the loudest whistle in the world, a saw(!) and axe etc.

Unknowingly she was adopting an implicit methodology, which I will call, ‘Undertaking Big Solo Walks’, possibly part of larger outbounding or trekking body of knowledge. All this preparation is needed, or at least a wise course of action, because:

–   The endeavour is new and untried by the participant(s).

–   There are proven ways of progressing and succeeding.

–   Blind hope and optimism has risks, including avoidable costs & delays or complete failure.

–   The application of specific skills, tools & techniques should make everything easier.

So far so good, but this analogy breaks down slightly. Other reasons that a formal methodology might be advocated and used include:

–   The sponsors, Customers or participants mandate that a specific methodology be used, or choose to adopt something from past positive experiences.

–   The results of the endeavour need to be formally reported, measured, accounted-for (costed) or audited, which is easier to do within a recognized framework.

–   Multiple participants need to adopt the same practice, including coded activities, quality standards and a common terminology.

There are some examples where a formal methodology might not be appropriate:

1. The exercise is trivial, for example, a 5 minute walk to the familiar location!
2. The endeavour or the domain or the technology is so new that there is no body of knowledge or framework to apply.

(Ed. (2) is unlikely, is there really anything new under the sun?)

The Goldilocks Principle

None of the above should be viewed as an unnecessary administrative or cost burden on what you are trying to do, in fact the opposite is true, as long as the chosen methodology is commensurate with the problem at hand (not too heavy, not too light, but just right!) and there is some expertise in applying the methodology, especially when it is adopted literally ‘off the shelf’ as in Cheryl’s case, then the benefits should more than outweigh the costs.

Which brings me full circle to Cheryl; she had many trials and tribulations along the way, some of which were potentially disastrous. Why? In a word, experience. Critically she had not tested herself, the equipment, or used any of the techniques in practice (proof of approach).

She did, however, adapt her approach during the trek, she learnt new practical skills, and took advice and proffered help from more experienced practitioners along the way.

Following a methodology is no guarantee of success; in the real world messy unpredictable situations occur that require both creativity and flexibility to overcome. The answer is not chaos but a methodology with built-in checks and balances, and one that can evolve and be extended with use.

Structure will set you free!

Projects and Project Management

Returning to Projects, which are of particular interest to the development of technology and software solutions. As covered in the separate IT Element, typical projects cover a number of broad process areas, with supporting control mechanisms:

(1)  Initiation

(2)  Planning and Design

(3)  Execution

(4)  Monitoring and Controlling

(5)  Closing

The modern discipline of Project Management started during the 1950’s, driven in part by the, ‘…critical need to communicate and co-ordinate work across departments and professions.’

In 1989 a method called PROMPT was adopted by the UK government for Information Systems/IT projects, sine renamed to the more familiar PRINCE (Projects IN Controlled Environments). Version 2 is now a more generic project management method and widely used in both the public and private sectors.  It is a formal or structured methodology that defines tasks to be carried out and outputs to be produced at each stage of a linear  waterfall-type project. The standard is underpinned by; clearly defined roles & responsibilities; specific techniques for planning and monitoring work, and; mechanisms for managing quality, change, risks & issues. It is sometimes perceived as an admin-heavy monolithic approach, but this is exactly what is needed in a lot of circumstances. ‘Lighter’ and more agile methodologies are also available!

For some editorial balance I will also mention an alternative method that came to prominence in the 1980’s;  SSADM or Structured Systems Analysis & Design Method. It is again a formal and widely-used approach for computer system development. However, it has a  slightly different emphasis on  creating and maintaining graphical models of the system as it is  specified, designed and built, i.e. during a typical development life-cycle. SSADM includes tools for modelling logical data, data flow and the dynamic behaviour of entities, that have evolved into various strands of software engineering including, Component-based Software Engineering & Object Orientation as well as a unified language and set of modelling tools called UML…topics for other elements in the table of IT elements…

Methods – not reinventing the wheel

Before you embark on some complex endeavour that you may or may not have done before, whether you are developing a new product, re-organising your business, carrying out some primary research, or crossing a wilderness, it’s normally a good idea to seek out the best practice in your industry or field of interest (no pun intended!)

If it’s been done before it is the ultimate conceit or foolhardiness to imagine that you can invent a better circular vehicular conveyance 🙂

Don’t reinvent the wheel, just realign it.

@ITelementary

© 2015 Antony Lawrence CBA Ltd.