Journals by RSS
Journals by EmailIn one of the applications I work on, we have been dealing with a rollout to different countries where their overseeing offices administer some of the procedures. This has made me ask myself again, “How much of the policies and procedures external to the app do I need to document?”
If policies are at all involved in the procedures accommodated by an application, I find it difficult to completely avoid documenting some of them. Especially when certain practices are preferred out of several options provided in the application. It’s easy to step over the line from strictly talking about how the software works to talking about why it’s designed to work that way. The why is generally to meet policies and procedures.
In this particular project, I’ve generally avoided bringing policy into the picture unless the stakeholders really want something highlighted for the users. This saves me some trouble because of the fact that the application will be used in offices around the world, and they are of course subject to the laws of the countries where they’re located. It would be a full-time job trying to keep up with everything, especially when governments change policies.
There are also policies in the stakeholder department that have to be considered, and those can change at times, too. The more change, the more the documentation has to be updated, and usually I have enough change from ongoing development to keep up with.
Though business processes and policies are closely connected with the software created to meet their needs, I think it’s best practice to keep separate the documentation of the two. Have a policies and procedures document, and then keep the software documentation separate. Sure, they ought to refer to each other.
For example, in the policies document:
“Offices should use the Web-based DoorStop System to keep track of the time that the front office door is open during business hours. For information about using DoorStop, see its online help.”
In the help:
“The corporate office has provided the DoorStop System for you to track how much time the front door of your office is open during business hours. See the Office Things Corporation Policies and Procedures for information about this policy.”
Of course, this preference is better for environments where things change. If your business processes and policies don’t change much, it may be better for the users if the how and the why are covered together, or at least are provided within the same document.
Related posts (auto-generated):
