Good project management is essential to a successful IT project.
In the previous article, I outlined what to include in the project plan. So, for this article, let’s assume that the project is underway and see what needs to be done to manage the project.
Keep an eye on the type of work that is being done. Make sure that everything that is within the scope of the project is being done. In addition, watch for changes in the project that indicate the amount of work is expanding. If the work is not defined in the project plan, it is out of scope.
There may be times that scope changes are necessary. Additional work may be required that was not anticipated in the project plan. Alternatively, scope reductions may be needed to get a project back on schedule or to complete within the budget. Scope changes should be analyzed and approved according to the change control process outlined in the project plan.
Track Progress Against Schedule
Compare the schedule to the work actually being accomplished. Watch for any discrepancies. If the project is behind schedule, find out why. Evaluate the alternatives available to get back on track. Don’t wait until the project is seriously impacted – take corrective action right away.
Get copies of invoices for all project costs and compare actual costs to the budget in the project plan. Ensure that the project is not over budget. If it is, evaluate options for getting back on track or determine that a change to the budget is required.
Assess the performance of the members of the project team. Watch for any members requiring more guidance or whose availability is less than outlined in the project plan. Continue to motivate team members throughout the project. Ensure resolution of any conflicts that arise.
Monitor for risks that were considered during the planning phase. Also, watch for changing conditions that suggest there may be new risks that were not considered earlier. If possible take action that will prevent the risk event from occurring. If a risk event does occur, implement the contingency plan outlined in the project plan.
Follow up on use of standards for programming, testing, documentation and logging of issues. Ensure that work being done is reviewed and that it is satisfactory. If not, take corrective action.
There will always be issues to resolve. Make sure that issues are properly documented according to the project standard. Determine a priority for each issue and a target date for resolution. Find out what is necessary to resolve the issue and follow up.
The requirements for resolving the issues may vary quite a lot. A simple issue may be recorded, indicating that a user decision on a specific account number is needed within a month’s time, and that it might be delayed. All that is needed here is to follow up and make sure the decision maker has necessary information an approvals to make the decision at the appropriate time. However, a bigger issue may be that a key program or system is not performing as required. This type of issue may need additional oversight, budget changes, scope changes, different resources and revisions to project plans.
Status and Coordination
Keep the project team members and the end users informed about the progress of the project. When the project is busy, continue to make time to keep stakeholders up to date, as outlined in the project plan.
Ensure that all coordination that is needed with other projects is occurring as planned. Also, make sure that any issues arising from the interaction between the various projects are resolved.
Hold project review meetings with the steering committee. At the review meetings, present key decisions that have been made, major issues and their resolution, and any proposed project changes.
If the project is off track, schedule review meetings with the steering committee more frequently than outlined in the project plan. The steering committee will want to be informed in more detail when there are problems. In addition, the approval of the steering committee will be required for any changes to the project plan.
Project Not According To Plan
So, what could go wrong? Anything! Examples include scope problems, deadlines not being met, issues that not being resolved timely, costs greater than budget, resources that are not available enough or not performing well, standards not being followed, risk events occurring, tasks that are not done to expectations.
When something goes wrong, evaluate the options for getting the project back on track. Determine what the best course of action is and draft revisions to the project plan. As with the original project plan, this will be an iterative process. For example, changes to resources will lead to changes in budget or completion dates.
When a revised plan is completed, meet with the steering committee and obtain approval for the new plan.
When the project starts, and as the project progresses, keep files of important documents related to the project. Examples of items to keep include the original project plan, approved change requests, minutes of project review meetings, documentation of key decisions made and reasons for them.
It is far too common for projects to appear to end abruptly when a specific milestone is reached (e.g. users start using the new system). However, the project really isn’t complete unless all of the items in the project plan scope statement are finished as well, including any planned documentation, post-go-live support period, or invoice payments.
Meet with the steering committee to review the project status, determine their satisfaction with the project schedule, completed tasks, key decisions, costs, and resolution of issues.
During the project, there may have been tasks that had to be dropped until a later phase. In addition, there are usually tasks identified as beneficial to the company, but that cannot be accommodated within the project schedule. All of these tasks should be documented so they can be considered for a second phase.
Any unresolved issues that surfaced during the project should also be documented, and assigned to individuals for resolution.
Post Project Review
After the project is completed is a good time to review the entire project to see what went well and what went wrong.
Things that went well can be used as a base for planning the next project. Problems that occurred should also be reviewed – these lessons can frequently prevent similar problems from occurring in the next project. Note that this is not a search for someone to blame for the problem. The point is to determine what to do better next time.
Keep Important Documents
Complete the filing of important documents related to the project. Note that this should be a relatively minor job at the end of the project, since filing should be done throughout the project.
It’s All Over
So, you have the information you need to execute the project plan and to finish the project. Don’t forget to celebrate the successful project completion!
Copyright 2015 Debbie Gallagher