Aneesh web pic for blog

Aneesh started his career in 2007 as a Business Analyst and joined IMA in 2013. He brings tremendous energy, focus and initiative to his job as a Business Analyst. When not solving client’s problems, he spends his time driving around the suburbs occasionally taking out his camera for a snap or two .

Documentation has always been a part of formal project management practices. There are many layers of documentation that get created. The three types that are normally done are:

(a) what is to be built
(b) how is it to be built and
(c) how the project is to be managed.

But often, documentation ends up being a task that is to be completed before ‘actual’ project execution begins.

Many IT projects involve multiple stakeholders and draw upon diverse skill sets of many project team members. The team may include project managers, technical and business architects, business analysts, developers, testers and change managers. The project is often governed by committees whose members may be involved in many projects.

Team Members

The members of the team then interact as required with the client who itself might have a hierarchical set up for approvals for requirements, testing and deployment. The role of each member of the project team and the client varies at each stage of the development life cycle and the stakeholders must make necessary adjustments as their roles changes.

Project Management Office

PMOs usually ensure that projects are well managed by implementing project management standards and procedures and often mandate various project management documentation in the belief that all well managed projects need them. The detailed documentation of the schedule of activities and expected outcomes/deliverables with timelines provide immense value from a management perspective. Mandated documents and their structures enable anyone familiar with them to quickly find information relevant to them on any of their projects. It provides an easy frame of reference for any project team member to assess his own role in light of a plan and prepare for the road ahead. Such documentation is especially relevant in projects requiring services of specialised consultants who are called upon in the project at appropriate stages and their roles could be limited to that particular stage. The project and programme management is also clear on the artefacts that are to be expected at any point in the project life cycle which results in efficient deployment and utilisation of project resources.


However, there are cases where projects with comparatively smaller budgets generate these documents for the main reason of complying with the PMO and in the process spending scarce time and budget in documentation. There have been instances where it consumes a significant percent of the project duration and cost. It may also delay the project implementation in some cases.

So the moot point here is what level of project related documentation is optimal. The most logical answer seems to be “It depends”. The value of such documentation needs to outweigh its cost.


At this point I am sure that many of you will think of Agile methodology as a possible alternative because of the preference given to deliverables over documentation. However not all business domains and industries have adopted agile as a preferred model and agile does not suit many projects and businesses.

Consider Parameters

Various parameters of a project like complexity of implementation, budget, duration, headcount etc. could be considered as inputs to derive a subset of the exhaustive list of project related artefacts. This sounds sensible as there seems to be no point in developing a whole gamut of project management documents to develop a website with just a handful of pages whereas it might make perfect sense to have all of the artefacts in a project aimed at developing an online student enrolment system for a big university.

In case of significant overlap of information in multiple documents it would be a good measure to amalgamate one or more of the documents into a single document. If there are various small projects which are executed under an umbrella programme, it might be possible to have documentation at the programme level. This will reduce the number of documents considerably. Projects in an organization could be categorized based on some of the parameters mentioned above and the artefact requirements could be defined for these categories.

To conclude, it is important to strike a balance on the level of documentation is required. For each project, what is appropriate might be different. Each document that is prepared must have a clear answer to the question ‘what is the value it adds’. This paper is only a flagging of the issue and suggesting some directions for change in broad brush strokes. Greater analysis of project management practices and methodologies is required in this area.