roymoggadmin
02-25-2008, 10:57 PM
Project Audit – Solomon
The primary purpose of a project audit is to find the reasons for apparent failings in the project process, and answer:
What is the current state of the project
Is the project going to deliver something useful that meets requirements?
Is the technical approach being used still appropriate
Is the business case still valid?
Is the project organised in an effective way
Is the project context hindering or helping progress
Are industry standard project processes being followed
Is the project following industry best practice development methods?
ŕ What should be changed to improve the project focus?
The output of a project audit will be the answers to these questions and a practical assessment what can be done to improve and fix problems?
Areas of investigation
Project management
Does the project communicate effectively with its sponsors and other stakeholders
Are decisions taken rationally and quickly?
Does the management team have appropriate skills and experience?
Project organisation and staffing
Is the project divided into effective work units (teams)?
Is there capacity within the team to handle the workload?
Are the teams located appropriately?
Are roles and responsibilities identified and clear?
Are internal and external communications effective?
Does the staff have appropriate skills and experience to do the job?
Is staff working in a suitable physical environment?
Project processes
Are project controls in place?
How are work-packages identified and allocated?
How is progress managed?
How is change managed?
Is proper version and configuration management in place?
Project planning and reporting
What kind of plan is there?
Is the level of detail appropriate?
How has the plan been validated and agreed?
How is progress against plan reported?
Where is the project against the agreed plan and what are the reasons for deviations?
Are the exception plans in place?
Is the project actually at the point where progress reports say it is?
How feasible is achieving the future goals in the plan?
Technology choice and usage
What tools and technologies are being used?
Why were these tools and technologies selected?
Is the selection in line with industry best practice?
Are appropriate skill-sets available to manage technology set?
System architecture
How do the pieces that make up the solution fit together?
Can the solution meet the quality requirements (speed, load, reliability? etc.)?
How are technical decisions made? Is there a design authority?
How are technical decisions recorded?
How is technical feasibility demonstrated?
Functional requirements
What is the requirements analysis process?
How are users involved in the process?
Are the requirements clear, complete and consistent?
Software design
How are functional requirements turned into solutions?
What kind of design documents is produced?
Code quality
Are coding standards in place and followed?
Is the code clear, efficient and well-organised?
Testing
What kinds of testing are carried out?
What testing strategy is in place?
How is testing planned and managed?
Is there a “test to fail” or “test driven” philosophy?
Is testing automated?
How are test cases identified?
What kinds of test tools are used?
Audit process
Initiation
The process of carrying out a project audit starts with initiation. In this activity a meeting with the prime stakeholder is held where the scope of the audit is agreed, a list the questions that need to be answered is drawn up and basic facts about the project such as scale, locations, goals, history, and progress to date are garnered. The output of the initiation is a plan of attack of the audit.
Enquiry and reporting
The twin tasks carried out during the audit are enquiry and reporting.
Research tasks
The first step is to understand the project “landscape” (who is who, what are they doing, where are they doing it) and status (where are they up to). This is normally accomplished by reading documents such as the brief, PID and highlight reports, and talking to the sponsor and the current project manager. It is at this stage that the overall context of the project at LAND is clarified.
The second step is to select interview candidates, and then to carry out semi structured interviews – these will be recorded for ease of transcription. Some interviews will inevitably raise further questions and lead to more rounds of interviewing or follow-up (which can be done by email if there are matters of clarification) - revisiting some people and other meetings. Interviewees may be drawn from both in- and outside the project team (for example from the ODP). Simultaneously, I would normally acquire and study relevant project documents and files during this process to see if good practice is in place. The status of the technical artifact as it currently is will be investigated by investigating the operational software and by carrying out reviews of the code – but this is likely to be confined to an assessment by the TDA.
Reporting - report contents
Summary
Background
<sections specific to questions being addressed>
Quantified risk assessment, showing for each major risk:
Nature of risk
Risk likelihood
Risk avoidance strategies
Outcomes if risk materializes (with probabilities for best vs worst cases)
The primary purpose of a project audit is to find the reasons for apparent failings in the project process, and answer:
What is the current state of the project
Is the project going to deliver something useful that meets requirements?
Is the technical approach being used still appropriate
Is the business case still valid?
Is the project organised in an effective way
Is the project context hindering or helping progress
Are industry standard project processes being followed
Is the project following industry best practice development methods?
ŕ What should be changed to improve the project focus?
The output of a project audit will be the answers to these questions and a practical assessment what can be done to improve and fix problems?
Areas of investigation
Project management
Does the project communicate effectively with its sponsors and other stakeholders
Are decisions taken rationally and quickly?
Does the management team have appropriate skills and experience?
Project organisation and staffing
Is the project divided into effective work units (teams)?
Is there capacity within the team to handle the workload?
Are the teams located appropriately?
Are roles and responsibilities identified and clear?
Are internal and external communications effective?
Does the staff have appropriate skills and experience to do the job?
Is staff working in a suitable physical environment?
Project processes
Are project controls in place?
How are work-packages identified and allocated?
How is progress managed?
How is change managed?
Is proper version and configuration management in place?
Project planning and reporting
What kind of plan is there?
Is the level of detail appropriate?
How has the plan been validated and agreed?
How is progress against plan reported?
Where is the project against the agreed plan and what are the reasons for deviations?
Are the exception plans in place?
Is the project actually at the point where progress reports say it is?
How feasible is achieving the future goals in the plan?
Technology choice and usage
What tools and technologies are being used?
Why were these tools and technologies selected?
Is the selection in line with industry best practice?
Are appropriate skill-sets available to manage technology set?
System architecture
How do the pieces that make up the solution fit together?
Can the solution meet the quality requirements (speed, load, reliability? etc.)?
How are technical decisions made? Is there a design authority?
How are technical decisions recorded?
How is technical feasibility demonstrated?
Functional requirements
What is the requirements analysis process?
How are users involved in the process?
Are the requirements clear, complete and consistent?
Software design
How are functional requirements turned into solutions?
What kind of design documents is produced?
Code quality
Are coding standards in place and followed?
Is the code clear, efficient and well-organised?
Testing
What kinds of testing are carried out?
What testing strategy is in place?
How is testing planned and managed?
Is there a “test to fail” or “test driven” philosophy?
Is testing automated?
How are test cases identified?
What kinds of test tools are used?
Audit process
Initiation
The process of carrying out a project audit starts with initiation. In this activity a meeting with the prime stakeholder is held where the scope of the audit is agreed, a list the questions that need to be answered is drawn up and basic facts about the project such as scale, locations, goals, history, and progress to date are garnered. The output of the initiation is a plan of attack of the audit.
Enquiry and reporting
The twin tasks carried out during the audit are enquiry and reporting.
Research tasks
The first step is to understand the project “landscape” (who is who, what are they doing, where are they doing it) and status (where are they up to). This is normally accomplished by reading documents such as the brief, PID and highlight reports, and talking to the sponsor and the current project manager. It is at this stage that the overall context of the project at LAND is clarified.
The second step is to select interview candidates, and then to carry out semi structured interviews – these will be recorded for ease of transcription. Some interviews will inevitably raise further questions and lead to more rounds of interviewing or follow-up (which can be done by email if there are matters of clarification) - revisiting some people and other meetings. Interviewees may be drawn from both in- and outside the project team (for example from the ODP). Simultaneously, I would normally acquire and study relevant project documents and files during this process to see if good practice is in place. The status of the technical artifact as it currently is will be investigated by investigating the operational software and by carrying out reviews of the code – but this is likely to be confined to an assessment by the TDA.
Reporting - report contents
Summary
Background
<sections specific to questions being addressed>
Quantified risk assessment, showing for each major risk:
Nature of risk
Risk likelihood
Risk avoidance strategies
Outcomes if risk materializes (with probabilities for best vs worst cases)