5 Tips for Successfully Stating Project Goals

For over two decades, my most important tool for rescuing or successfully delivering technology projects has been reworking the project's objective into a high-quality success statement. This technique is broadly applicable to technology projects. For instance, I attribute the success of a £70 million project rescue to this method. The project involved redeveloping the hardware, software, and network for a point-of-sale system (till) for one of the UK's largest retailers, with over 1100 stores.

The reason is simple: if the team's goal isn't on everyone's mind every day, the project cannot achieve its goal because the destination is unclear. As I've said before, I believe this is the single biggest contributing factor to what research shows: over 50% of projects fail. I can't over-stress the power of a well-formed success statement. While many of my other techniques are specific to digital builds, this one is broadly applicable to technology projects.

1. Make It Memorable

Firstly, the success statement needs to be part of the whole team's DNA, so it must be short and memorable, without jargon. Remember, this phrase is for everyone: users, stakeholders, management, and the delivery team. One of my favourites is "Judy goes home on time." I love this because it is particularly short and punchy, but it is possible to have something slightly longer and still memorable.

The key is that anyone should be able to hear the sentence once or twice and retain its core meaning, even if they use different words or order. For example, "dramatically reduce the number of inbound contacts to a valid student application" is a longer statement, but the extended team reliably replicated it because the core words and concept were easy to understand.

2. Focus on One Thing

The tendency to use commas or the word "and" brings us to the second important attribute of a good success statement – it should focus on one thing, not many. The whole team must concentrate on one problem, not several. In my experience, the business case for most projects lists many objectives without highlighting the most important one. This was something I looked for in my project rescue days because I learned early on that multiple objectives just don't work.

Different objectives typically align with separate sponsors, which means having more than one boss. In practice, this meant the team was pulled in different directions depending on the day and the sponsors' personalities. Often, their objectives were opposing. For example, in a call centre project, the objectives of "increase customer satisfaction" and "reduce cost through self-service" were at odds. The goal of increasing customer satisfaction was owned by the marketing department, while the goal of reducing cost was owned by the call-centre manager. The project I took over was tasked with building a solution for both, which is often impossible in practical situations.

The solution is to break these into separate initiatives. In almost all situations, better results are achieved by making these sequential, not parallel, because they often impact the same systems and people. In most cases, as long as the objectives are not directly opposing, solving one problem often positively impacts solving others. Thus, a follow-on project dealing with problem number two is sometimes avoided because 80% has been addressed by project number one. The key is that removing problem number two from project number one dramatically increases focus and the likely success of project number one.

3. Problem Focus

The third thing we're looking for in a good success statement is (ironically) a problem focus, rather than a solutions focus. When I first ask, "What is our objective?" on a new project, I typically get solutions-focused responses like "we need to replace the student application form," "we need a like-for-like replacement of the call centre application," "we need a workflow management system," "we need a CRM," or "we need Dynamics 365."

The problem with solutions-focused goals is twofold: firstly, they are ambiguous; secondly, they cannot be tested on a small scale before the project is complete. By "ambiguous," I mean there is no clear finish line. For example, how do we know when we have finished "replacing the student application form"? We could go on forever and never finish, with new features being suggested every week. This is the reason for scope creep in all projects. We simply haven't drawn a clear line in the sand.

A problem-focused goal, like "Have I recorded attendance before the class has finished?" has a black-and-white feel to it. In practice, I may include "... for 90% of classes" to be pragmatic, but even in its first form, it's immediately more useful as a yardstick. I can talk to the program coordinators, ask that question, and get a yes/no answer. If the answer is affirmative, then I am done.

4. Test Incrementally

This approach can also be tested on a small scale, which is the second important aspect. In all the solutions-focused examples I gave earlier, the criteria can only be fulfilled once the whole project is completed. I cannot test "replacing the student application form" until it has been replaced for everyone, everywhere, and for all cases.

However, "dramatically reducing inbound contacts from agents" can be tested immediately with one agent out of several hundred without making any changes to internal systems or committing to new technologies. Even better, we can test it effectively with any number of agents, from one to hundreds. This is revolutionary because it allows us to govern success incrementally and even fund projects incrementally. I can ask for 20% of the expected full budget and be expected to deliver at least 10% of the benefit to 10% of the agents before coming back and asking for more money.

5. Define Clear Assessment

The fourth tip in coming up with a success statement is to be clear on who should be answering the question or assessing success. In almost all cases, this should be the primary group of internal users. It should be the group of people who are experiencing the pain today due to not having an adequate solution. For ministerial briefings, am I asking the paper's authors, the coordinators, the approvers, the ministers' aides, or the ministers?

In this case, it was the Judies of the organisation (the coordinators) who were feeling the pain of today's broken process, which resulted in extensive stress and negative impacts on their personal lives due to working till midnight for two nights of every fortnightly sitting of Parliament.

Bonus Tip: Pose the Statement as a Yes/No Question

Tip number 5 is to pose the success statement as a question with a yes or no answer. Regarding ambiguity, there is nothing inspiring about getting to the end of a 12-month program of work and asking, "Have we been successful?" only to get responses like "I guess so" or "meh." We are looking for a resounding "hells yeah!" A sub-tip here is that for an ambiguous question like "Did we reduce...?" simply adding the word "dramatically" at the beginning converts it from a potentially grey answer to something clear-cut, like "Did we dramatically reduce the number of inbound contacts?"

A good success statement does not need to be quantitative. In fact, numbers are typically less emotive than qualitative statements, and setting a quantitative question often requires an existing tracking mechanism or baseline against which to measure an uplift or reduction. The only common exception is measures involving time.

For example, "Can we offer a place in less than three weeks?" (where the current average is around 13 weeks) is clear and time-bound. On the other hand, "Increase customer satisfaction by 20%" is a poor success statement if you are not already tracking customer satisfaction reliably. In my experience, these tips are easy to train and easy to retain. I was using these as step one in my project rescue handbook before I came across the idea of Flintstones pilots, and as I say, the benefits of a good success statement outweigh the benefits of a pilot.

That said, a good success statement paired with the Flintstones pilot approach is a match made in heaven.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.