A Design and Specifications Document (DSD) is a supporting document to the Product Scope Definition and the Work Breakdown Structure (WBS). More than that, it is a major source for decisions regarding the purchase of materials and equipment, as well as, features and functions that will be used and installed as a part of the project. As you may or may not know, the WBS definitions are usually used to provide some of the details regarding materials and resources; however, many projects are quite complex with a lot of details that simply referring to the WBS definitions will just not be enough information for the persons performing the actual work. This is where a DSD comes into play.
What is it and what is it used for? How do you know how long the project will take to complete and how much it will cost if you don’t know all that is desired and required inclusive to the output of the project, in terms of a product or service? You can’t create a true, complete and accurate WBS and further, the Work Package Authorization (WPA) information without capturing all the design and specification requirements for the project and product/service/outcome. Of course the potential volume, in numbers, of the specifications is dependent on the complexity what the project is to produce.
DSDs come in many forms. They may even go by many names depending on the nature of the project and the naming convention preferred by the organization and industry. Various names used for software projects include Technical Design Document (TDD), Software Design Document (SDD), and System Design Document (SDD); Architectural/Construction projects may call it a Detailed Design Document (DDD) and Telecommunications projects may call it a Technical Design Document (TDD). For the sake of simplicity I will use the acronym DSD as all inclusive of any form of detailed design, specification and functionality document during the remainder of this discussion.
Detailed Specifications for all Features and Functionality is the key concept in a DSD.
It’s important to note that, when specifications only give the parameters required and not the actual equipment model, material resource name, etc., a cost range or maximum allowance cost, must be included in the parameters and specifications description. For example, if the project involves an upgrade or new installation of computers, software, and video conferencing equipment for a high-tech classroom; and, if the client doesn’t know exactly what type and brand of equipment they want, or they only know what functionality and specifications they want for the classroom, in this case, after collecting all the functionality and specification requirements the PM and techie project members make a recommendation as to what the client should consider for the minimum and maximum cost/budget range to write into the DSD. In this way, you still have a known budget to work with when researching and making final recommendations to the client for the selection and purchase of equipment and materials.
Where does it fit in the project lifecycle? Whether you follow the Project Management Institute (PMI) [Project Management Body of Knowledge (PMBOK)] or the Department of Defense PMBOK version, the common philosophy is that scope development and definitions fall into the Project Scope Management and the Planning Process Group that include: Plan Scope Management, Collecting Requirements, Define the Scope, and Creating WBS. The DSD and the WBS also directly influence the monitoring and controlling process group with validating the scope and control scope.
How is it created? It begins with the Product Scope and then to a first draft of the WBS at the first two or three levels. At these first two or three WBS level you will start to find product elements or features that may require detailing in terms of features, functions, and requirements. Work to create the WBS and the DSD will switch back and forth between the two until the customer/client/user/sponsor/project team and PM are all satisfied that the documents fully and completely represent everything that is “In (Product) Scope” for the project. If it’s NOT in the WBS and the DSD, it is NOT In-Scope or in the project. Once the DSD is completed – get the client/customer/sponsor authority to sign it as approved or acknowledged. You will have then provided an anchor point for the start of the change control process.
Project versus Product
Let’s now continue by clarifying a few things regarding the use of the word Project versus Product. A Project, as you know, is a temporary endeavor that has a defined starting point and an end point that “produces” a specific “product or service.” Product(s) and Service(s) are outputs of a project. Products are not the project; and the project is not a product. The output of the project is a product(s) or service(s) with its own desired design and specifications that are used to define and refine the Product Scope, the WBS, WPA, materials and equipment procurement.
- Project Scope: The work that must be done in order to deliver a product with the specified features and functions. Completion of project scope is measured against the plan.
- Product Scope: The features and functions that are to be included in a product or service. Completion of the product scope is measured against the requirements.
What if the Client/Customer does not know what?
If a client/customer/purchaser desires a new product or service but doesn’t know exactly what they want in it in terms of features and functions, and the project is still going to go forward without this product scope information, you will not be able to provide realistic or accurate schedule and cost estimates. You might be able to provide relative cost/time estimates for pieces and parts of the project but not for the entire project. That being said, it does not preclude a project from moving forward. However, in regards to procurement and contracts, projects with these circumstances should be performed as either:
- Cost Plus Contracts: Used when the product is less defined as a way of sharing risk between the buyer and seller. This includes reimbursement of both direct and indirect costs. Direct costs are salaries, material, and services for project; while, indirect costs are usually seen as overhead, purchasing, administration and undefined operational support expenses.
- Time and Materials Contract: Contractor(s) is paid for labor at pre-established rates and reimbursed for the cost of materials. Subcontractor(s) labor is considered material.
What is in a DSD?
DSD may include, written descriptions, tables, charts, diagrams depicting the product (and sometimes project) specifications. It may include appendixes or attachments with referenced from the main document, to provide more narrow focused details smaller or sub-elements of the design.
DSD for software products will contain all the descriptions and requirements the software team need to develop the architecture and coding for the software project. In website development, the document may include details regarding the webpage layout and content, any interactive elements or data entry fields, how user entered data is handled – what happens to it next, links to other sites and how advertisements will be managed. Either in the main document or in an appendix, there must be instructions and specifications for how users will interface with the product. There should also be appendixes for user training requirements, “Help” menu support, “Contact” support, etc.
A DSD for an architecture and construction project will include construction/building design, structural building requirements, building materials requirements, and can be as specific as to provide a list of all window type, size and brand; include a list of door hardware; may include design instructions for automated security system; signage requirements; power generators, location for utilities, just to name a few.
Who creates the DSD? The Client/Customer/Sponsor/User has the most significant responsibility in DSD creation; however, usually, the PM as facilitator, the Project Team and representatives from the client/customer technical/user group will work together to collect, assembles and creates the document. This can take a lot of time to accomplish.
Who manages it? The Project Manager and the project team.
Here is a very simple example of the difference between a project scope statement, a product scope and into DSD requirements. Even with a bit more definition in the product scope statement, there is still a lot of unknown and unanswered questions yet to be resolved.
- Project Scope: Convert a 10,000 square foot warehouse into a research facility.
- Product Scope: To have a new 10,000 square foot research facility for new product development; inclusive of office spaces for 12 employees, research lab and meeting rooms.
- DSD Items: Just a few basic items in the DSD for this product scope could include: Internal structure requirements of: four 200 square foot offices; eight 140 square foot offices; two 300 square foot restrooms: one male restroom and one female restroom; both with shower facilities; one 400 square foot break room; one 400 square foot meeting room; one 200 square foot meeting room; one 100 square foot records vault with high security electronic lock; External facility design includes entry/exit on all four sides; electronic key card with pin-number entry for exterior doors; security cameras covering all exterior doors and windows; interior doors with cark key entry pads; interior security cameras monitor entry/exit doors; for exterior camera’s use Acme Super-Dooper All-Weather Camera Model 1235xyz; for interior cameras use Eye-Spy Camera Model 6789; Use Honeywell electronic keyless security system with Keypad Model 2468; so on and so on…..
- In a project like this, it is advantageous to break the DSD into sub-functions of Exterior Structure, Interior Structure, Security System, IT, and Communications, for example.
- I worked on a software developed project that took six weeks to complete the DSD. The project team and the client/users collectively worked as one group, meeting every day Monday through Friday for eight to ten hour days hashing out every requirement, formula, calculation, graphic interface design, reporting requirements, data relationships, user training and user manual requirements.
- Our project team and the client/users divide the DSD into headings based on various functional areas of data design, data objects, data structures, architecture design, interface design, calculations, reports and procedural design.
- The effort was worth it – Once the DSD was completed and signed off by the customer/client/sponsor, it became the anchor for the WBS and the Product Scope. It allowed me (as PM) and the project team to develop a more accurate and predictable schedule with associated cost estimates. And, it made change items as well as potential risk items easier to recognize and manage (Change Control and Risk Management).
Sum-up: Remember the old saying, “If you fail to plan, then you plan to fail.” The DSD needs to be an anchor for the development of the product and along with the WBS, serve as a foundation for change management. Failure to capture at the outset of the project all the features and functions the customer/client/user requires in the final product will result in continual changes throughout the project, added costs, increased schedule times, and unnecessary stress on all parties.
More on Leadership, Team Building, Change Control, Problem Solving, Meeting Management, Interpersonal Communications, Project Scope Statement,Project Charter