Projects Have Requirements and Goals


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.

2 Replies to “Projects Have Requirements and Goals”

  1. Hi Johanna,
    There is no doubt that projects must have requirements and goals. For me, goals are which requirements are based on and not something that is done “if there is time”. Requirements need to be aligned with the projects goals and that any thing else could be suspected as waste. There are three types of goals that I see.
    – The project goals. Project X needs to be completed with time Y and bugdet Z with requirements A thru M. Within the project goal, you have your requirements and each requirement should have a level of “performance/functionality/usability” that lets the team know that the requirement is complete. Your example of performance fits nicely into this bucket. The user story may be “Display a list of tables for a given database”. The level of performance metric could then be -“Must enumerate 10,000 tables within 1 second”.
    – Team goals (or values). These are the things that the team agrees that are important to them and their work. Trust and reliability are the type of values that jump to mind. They can also represent thinks like performance, security, usability. When a team takes on a performance value, each team member strives to make their code as fast as possible. When they take on a usability value, they care more about the user interaction experiance. These values can represent the “dark side” of any project when obsessive behaviors kicks in and leads to sub-optimization of the organization.
    – Organization goals (or objectives). For example, a progressive organization may have a goal “Reduce the overall duration of projects to improve our organizational agility”. In my opinion, there should be projects that are also aligned around the organizational goals as well but they are often neglected as being percieved as overhead. For your Agile example, by knowing your organizational goal, you can direct your slack resources towards this type of goal. For example, use team to develop a better way of automating test runs or investigate ways to get timely customer feedback so that you can avoid rework.

  2. Requirements come in different priorities (see
    – Must have this
    – Should have this if at all possible
    – Could have this if it does not affect anything else
    – Won’t have this time, but Would like in the future
    According to your description a “goal” falls in the category of “Could have” requirements, which would still make it a requirement. A “goal” is more like something you want to achieve with your project. The primary goal probably is “a product that satisfies the requirements”, but a secondary goal could be “knowledge and experience for the next project” or “having fun together”. I think you can look at the requirements as being part of the project’s mission, while the goal is part of the project’s vision.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.