Solution Specification

Heeding the Proverbs

Measure twice, cut once. Look before you leap. Better to be safe than sorry. An ounce of prevention is worth a pound of cure. We've all heard the sayings.

You need a plan before you embark on finding or building a solution. The type and content of the plan ultimately depends upon the need, and this is where a lot of folks get hung up. The challenge is approaching the problem without any undue pre-conceptions regarding what the solution will be.

A solution, and especially a technology solution, may be custom software development or software integration. It could be a matter of software selection or it may have nothing to do with technology.

Planning is a process. It takes both time and expertise. Before creating a plan, we recommend a solutions brief which documents the possible solutions with the costs, risks, and expected value of each. The brief can provide much-needed guidance on the approach to a given problem before too much time or money is invested in a favorite solution that isn't actually the best choice.

Minimum Viable Documentation

A software development plan includes the what, the how, and the when. A project charter documents the why.

Measure twice, cut once.

A Proverb

What constitutes good documentation for a software project? We tend to think in terms of minimum viable software project documentation. Too much documentation takes too much time to create and consume. Too little documentation means the developers are starved for the detail that makes for a healthy project.

In general, this includes five documents:

1. Functional Specification (what): A functional specification describes the expected functionality, including roles/personas, stories/use cases, and supporting documentation such as processes and flowcharts.
2. Technical Specification (how): A technical specification pertains to the actual implementation, including the overall architecture, data models, multi-tenancy requirements, and the technologies employed.
3. Project Plan (when): The project plan includes a breakdown of the work to be performed, the estimated level of effort, and a calendar schedule. The plan will also define implementation guidelines and the methodologies employed.
4. Design Brief: A design brief supplements the Functional Specification to provide color and style information, wireframes, and mockups.
5. Product Plan: The product plan provides guides and processes for testing, release, maintenance of the finished product. The plan may also specify the required end-user documentation and how the product will be supported.

Build Versus Buy

Often our clients come to us because they can't find an existing solution that meets their needs. But sometimes an existing solution might be perfect -- or at least good enough.

We offer a specification, research, and guided selection process to help identify existing products and the objective evaluate of their suitability as a solution.

If no product matches the desired return on investment, the client has the option of proceeding with a full specification to determine if a custom project is the better solution.