Measuring success

In most organizations, there is a set of requirements for projects that need to be satisfied for that project to move into a state where it is no longer actively worked. I think the states, finished and canceled are what we call it. We often overload those terms, finished and canceled with the concepts of success and failure.
If we've finished the project according to plan, we've succeeded.
If we don't finish the project according to plan, we've failed.
Consider software. What makes software successful? I judge the success of the software that I use based on its ability to meet my needs. The software that meets my needs best, is the software that I like the best. Take Beyond Compare for example, as I wrote earlier, Beyond Compare meets my file differentiating needs better than any competing product I know.
I don't know how it was made. I don't know if it was delivered on time. I don't know if it fulfilled all of the business requirements. I don't know if it was delivered within the budget. It could have been created by an 8 year old Romanian kid for all I know and all I care.
All I care about is the product's ability to differentiate files. It does it better than anything else I've used. Until, or unless, I find something that does it better I am going to continue to use BC and recommend it to others.
All of the criteria I use to evaluate software does not directly relate to how it is made. Am I saying that deadlines and budgets are unimportant? Yes and no. They are important, but by themselves do not measure the success of an effort. Often times, the metrics we use on projects are incidental to the purpose of the project.
We do projects to meet a need. Our metrics usually focus on how much something costs, when it is finished, and is it what we thought it would be when we started. On budget, on time, and complete. You could meet all three of those goals and still provide something that doesn't meet the needs that the project set out to meet.
On time, on budget and complete are easy metrics to measure. The guys in finance love these systems because it fits in their spreadsheets. If I were solely interested in promoting myself within an organization, I'd like this type of system too. I could game the hell out of it. You measure me by my numbers? Ok, I'll make my numbers better than anyone else.
What is the true measure of success? It's not easily defined. You aren't going to see it on delivery date. You're probably not going to see it within a year of delivery. It's going to be well down the road from when you're finished when most of the people in a project have moved on to other things.
I would like to try measuring the happiness of a team in a project and correlate the happiness of the developing team to the satisfaction and resulting happiness of the customers. I think happiness is as good of a metric as anything else. If a team is happy, it seems like a safe assumption that the team members are likely to be motivated to put extra care in their work and take more ownership of the project. I would also assume that a happy team is one that is more motivated.
There are many elements that can make a team unhappy. I think it is the task of leaders to eliminate and minimize as many of the unhappy elements as they can. Elements that make teams unhappy are the same elements that unhealthily distract team members from their projects.
Unhealthy distractions are the things that cause team members to gripe or despair. Those unhappy activities spread unhappiness. What causes unhappiness? Many things, a short list would include isolating team members from what they enjoy, requiring wasteful and/or tedious administrative work, e.g. unnecessary documentation, disenfranchising team members, and the list could go on.
The irony is that many of the unhealthy distractions are a result of disconnected managers trying to increase productivity by reducing what they perceive as waste. For example, when managers implement web filters that are overeager to banish sites that have the potential for abuse, e.g., youtube, then a negative net effect can occur instead of the desired reduction of waste. There are legitimate productive uses that are lost in the name of stopping lallygagging.
Healthy distractions are distractions that have a positive effect on team members' happiness. If we can accept the fact that team members need breaks, then why not support them in distracting themselves? Provide break areas that encourage collaborative breaking and you'd be surprised what comes out of it.
Facilitate happiness. I think that what we'll find is that if we focus on the happiness that the other metrics will reflect a happy and healthy project.
With that said, still take all the metrics you normally would and add at least one more: a team happiness quotient. Find a way to gauge team happiness and track the hell out of it. More on how to do that on another day. If the team's happiness level is dropping, find out why and fix it.
As time progresses, the other metrics should trend towards the happiness quotient.
Because you really can't tell whether a project is successful at the time when it is delivered, why not keep the metrics from the project and determine how well it met its goals at a time when that can be measured. I am willing to bet iPhones to donuts that the happier projects are going to be the ones that are the most successful.