Westerly Consulting

Homehome.html
Due DiligenceDue_Diligence.html
ProductProduct.html
Management AdvisoryManagement_Advisory.html
ResourcesBlog.html
AboutAbout.html
Contact UsContact_Us.html
 

Approach Reviews


By Fred Engel

Westerly Consulting


The need for speed is something that dominates a great deal of product delivery discussions. Building a product that takes a long time to get to market is being displaced by more iterative processes that allow for smaller releases that get to the market more quickly. The Agile mantra is “Individuals and interactions over processes and tools”.  The focus of Scrum and other changes in software development is to provide a better methodology for the software developer.  This note discusses iteration in the Product Requirements phase of the process.


Building a products requirements document is similar to building the software that it describes. A Requirements document is a complex document with a lot of interacting that is expensive to change and get right. The Product Manager carefully crafts such a document after synthesizing the input from customers, sales, engineering, support, the competition, and anyone else that has valid input. Like processes of old, the document tends to be delivered when the Product Manager is "finished" and ready for a series of review meetings that will end when people are either exhausted or in agreement with its content. The problem is the feedback comes too late to make change be affordable.


If we change the actual process the Product Manager uses to build the requirements document by interspersing reviews along the way, we have a more interactive process that can bring the teams along more quickly with fewer miss steps. Think of an Approach Review as Agile Requirements building.


Let's examine the process of writing a requirements document. By the time the Product Manager is ready to write it they have already talked to customers, looked at the current product, looked at the competition, discussed ideas with engineering, gotten input from Support and QA, and generally developed a set of notes and ideas about the priorities in this requirements document. At some level, much of what will be written is rolling around in the mind of the Product Manager. The new methodology suggests sending out a skeleton of the direction.


Step 1, then, is to spend a very small amount of time (1 or 2 days) writing down a broad description of the priorities of the requirements document. What is the approach that is being taken in this requirements document? What are the important items that will dominate the document? What are the controversial items? What are the items that are most complex and have impact on everything else? The idea here is to produce a very incomplete document that is a work in process not a finished good.


This brings us to the heart of the problem: the need to produce a document that is complete and unassailable. It is human nature to want praise and not invite criticism. Human nature wants the document to be reviewed to be complete not an embarrassment to the author. An Approach Review document is grossly incomplete and the ideas in it are not well developed. What it provides is quick iterative feedback that significantly speeds up the process.


Step 2, this initial rough draft is sent out for broad review to at least the same constituency that will ultimately need to approve it. There are several reasons to do this. First, the earlier disagreements or errors are discovered the cheaper it is to correct. Second, the author is not fully vested in the ideas, making change all that much easier. Third, it is easier for people to follow the direction of the Requirements Document because the document being reviewed is smaller and focus on key issues. Fourth, more people will read a short document and therefore there is more real review. Fifth, the Product Manager will have more confidence in the writing of the next phase because the doubt about people agreeing with the current phase has been removed. The review should also be a short, 2-3 days.


Step 3, gather and resolve the issues. There is not enough space here for a description of a review process but a review process needs to be run iteratively as well.


Step 4, send out the new draft with the next level of detail (and change bars). The Product Manager can decide on how many iterations are useful, but should err on the side of small steps. Getting the various items to be hammered out early saves time and improves the final product


These steps should be repeated until the Product Manager believes he has a complete document. Establishing the basic direction and product definition early is the key to not having to rework all that was written. As each step is taken the probability of having to rework big parts of the requirements document decreases.


These steps should be repeated until the Product Manager believes he has a complete document. Establishing the basic direction and product definition early is the key to not having to rework all that was written. As each step is taken the probability of having to rework big parts of the requirements document decreases.


Send comments to: fred@westerlyconsulting.com