I’m in the midst of writing the PM book (which is why I haven’t blogged much). One of my tips is that projects have both requirements and goals–and that the PM (at least) needs to know the difference.
A requirement can be a use case, user story, a shall statement, whatever. So can a goal. But a goal is something that if there is time (the effort is not on the critical path), the user or customer would want.
Let me be clear. Testing is not a goal. All too often, projects shortchange their testing efforts. The problem is: how much testing? I wish I had the answer. But if you find that your product’s technical debt is increasing with each release (or iteration), I would make more testing an explicit requirement for the next project.
When I discuss this topic in my PM workshop, some of the Agile folks say, “Well we have iterations and we don’t need to think about this–we only do what’s required in an iteration.” Yes, that’s true, especially for the first few iterations. And, at the end of the project, it’s possible that the team has a velocity of 15 user stories, but only has to complete 2 user stories in the iteration, as part of the requirements. That extra time can either be used to move people off the project onto another project (which has its own set of difficulties), or to add more stuff to the product–the goals.
It’s worth thinking about what’s necessary (requirements) for whom, and what’s a goal (and for whom). Sometimes increased performance or reliability is a goal, not just more features. Sometimes an earlier release date is a goal. Sometimes, paying down technical debt is a goal. But knowing what’s a goal and what’s a requirement helps the PM organize the project better (regardless of lifecycle) and helps focus the project team on the requirements.