Beginning with the End in Mind: The Solution Design Document

Imagine for a moment that you are building a house. You know you want 3 bedrooms, a functional kitchen, and extensive entertainment technology incorporated into every room. Go! Those are nice ideas, but they really don’t narrow it down much, and they certainly aren’t enough to communicate to the myriad of contractors, sub-contractors and trades. What would this house look like? Could your general contractor estimate on these requirements?

You wouldn’t expect such enigmatic ideas to be good enough for a construction project, so why would we expect IT projects to be any different? Most IT projects begin with similar vague ideas. Statements like “central information repository”, “seamless integration with the enterprise systems”, “easy to use graphical user interfaces”, and “improved business processes” are common high-level requirements. These types of statements are traditionally present in project charters and speak to the business goals. But just like that house you want to build, these are not enough to provide the required clarity to all of the stakeholders.

Enter the Solution Design Document

Sandwiched between the project charter and detail technical design documentation, the solution design document fulfills a critically important role in any IT project. Why do we need pretty pictures? What’s all this non-technical stuff good for? What does WebDAV mean? These are the types of questions I’ve received over the years and here is my response;

• It provides the big picture to a broad audience.
• It communicates what the outcome will look like and how it will be achieved.
• It provides sufficient detail to allow project sponsors to make informed decisions.
• It uses language that is not exclusionary or overly technical while at the same time contains detail to be of value to technical resources.