You can watch the summarized video presentation here.
What gets measured gets controlled and finally delivered!! In fact, every project manager uses some sort of statistical measurement to help track the progress and delivery of projects and programs. For this, the project manager relies on Metrics. Metrics can be used to measure a lot of areas within the project. But, let us first understand what would really make metrics work. Yes, that’s right! It is important to understand this aspect because a number of times, metrics are either underutilized or are used as a political weapon to prove certain points about the project. To help prevent getting into this mess and to sincerely leverage the use of metrics, it is therefore, important to know certain fundamentals. So here they are:
1) Align the metrics to the organizational or program goals. If not, talk to your seniors and ensure that it does relate to the organizational goals / program goals and relates to the delivery of the project and probably can be tracked down to the KRA’s of the employees working in the project/ program. The first thing it does is everyone in the program takes metrics seriously. To a great extent, this can solve a number of problems at once for the program or the project. It will reverse engineer to ensure that the right metrics are measured in the right way and for the right audience. While talking about the organizational or program goals, the key parameters that would definitely need to be addressed are:
a. Financial goals: that would directly relate to successful delivery of projects and getting revenue from the customers.
b. Process related goals: that would measure process improvements to help achieve the financial goals. It could include innovations; Performance improvement and appropriate cost cutting, ensuring proper processes are followed to meet scope adherence, risk management, quality and testing. Rather the bulk of the project metrics would address this is some way or the other.
c. Customer Driven goals: Ensuring customer satisfaction, Product or service usability.
d. Employee or HR related goals: to ensure that the employees are motivated, rewarded and that conflicts are resolved effectively.
There can be more or different goals as per the organization, industry or the nature of the program or project, but what is important is the alignment.
2) Ensure that the metrics cover the vital areas of the project. Once the metrics are aligned to the goals, it is important to measure the key metrics across the vital areas across the project. Some of the major areas are:
a. Delivery: Project delivery, Project plan progress in terms of Earned Value Analysis, Scope adherence.
b. Customer satisfaction: Product or service Usability.
c. Intelligence: Predictability of project deliverables and Quality.
d. Quality of the product: Including both Testing and the basis of testing through audits.
e. Product Development: Software Engineering goals, Change Requests, Design Defects and Bugs, Defect Density, Defect Slippage, Percentage of Invalid Defects.
f. Human Resources: Productivity, Employee Morale, Rewards and Recognition, Conflict resolutions
g. Risks and Issues: Risks / Issues logged, resolved, mitigated or transferred, tracking the watch list for potential risks, quantitative and qualitative risk and issue analysis.
Again, the list could go on, but what’s important is to factor in whatever is important for the project or program and prioritize the measurement effectively.
3) Set-up clear Metrics standards and Criteria: This is another challenging area in metrics. The major problem with metrics is that everyone tries to generate all the metrics for his area of the project resulting in too much of reporting, confusion and finally affecting delivery of the project through impact to the vital areas listed above. For example, if there is too much of metrics or similar type of metrics generated by too many leads/ managers with varying reports and results, it can amount to tremendous amount of energy being used up in ONLY trying to sort out the RIGHT NUMBERS. Instead, if the metrics standards and criterias are set-up and shared and cascaded through the hierarchy across the program or project, it can make everyone to at least start speaking the same language. So, setting up clear metrics standards and criteria is a must. Depending on the size of the program and project, the management can take conscious decision to have a separate dedicated Reporting team which is empowered to take informed decisions and proactive in measuring the metrics instead of just passive reporting. And this could be key element in ensuring that metrics are clear and uniform across the program.
Coming more to the specific criteria: Clearly communicate what are the standard parameters that will be used to measure each of the varying areas.
For example:
In Risk Management: Define clearly the qualitative and quantitative metrics. See: How to show risk management in Enterprise Project Management Dashboard
In Schedule management: Clearly define the EVA and the parameters that will be measured. Standardize the rules used in tracking projects using tools such as MS Project. See, Effective scheduling using Ms Project.
4) Put in standard or custom tools to measure metrics. Why I would say both standard and custom is because many times the projects or program are so complex that they cannot be tracked using standard tools such as VSTS or MS Project or Primavera alone. Also, to measure the metrics across so many vital areas might need a number of tools in different department across the program. There is no “one size that fits all” tool, and even if there is, it might require quite a lot of customization to use it successfully with the desired results. This becomes clearer if you have done points 1, 2 and 3 seriously. You then realize where the gaps are instead of just handing different tools to different departments and finally end up spending lot of time reconciling.One approach is to create a set of customized standard tools and co-ordinate them effectively so that they all can talk to each other. This should be part of the set-up for e-PMO dashboard.
ENTERPRISE PROJECT MANAGEMENT DASHBOARD
EPM Dashboard is normally used to show the end to end project status across all phases in a given project. It is especially useful in large budget projects that would have multiple stakeholders and sizeable end result, service or product.
Naturally, the EPM dashboard that we are assuming here is of a large proportion with:
- Rich UI
- Consolidation of variety of tools such as MS Project 2007, Testing tools (standard or custom), Reporting tools (standard SQL reporting services or custom), Risk capturing tools (standard or custom) all linked through common databases (DB’s) that can connect to each other through complex or interdependent queries.
- You will need a separate strategy to define how to develop the tools to measure the effectiveness of the project. All this should form the part of the Planning phase. For example, to measure delivery of projects, after deciding the success criteria’s you must know how to measure it using say, MS Project or any such project tracking tool. To measure customer satisfaction and usability, appropriate CRM tools can be used and the results scan be shown in e-PMO dashboard. To measure risks, you can develop an in-house custom tool that suits your criteria and link it to the e-PMO dashboard. See, How to show risk management in Enterprise Project Management Dashboard
- We shall deal with developing an e-PMO dashboard in more depth in my subsequent blogs.
5) Adapt, Innovate and Change: This is again fundamental and ironic. If we change the way we measure, then why did we put so much efforts in standardising the tools? Yes, it is necessary because of the fundamental nature of the project itself – that is to change. Hence we need to adapt and grow to accommodate the changes in the project to help measure metrics more effectively.
For example, in the initial phase a lot of metrics would be utilised in tracking initial scope, testing, risk, communication plan with the stakeholder list, organisation structure that would be put in place. But as you move ahead in the project, the measurements shift to tracking Schedule variance, cost variance, to complete performing index, risks and issues raised and resolved, productivity, rewards, conflicts etc… While during the fag end of the project, the focus would be more on the deliverables, auditing, scope compliance, defects raised at customer site, customer satisfaction and finally lessons learnt.
What a standard process and a systematic approach does is that it helps manage the change better using standard tools.
You must be logged in to post a comment.