I’ve definitely walked into the “can’t get it all done” situations too – usually when being parachuted in to help out a project that was initially staffed with people who couldn’t deliver, or a project who’s sponsors had impractical expectations – often mis-set by vendors.

Great observations about the impact of people not knowing that what you are delivering is partial. One approach to mitigating that affect is to use breadth first coverage of requirements / use cases. In other words, define the use case names, then use case briefs, then formal use cases. Each discrete deliverable is “complete” with a particular level of rigor, and people can be confident that the formal use cases are complete, while the use case briefs will require additional effort.

I’m not sure there is a reasonable way to address other requirements artifacts, other than managing their status (e.g. draft form vs fully vetted) with some custom attributes.

And thanks very much for the positive feedback! Keep reading and commenting.

In these cases, there are often other factors working against you (the aforementioned scope/time/cost constraints, usually), and the project is in a less-than-optimal position. I think that the ability to effectively manage these types of projects separates PMs with *talent* from PMs with certification.

Always fun to write Requirements on the run :)

And it’s even more fun when a scope iteration impacts you in a way you didn’t anticipate.

I am enjoying your blog. You address a lot of interesting topics in a way I find easy to digest.

Best,

Josh Milane