Managing a project consists of many tasks that need to be scheduled, delegated to the members of the team, completed, and followed up on by the project manager in order for the project to be successful.

One of the main tasks of the project manager is to track the overall progress and profitability of the project by the total hours and cost of goods charged to the project compared to what the bid has allotted.  At Setpoint we have an open book policy for all projects.  Anyone can go to the team board and see exactly what the progress is of any project at any time.  This board shows the project revenue, the bid cost of good sold (COGS), actual COGS, project gross profit (GP), earned GP, percent complete, the week’s hours, the week’s GP, the week’s GP per hour, and the GP per hour to date for each project.

Reporting these numbers can sometimes be a tightrope walk for the project manager who reports the progress of each of his projects to management and the team of assemblers and programmers working on them.  The management team wants answers to why the progress of the project is behind the forecast numbers he gave them at the beginning of the month.  The assembly and programming team members working on the project are wondering why the hourly rate is so low or they are expecting the percent complete to be much higher.  There are usually good answers for both teams.

As a project manager, I take the conservative approach.  Sometimes a projects progress is well ahead of the hours that were in the bid, and sometimes the cost of goods is less than what is in the bid.  This doesn’t often happen, but when it does I don’t like to take all the “good news” on the progress report until I am sure that all the parts have been accounted for in accounts payable and the majority of the debugging has been done on the machine.  Some people might call this “sandbagging,” I call it proper project management.  Can you be too conservative?  Sure you can.  But I ask you this; would you rather take all the “good news” at the point of discovery and find out later that one of the key, and very costly, components was not accounted for or was overlooked in the procurement state?  Maybe you find out the scope of the project was not communicated to the programmer correctly and you now have two more weeks of programming to do.  This is usually not the norm, but it happens.  You now have costs or time you need to “give back” on the next progress report, or several reports, making it look like you have made no progress when the team is still working hard on the project.

Yes, in reality the end result should be the same; but let’s say your team can earn bonuses for completing projects ahead of schedule and below cost.  I for one do not want to get the team excited about their efficiency and the prospect of getting a bonus for their efforts one week just to have it taken back the next.  It doesn’t help the morale of the team.  There is a “happy medium” for claiming the ‘good news” that differs from project to project.  This is one of the hardest tasks to conquer for a project manager.

So call me a “sandbagger,” I’m ok with that.