Project audits

New product project audits are not the same as lessons learned. Project audits are performed by external teams (objective outsiders) who have not been part of the project process. The audit has been described as "the process of coming down off the mountain after the battle to kill the wounded." Such audits can be useful if they address issues that have already been identified by the project team. The purpose of an audit is to connect factors that contributed to project successes and failures based on documents and recorded information, and to match the project outcomes with project goals and objectives.

Performing a risk lessons learned review. A lesson learned project review should be conducted soon after project closeout, and should include all project team members, a member of top management, and stakeholder representatives. The focus should be on identifying what went right and what went wrong—and dimensioning what went wrong in terms of unanticipated or unmitigated risks and uncertainty. This can be accomplished by scheduling and facilitating the meeting around key risk issues or topics that help to capture the risks inherent in the project. The following is an example of an outcome report from a risk lessons learned session in a modern avionics instrument product development process.

Example of a lessons learned report. What went right (things that we want to recreate for future projects)

■ This was a focused team with largely full time assignments

■ Our team was autonomous: we drew the line with the customer for appropriate "windows" for changes, disruptions, etc.

■ Little or no scope creep

■ Resources (e.g., test equipment) allocated to resolve problems quickly

■ Contingency plans in place when necessary

■ Team defined its approach to documentation, etc., together, "as we went" (also noted as a weakness below)

■ Communication within team was good

■ Consistent high priority on this project from corporate: this was a high visibility, high priority project from the beginning, and we knew it

■ Responsiveness of team members to each other very effective

■ Project itself was not technically insurmountable; success was feasible

■ Team able to separate what was controllable from what was not, e.g., flight test, and managed accordingly

■ Team was highly proficient; good professional and technical skills

■ Scheduling process handled resource issues somehow

■ Program manager was open to change; flexible in responding to team issues

■ Program manager used schedules as guides, but was very task and action oriented in meetings

What went wrong (things that we want to correct for future new product projects)

■ Company process and procedure requirements, and differing interpretations of document requirements, sometimes acted as barriers to necessary work, and did not always facilitate successful completion of the project, e.g., software documents, reference documents, tables

■ We sometimes described procedures after we completed them instead of before; documentation often followed verification rather than guiding it, e.g., STD checklist

■ Confusion and uncertainty in the actual application of ISO, FAA certification procedures on the one hand, versus "actual" procedures that the team decided were necessary to get the product out on time

■ Company changes (split) created resource issues; we had to "ad hoc" it in handling engineering change notices, assembly drawings, etc., because of resource problems created by the split and loss of staff

■ Document numbering system created a lot of tension and uncertainty

■ Training needs: staff involved in the project were not always trained to carry out procedures, e.g., staff loading the boxes did not have good guidance and training

■ Ineffective version control on some documents and configurations

■ Stress created by long hours was a problem; can't stretch people and expect them to stay on

■ Schedules were not accurate in many cases, compared to the real work, e.g., the sequence of tests and dry runs

■ Sometimes the team did not have the "big picture" on the project; sometimes the big picture helps to facilitate doing your job

■ Wasted time in some meetings; meetings had agendas, but there were times when the team "blew off steam" and wasted a lot of time

■ Some residual issues rooted in "military" versus "commercial" approach had an impact on the project, which came in the middle of the transition from military to commercial methods

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment