I have played a role in many successful projects over the years, but there were some that ended with failure. Those that did had one thing in common, a failure to align the project with the enterprise goals. If the organization is not aligned on the reason for the project, project participants are going to struggle to determine what should be in scope and what is the definition of done. It’s a simple question. Why are we doing this?

I had a college professor who owned a software development company tell a couple of stories about projects he was paid to do that I think help provide context around the question of why. They went something like this. A brand name company was selling insurance on their website and felt they had a high abandon rate. They hired him to solution and implement a way to track and record every interaction and all data entry on their site regardless of whether the user submitted the data or not. They were hoping to capture enough data to identify the user and quoting my professor, “hound them to close the sale”. He found a company that provided the service for a fee and all he had to do is embed some code on the site. (Side Note: There are some really cool tools to help accomplish this out in the market place). The cost of the tool was $25,000/month and the entire project over 3 months came to about $200,000. The team got back together to evaluate the results and it turns out an additional $20,000 in revenue was generated. Everyone was excited and someone asked how can we double our return next time. My professor raised his hand and said he can guarantee a way. Everyone perked up to hear his idea. The solution? Hand him $200,000 and three months later he would write a check back for $40,000. The point of his story was that people get so excited about things that they lose perspective. He considered the project a failure.

I would argue that to determine if the project was a success, you would need to understand the reasoning behind it and whether the solution implemented was the right one. For example, if the driver was to increase revenues, then it’s a win. The solution provided and implemented delivered more revenue. If the goal was to increase income, then it’s a loss. The solution was too expensive to offset the revenue gained. What if the driver was to improve the customer experience? In that case, the project failed. The failure started with the agreed upon solution. Collecting the contact data and having a sales team reach out to close the deal didn’t meet the driver of understanding the customer experience. If the intent was to improve the customer experience, the focus of the project should have been determining what caused the users to abandon the site in the first place. The data provided should have included details of when and where the user abandoned the site. Part of the follow up process should have been to ask about the user experience. The meeting should have started with the findings and the question of how do we improve the customer experience going forward?

The second story was about a successful project that drives home the point about the importance of why. A privately owned company with about 100 employees hired him to build an internally facing website to provide employees with company updates, event information, and contacts for employees. The owner requested 100% uptime. He approved the highest package to host the site, almost $2,000/month to ensure that happens. The cost of the project was $25,000 to implement. The owner loved the site and was so excited about being able to finally communicate with his organization consistently. My professor said it was crazy to spend $2k a month for a site that made no money, but he made a valuable point. The owner’s driver wasn’t to make more money. His driver was to improve the employee experience, deliver better communication, and make sure his employees felt valued. Spending $2,000 a month to make that happen was worth every penny to his organization and the project was a complete success.

The answer to the question of why is unique to your enterprise at a specific point in time. Corporate objectives and key results (OKRs) should be the key driver to help determine the value of a project. As those change, so should the value of delivering any project. Anyone in your organization should be able to easily determine the value of a project without knowing anything about it specifically. Anyone involved with the project should focus to ensure the scope and solution being delivered brings that value at the end. I have seen organizations really struggle to communicate openly, from the CEO on down, the reasons for doing things. I also see a lot of projects have scope creep that has nothing to do with the objectives. These things can really impact the perceived value of completing projects. Most importantly, the IT organization usually takes the blame.

I once worked to help start an innovation board at a company. The first thing we realized we needed was a broad group of members that could speak to impacts and value on different parts of the organization for the suggestions submitted. The second thing we realized quickly is we needed to be able to score that value based on a set of criteria to determine which innovations we should try and to determine if they were successful. We made all of the suggestions, their scores, and results available to the entire organization on a SharePoint page. Doing so not only allowed everyone to see the projects and the reason for them; but, additionally, it turned out a lot of the organization had the same struggles. In some cases, others had already implemented solutions, but those were not communicated to others. The same approach can be taken from a project perspective. You can use any tool you like to make the scoring and results available, but I think its necessary. It increases accountability and encourages others to voice their concerns or support for the projects.

Let’s talk a little about what a score card should be. It should be simple, easy to understand, and easy to change to match the current company OKRs. It should be easy to identify the owner and the executive sponsor. It should include a complexity score and a brief description. Remember, all project requests are scored to understand the why, even before they are approved for requirement gathering, solutioning, and project planning. The score can change as the requirements are gathered and the solution architecture is developed. Most importantly, if implemented, everyone can determine value delivered by the project. Here is an example of a score card you can use to build out your own.

Remember, the score card needs to make sense to your organization.

I don’t want you to walk away with the idea that understanding the why guarantees project success. What it does is provide the framework for the project scope and the solution design. It helps bring engagement across your organization and it helps everyone work towards the same goals. Implementing a scorecard will help your organization focus its effort on the company objectives. Consider it a game plan for that awesome team you assembled.