The challenge is that project success is often judged using only a few visible outcomes.
- Did the release happen on time?
- How many bugs were reported?
- Was the customer satisfied?
These are important questions. But they do not always tell the complete story. A project may have fewer bugs simply because it is smaller. Another project may have more bugs because it has more developers, more releases, and more functionality. One team may work with stable requirements while another deals with constant change. One year ago, we realized that if we wanted to recognize project performance fairly, we needed a better way to measure it. That thinking led to the Project Award Score.
The objective was to answer a simple question:
How do we compare projects fairly when every project is different?
- As the company grew, project reviews often became discussions based on individual observations. Different stakeholders looked at different indicators. One person focused on delivery. Another focused-on quality. Someone else focused on customer feedback.
- The Project Award Score was introduced to bring these measures together into a single framework. The idea was not to replace judgement. The idea was to support discussions with data.
The score looks at five areas that influence overall project health.
Quality
- Quality is measured through defect-related metrics. The goal is not perfection. The goal is continuous improvement and reducing avoidable defects.
Issue Management
- Projects are expected to identify, track, and close issues properly. Good issue tracking helps teams address risks before they become delivery problems.
Engineering Complexity
- Not every project faces the same technical challenges. Some involve multiple technologies, environments, stakeholders, and production responsibilities. Complexity is considered to ensure fair comparison.
Release Performance
- Projects are evaluated on how consistently they meet agreed release commitments. Reliable delivery remains one of the strongest indicators of project execution.
Project Lost
- Project Lost measures the productive project time lost due to planned and unplanned absences or reduced working hours. It encourages better attendance, effective time management, and helps teams minimise the impact of lost effort on project delivery.
One of the most valuable outcomes was the feedback we received from teams. Several teams challenged the scoring model and highlighted situations where the framework could be improved. Many of those suggestions eventually became part of the system itself.
Lesson 1: Bigger Teams Were Being Penalized
- One concern raised by project teams was straightforward.
- If a project has more developers, it naturally delivers more code. More code often means more defects. Comparing total bug counts alone was creating an unintended disadvantage for larger projects.
- To address this, defect tracking was revised. Instead of looking only at total defects, the framework began considering team size as part of the calculation. This created a more balanced comparison between projects of different sizes.
Lesson 2: Important Information Was Living Outside the System
- Another challenge involved tracking.
- Some risks were being tracked through emails. Some through personal notes. Others through conversations. The problem was that project information existed in multiple places. As a result, important dependencies and risks were not always visible to everyone.
- The solution was simple. Projects were expected to maintain issue information in a common Issues Log. This created a single source of truth and improved visibility across teams.
Lesson 3: Documentation Matters More Than We Thought
- Keeping project information current became everyone’s responsibility.
- Project metrics, meeting minutes, action items, and status updates were sometimes treated as secondary activities. The assumption was that documentation could always be updated later.
- In reality, outdated information often creates confusion, delays decisions, and makes problem-solving harder. For that reason, operational updates became an important part of project governance.
No scoring system is perfect. The Project Award Score is no exception. Several questions continue to generate healthy discussion.
- One of the biggest discussions around the Project Award Score has been how to fairly evaluate projects that operate under very different client delivery models.
- Engineers often ask: “If a release is delayed because of factors outside our control, should it affect our project score?”
- There is no single answer because every client works differently.
- In some projects, clients define release dates during monthly sprint planning and review them regularly through Go/No-Go decisions. The final release depends on several external dependencies, including environment readiness, access and permissions, infrastructure, and third-party integrations. If any of these dependencies are delayed, the client revises the release date. As a result, these projects often achieve an “on-time” release because the committed date itself is updated based on overall readiness.
- In other projects, clients do not define fixed delivery or release dates. Even after development and testing are complete, the team continues to work on minor enhancements, clarifications, and change requests until the client decides the feature is ready for release. Although the engineering work may be substantially complete, the project remains active for a longer period.
- There are also projects where the delivery plan is owned by the project team. The team commits to release dates, and the client generally accepts those commitments without actively managing the schedule.
- These examples show that the same “On-Time Release” metric can represent very different situations depending on the client’s delivery model.
- This raises an important question:
Should all projects be evaluated using the same release metric?
- This is one of the areas where the Project Award Score continues to evolve. The objective is to distinguish delays caused by internal execution from those driven by customer decisions or external dependencies.
Projects such as AI and automation initiatives often involve significant effort that is not visible through ticket counts alone. Understanding requirements, investigating root causes, experimenting with solutions, and stabilizing systems can take considerable time. Capturing this effort remains an ongoing area of discussion.
- Another discussion that emerged from team feedback was around the current eligibility rule. At present, a project that wins the Project Award in one quarter is not eligible to compete in the immediately following quarter.
- The intention behind this rule is to give more teams an opportunity to be recognized. However, some team members feel that it may unintentionally reduce the motivation of consistently high-performing teams. Once a project has won, the team knows it cannot compete in the next quarter, even if it continues to deliver exceptional results.
- Some employees believe the highest-performing project should always remain eligible. Others feel the rule creates opportunities for more teams to be recognized. Both viewpoints have merit, and the discussion continues. The challenge is to strike the right balance between celebrating consistent excellence and ensuring healthy competition across all project teams.
While the Project Award Score continues to evolve, it has already brought about several positive changes in the way projects are managed and reviewed.
Better Visibility
- Project reviews are now based more on facts than assumptions. Teams regularly review defect trends, release commitments, issue logs, and delivery progress using a common set of metrics. This has made project discussions more objective and helped identify areas that need attention earlier.
Greater Accountability
- With clearly defined performance parameters and regular reviews, teams have become more proactive in updating project information, communicating risks, and following up on action items. This has strengthened accountability across project managers, developers, testers, and other stakeholders.
Shared Ownership
- Quality and timely delivery are no longer seen as the responsibility of a single individual or function. Developers, testers work together to identify issues, resolve risks, and achieve project goals. As a result, discussions have gradually shifted from assigning blame to finding solutions and improving delivery as a team.
- The Project Award Score was never intended to be just an award.
- It is a way of understanding project health. More importantly, it is a way of learning.
- Over time, the framework has improved because teams challenged it, questioned it, and suggested better ways of measuring performance. That is exactly how it should work.
The goal is not to create a perfect score.
The goal is to create a common understanding of what successful project delivery looks like and to help every team move a little closer to it.
- As the Project Award Score has now been in operation for more than five quarters, the next step is to analyse historical project score data to measure improvements in areas such as documentation compliance, release adherence, issue closure, and defect trends. These insights will help us further refine the framework and ensure it continues to support fair, objective, and data-driven project evaluation.