There is often a temptation when developing decision support tools to dispense with planning them and dive directly into creating a tool and performing analysis. The big problem comes when the tool is unveiled and it fails to meet expectations. Worse, along the way, there is the added challenge of being unable to leverage an implementation team to produce the desired result (because the desired result is ill- or un-defined) and therefore drag out the development time.
There is a better way: following the "Six Steps for Successful Solutions." Of course, we didn't invent the steps, but we do know the value of laying them out and making use of them. The results are happier clients, less expensive implementations, and shorter solution delivery times.
Solution Delivery Process
The six steps, illustrated in the figure, are as follows:
- Problem Definition
- Requirements Specification
- Solution Design
Using this process does not require complete rigidity. At the requirements specification phase, requirements can be prioritized by version number or as "absolutely necessary," "nice to have," or "future," for example. Project additions can introduce new requirements and spark other steps to be repeated.
Step 1: Problem Definition
The problem definition captures the business need that is the reason for creating the tool or solution. There may be one or many business need(s) for which the analysis/decision tool is being developed and each should be articulated. These need(s) are inputs to the next step.
Step 2: Requirements Specification
Once the problem(s) have been defined, the requirements that must be addressed by the solution can be identified. The Requirements Specification (RS) provides written confirmation that the system requirements and dependencies are understood before the actual design or development work proceeds. Because later steps relate back to the RS, it is a very important step of the solution delivery process.
The RS helps ensure that user and developer expectations are aligned. The idea is to get a precise and explicit documentation of functions, capabilities, and constraints that are expected from the solution. The RS contains only functional and nonfunctional requirements and should not contain design suggestions, possible solutions, or other information (although some may already be in mind).
The RS is supposed to do four things:
1. Provide Feedback to the client. The RS is the client's assurance that the issues or problems to be solved and the software/decision tool behavior necessary to address those problems are understood. Therefore, the RS should be written in a clear, unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.
2. Decompose the problem into component parts. The simple act of writing down requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.
3. Serve as an input to the design specification. The RS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the RS must contain sufficient detail in the functional system requirements so that a design solution can be devised.
4. Serve as a product validation check. The RS serves as the parent document for testing and validation strategies.
Investing in this step pays dividends with a smoother, more-efficient and more-cost-effective solution delivery process.
Step 3: Solution Design
Once the requirements are defined, solution design activities can commence. Using the information in the RS allows a faster design process. For example, the RS should have identified what data elements are needed in reports and calculations. The design identifies and creates a plan for the data structures, routines, and processes to satisfy the requirements. For many engagements, we develop nearly the entire documentation for the software - screens, usage, and reports - prior to any code being written. Moreover, the screens, usage, and reports are roughed out interactively through workshops. This approach enables changes to be made before the solution is implemented.
Step 4: Implementation
A solid design enables fast-paced and accurate implementation of solutions. Well-designed and well-specified solutions are easily distributed to multiple programmers for implementation.
Step 5. Testing
Having a detailed RS greatly facilitates testing and acceptance activities. Simply put, if the solution satisfies each of the requirements in the RS, it is a success. The RS eliminates ambiguity and enhances client satisfaction.
Step 6. Deployment
Once the solution has been tested it can be deployed to the organization. A variety of deployment strategies can be developed and used depending on the number of users and the design of the solution.
The six steps for successful solutions emphasize the power and importance of spending the time to define and develop the problem definition and an RS. Ultimately, employing work plans that encompass the six steps leads to faster, better, and cheaper delivery.