Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Information Technology, Lessons Learned, Organizational Culture
IT Project Artifacts: Where is the balance between overhead and value
With the proliferation of Agile methodologies and the mistaken belief that Design Artifacts are not required, there is a real pressure on traditional SDLC to become more efficient.
Documentation transcends organizational change and can become the only consistency when projects are impacted by resource attrition.

We often create standard artifacts, which must satisfy large complex projects, however they become overbearing for smaller, simple ones.

Has anyone figured out the best approach to maintaining artifact standards while being flexible enough to drive efficiencies that make sense ?
Sort By:
Derek -

What we want to focus on is achieving the delivery and control objectives for capturing some info. Assuming teams understand those objectives, then let them pick the best method of capturing information - in some cases, it could be a flexible template which allows for tailoring or in other cases, it could be an online repository of knowledge such as a Wiki.

For every document, those involved need to understand its purpose and then encourage minimal sufficiency in its contents and production, especially for those artifacts which are byproducts of the delivery process.

Document the product, not the project. Project-centred documentation tends to waste time and effort and often impedes collaboration.

Build documentation incrementally and use wiki and collaboration tool based artefacts rather than static documents. Regular reviews and retrospectives are the best way to ensure quality documentation.
In some cases, you may be stuck with documentation that is very burdensome, such as if your product pertains to regulatory compliance.

When the documentation requirement is self imposed, those requirements may be written at a high level to ensure you meet the required functionality, without being overly prescriptive. Then, like a PM plan, you may tailor your process docs to suit your project

I have worked with processes that were developed for the very large program worst-case scenario. On smaller or less complex projects, we came up with "light" versions that met the functional intent, but eliminated a lot of unnecessary baggage. That was allowed because our processes said, "Your process must meet these minimum requirements." rather than prescribing the solution.
If somebody said that Agile is not about to maintain documentation or any type of artifacts then this person is totally wrong and this person will fail when tried to work with Agile approach. I am working with Agile from 1992 in software and non software solutions creation and, including today in my actual work place, we use all type of artifacts that are aligned to the key and seminal and foundational principle of Agile: quality. If you achieve quality then you achieve value creation in implicit way.

Please login or join to reply

Content ID:

"Doubt is not a pleasant condition, but certainty is absurd."

- Voltaire