reporting

Learning Project Reporting on the Fly

Posted on by daniel598fall15

I recently became the project manager for a project that was started this past August. The project contributes to a strategic corporate initiative and has high visibility. Given the project had already been in progress for 2 months, I assumed that much of project plan and reporting structure was already in place. This was not the case!

There was progress being made. However, there was no formal communication/reporting protocol with upper management and the various project stakeholders were not working to an aligned plan. Before I formally took over the program, my manager and I reviewed the overall status and decided we needed to hold a workshop to bring all team members/stakeholders together.

We held a two-day workshop with the goal of formalizing the project plan and WBS to meet the target launch date and shipment quantity. The workshop was very successful and the team left feeling aligned and empowered. However, there was also a feeling of uncertainty.

As project manager I was given the task of developing a dashboard to communicate the project status on a weekly basis: project timeline with key milestones, materials procurement, CAPEX (capital expenditure), and hiring. Being new to dashboard development, I embraced the challenge and compiled the required data.

Much like the examples found in the textbook, my dashboard includes a Gantt chart for project milestones. Within the Gantt chart I also included initial production quantities, weekly spend requirements for materials purchases and CAPEX expenditures, and weekly hiring requirements. Additional tables were included to better quantify the information in the Gantt chart. I was amazed at how much information could be displayed on a single chart!

Once the dashboard was complete, the reason for the team’s uncertainty at the workshop’s conclusion was clear: the project was significantly behind schedule and under-staffed.

How could such a discrepancy exist? No detailed planning was conducted at the beginning of the project. Yes, key milestones were defined along with primary deliverable, but the detailed investments required to support the project were not effectively communicated until the workshop. At this point, the only way to refine the project plan was to proceed like Dilbert:

Dilberthttp://dilbert.com/strip/2011-08-18

After working backwards and compiling a daunting list of overdue expenditures, the team leveraged the dashboard to inform upper management of the current project status. Naturally they were not impressed and requested the team to drive improvement. We are now in catch-up mode and working to fulfill the initial plan as much as possible. The team is in a difficult situation as product performance has been agreed to with the customer, and senior management has mandated that all costs be minimized while fulfilling the target launch date and quantity.

We are committing to the realistic schedule/quantity and reporting this as baseline during our weekly meetings. Now we just need to get senior management on board.

Have you ever worked on similar projects that were behind schedule, over budget, and under-staffed? Please share your experience!

 

Starting at Red

Posted on by michele598sum14

In class we talked about how project managers often use the red/amber/green method to signify if a project is running on track.  My company uses the thius same approach to track project work as well as many of our monthly KPI’s.

Most if not all projects typically start with a green indicator and will remain that way as long as the project completes on-time.  I read in interesting article called “Starting at Red” that suggests all projects should start with the color red.  The reasons cited in the article are as follows:

  1. When a project begins, the team is as far from delivering anything as it will ever be. Sounds pretty much like a “Red” scenario to me. What if the project remained at “Red” until the PM could justify downgrading it to “Amber” – based on progress achieved, and then eventually (hopefully) “Green”?
  2. Green at the beginning doesn’t work because we have no idea if we’re going to achieve our goals so saying the project is “Green” really means “we haven’t yet found a reason why we won’t deliver”.
  3. If a project starts at “Green” and remains “Green” all the way through, at what point does it go from being “we haven’t yet found a reason why we won’t deliver” to “we will definitely deliver”? At some point it will have changed, but this is not recorded by a change of project status.  Seems like an important distinction to make.
  4. “Green” is a problem because reality doesn’t work like a textbook. It is usually very hard for the PM to change the project’s status.
  5. Starting at “Red”, there is no need to worry because a “Red” status is the norm. This clarifies that “Green” only means “we will deliver”, and no project can go to “Green” until it is clear that the progress made justifies the change of status.
  6. The PM will naturally be keen to find reasons to change the status to “Amber” and then “Green”, but this will require delivering good news, and justify the change – which is much easier than delivering the bad news required to go from “Green” to “Amber” to “Red”.

The article summarizes by saying that starting at “Red” makes it easier to focus the team on the critical activities required to go to “Green”. Everything else is secondary. This is the kind of project environment that is usually only created when there is a serious problem. Why wait until then? Start with the attitude that the project is going to fail unless you take immediate action – because it is!

The challenge posed at the end of the article is for all PM’s to try this on their next project as see how it works.  Would you be willing to give it a try?

http://www.projecttimes.com/articles/starting-at-red.html