The Five “W”s of Documentation

The real challenge to all of this is modifying old habits and developing the discipline of great note taking. OneNote should be the go-to resource for capturing requirements at the initiation of every project. Recording information in real time with project stakeholders is hugely beneficial in defining project expectations. Listening to End Users and integrating their ideas in the process builds confidence in the project success, which transforms into user adoption upon completion.

Note

Make it simple. Everyone knows that if documentation demands become too burdensome or tedious, it will not happen. Some may feign time restraints in resistance to use, but what they may not realize is that using that time wisely today in the form of effective note capture can be a real time saver tomorrow! At the very least, capture the absolute basics, most of which can be documented at that project initiation meeting.

Record the who of the project. Which people, group, or team will benefit from this solution? Include titles along with names, because employees change, and those supporting this solution three years from now may not know Joe the same way you do.

Document the what with a simple description of the anticipated solution and any of its unique characteristics. This one may take some brainstorming, or it may be hammered out at that initial stakeholders meeting. Is this a multistep workflow, an InfoPath form, or even just a slick way of dealing with sensitive information using tricky filtering techniques and some simple disposition workflows? Consider which bits of information are most necessary for supporting this solution in the future.

Where is this thing on the site, and what permissions are unique to that location? Simple enough, but imagine the unlikely scenario in which a solution is abandoned and years from now someone would like to know more about it (can it be deleted, or does it actually serve an archiving role of some sort?). A simple search on the URL in OneNote should surface some notes.

Similar to what, why pertains more to current process. Why is the current solution no good? What are people doing instead of using SharePoint? The why can also tie into ROI (return on investment); how much time is wasted doing it the current way? Take a moment to record ROI on those inefficient processes whenever they come up. Showing hard savings is sometimes a challenge, but can lead to justification for the creation of new SharePoint positions.

When is this thing going to be ready for use? A go-live date would be handy in the future to examine how long a list or library has been in existence, especially if disposition workflows are deleting all items that are 24 hours old.