Project Quality Management 2/2

Click here to read Part 1 of Project Quality Management Continuing the list of ESA's one can expect on a normal project. These are:

2.0 Software Development

This will usually take place during the process of software development and include the:

• Use Cases
• Software Requirements Specifications (SRS)
• High Level Design (HLD)
• Software Design Documentation (SDD)
• Detailed Project Risks and Issues Log
• Detailed Project Plan

Whilst harder than the project initiation ESA this one is still one of the easier ones. Virtually all of the deliverables will be produced by those with business analysts skills and software development architect or team lead. Further at this stage of the project they should have had plenty of time to get this all documented and approved.

3.0 Testing

This will usually take place during the software testing life cycle and include the:

• Test Scripts
• Test Plan
• Entry and exit criteria
• Bug fixes or TIR's
• Defect Log

This is usually where it all goes horribly wrong. The test team will either not have had enough resources to do this work, be confused on the scope not matter how well the project scope statement was written, or simply do not have the right level of experience in the team.

If you get a red here then don't panic. Just make sure you have confidence in the test scripts and test plan written.

4.0 Project Closure

This will usually include the:

• Project budget
• Lessons Learned
• Project closure document

Okay I admit it. In 13 years interim project management I have only been through one of these. The reason being that Organisations which have a large amount of projects are simply unable to allow their experienced project managers to spend time closing projects down. In fact if you are any good you will find that hardly have you launched a project than you are immediately onto the next one which will probably have the business requirements documentation (BRD) already written.

Project Quality Management - Tip

I have consulted at many Organisations during my career. Most do not go to this level of depth for the simple reason that it adversely impacts project time and cost. However the public sector, offshore / external software consultancies and heavily regulated sectors such as defence, pharmaceuticals and lotteries will expect to see detailed project quality plans.

The key to remember is that your project can be of the best quality and still not deliver. Organisations want project manager's who can deliver, therefore try to ensure you have the lightest possible ITQA involvement with the least amount of ESA's because otherwise you will find your team leaders spending more time doing paperwork and not enough time managing project teams. And the last thing you need is a project paralysed with mountains of paperwork!

---