A commenter on the post immediately preceding this one links to his own thoughtful essay on project management. This kind of thing may be old hat for the PM gurus here but it’s meat to me. You might like the essay if you, like me, are interested in the dynamics of managing big technical projects, and particularly if you are interested in how projects fail.
1 thought on ““Requirements Kill””
Comments are closed.
One thing that tends to cause problems in systems is poorly scoped requirements… requirements that span multiple segments of a system. This is what leads to situations where subsystem A changed and subsystem B has to be modified to compensate, only team B has no idea. You have two segments of a system that have to jointly combine to meet a particular requirement, so neither group has responsibility for actually meeting it.
What you want to do is put your requirements at the interfaces — at each step where you break the system down into smaller parts, the requirements you create should describe explicitly how each part interacts with each other part. That way, both teams know that if they’re going to change something, they have to change their parent requirements, which will require an explicit change in the other system.
What kills systems isn’t exactly too many requirements… it’s too many requirements with too little structure and nobody taking responsibility to keep them working together. It’s requirements without a common goal or common oversight.
(‘course, I could be wrong… my wife is the SE, not me.)
When we’re talking about laws, safety regulations, etc. the same is true — too many laws or regulations without a common goal, common oversight, or sensible structure simply become a tangled mass of ugly. The “sensible structure” part is really important. If you can’t tell how one rule/law/requirement fits into the larger structure, you can’t make judgement calls about it. You don’t know how important it is, what the consequences of failing to meet it will be, and so on.