What do we suppose to do if the a user keep insisting the technical documentation is not details enough (even after many rounds of amendment)? Saving Changes...
Sort By:
John ZacharProduct Dev Manager| Association for Project Management (APM)Brackley,, Northamptonshire, United Kingdom
I think the real question you are asking is about requirements elicitation and scope management. The way I work is to establish what products or deliverables with satisfy the objective of the project, any CSFs tht there may be, and solve the problem. As I establish the product set, I aslo establish the acceptance criteria, which really has to come from the customer. The acceptance criteria really does establish fitness for purpose. Get that agreed, and then establish a change control process to control the scope. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Ron, it appears that the users believe they know what complete documentation is. Therefore have them prescribe the form of it and provide samples of what they believe is appropriate. Then deliver in that format and level of detail. They can't reasonably reject it then. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Ron, it appears that the users believe they know what complete documentation is. Therefore have them prescribe the form of it and provide samples of what they believe is appropriate. Then deliver in that format and level of detail. They can't reasonably reject it then. Saving Changes...
I think Michael is right: they're not giving you enough information to meet their unspecifed criteria, so you must elicit that critera, just like you would for the software itself. What is the purpose of the documentation? How can you measure successful documentation? Who will be using the documentation? What are their needs? What is the budget for producing documentation? Manage it as a "mini" project, set the scope, document the requirements and manage change to those requirement. Good luck, it doesn't sound like fun. Saving Changes...
Ron, this is a common pit that many companies fall into.
Jacqueline is absolutely correct. As an add-on to her recommendation: in addition to treating the documentation as a mini-project, think of it as a separate product else the documentation support issues will eventually catch up with you (whether the actual product changes or not). Can be a huge money 'pit.' Saving Changes...
Lots of good suggestions and hopefully a big lesson learned for your organization. On any project that has documentation deliverables, it is important to either provide samples of what you intend to provide during the project alignment, or to build in a documentation prototype (outline and a single section detailed) and review at the beginning of the development of any document. You have gotten yourself into a situation where you have allowed the client to continuously refine what they consider 'detailed' documentation to be. Obtaining some 'acceptable' documentation samples from your client may be your best course at this point. Saving Changes...
