Topic 1.9: Project documents

Likes people like this topic - including you!

SharesThis topic has been shared 25 times!

Progress2,639 people have passed the quiz

Project documents - which are known elsewhere as organisational process assets - are the lifeblood of any project.

Although they are increasingly being raised in dedicated project software, many organisations still use word-processing or spreadsheet applications to maintain them.

The following infographic shows the point in the project lifecycle when they are typically developed or delivered; however, this is a loose categorisation.

Each may in fact be developed earlier and/or used later, depending on the needs of the project.

Templates can be a great aid to projects

They help guide more junior team members through the planning and reporting processes, ensuring that they capture vital information.

They are one way that organisations can educate staff on the importance and need for capturing certain information.

Templates can be valuable for more experienced project managers, too.

They provide structure and act as a checklist for data that needs to be captured, so it is less likely that something will get accidentally overlooked.

They also speed decision-making by presenting information in a consistent, relatable format.

That said, sometimes all a good project plan does is document your failures with greater precision.

Although this scenario is the exception, it is possible to have a perfectly documented project that somehow finds a way fail.

Importantly, project documents should support and enable project delivery, as opposed to getting in the way.

Sometimes the constraints of documentation can frustrate the work of the project. This will manifest as general inefficiency, missed opportunities and poor staff morale – don’t be overly bureaucratic!

It is also well documented that using the same format or template over and over can cause users of the output to miss important items that may need to be included.

In the same way, ‘save-as’ syndrome – where new plans for a project are just copy-and-pasted version of a similar project – can not only cause errors to be repeated, but stagnate independent and creative thinking.

It is important to note that while following a documented process may be a minor nuisance to the project team, the positive outcomes enjoyed by all stakeholders usually make the process worthwhile.

That said, not every process needs to be used on every project.

If using a template adds time to a task because you are doing so much modifying and deleting while trying to shoehorn your project into the defined format, then you need to either seek advice or let it go and start from scratch.

Keep the end in sight – challenge the value that each process delivers relative to the objectives of the project and your organisation

We will address this balance more directly as we move through the program; for now, though, recognise and appreciate that a project structured around some key, enterprise specific documents can bring the previous stated benefits of methodology to the organisation and the team.

Other documents that may support the project plan include the more static policy guidelines of the your organisation

A policy is a set of rules for doing business (how we do things); whereas, the documents we refer to here usually encode a specific set of actions (what we do)

Policies stipulate, among other things, communications strategy, procurement strategy, staffing procedures, and change control processes.

Policies should also be regularly reviewed and updated

Within these policies, you might find direction on (for example) delegated authority or spending limits, agreed methods for conducting estimating or risk analysis, escalation processes (in other words, where to turn when things go wrong), and items like presentation style guides and glossaries of common terms.

Because these guidelines are usually specific to the performing organisation and the projects it delivers, we do not attempt to definitively list them all here.

That is not to say, however, that policies are not important – like any organisational process, they constrain what you can do in your project, but also offer you valuable guidance and support.

Policy development is best considered in the context of programs and portfolios of work. It is beyond the scope of a project management course. If you do not have clear project policies in your organisation, then try Googling standards to find what best suits your project context.

In the absence of specific policy guidance from your organisation, we will introduce you in this course to a number of good-practice project documents that you can align to the policy context of your organisation and the projects it delivers.