Criteria for Creating Project Artefacts

If I take a look at the people I follow on Twitter (currently about 1100) they fall into roughly several main categories listed here but not in any specific order:-

• Process and Quality Experts (including CMMI, ITIL and ISO specialists)
• Apple technical experts (including magazines and developers)
• Apple fanboys and girls
• Business leaders (non-IT)
• Musicians and other "celebrities"
• Journalists
• IT professionals

Out of all the IT professionals, nearly all of them are self proclaimed Agile practitioners, managers or gurus. Why do I mention this? Well mainly because I don't believe that this reflects the real state of the larger world where I suspect the Agile sector is much smaller than the more traditional development approaches. Even within the Agile sector, I suspect there are only a tiny percentage of people "doing Agile properly". Of those who do, most of them seem to spend most of their time on Twitter, so I'm not sure how much they really practice what they preach!

By and large businesses still run fairly old fashioned IT programmes and projects, and very often these projects follow quality management systems that are somewhat over-engineered and overblown. Personally, I think I fit somewhere between the two places - I don't count myself as an Agile practitioner although I was part of the DSDM movement many years ago, and I have an aversion to heavy weight development and management processes and methods.

Even with heavy weight process sets, most standards encourage tailoring of the process and the project documentation so that it aligns with the specific requirements of the project. In other words, you do what is necessary and ignore what is irrelevant. Quality and process 'experts' are on hand to assist the project or programme manager make these 'difficult' decisions, and to help the project team members create the project artefacts that are deemed to be required.

Which brings me on to the real gist of this post, namely that there is something wrong with this approach. If a project manager doesn't know what a specific project artefact or process is all about or cannot make a decision about whether or not a particular artefact should be created or process followed then there should be some serious questions about whether he or she should be managing a project in the first place.

This isn't aimed solely at project managers, but anyone involved in the planning and execution of a project, including developers, testers and business analysts.

For me, there are really only three criteria which should be used to judge whether a project artefact should be created or not.

• Does it add value?
• Will the project be at risk if it is not created?
• Do you know why you are creating it? (because I've been told to is not a valid answer)

If the answer to the last question is no, then the next question should be "Am I the right person to be doing this job?"


 .