Friends, this particular column is simed at the I.T. sector. However, corporate managers should also find it of interest. With that said…
2011 marks our 40th anniversary in the methodology business with the advent of our “PRIDE” product, the first commercial methodology for designing and developing information systems. “PRIDE” was born out of the need to implement the massive Management Information Systems (MIS) of the 1960’s. As we began to market the product in 1971 people would inevitably ask, “What exactly is it?” Good question, as there had never been anything like it before. We thereby coined the expression “methodology” to refer to “PRIDE” as an organized process for building systems. The expression was considered somewhat avant-garde at the time and caught on. As the structured programming movement blossomed in the late 1970’s the term also came to be associated with specific techniques for software design.
Recently there has been renewed interest in methodologies and quite a few papers written about them. Frankly, I’ve been disappointed in their observations and conclusions and, through this article, I hope to set the record straight.
The reason we chose the word “methodology” is because we recognized there were essentially two ways of designing and building any product, either one at a time or standard and reusable processes. The “one at a time” approach means you have to define your methodology with each new project. The “reusable” approach is a recognition the same processes can be applied to building products of similar type. For example, there is a standard and reusable methodology for designing and constructing houses, bridges, ships, or skyscrapers, or for the design and development of products, such as electronics, automobiles, jet engines, etc. An assembly line, as found in manufacturing, is perhaps the most visible implementation of the methodology concept. It consists of a series of workstations where certain tasks are performed, and a deliverable is produced for review before proceeding to the next workstation. There are methodologies for just about every type of work effort. It would be rather arrogant to assume systems development would be any different. All I.T. organizations have such methodologies, whether they are cognizant of it or not; some are well defined and applied consistently in an organization, others are not.
The concept of “methodology,” as we implemented it in “PRIDE” in 1971, was to define the standard and reusable steps by which an information system was designed, developed, tested, installed, and reviewed. Again, we saw this as analogous to an assembly line in a factory where products are assembled in increments until a finished product rolls off the line, such as an automobile. This means a methodology operates independently from project management. If you do not care about time or costs, the “PRIDE” methodology could still be used to design and build a system. Many people believe project management is an inherent part of a methodology; it is not. A good methodology supports project management but it is certainly not dependent on it. Using the manufacturing analogy, an assembly line defines how a product is assembled. Only then can we apply production control to determine if the line is progressing on time and within costs. This means project management is analogous to production control in a manufacturing facility. It also means project management is dependent on a methodology, but not the reverse. Nonetheless, most people look to obtain a methodology for solving their project management problems, which it certainly can help, but that is only a byproduct and not its main focus.
Like an assembly line, we designed every phase, activity and task in the “PRIDE” methodology to produce a reviewable result, a “deliverable” of some kind which can be reviewed for completeness, thereby providing the means to build quality into the product during its development as opposed to inspecting it in afterwards. Deliverables can take many forms, be it a report, a file, a program, test data, etc. Regardless, “PRIDE” defines the 5W’s + H, “Who is supposed to do What, When, Where, Why, and How,” thereby everyone in the methodology is cognizant of what their duties and responsibilities are, including the work that precedes and succeeds them.
Methodologies can be defined for any form of work, be it I.T. related or otherwise. In “PRIDE”, for example, we devised three complementary methodologies – one to study a business and devise an enterprise wide information strategy (Enterprise Engineering Methodology), one to build systems (Information Systems Engineering Methodology), and a third to develop the corporate data base (Data Base Engineering Methodology). These are not “make work” methodologies as much as they are designed to define the assembly lines of an I.T. organization.
When it comes to systems methodologies, there tends to be two schools of thought: linear or spiral development. Linear methodologies refer to the classical approaches for systems development as fostered by academia, whereby there are typically five basic phases of work:
1. FEASIBILITY STUDY2. DESIGN3. PROGRAMMING4. TESTING
5. INSTALL AND REVIEW
Variations of the classic linear approach abound and can be found in many different places, including consulting firms, universities, and packaged offerings. It is sometimes called the “waterfall” methodology or SDLC (Systems Development Life Cycle).
The spiral approach is based on the premise the development process is evolutionary in nature (which, in fact, it is). The concept is to initially design a program, then add additional phases of work to constantly revise the program to enhance its features. From a Project Management perspective, the problem with this approach is that the project never ends. What is today referred to as “Agile” falls under this category.
Interestingly, neither the linear or spiral philosophies take parallelism into account, as is commonly found in product related methodologies. This is because most system developers do not grasp the concept of associating a system with a product. In reality, an information system is a collection of business processes (aka, “sub-systems”) that can be depicted as a hierarchy of subassemblies and parts which is essentially no different than any other product structure. This philosophy thereby provides the means for the methodology to branch out to mirror the product structure. It also means sub-systems can be developed and delivered in parallel and concurrently, thereby allowing a system to implement its kernel components while the rest of the system is still under development.
I find it interesting that people in the industry still do not understand this simple concept of parallelism and insist on thinking linearly. Maybe it’s because this is how most programmers work, one step at a time. This may be fine for a single program, but a system is much more robust in size and scope. Working and thinking in a linear manner has been the cause of many development disasters over the years. It is simply not practical or necessary to do so.
Over the years, one of the major criticisms of methodologies is the idea of forcing a small system change through the rigors of a robust methodology, thereby being viewed as a bureaucratic nightmare. Again, going back to the assembly line analogy, suppose we had to modify or correct a small change to a television set, would it make sense to take it through the whole television assembly line or rather go to just those workstation(s) necessary to implement the modification? The latter obviously. The same is true in systems development, in the event of a change, it is necessary to identify and execute only those phases (workstations) necessary to implement it. Big changes, many phases; small changes, few phases. Again, this is only possible with a product perspective.
What distinguishes “PRIDE” from other methodologies in this area is that it is based on a simple concept: “A system is a product that can be engineered and manufactured like any other product.” If you buy into this concept, then it is possible to transform an I.T. department into an Information Factory. If you do not, you will probably continue to think linearly and complain about the bureaucracy of methodologies.
For more information on this subject, see:
“Standard System Structure”
“Methodologies versus Techniques and Tools”
“A Short History of Systems Development”
Finally, let me leave you with a definition which we use in connection to “PRIDE”:
Methodology – one or more phases of work to be executed in a prescribed manner. The methodology denotes a project’s sequence of execution or network. All projects have a structure; some are based on key events to be completed and others are based on the structure of a product to be built. All projects have a beginning for planning, a middle for execution and an end for review. The beginning phase of most projects is performed through some form of feasibility study. The ending phase is usually an evaluation phase. Each phase, activity and operational step within a methodology must produce a reviewable deliverable to substantiate adherence to the methodology.
(See Deliverable).
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at [email protected]
For Tim’s columns, see:
http://www.phmainstreet.com/timbryce.htm
Like the article? TELL A FRIEND.
Tune into Tim’s THE BRYCE IS RIGHT! podcast Mondays-Fridays, 11:30am (Eastern).
Copyright © 2010 by Tim Bryce. All rights reserved.