Success unmeasured is not repeatable.

Occasional success at anything can be a simple struck of luck. The world’s worst project manager can stumble in hangover, meet with the team for the first time in two weeks and discover - EVERYTHING IS GREAT! WE ARE ON TRACK! This is an incredibly rare event and can cause a deep level of confusion about what it takes for software projects to succeed.

In software development two things are true:

1. Success comes through best practices, and
2. Repeated success comes through measurement of adherence to best practices and measurement of key performance indicators

I have been working on a series of articles on best practices. You can find my first three articles here (Risk Management, Adequate Budgeting, Overview). In total, I expect the series to consist of 20 or so articles, with 10-15 process artifacts.

Today, I’d like to focus on measurement of project success.  Let’s start at a high-level and drill down. Project success on agile projects is measured :

1. At a global level - is the project overall on track towards success?
2. At an epic level - this is the largest division of work within a project. It is a high level user story, which is broken down into multiple detailed stories.
3. At a sprint level - Are your sprints on track and do the results of your sprints indicate that your team and the project are positioned to succeed?

We’ll deal with the highest level in this article and expand into measuring project success of epics on Wednesday and then measuring sprint success on next Thursday.

Tracking Success of Your Project at the Project Level 

Your project begins with the project charter. If you have no charter, then it may not even really be a project. The project charter will define a number of key measurements for project success. These measurements should be monitored throughout the life of the project:

1. Project risks

Your risk register should always be up to date. You must review your high impact risks on a frequent basis, document progress on mitigation tasks and document measurements of indicators of the risk event. For example, if a risk identified at the beginning of the project is scalability of the solution, then you should have mitigation tasks to test and improve scalability throughout your project and you should have tasks on many of your sprints to verify that the system meets the scalability requirements.

2. Key milestones

A component of sprint planning must always be to review key project milestones and document risks associated with meeting those milestones. Maintaining a portion of your risk register specifically dedicated to Milestone Risks will go a long way to protect you and your stakeholders from last minute emergencies.

3. Scope Creep

Always have a section of your risk register dedicated to Scope Change Risks covering all major components of your project. Document scope changes against these risk items and follow your change management process. Document the impact to the project in terms of time, cost, risk and scope.

4. Communication

Document and quantify the frequency, quality and clarity of your communication with key project stakeholders. If you have events where the project is adversely affected by some communication failure, it’s critical that you document this against a “Communication Risk” item on your risk register and plan and execution mitigation so that it does not re-occur. This is especially true when you have issues of unmet expectations on the part of a project stakeholder. It is quite dangerous to your project to overlook expressions of frustration or confusion by a key stakeholder.

5. Stakeholder Milestone Survey

The golden key to dramatically increasing perceived project success is frequent, specific, quantified measurement of stakeholder satisfaction. The successful project manager will document stakeholder responses to project success surveys throughout the life of the project. 

These surveys benefit you both in successfully executing the project and in maintaining stakeholder satisfaction levels on your project if you hit bumps in the road. If you handle the feedback received properly, you will build up a reserve of positive energy to be leveraged if risk events occur.

The experienced project manager understands the importance of stakeholder disposition. Critically, you must respond to any expressions of concern, doubt, frustration or risk proactively and communicate clearly. The use of stakeholder satisfaction surveys is incredibly effective in uncovering misalignment of the project with what might be evolving needs within the contracting organization. The surveys also have a great effect in maintaining buy-in among your project sponsors and champions.

It is important to remember the Stakeholder Risks - the risks that stakeholders bring to the project. A chronically disgruntled curmudgeon of a stakeholder can be as deadly to project success as the overly exuberant, non-confrontational, always happy stakeholder.

After building software for business for the past 24 years, I can confidently state that your best opportunity to create an environment for success on your project is to be structured, disciplined and intentional in defining project success and measuring, monitoring and documenting the identified KPIs you and your stakeholders define for the project.