Over the years I have had numerous friends and family ask me what exactly our company did; it seemed rather mysterious to them and perhaps still does. Flippantly I tell people we are in the "methodology business" which is the truth but a bit unsettling to people as most only have a vague idea what this means.
In a nutshell, a methodology represents a series of steps in a project specifying Who is to perform What, When, Where, Why, and How (aka, "5W+H"), from start to finish. Perhaps the best way to think of a methodology is as a roadmap or an assembly line where a product is developed over a series of work stations. The operators at each station perform specific tasks on the product until it is ready to progress to the next work station and, ultimately, completion. Our company's particular forte is in the areas of standard and reusable methodologies for Systems Design, Data Base Design, and Business Planning. Obviously, there are many other methodologies for different types of work effort, such as architectural, manufacturing, engineering, accounting, and other industries. Whether you are constructing a building, manufacturing an automobile, or designing a bridge, there are certain stages of work that must be completed in a specific sequence. In project management terms, a methodology is commonly referred to as a work breakdown structure (WBS) with precedent relationships denoting the sequence of steps in a project.
Typically, a methodology consists of a series of phases of work which can be subdivided into activities and tasks. As one phase is completed, the project progresses to one or more other phases thereby allowing parallelism. Not all projects are executed sequentially, some may follow parallel paths where work is performed concurrently. Regardless of their construction, methodologies should be documented in order to provide guidance in their execution and to provide a convenient means to verify the methodology is being adhered to. To this end, the International Standards Organization (ISO) devised the ISO 9000 series of standards back in the 1980's which was intended for a company to document all of its methodologies which, in theory, is intended to improve quality. Through the documentation, people can verify the various project steps were executed properly. Although this is certainly helpful, it cannot substantiate how well a product was built, only that it was built in accordance to a methodology. Even if the methodology is superbly documented, a flaw in the actual construction of the methodology itself will prove fatal to any project using it. This little oversight is the Achilles Heel of the ISO standards.
Not all methodologies are created equal. Most are written as an inordinate series of books and worksheets. Regardless of how well they are written, if workers become more obsessed with completing forms and checklists, they tend to lose sight of the product they are building. We refer to this phenomenon as "The Dance of the Fairies," whereby developers are more concerned with following paperwork than in producing a quality product. Whenever you follow a methodology blindly you tend to overlook the work product you are trying to produce.
In devising any methodology, I ask customers to think of the work product to be produced and base the construction of the methodology on it. For example, if we are to build a major product, like an automobile, I instruct them to break the product into separate assemblies of work, e.g., body, drive train, engine, etc. By doing so, it is easy to define what phases may be executed sequentially or in parallel. In other words, the methodology maps the product structure, not just some random series of activities. When defining any step in the methodology, be it a phase, activity or task, it is important to define the deliverable associated with each step. By this I mean defining a tangible result which can be reviewed for acceptance; it has either been done or it hasn't which is one of the earmarks of an ISO standard. Defining steps without a tangible result is pure folly. Further, for each deliverable, acceptance criteria should be provided to give reviewers a basis for performing a proper examination. Without an acceptance criteria the reviewer has no way of knowing how well the deliverable was built (only that it has or has not been done).
To me personally, a methodology is a state of mind, not an extensive library of documentation. Instead, it is what all good craftsmen know about in terms of building any product; that there is a right way and a wrong way for building something. Such craftsmen understand there is a calculated risk for overlooking or cheating a step in the methodology, risks that jeopardize the quality of the product. They also understand a documented methodology is helpful for providing insight in how to build something, but it is not a guarantee you will produce superior results. Quality must be built into the product during design, during the methodology, not inspected in afterwards, and this cannot be done by blindly following "The Dance of the Fairies."
No matter how I try to explain it though, I find the concept of methodology is still somewhat nebulous to most people which is why I normally describe myself as a "management consultant" or someone involved with the I.T. industry. I still get blank looks but it seems to sink in better than "methodologist." Perhaps this is why I envy farmers, bankers, butchers; at least people have an idea what they do for a living.
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 timb001@phmainstreet.com
For Tim's columns, see: http://www.phmainstreet.com/timbryce.htm
Copyright © 2012 by Tim Bryce. All rights reserved.