Learning Project Reporting on the Fly

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:


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!


A Risk Management Lesson from “Silicon Valley”

The video clip linked below is from HBO’s “Silicon Valley”. This television program follows a group of software engineers as they launch an innovative app and their associated start-up company (both named Pied Piper). This clip focuses on Pied Piper’s primary competition, a tech conglomerate named “Hooli”. The clip shows a speech by Hooli’s CEO, followed by several discussions between members of a project team.

HBO’s Silicon Valley on Risk Management

This scenario highlights several instances of risk management failure which are tragically relevant to the workplace. Some of the failures I observed are lack of communication within the project team, lack of escalation within the project team and larger organization, and absence of risk planning and mitigation planning early in the project. In today’s hyper-competitive, fast-paced marketplace proper risk management is critical to project success. Has anyone observed this type of situation at their workplace?

Recently I encountered a scenario where the customer made a significant design change late in the project. The product was nearly qualified, but was deemed unacceptable due to reliability and performance requirements. The team was faced with a tough decision: kill the project or redesign.

As the contract manufacturer in this arrangement, I raised concerns regarding the potential risks this design change could have on the project. Any delay or high defect rate would result in lost revenue and profit to my organization as well as the customer. I was reassured there would be no issues and no change to the product ramp/launch dates and product cost.

As we built increasing numbers of the product the failures began to pile up. Both customer and manufacturer turned to firefighting mode and additional resources were dedicated to expedite resolution. In my customer’s organization I could see finger-pointing among several teams as each department tried to cover themselves and avoid being the next bearer of bad news to upper management.

Eventually the product was fixed and had a successful (yet slightly delayed) launch after several weeks of many stressful meetings. Could this situation have been prevented? I believe so, but only if the correct tools, controls, and planning were put in place at the beginning of the project at both the customer and manufacturer. The following article details such risk management best-practices:

Risk management and project management go hand in hand

Some noteworthy items include ingraining a risk management culture/mindset in the project team, frequently analyzing the project status and forecasting new risks, developing and agreeing to risk response plans in advance, and assigning an owner to each risk who can drive corrective actions and track progress. Although you cannot predict every possible risk in a project, I’ve seen how important it is to conduct this planning at the beginning of the project to avoid firefighting late in the project.

Does your company have a formalized process for risk management? Are these successful, or would you suggest alternate approaches? Do you have any horror stories similar to mine? Please share your experiences!