You know I study methodologies. I like to think of a methodology as an entity that is created, used and perfected over time. Following this approach, engineering practices can be applied to the creation and maintenance of methodologies, very much like you create and maintain a house, a bridge or a piece of software. You study the context, make sure you understand it, design a solution, implement the solution and put it to work. Usually, changes and adjustments are necessary once the thing (house, bridge, piece of software or methodology) is working; that’s fine.
One of the crucial tasks in this approach is determining the requirements of the thing to build, i.e. what its future users expect from it. Usually, this is achieved by talking to the future users of the thing (plus perhaps other stakeholders), analysing what they say, documenting everything and validating against them that what has been documented really expresses what they really want. This general approach, usually called “requirements engineering”, is often used for software development and, as far as I understand, in other areas of engineering as well.
Now, if we decide to apply engineering principles to the construction of methodologies, then a requirements engineering effort is advisable before the methodology to construct is designed. The characteristics of the methodology to build will be determined from the agreed-upon, well-understood and documented requirements obtained from its future users. At this point, you could wonder: “what are the requirements of a methodology?”. Well, if we think of a methodology as a thing that solves problems (like a bridge or a piece of software do), the requirements are majorly given by the kind of problem that the methodology is aimed to. A particular user could say “I need a methodology that allows my co-located team of 5 people to develop small and quick web applications for small enterprises in an innovative and aggressive way”. A different user could state “I need a methodology that allows my 200-person, geographically distributed organisation to develop life-support hardware and software using well-known, established semi-formal approaches”. It is obvious, from these statements, that the methodology that would satisfy one customer would not satisfy the other. They are, in fact, expressing their methodological requirements.
I think that the requirements of a methodology can be classified into three large groups: organisation, project and product-related.
- Organisation-related requirements express the characterstics of the organisation in which the methodology will be used, such as its management and engineering culture, how reluctant are people to incorporate new ideas, or the average skill level.
- Project-related requirements describe the projects that the methodology will be used for, including characteristics such as the size and complexity of teams, their geographical and organisational distribution, the schedule, staffinh and financial leeways often available, or the average volatilty of system requirements.
- Product-related requirements, finally, describe the properties of the products that the methodology will be used to build, such as their size and complexity, business criticality and desired level of quality.
All this is based on common sense and my experience as a project manager and software engineer. I am currently trying to find literature on these issues so I can come up with a well-defined collection of methodological factors that can help a method engineer elicit the appropriate requirements from future users. Pointers and advice will be welcome.