In this component of your scope document, you say (on a general level) how you'll go about creating the deliverable(s) for the customer. You present the order in which you will execute the project's phases in order to produce the deliverables. Outlining your strategy is useful for other nontechnical eyes, because often one who has no clear feel for the technical direction of a project can still point out logic errors in the way you' re going about project implementation.
In defining how you' l l create the deliverables, you need to communicate with a wide variety of people and avoid "computerese" if possible. Dor example, suppose that you' re going to create a client/server application using Visual Basic running on IBM DB2 for use on a Domino server. Most nontechnical stakeholders aren 't going to have any idea what you ' re talking about. So you need to communicate clearly about how you' re doing what you ' re doing and why the tools you' re using are being used.
Using this Domino Server example, you could say, "We ' l l be using Microsoft ' s software development environment, Visual Basic, to communicate with a database we've created using IBM' s DB2 database system. The entire thing will be hosted over our Lotus Domino e-mail system." Now, you' ve defined the specific product names you intend to use (very important because you cannot switch horses in midstream—better to get this dialog out of the way right away) and how you intend to deploy. However, customers may have no idea of what you just said.
Working harder to make this more generic, yet explanatory as to how you re going to go about doing what you intend, you might further refine the previous statement this way: "We ' re going to use Microsoft ' s Visual Basic software to set up some data-entry screens to communicate with a database. We ' re going to create the database using another product—IBM' s DB2. Once we' re done with the screens and the database system, we ' l l put the whole thing on the Lotus Domino e-mail system so it can be used via e-mail. Once we 've put the data-input screens and database up on the e-mail system and we ' ve tested it, we can safely say that we ' ve 'deployed' the system."
The creation strategy doesn' t name the products and tools that make up the deliverables themselves. You' re talking here about the tools used to build the deliverables. If the deliverable is a table, the creation strategy can involve lists of steps (1: Draft design. 2: Cut wood. etc.), parts (x boards of length y), and tools (circular saw, wood glue, sandpaper).
Customers aren' t generally interested in your deliverable creation methodology; they ' re interested in how well the deliverables function. Keep your deliverable creation strategy high-level in the scope document, and communicate with stakeholders at an extremely basic user level so you don' t confuse them. However, it is still important to detail the hows and whys of deliverable creation. I' d recommend giving an executive summary-style overview of your deliverable creation strategy, then take a couple more paragraphs to provide detail for interested readers.
Communicating in this way, you' l l still be left with one of two types of questions: those that are more technical in nature, from people who have a high technical expertise, or questions from those who don't understand the basest of the terms you use and need further clarification. But you ' ve defined what it is you ' re using and how you intend to use it, and you did it with not many more words than you' d use if you were simply to state the tool, the database, and the server product.
Communication is the most important element a project manager can be involved in. It is critical that stakeholders are always apprised of all the important changes and thoughts regarding the project.
Was this article helpful?