by Donna Fitzgerald | September 16, 2015 | Comments Off on A Minimally Viable Process for Project Documentation
The amount of process and project documentation are usually problem areas that IT PMOs struggle with in their efforts to become more agile or to support ITs move to bimodal. While every situation is somewhat unique, it occurred to me that much of the problem could be solved if both the PMO and the Agile teams agreed to meet in the middle and define a minimally viable “process” around how much documentation is actually necessary.
To have this discussion we need to start with the Agile Manifesto which asserts
“Working software over comprehensive documentation”
Notice the word “comprehensive” in this statement. The Agile manifesto does not say “we don’t need no stinking documentation” (and yes I’ve actually heard the latter statement out of development teams). It says we need to focus first on working software and only secondarily on comprehensive documentation.
So the first step I would ask of an IT PMO is to first go back to core principle and separate the SDLC documentation from the project documentation. Approach this first as a mental exercise. I know of one organization that had 50 plus mandatory documents. Obviously all 50 of those were NOT project documents but because the PMO was the control point in assuring they were complete, the PMO was saddled with the perception of being “slow, bureaucratic and unresponsive”.
The second step would be to review the project documents that are currently required and ask yourself exactly what value they really provide. I normally end up spending most of a 30 minute call discussing how to determine value with clients so I’ll just say that my own short list of documents I insist on is 1) a statement of scope, 2) a dependency linked schedule, 3) a budget, 4) a change management/stakeholder engagement plan and last but certainly not least 5) a risk mitigation plan.
Step three would be to sit down with representatives of the Agile teams in your organization and ask them if it’s possible to agree that the THINKING involved in these (5) documents supports the development of working software. You’ll generally get some pushback on the dependency linked schedule but a project that is not larger than just software development shouldn’t be your concern, so this shouldn’t be an issue. (If it is then your projects are too small and that is a subject for another blog). Once there’s agreement on the thinking then negotiating the format becomes a discussion you can have with the PMs who are running the project.
Respect and understanding of what the Agile teams are actually trying to accomplish will go a long way toward helping reach agreement. Also by adopting a language that is a key part of the Agile lexicon you communicate that you know enough about the core principles of Agile to tailor your vocabulary to theirs. Give it a try and let me know if it works…
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.