Goals and requirements drive the work schedules of all projects. Some of these requests are necessary to the success of the current project, others are not so critical. Yet sometimes we lose sight of this and spend many work hours trying to complete more than what can be done within the timeframe of a project. In this week's column, Johanna Rothman reminds us to look critically at what we're working on to make sure we're satisfying the goals after the requirements have been satisfied.
Kris, a technical lead, saw Tom, one of her project's developers running down the hall. She was curious, but didn't interfere. A few hours later, she saw him running back. He stopped and made a U-turn into her cube.
"Kris, do you have a minute?" he asked.
"Sure, what's up?" she said.
"Well, Danny over in marketing wants me to add these things to the screen, and I was wondering if you could take a look at it?"
Kris started reviewing the changes and asked, "Tom, is this why you've been running around all day?"
"Uh, yeah. Why?"
"Because what Danny wants is something that's a goal, not a requirement for release. Remember the product roadmap? This feature is for the next release but was a goal for this release. We need to finish the requirements before we think about the goals. Let's go talk to the project manager and see if anything's changed."
Many projects have more requirements than can be finished in the desired project time. Some of those unfinished requirements turn into goals. Other times, the project team members have internal goals it wants to accomplish. Or marketing has said it would be nice if the team could achieve a certain performance or reliability greater than what it specified. Or the organization wants faster projects. All of these are goals, and the team should satisfy the goals after it satisfies the requirements.
Separate Goals from Requirements
It's easy, especially at the beginning of a project, for a project team and the people who request deliverables (some of which are requirements) to be unable to differentiate between goals and requirements. The project team might be excited about the project and want to do everything. The people who want the release might feel as if there's pressure for everything in this release. But it's too easy for the project team members to be sidetracked if they haven't differentiated between goals and requirements.
Here's how I do it. First, take your requirements (if you have them). Now, for each requirement, ask the person who gave you this requirement into which bucket this item belongs. The buckets are:
- Product requirements required for this release
- Product requirements for some time in the future
- Project goals, such as a reliability or performance measurement that exceeds the product requirement
- Team goals--things the team would like to do (e.g., pay down some technical debt by investing in more unit tests)
- Organization goals, such as finishing this project before the next one needs to start
Only the first item in this list represents the project's requirements. Everything else is a goal.
Define Release Criteria
Now that you know the requirements, you can test whether or not you've bucketed everything correctly by defining release criteria. The release criteria should be a subset of the requirements. If you find anything creeping in from the goals, you know you either have more requirements than you thought or your release criteria are not actual release criteria--they're goals someone wants you to deliver.
Here's how this could play out in a project. Imagine you have an online store, and you have a requirement of improving the search for a specific set of items--say, canary cages--by ten percent to bring total search time for canary cages to less than two seconds. In addition, you know that for next quarter's release, you need to bring canary cage search to less than one second--as well as bring the search for all cages to less than 1.5 seconds. This is a goal for this release, but a requirement for next release. If you can see