How to Define IT Project Success

When you're pitching a project, it's easy to get caught in the classic mistake of overpromising. After all, you want your project to get funded. But overpromising will inevitably lead to a big letdown, so it's important to define project success in a way that's fair to the technology, company, and you. Here are a few ways to reach that balance.

The first problem is managing project scope

Managing project scope can be tough. It's easy to sketch the outline of an excellent solution and visualize the tasks you know need to get done falling into place like dominoes – with no interruptions, missteps, gotchas, or unforeseen changes in direction.

The customer doesn't have a firm idea of what they want. The problem and solution space aren't thoroughly understood. Perhaps you envision delivering something that's novel and untested. That's certainly exciting, but how do you deliver? Meanwhile, the business environment is changing around you as you're working.

It's no wonder that the overpromise is baked into expectations.

How do you avoid overpromising? To define what project success will look like in a compelling but realistic way, you must:

• understand your customer's underlying objectives;

• be able to estimate what you can reasonably achieve;

• agree on the scope of the solution, collaborate to prioritize, and;

• be prepared to manage changes in scope.

Keeping promises is essential to healthy business relationships — and referrals grow out of trust.

Scoping out the project consists of collaborating with the customer to clarify your mutual understanding of the problem and arriving at a realistic plan of action to meet their needs.

Understand your customer

The most important element to defining project success is understanding your customer. We've seen this problem in things as seemingly straightforward as cloud migrations. After all, it's the "unknown unknowns" that will get you. The customer's expectations — and your own — must be clearly understood.

Your key, upfront goal is to elicit and understand what the customer wants to achieve by means of this project. What strategy is this effort intended to advance, what is the desired outcome in terms of their business goals?

Solving the customer's problem within the constraints at hand – particularly schedule and budget – is the heart of engineering. But a project may be on time and under budget and be judged a failure. It may be late and blow way past its budget, but still be seen as a success.

Knowing the customer's underlying objectives is essential. What do the relevant stakeholders want, and in what priorities? The customer may not have fully thought through the objectives and goals that motivate this effort. Their initial idea of the desired solution may be half-baked. This cannot be left to guesswork. A dialog is required.

Estimating what's achievable

A realistic promise of deliverables depends on good plans and accurate estimates. Be wary of biting off more than you can chew and know how much overrun you can absorb.

There are aspects of planning and estimating that can be learned from studying. You want to factor the tasks into small elements you can estimate and make sure you are covering the entire effort. Agile has some good tools to help with these processes — like burndown charts and planning poker.

You want to consider the availability of needed resources. Your schedule and budget should be a bit generous so you are not too dependent on poorly predictable items. You want to include flexibility to handle risks and opportunities.

But estimating well depends in large part on experience and baseline data. Your known biases improve your initial estimate. You should ask yourself:

• What types of personalities do you have on your team?

• What problems tend to crop up?

• What gotchas did you miss in previous plans?

• How good are you at estimating?

Your up-front plan and estimate at project proposal time will be rather high level and fuzzy, but with knowledge and experience, you can give the customer a realistic basis for evaluating your idea.

Agree on the scope in writing

Despite a good effort at all the above, if the customer does not clearly understand what you are promising – and what you are not – you may fail to meet expectations. If either of you has an uninformed or vague understanding of the project's scope and success criteria, you and the customer are walking into a minefield. That's why you need to agree on a written scope of the project.

The goal is to establish accurate expectations up front. Both you and the customer need to have as good an idea as possible of what you will be doing for them before you mutually commit to it.

The scope document communicates your commitment to the project. It states your understanding of what the customer needs, what you plan to do, and what that will cost. It reflects how you have thought through the pieces of the effort, the who, what, how, and when. It also states what won't get done – what you won't be delivering. Stating what is out of scope prevents unwarranted assumptions, so the customer doesn't feel cheated later.

The written scope may be a formal document, or it may be an email with adequate details laid out in bullet points. Having the scope in writing, understood and agreed to, circumvents the problem of differences in how things are heard and interpreted. It's also the key prerequisite for fighting scope creep as you go forward.

Prioritizing and change management

A realistic project definition acknowledges that change happens and recognizes that not all goals have the same priority.

An application of the Pareto Principle states that 80% of the desired functionality for a deliverable comes from 20% of its features. It's important to know how the customer ranks the project goals. Which ones are the essential ones?

If you know what is critical to satisfying the customer, you can distinguish between what is necessary for a full delivery, what is a nice-to-have, and what is gold plating you are better off without. You have a basis for offering multiple alternative solutions upfront and for proposing how to descope if you are later running low on time or budget.

Change is natural — and there are ways to handle change well. Your project definition should discuss upfront how you will handle surprises and how you will address requests for changes. To prevent uncontrolled scope creep and resulting customer dissatisfaction, state how additional work must be agreed on and paid for between both parties.

The Significance of Agile

It's worth noting that many of these issues are organically addressed in agile methodologies. Agile projects ensure close ongoing interaction with the customer (or the customer's agreed-on representative). The scope is refined over time and prioritization is a regular activity. Frequent deliveries of working subsets enable regular feedback and input on scope and priorities for the next iteration.

Conclusion

How do you avoid overpromising and missing customer expectations? Defining what project success looks like in a compelling but realistic way is a matter of understanding your customer's underlying objectives, planning and estimating what you can reasonably achieve, agreeing in writing on the scope of the solution, collaborating to prioritize, and being prepared to manage changes in scope.