Although all consultants would agree that some diagnostics and articulation of customer wants and needs are appropriate in most engagements, there is a lot of room to debate whether we really need some of the more detailed (and expensive) requirements analyses. What are some ways to simplify the process and reduce its time and cost?
Part of our value of as consultants is not just to improve the client’s condition but to also make the improvement process itself efficient. One way to do this is to streamline the upfront activities that inform us of where the client needs to go from a customer standpoint. This is where user stories come can be extremely useful. Created for agile software development, they are adaptable and quite useful for many projects.
User stories often take the place of a more extensive requirements document. Instead of detailing the functions and features of the desired product or service, a user story explains the customer's role and desired outcome and the benefit it confers. They are informal, short statements of a single concept. The format is something like, "As a [role], I would like to have [outcome] so that I get [benefit]." For example, "As a sales representative, I would like to get hourly downloads of stock data so I can advise prospects in real time." This type of statement, combined with user stories for other roles and outcomes assures that the customer perspectives are defined and the outcomes and benefits can be ranked and inconsistencies surfaced.
Each informal, short use story can then be assigned a likely time and resources required to produce that outcome and benefit. The collection of stories (10-20 or more may be reasonable depending on the complexity of the effort and likely time to complete) can then be arrayed for design and implementation. Tip:
User stories are a powerful way to cut to the heart of the customer needs and define the successful result. It focuses on the users and their priorities rather than the requirements document, which is more about the product or service development process. There may be a time for more detailed requirements, but only for some aspects of the change process and only as needed. © 2011 Institute of Management Consultants USA