project management

The Project Audit Check List

Project Audit – A check List

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?

Royston

Doing a Feasibility Study

Is your project feasible?

The best way to find out whether your project is feasible is to complete a Feasibility Study. This process helps you gain confidence that the solution you need to build can be implemented on time and under budget. So here’s how to do it in 5 simple steps…

Completing a Feasibility Study

A Feasibility Study needs to be completed as early in the Project Life Cycle as possible. The best time to complete it is when you have identified a range of different alternative solutions and you need to know which solution is the most feasible to implement. Here’s how to do it…

Step 1: Research the Business Drivers
In most cases, your project is being driven by a problem in the business. These problems are called “business drivers” and you need to have a clear understanding of what they are, as part of your Feasibility Study.
For instance, the business driver might be that an IT system is outdated and is causing customer complaints, or that two businesses need to merge because of an acquisition. Regardless of the business driver, you need to get to the bottom of it so you fully understand the reasons why the project has been kicked off.
Find out why the business driver is important to the business, and why it’s critical that the project delivers a solution to it within a specified timeframe. Then find out what the impact will be to the business, if the project slips.

Step 2: Confirm the Alternative Solutions
Now you have a clear understanding of the business problem that the project addresses, you need to understand the alternative solutions available.
If it’s an IT system that is outdated, then your alternative solutions might include redeveloping the existing system, replacing it or merging it with another system.
Only with a clear understanding of the alternative solutions to the business problem, can you progress with the Feasibility Study.

Step 3: Determine the Feasibility
You now need to identify the feasibility of each solution. The question to ask of each alternative solution is “can we deliver it on time and under budget?”
To answer this question, you need to use a variety of methods to assess the feasibility of each solution. Here are some examples of ways you can assess feasibility:

Research: Perform online research to see if other companies have implemented the same solutions and how they got on.
Prototyping: Identify the part of the solution that has the highest risk, and then build a sample of it to see if it’s possible to create.
Time-boxing: Complete some of the tasks in your project plan and measure how long it took vs. planned. If you delivered it on time, then you know that your planning is quite accurate.

Step 4: Choose a Preferred Solution
With the feasibility of each alternative solution known, the next step is to select a preferred solution to be delivered by your project. Choose the solution that; is most feasible to implement, has the lowest risk, and you have the highest confidence of delivering.
You’ve now chosen a solution to a known business problem, and you have a high degree of confidence that you can deliver that solution on time and under budget, as part of the project.

Step 5:
It’s now time to take your chosen solution and reassess its feasibility at a lower level. List all of the tasks that are needed to complete the solution. Then run those tasks by your team to see how long they think it will take to complete them. Add all of the tasks and timeframes to a project plan to see if you can do it all within the project deadline. Then ask your team to identify the highest risk tasks and get them to investigate them further to check that they are achievable. Use the techniques in Step 3 to give you a very high degree of confidence that it’s practically achievable. Then document all of the results in a Feasibility Study.

After completing these 5 steps, get your Feasibility Study approved by your manager so that everyone in the project team has a high degree of confidence that the project can deliver successfully.

Get Some Templates Here for Free

The Project Audit Process

The Simple Steps for a Project Audit

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 the organisation 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 program office). 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)

Royston