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.

The Catalyst for Team Dynamics

Let’s put tactical details aside for a moment, and discuss some of the less obvious advantages to the solution design document. The solution design document is first and foremost a communication tool and represents synergy between what the customer wants and what the technical teams can deliver. Simply going through the process of creating the document results in team building and stakeholder buy-in. Rather than a solution magically emanating from a single source in some back room, the solution is the result of a collaborative effort. In fact, the hidden value of the solution design document is in the relationships that result. If executed successfully the process can set a positive tone for the entire project.

It needs to be usable - In the same way that a web site needs to be usable for the intended audience, the solution design document needs to usable for a broad range of individuals. With the primary goal for the solution design being communication, the language used must appeal to your audience. The old adage, a picture tells a thousand words, is still true. The inclusion of diagrams and mock ups makes the communication richer and broadens the appeal.

It needs to be flexible - Every project is different. The knowledge/experience of project stakeholders varies from project to project so the solution design can’t be a cookie cutter format. More experienced stakeholders may want more technical details and less high-level stuff whereas the uninitiated may need more approachable content thrown in. Gauge your audience and communicate to them in a way they can understand.

It needs to strike a balance - Don’t try to nail down every last detail or you’ll end up in paralysis with diminishing returns. The content of the solution design document needs to be accurate but not prescriptive. It should provide the framework within which more technical decisions can be made as the project moves ahead. Again, it is the big picture that everyone agreed on and guides everyone in the direction we all agreed to go.

It needs to be iterative - Iteration is imperative! Team-wide participation and review of the document is key to the relationship building opportunities and will ensure the resulting solution design is jointly owned by the entire team. Of course, an iterative process will also result in a more well thought out solution having facilitated participation from the most senior stakeholder to the most junior technical resource.

Can we be successful without a solution design document? Perhaps, but skipping this step means you will miss the opportunity to develop quality relationships. If your project starts to go south it is a lot easier to get it back on course with a team that is familiar with each other. This is especially true when everyone charts the course together. Furthermore, without a solution design how would you know if your project was going south in the first place?

- Paul Garden, Portals & Collaboration Consultant

Follow @Ideaca