4 ms·

> Negotiation about scope. I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documen

> Negotiation about scope. I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documents that always started with a "flexibility matrix". The flexibility matrix had three rows labeled "schedule", "scope", and "resources" and three columns: "flexible", "moderately flexible" and "inflexible" and they were supposed to check one option for each row. So every single requirements document listed "resources" and "flexible", "scope" as "moderately flexible" and schedule, OF COURSE, "inflexible".

jerf 8y ago
You sound like you're complaining, but your complaint may be incomplete. If those bullet points were honored, that is indeed how pretty much every organization doing development will operate, whether it likes it or not. That is not intrinsically a problem. I take it these requirements documents were not honored by your non-developers? A document labeling scope as "moderately inflexible" does little if it's treated as written in stone.
- Bartweiss 8y ago
  One basis for complaint that stands out to me is framing "flexible resources" as a full degree of freedom. The first question is of course whether that's true, since resources don't tend to flex up unless someone outside the project dictates it. But even if it's accurate, it tends to produce the situation The Mythical Man-Month was written to condemn. If the ship date can't move and the scope won't bend on core features, there's a very real risk of finding that extra resources can't fix the timeline problems. You're right that most organizations have to operate this way, and it's not inherently bad; I've just found that "flexible resources" is often used as a way to avoid admitting that the real third category is "risk of failure".
  - commandlinefan 8y ago
    Actually it started out as a 2x2 matrix (scope/schedule), and all of them were scope = flexible and schedule = inflexible (of course), and they started adding the "resources = flexible" row so that they could walk back their claims of scope being flexible, because of course it wasn't.
afarrell 8y ago
Wait, how are resources flexible here? You can’t just scale the number of engineers on a project quickly..
- fdjlasdfjl 8y ago
  Depends on the number of devs you have working on the project. If you only have 1 then you can flex to 4 pretty easily and still have an efficient team. If you have 7 and flex to 10 then you're just adding inefficiency.
- commandlinefan 8y ago
  We actually tried asking for more resources when the schedule was in "jeopardy" and were told that there weren't any available. They suggested we try working weekends to make up the shortfall.

jerf 8y ago

You sound like you're complaining, but your complaint may be incomplete. If those bullet points were honored, that is indeed how pretty much every organization doing development will operate, whether it likes it or not. That is not intrinsically a problem. I take it these requirements documents were not honored by your non-developers? A document labeling scope as "moderately inflexible" does little if it's treated as written in stone.

Bartweiss 8y ago
One basis for complaint that stands out to me is framing "flexible resources" as a full degree of freedom. The first question is of course whether that's true, since resources don't tend to flex up unless someone outside the project dictates it. But even if it's accurate, it tends to produce the situation The Mythical Man-Month was written to condemn. If the ship date can't move and the scope won't bend on core features, there's a very real risk of finding that extra resources can't fix the timeline problems. You're right that most organizations have to operate this way, and it's not inherently bad; I've just found that "flexible resources" is often used as a way to avoid admitting that the real third category is "risk of failure".
- commandlinefan 8y ago
  Actually it started out as a 2x2 matrix (scope/schedule), and all of them were scope = flexible and schedule = inflexible (of course), and they started adding the "resources = flexible" row so that they could walk back their claims of scope being flexible, because of course it wasn't.

afarrell 8y ago

Wait, how are resources flexible here? You can’t just scale the number of engineers on a project quickly..

fdjlasdfjl 8y ago
Depends on the number of devs you have working on the project. If you only have 1 then you can flex to 4 pretty easily and still have an efficient team. If you have 7 and flex to 10 then you're just adding inefficiency.
commandlinefan 8y ago
We actually tried asking for more resources when the schedule was in "jeopardy" and were told that there weren't any available. They suggested we try working weekends to make up the shortfall.