Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Descriptive or Prescriptive?
The first question, the one the textbooks often skip, is how you think of the methodology: Does the model describe how things are generally done around here (descriptive model), or does it tell the staff exactly how to do the work, every time (prescriptive model)?
Authors of descriptive models have given up on planning exactly how each step should go, and are relying on smart people to make good choices in the moment. Still, new hires need somewhere to start, so descriptive models can be very helpful to them. They tell the new employee what’s expected and give a sample flowchart. A descriptive methodology might talk about what-how-build-use, or perhaps say that the organization creates a simple working system and builds features, or talk about the importance of prototypes or customer signoff. A descriptive model is supposed to model how work is actually done, so it might go so far as to say "We do X when we think it has value" or "We tend to do Y on smaller projects and Z on bigger projects." Descriptive models have drawbacks; cowboy developers can ignore them and create risk.
Prescriptive models, on the other hand, tell everyone exactly what to do and when. They tend to be large, require a lot of documentation, and are expensive in terms of person-hours to create. Prescriptive methodologies are essentially "project insurance"; your team pays a price of inefficiency now in order to mitigate or avert a disaster later.
So here we are, just discussing what a methodology is, and we’ve got a tradeoff.