Championing document management and document quality, part 1

Consider the idealised world in which work is undertaken to a high standard with a minimum requirement for supervision by the project manager, where project communications are well managed and self-sustaining, where product handover is almost a formality, where all project stakeholders can independently source the correct information they need, when they need it with little need for involvement from the project team, where all project resources are enabled to work independently towards the management of risk and quality. Consider a world of high performing project teams and projects which take on some of the characteristics of a repeating cyclical process and where project managers can manage by exception. Sound too good to be true? I don't think it is.

I'm going to return to this theme of "projects as BAU" (business as usual) in the coming weeks, but I'm going to start with what I consider to be the single biggest step that an organisation can take towards a more stable footing for its project activities, namely high quality documentation supported by high quality document management.

I'm going to take another look at the points in paragraph 1.

• High standard of work, undertaken independently - enabled by the authoring of high quality work packages, peer reviewed and agreed with the named project resources who are to do the work. The work package's deliverables should be detailed, reviewed and approved product descriptions which relate back to the WBS. The approach to quality should be stated clearly
• Project communications which are well managed and self-sustaining - enabled by a collaborative approach to the generation, publication and sharing of high quality project products (PID, Brief, Communications Plan, Configuration Management Plan etc). Usually there isn't the time to spend on these products that they demand because everyone is too busy managing email. This in turn is because they don't have high quality project products published to say, SharePoint.
• Product handover is a formality - enabled by detailed, reviewed and approved product descriptions and a rigorous approach to quality (V-Model for instance)
• Where project stakeholders can independently source the information they need - enabled by getting out of email, getting into documentation and publishing in a collaborative platform (SharePoint, SameTime, Exchange Public folders, or your own document management platform)
• Project resources enabled to work independently towards the management of risk and quality - enabled through project resources accessing and sharing information about all aspects of the project - they're not just compelled to raise a risk or an off-specification. They can actively manage, own and control outcomes because they're equipped with the knowledge to do so
• Taking on the characteristics of repeating cyclical processes - almost every project will have some repeating cyclical processes, whether it's moving servers between data centres, packaging applications or designing web applications. Assess whether a process will add value*. If it will, work with all parties involved to generate a process which is shared, owned and understood. It doesn't necessarily need to be perfect, that will come later.

* I'll post something on this in due course.

I don't offer this without the benefit of seeing both sides of the fence and also the consistent and tangible improvements resulting from transitioning from one state to the other.

I'm not going to belabour the matter too much here  although  there are some perspectives relating to proportionality which I'll pick up another time. I think the points above are self-evident. I hope you do too.

If you want more information generally and a bit of structure you might try this from JoAnn Hackos