This issue is not applicable for many companies, but for many others, it should rank very high on any risk analysis rating. A huge basket of resources gets expended on large projects, and a simple internet search for “failed multi-million dollar project” got me about 36,200,000 results (0.31 seconds).
Now, there are companies that have this nailed down and have excellent controls. These companies are usually in the project management business, and poor project management controls mean the business is likely to fail. But even an experienced IT application development company can fail. I invite you to read the brief summary when you search for, “Maine’s Medicaid Mistakes CIO.com” I was there. Iwatched it happen. It was like watching a train wreck in slow motion. It was ugly and depressing.
But many others experience a limited number of one time large scope projects whose failure can have serious negative repercussions for the business, but not be fatal.
I’m going to orient these comments to IT development projects, since I am an IT internal auditor, but the principles should be universal to a large extent.
Despite the fact that there are any number of different flavors of professional project management designations and professional organizations, I don’t believe that this is rocket science. But it is specialized. There are a million different project management templates and formats and disciplines and methods. It doesn’t matter which one you use. Pick one and stick to it. They all break down to, “Plan the work and work the plan.”
From the discussion below, you should be able to cut and paste many of the questions and comments into a simple, rudimentary, but effective high-level audit program.
Project Management Audit Checklist
Is there a formal, comprehensive, detailed, written project plan?
A simple list of major milestones disguised as deliverables is not good enough. The project plan is the key to success or failure for any single project.
Is the project plan managed within Microsoft “Project” or similar application?
If the project is of any size, complexity or duration, a spreadsheet or document or self-constructed database is inadequate and a serious red flag. You are spending tens and hundreds of thousands of dollars or more. You can spring for a copy of “Project” and some training. Failure to track the project’s progress on MS Project or application of similar or greater capabilities, is a major audit finding. It’s inexcusable.
Is the project baselined?
Within MS Project, to baseline the project is to record and set the planned, projected start and finish date of each task. This is the line in the sand. If the project is in any way active and in-progress, the failure to baseline the plan indicates that the plan is not complete or approved or adequately comprehensive. The plan is not ready. Management has not formally approved and accepted the plan. This project is not ready. It also means that the project manager or other project leader is not willing to commit to the schedule and is not willing to be held accountable for setting the baseline standards. Talk about a red flag! It also may indicate management’s insistence on unreasonable and unattainable time deadlines.
In my opinion, any review of project management that uncovers an active project that is not baselined, should pause the audit and immediately issue an interim finding of high significance to senior management. This is a major finding. It’s inexcusable.
- Is there a senior steering committee?
- Is it composed of the senior project sponsors and stakeholders?
- Does it meet regularly? Monthly is inadequate in many cases. Meeting only once a month is an indication that this project is not a high enough priority for senior management. What is it that is more pressing that they cannot meet at least once a week for an hour…..TPS report reviews?
- Is there an agenda for every meeting?
- Are there written minutes created for every meeting?
- Is the status of the project plan reviewed and documented at every meeting? If the project manager provides the excuse that it is too much work to update the plan every week, then you need to find a new project manager or hire more staff.
- Are specific action items and performance objectives created every week? Simply getting together, consuming coffee and donuts, chatting about the latest sports story, and agreeing that things seem to be “on track” this week, is a red flag that the project governance is woefully inadequate.
- The senior project sponsors need to know what questions to ask the project manager. What tasks were added or changed this week? How did this impact the timeline? What tasks were delayed? How did this impact the timeline? Any vague or incomplete answers from the project manager should raise immediate red flags. Are the senior project sponsors actively and directly engaged with the project progress? They cannot just leave it all up to the project manager.
Does the project manager have the organizational authority to direct the work and standards of everyone working on the project? Somebody has to be ultimately in charge of, and responsible for the project. If it’s not the project manager, you run the risk of someone exercising undue influence and authority to hide, cover up, disguise, deflect and deny operational, financial, organizational and personnel problems and difficulties that negatively reflect on his or her performance. Segregation of duties, and strict lines of authority and responsibility are critical to successful project management. You have got to take the personal ego and emotion out of the governance structure and organizational authority. If you don’t, it will undermine the project.
A project status report should have a financial report included at least once a month. This should be at least as detailed as any construction work-in-process spreadsheet. See the simple template attached:
If the summary is not reconciled to the general ledger, you have a major finding. If it’s not reconciled to the general ledger, it is pretend. Decide how to handle accruals and other timing differences, and be consistent.
Who approves invoices? Does the person have that organizational authority? Is invoice approval tied to written review and approval and acceptance of specific deliverables in the contract?
Every steering committee meeting should include an agenda item that addresses the topic of scope creep. They should specifically and directly document their understanding of the nature and extent of the issue at each meeting. Does the project manager provide a summary of new tasks added to the project plan since last meeting? Does the project manager have a written remediation plan to address the effect of these? Any change in project scope needs to be reviewed and approved by the senior business sponsors, and that approval has to include an explicit acknowledgement of the additional days and dollars the change in scope entails.
This is almost exclusive to IT development projects. During the course of data conversion, development and testing, you will discover defects, flaws, errors, etc. Is there a formal system for reporting and tracking the resolution of defects? Is there a formal review, verification and approval process for creating a defect report? You cannot let anyone create a defect record. You will get duplicates, errors and mass confusion. Is there a formal review and approval of the prioritization of defects into categories? Within categories, is there a formal review and approval of the prioritization of defects into immediate priorities? If the list of “critical” defects expends beyond what is almost immediately addressable, the staff cannot be allowed to self prioritize their work. Senior and experienced business managers have to understand the financial, business, process and project implications of each defect and make sure the most important are completed first. The business owner cannot be allowed to spew a fire hose of defects at the contractor or developer and expect the work to be done by magic. The developer/vendor has to be able to commit to the deadlines and prioritized of the customer. There has to be a documented and approved meeting of the minds on defect remediation and reporting.
Each status report should summarize the number of defects in each category at the beginning of the reporting period, the number added, the number closed, and the number remaining at the end of the reporting period. Do the math. Based on past experience, is there REALLY enough time to correct all the defects prior to going live?
Inadequate business requirements
The issue of written, formal and comprehensive business requirements is a huge issue for many IT projects. Many times, the business unit simply wants to automate a formally manual process, or integrate many manual processes into an existing application. What the application developer finds is an absence of complete or comprehensive understanding of all that goes on within the business unit. Just trying to understand the business process and how it all works together can be a serious challenge. And if you add the stress to the business unit of maintaining ongoing operations while at the same time, developing written business requirements for the new application, you have the potential for problems. Are the business requirement completed, reviewed and approved all up and down the line before the programming starts? The business requirements should drive the programming, not the other way around.
Scope creep happens when the business requirements are incomplete or wrong, and need to be corrected, expanded and modified after the project has begun. This is a huge red flag.
Inadequate commitment of business resources
Does the project manager provide a report of tasks that have delayed finish dates that impact the project timing?
This just scratches the surface, but if you see any of the red flags I discuss above in your organization, you really need to speak up. Good luck.
failed projects, internal audit of project management controls, internal controls, project management