Editor’s Note: Today we launch a new occasional how-to series, Geek Speak. We take complex tasks and topics and break them down into lay language. No longer will geek speak get in your way! The concept and this initial post are the brainchildren of two of our senior PMP consultants. Want us to help you get rid of geek speak? Send your nerdy questions to deardel@delcor.com and watch here for an answer!
Creating a useful report specification is one of the most difficult tasks for a project team. A solid report requirement has several key components.
Narrative – The narrative section of the report is the written business case and use of the report. This document should include:
- Audience: Identify who will be using this report on a regular basis. Is this report used by internal staff or external users?
- Purpose: Describe how the report will be used – will it be a statement to members, graph to Executive Team, analysis, etc.
- Selection Criteria (GEEK ALERT): Outline the data set that will be included in this report. It is critical that developers understand what data should be included or excluded. Typically this includes information such as: members, active status, exclude inactive members.
- Parameters: Parameters are options selected by the user to personalize the report. Frequently, parameters are drop down menus and date ranges in the system. (List of Events, Event start and end dates, Publication type)
- Sort/Group Order: Define how data will be sorted. Will information be grouped by a category?
- Fields: List all fields (INCLUDE THE ACTUAL FIELD NAME) that will be displayed on the report.
- Output: Define the final format of the report. Will the report be exported into Excel, display results as a graph, etc.
Mock Up – Draw a picture!
Work Flow – Create a diagram to define the process. How will users access and run the report?
- Functional: Confirm all functions are operational. Does the report return results, do the drop down menu display info, etc.
- Scenario: The subject matter expert outlines common interactions with the system.
- The user will run this report for a single meeting between X and Y date.
- Another user will run this report for several events
- Validation: Compare report results with expected data. If the database lists 10 registrants for an event, the report should report the same 10 individuals.
- Exceptions: Develop cases for data that should not be returned in the report. Try to run the report using data that should be excluded.
- Feedback Loop: The team must decide what process will be used to report feedback. For example, feedback must include all information so a developer can follow the steps a user took to recreate the issue.
Flickr image by Jimmie. Report examples supplied by authors.
