What I Learned from Reports in Project Management Software

When choosing project management software to help in the management of your project, make it a point to look into its report-generating capabilities. Keep in mind that reports aren’t just for the sponsors or the customers, whose main interest is to ascertain the timely completion of the project in accordance with their requirements. Reports are basically for your own use, as a way to raise your awareness on how well your project plan, schedules and cost estimations, are holding up against the real figures.

Personally, I sometimes go over reports from my previous assignments, and recall the lessons I have learned when I’m about to draw up a new plan. In fact, there’s now project management software that allows you to capture the knowledge that you can derive from the reports that came out with unaddressed issues, critical deviations and potential risks that could adversely affect your project.

Anyway, let’s go over each standard report and look into my examples of such occurrences, as these caught me off-guard when I failed to discern what the standard reports were trying to tell me:

The Detailed Project Status Report:

This report gives a complete picture of what has been accomplished so far, as of review date; and if there are any issues to address. The details include the particular tasks accomplished, descriptions of the accomplishments, and how much time and money has been spent as far as the completed or still to be completed task is concerned. The software-generated report provides a column for WBS, which stands for Work Breakdown Structure; the purpose of which is to provide exactly what its name implies, a breakdown of the work schedule.

Yet, as I go over my project status report, I don’t pay much attention to the WBS column as it does not contain any index numbers which I’m supposed to use as reference. You see, I used to be the kind of project manager who supported the notion that a WBS is applicable only for large or complex projects. Besides, I used to do things manually; hence, I never got around to forming the habit of creating one for my assignments, because it was a tedious task in the first place.

So when I started using project management software, there was no data pertaining to the work breakdown, which the system could use as reference simply because I didn’t make a WBS for the system to process and use, when generating the project management reports. At first, I couldn’t figure out why there were still issues to address in my status reports, and because of those issues I was at risk of not being able to complete the tasks as scheduled.

Then it finally dawned on me that the issues were mostly functional requirements in the deliverables, which I presumed that the task-owner was aware of. These happened when there was a change of hands that transpired in one of my business development projects, in which I proceeded to draw-up a plan with the same presumption in mind. Only to find out that the person, to whom I had assigned the accounts receivable program, was not aware that the system should have the capability to age all receivables that went beyond its due dates.

It turned out that I was partly to blame because the team member in charge of the accounts receivable system was looking for a work breakdown structure dictionary. Accordingly, he could have used this as a reference and as a checklist to ensure that all important features have been adequately addressed. Since there was no WBS in place, there was not a supplementary WBS dictionary either. From then on, I learned my lessons from this experience, since it affected issues regarding project scope, requirements management and change management.

The Project Progress Reports

A simple project progress report basically tells you if you’re ahead, right on schedule or lagging behind, based on the accomplishments that your project team has, so far, completed. The progress status is likewise analyzed by the automated system in relation to the next set of goals, which your team is about to tackle. In order to avoid issues over not meeting deadlines, one of the best practices in setting-up a deadline is to provide time allowances for unexpected events.

Some problems might be inherent in your project, your location or workplace culture. However, there are also lessons to be learned for overestimating these time allowances. Hence, it would be wise to be more discerning with your project progress reports.

Bear in mind that in over-approximating the amount of time you added to your task-duration estimates, you will be allocating too much time for a task to be completed. In my case, I almost congratulated myself for a job well done regarding my time estimations. The team was never late with its deliverables and was able to complete their tasks exactly as scheduled.

Still, the thing that bugged me most was that the progress reports never showed instances of tasks being completed ahead of schedule. This is considering the fact that everything went on smoothly as planned. Issues, if any, were very minimal and were addressed right away. This means that the team could have completed the project based on bare time estimates that have no allowances for time constraints.

Apparently, I was giving my team more time than what was necessary. Hence, I had also made over-provisions for some of the budgeted costs, since the method of calculating cost estimates were computed based on the overestimated number of man-hour requirements.

The Resource Usage Report

The resource usage report shows the actual hours spent by the human resources working on the project and how these compare to the baseline figures. A reference to baseline means the average of reality-based figures, which are usually derived from industry standards or from past projects. I came to appreciate this report, ever since I learned my lessons about making overestimations in setting-up deadlines.

It used to be that I was more concerned about beating the due dates and paid little attention to the information being provided by this report. I had overlooked the fact that the resource usage reports were comparing actual man-hours spent against industry standards; hence, I was not aware of how far off I was with my time estimations.

However, the matter of making excessive provisions for the budgeted costs doesn’t pose as a problem to your company because the company will be realizing greater profits if the terms of the project is based on a negotiated contract price. The actual cost incurred by the project will definitely be lower than what was projected; thus, equating to a large amount of savings.

Still, there is a lesson to be learned in being more realistic with your estimations. Your company can easily lose its chances of winning at contract biddings by stating a contract price that is too far from being competitive. Overestimation places your company’s bid at a disadvantage, as prospective clients can easily make comparisons against industry standards.

The Lessons Learned Report

There are certain types of project management software that create a summary report of all the entries in a Lesson Learned Log. It provides the resulting discrepancies between the system’s built-in audit and the actual figures reported. The discrepancies stemmed mostly from the analysis of project issues and abnormal events, as well as assessments of the technical methods and the processes applied.

In a corporate environment, the information that can be derived from this report will be used to determine the methods, tools and processes that should be in place, to avoid the recurrence of the discrepancies. After which, these will be passed on as lessons learned to a specific audience, usually, to those who are new to project management.