Metrics 2.0 Rick A. Morris, PMP, OPM3, MCITP

Project Management Maxims  Projects with realistic budgets and timetables don’t get approved.  The more desperate the situation the more optimistic the progress report.  A little risk management saves a lot of fan cleaning.  The difference between project success and failure is a good PR company.  Nothing is impossible for the person who doesn’t have to do it.  A project gets a year late one day at a time.  Activity is not achievement.  If at first you don’t succeed, rename the project.  Everyone wants a strong project manager - until they get one.  If project content is allowed to change freely, the rate of change will exceed the rate of progress.  A failing project has benefits which are always spoken of in the future tense.  Projects don’t fail in the end; they fail at conception.  If it wasn’t for the ‘last minute’, nothing would get done.  If you can keep your head while all about you is losing theirs, you haven’t understood the plan.

Metrics Beyond Normal  We need to track beyond what we are today.  % Complete, Budget Status, Project Status do not tell the whole story.  Are you getting what you need?  Are you getting participation from your team?  Are you being setup for success?

Creating New Metrics  How do I measure it?  What does the data say?  How do we solve it?  Did it work?

Sample Resource Metrics  # of times invited to a meeting  Meeting participation type  Meeting engagement level  # of times resource showed up  # of issues assigned  # of risks assigned  # of issues resolved  # of risks resolved  # of issues introduced  # of risks introduced  # of tasks assigned  # of tasks completed on time  # of tasks past due

New Metric Outputs  Resource Participation Score (Based on meetings, issues, risks and tasks)  Resource Engagement Score (Based on attendance and completion of issues, risks, and tasks)  Resource Project Focus Rating (Overall ratio factoring in all metrics)

Case Study  Large strategic project with multiple departments  One department met with executives directly to try to stop the go live of the project  Department head stated that the team was not consulted and that the project manager had not involved them appropriately in the project.

Result  Stated that due to their project focus rating, it appeared that they did not want to be involved.  Invited to 47 meetings in which they never showed, 31 s went unanswered, 3 issues were assigned that were not completed, 2 direct requests for assistance were not answered.

Result  83 separate requests went unanswered.  Reality was that once they saw the impact of the project at go live, they tried to save themselves.

Other Metrics Initial Estimates  Date Estimate Requested – The date the sponsor requested the estimate  Best Case Estimate – Your best case estimate  Most Likely Estimate – Your most likely estimate  Worst Case Estimate – Your worst case estimate  PERT Estimate – Formula: (Best Case + (4 * Most Likely) + Worst Case) / 6  Estimate Variance – Formula: (Worst Case - Best Case) /6  Budget Number Selected by Sponsor – The figure that actually made it into the budget Planning  Date Project Started Planning – The date planning on the project started  Estimate Presented by Project Manager – The figure you requested after planning  Date Estimate Presented by Project Manager – The date you presented the refined figure  Baseline Estimate – The figure that was in the sanctioned budget Project Completion  Actual Cost – The actual cost of the project

Reports  Actual Cost vs. Baseline Estimate (the most commonly tracked financial metric)  Actual Cost vs. Estimate Presented by the Project Manager (the most commonly forgotten metric)  Actual Cost vs. PERT Estimate  Estimate Presented by the Project Manager vs. Baseline Estimate  Time Elapsed between Date Estimate Requested and Date Estimate Presented by Project Manager

Validate Assumptions as Metrics AssumptionActual Occurrence The requirements would be "time-boxed," and design would only happen in the beginning of the project. Many items were designed and redesigned. The team made key decisions without input from the user, as stated within the charter, but every time the system was shown to the user, new requirements and designs were accommodated. The budget spreadsheet went through 24 revisions, yet it still did not seem to be right. Another team was working on a business process reengineering effort. The output of their process would be the input to the requirements of the project. The business process reengineering effort was not completed. The team never received the inputs. The core team would be responsible for all key decisions.Many decisions were made outside of the core team. Scope would be tightly managed. Any new requirements not already identified would be included in the next phase of the project. Scope was not tightly managed. When the team would push back on new requirements or significant changes, they were put under a lot of top-down pressure to have changes made. All resources on the team would be 100 percent dedicated to this effort. Only 2 of the 24 people assigned to the project remained on the project full-time. The other 22 were either removed, the time they could work on the project was reduced, or they were switched for other resources throughout the project. Due to the accelerated timeframe, only 80 percent of the requirements would be delivered. The team delivered 132 percent of the requirements.

Social Media  Blog:   Linked In & Facebook updated often  Website:

Questions?