September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
I suggest you use the risk assessment approach. Determine what documentation is necessary to mitigate the risks associated with lack of documentation. Coming from a contract management perspective one of the main risks is not being able to defend against a contract claim due to lack of information or record of what has transpired.
So, ask yourself what could be the result of no documentation, what risks could arise, what would be the impact, can the project tolerate the risk and what can we do to mitigate.
Only record and document what is necessary to address the risk of not doing so.
Documentation needs are driven by 3 things:
1. Regulations, policies & standards
2. Addressing control objectives for risk
3. As a means of conveying information between team members
#3 can be made as lightweight (or even non-existent) as needed, #2 will provide the "what" and the team can figure out the "how", and #1 will just have to be lived with :-)
Jonathan, no documentation is not good, no matter what project one is on. The amount of documentation required would depend on the demands from the project. I've heard the odd person say, "Who ever reads the documentation". I've heard others say, "How does this system work, where is the documentation". When the deliverables and work are measured, based on the project objectives, shouldn't these results be documented? At a bare minimum, like Peter said, you need documentation to mitigate the risks associated with lack of documentation.
Forgive my English.
Documenting is not recording facts but showing processes.
It is not a profession, but an attitude towards life: a mentality rather than a technique.
The documentation that interests us is the one that makes the learning processes visible and, consequently, demands from whom the practice ask questions about what to highlight, how to show it and where to do it. All three questions involve a deep understanding of what we did and where we are headed.
I start with the question:
"what do we need to communicate during and after the project"?
I believe this will naturally pick up all points from Peter, Kiron and Marcus, ** to the degree necessary **. After all a document should have a purpose and if the only purpose is "tick or check a box" then the process (and therefore the document) is essentially valueless (and, no, meeting regulatory requirements is not valueless - it is covering a risk as Peter suggested - even if the purported quality or other value intended by the regulations is not really that great).
Also note the 2nd Agile value:
"Working Software (system/process/outcome) Over Comprehensive Documentation"
That depends on (1) Industry, (2) Regulations (by government and corporation), (3) Size and complexity of project, (4) Management Methodology and Product Delivery Approach, (5) Tools for Management & Collaboration, (6) Your company maturity and (7) Agreements (between parties).
Kiron is spot on. What MUST you document and what do stakeholders WANT to know.
A lot of good comments thus far. Just two foot notes:
1. Project documentation is not limited to project governance but also to the documentation generated throughout the project. In this case, the pharmaceutical industry follows the principle "what is not written it doesn't exist".
2. The documentation management system is just as important as the documentation itself.
I'll take a value driven view:
What documentation in which format is needed to create value for the stakeholders, users, maintenance guys, operations, sales, marketing etc., and in particular the product is enabled to provide its potential value.
Look at a sustainable product architecture, which will include valuable information for those who want to improve the product after two years?
And if you create a product and now it is to be used by users, a change management effort will require additional needs to create documentation, like training manuals, FAQs, selling pitches and so on.
BTW in construction, the use of BIM will include the creation of up-to-date and historical data about the product, as part of the system and from the views of different stakeholder views.
Those that helps you to demonstrate to your stakeholders that the project is creating "what you need is what you get" in the framework of organizational governance.
Please login or join to reply