One thing I associate with product management is the need to keep marching through the many efforts required to design and build software, then launch it in the market — no matter how difficult the times. And so we have this week’s issue, as scheduled.

Respectfully,

Jacques Murphy,

• Feeling sad for the people of Iraq,
• Grieving for the lost and those who love them,
• Feeling proud of the U.S armed forces,
• Hoping for a swift return to peace,
• Reliving feelings from September 11,
• Trying to go about my daily tasks in spite of it all.

In the previous issue we “took a course” called Requirements 101 covering the Requirements document. That document is a tool produced for each release and serving as the fuel for the next round of software development work. It is the main component of the requirements effort.

Requirements 101- the Requirements Document, is the “prerequisite” for this week’s course.

In addition to the Requirements document, the process of researching, soliciting, gathering, defining, prioritizing and communicating requirements rounds out the whole requirements effort. The process serves to ensure that the Requirements document attains the right level of quality, and that development output matches the business needs and priorities expressed in the Requirements document.

You can rely on the process to make a painstaking component of product management run a little more smoothly.

Read on for the steps to follow for a successful Requirements process, and for overall guidelines on it.

[private]

Step One: Research

Conduct product research and competitive analysis as an ongoing effort. You’re better off making this a frequent, or even constant, part of your job in order to gain the level of understanding needed to determine just what functionality is going to be needed to make the product more competitive.

This also includes business development tasks such as alliances and partnerships, which will take place on an ongoing basis independent of development cycles.

Read Product Research in Today’s Tough Times for ideas for how to conduct product research with customers and prospects on a tight budget and as an integrated component of your daily work.

Step Two: Solicit

About a month before the Requirements document is due, send out requests to all the various groups of constituents you want to receive requirements from. In addition to customers, this includes sales reps, implementation consultants and trainers, customer care reps, and developers.

Send out a reminder two weeks before the due date and one week before, specifying the deadline for sending requirements. Realistically, most of the requirements will come within a week of the deadline (this also means within a week after the deadline, which is a good reason to have an official deadline which comes before the actual date you need to have the document done and transmitted to developers.)

Step Three: Gather

Set up a system to gather requirements for the upcoming release cycle. While you may not receive many suggestions in writing from others until the next deadline rolls around, you will receive plenty of verbal ones. Demos to prospects will also spark a lot of ideas, which you’ll want to jot down while they’re fresh in your mind.

Maintain a file where you and other Product Managers add written notes for each suggestion. Put individual suggestions on separate pieces of paper, so that you can sort and organize the suggestions when it comes to the next step.

This folder also contains all product research you have conducted since the previous development cycle.

Step Four: Define

This is the step where you build the Requirements document. Take the requirements you have gathered, and sort, organize, and consolidate them as appropriate. Then work on defining each requirement using a matter-of-fact explanation that does not leave it up to developers to make major judgment calls for business issues (as opposed to technical or screen design issues).

Two issues below provide suggestions for defining requirements:

• Requirements: From Hype-ful to Helpful
• Requirements: How Much Is Enough?

Step Five: Prioritize

After describing each requirement, prioritize them into a system such as High, Medium, and Low, as explained in Requirements 101 – The Requirements Document.

When determining which requirements are high priority, look at all the requirements within a category or module, but also look at requirements across the whole product, to see them in perspective.

Prioritizing is a time when you take a step back from the closeup involvement you have had while defining and describing each separate requirement, in order to look at the overall importance of requirements relative to one another.

At the end of this step the Requirements document is complete.

Step Six: Communicate and Finalize

The first and most important piece of the communication step is the handoff to Development. Send the Requirements to all developers involved in understanding and estimating time needed to build each requirement. If you have fewer than 15 developers, this is usually everybody in the department.

Conduct a Requirements Meeting or series of meetings to review each requirement with the appropriate developers. During this meeting, as the developers understand each requirement, they can give a high-level estimate, which you note down. Your presence is critical at this point to clarify the business purpose of the requirement and to provide answers the developers may need to come up with an estimate.

Some estimates may require further effort outside the meeting, but try to get a basic estimate for every requirement if possible.

After the meeting, fill in the time estimates and distribute the updated requirements to Development. Estimates can be added up to allocate resources and schedule time.

Once the Requirements document is finalized and requirements are scheduled, you can communicate the list of scheduled requirements to all other constituents — sales and marketing, consultants, and customers. You probably won’t use the Requirements document for this, because it’s too detailed. Instead, it’s more useful to create a one or two page Planned Features document, with a bulleted summary of major new capabilities.

Step Seven: Consult and Interpret

The finalized Requirements documents serves as the authority, when there is a doubt, for developers who are scheduling, planning, designing, and coding.

Be sure to reinforce the importance of the Requirements document, and get the most out of all the effort you invariably have to put into making it, by always referring back to what was stated in the requirement.

However, you can never have a Requirements document that captures everything developers need to know as design and coding unfolds. In the end, you need to be the one they go to for judgment calls on what will best meet a given requirement.

Also, while you yourself may consult the requirements every time, you’re better off allowing some team members to simply approach you in person when they have questions instead of making them check the requirements, because you don’t want to discourage two-way communication. Having programmers come to you is much better than not having them check the requirements at all.

Step Eight: Verify

As planning, design and coding work is completed, refer to the requirements to verify that they are complete. Certain large requirements may wind up being partially completed in one release, and spawning a new requirement to complete the capability in the next cycle.

A great way to do this formal verification is at the Requirements Meeting, where the team first confirms what has been done in the previous release — you can use a Status field to indicate Complete or Open, for example — before going on to the new requirements. It can be a very encouraging way to start out each development cycle.

Certain requirements may not be completed as planned, if your software release dates are fixed rather than allowed to slip due to development delays. It’s important to update the Planned Features document as well so all constituents understand which capabilities have actually made the release.

Guidelines For the Requirements Process

In addition to the steps of the Requirements process, consider these guidelines to improve its effectiveness.

Publish Fixed Deadlines In Advance

Requirements tend to become a vague, undefined notion in the minds of customers and teammates in other departments. They know you’re responsible for them, but don’t necessarily know when requirements will be turned into development work. If they’re not sure when the requirements will actually be used, people are less likely to submit suggestions to you.

Publish a clear schedule of when you plan to submit requirements. Yes, this may change every month if your development dates slip or change, but this way customers and coworkers have a clear idea when you’re next planning on submitting requirements for the next development cycle.

This confidence makes for more regular suggestions from the various sources who bring a valuable perspective to development needs.

This is also why communicating to all constituents is so important.

Concentrate the Effort

You will be doing research on an ongoing basis. In fact, the more regularly and continuously you conduct research, either formally or informally, the better off you’ll be in terms of building a significant store of market and competitive insight.

You will also gather requirements as an ongoing effort.

However, concentrate the effort to build the Requirements document into a week or two. Otherwise, you’ll waste too much time writing out requirements one month that three months later no longer seem that important, or that have evolved dramatically in that time.

Creating the Requirements document can also be a painstaking and tiresome effort, so you’re better off doing this in a short burst at the end. Not to mention that many of the suggestions from other departments will come in just before the deadline (or even just after it!).

Make Submitting Requirements Simple

You want to encourage as much input as possible, even if you don’t use a lot of the suggestions, or more accurately, a lot of them aren’t high priority. Therefore make it easy for others to submit a requirement. Don’t ask for formal written explanations. Allow emails, jotted notes, voicemails, and simple verbal explanations given while passing in the hall.

Write down any verbal suggestions right away on separate pieces of paper, and take written suggestions and add them to your cumulative file for the next Requirements crunch.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]