As an IT manager, you have probably lived through an “IT project from hell.” A project where the requirements morphed every time you looked at them, the timelines were unrealistic, and the outcomes didn’t come out the way the client wanted.

If you have — and you want to avoid a repeat performance — here are five strategies to employ the next time someone says, “Hey, I have a new project I’d like to discuss with you.” If you haven’t experienced an “IT project from hell” in your professional career, these strategies will help make sure you never do.

1. Cut out the chatter so you can hear what’s important

IT projects from hell usually start with you as the only IT person in a room filled with business users … all of whom are eager to explain what they want, why they want it, when they want it, and all the rest of it. You get informational overload in a matter of minutes.

Stop, take a deep breath, and remind yourself: “Not all these people carry the same weight — even if they are all in the same room!” That means you need to really listen to some of them, and you can (mostly) tune out some of the others.

As a result, your first objective in a project kick-off meeting is to clearly understand the org chart for the project: Who is responsible for giving you the technical requirements? Who, from the business side, is going to sign-off on those requirements? Who has input on timeframes and budgets?

Once you have established this all-important list, email it to the stakeholders for the project. You want everyone to be perfectly clear who is in charge, and what they are in charge of. You will then know how to cut through the chatter to hear what’s really important.

2. Separate “need to have” from “nice to have”

Distilling what you hear in the kick-off meeting and documenting the requirements of the project so that everyone is on the same wavelength is absolutely necessary. Not doing so is an invitation to disaster.

However, a serious mistake IT managers make is combining “nice to have” features with “need to have” features when they document the requirements. Later, during implementation, this can lead to the IT team losing focus on what was supposed to be delivered.

Take time upfront to separate out “nice to have” items from “need to have” items. This may require conversation and even negotiation (since not everyone may agree immediately as to which is which). Your final list will clearly show the critical features the solution must have, and the features that can be added in future phases of the implementation.

3. Learn to say “No”

As you sit in the room during the project kick-off meeting, ask yourself, “Do I have the bandwidth to take on this project?” Answer honestly. If you aren’t sure, the answer is probably “No.” Perhaps the timing is bad, or your resource allocation isn’t optimal, or your other projects have to take priority.

If the answer is “No,” then you have a very difficult task ahead of you: you have to tell people, “We can’t do this.” Don’t say “Yes” just for the sake of making everyone happy. If you do, you will regret it later when you are scrambling for resources, working outrageous hours, rushing through important steps, correcting errors, or — worst of all — completely failing to deliver.

4. Avoid scope creep

Let’s say you’ve gotten past the project kick-off phase. In fact, you’ve gotten through the majority of the work and you are now in testing. And during testing, the business teams ask for additional features to be included.

You should expect this to happen. Testing is where users get to play with the actual solution. It’s no surprise that they will think of ways to enhance it. But you have to have your response in place. It will usually be: “No” or “Not now.”

Certainly, you should listen to all recommendations, document them, and consider them for future phases of the implementation. There are even the occasional ones you will want to do “on the fly.” But if you always succumb to the people who are urging you to add this and change that and modify the other thing, you will get into the world of scope creep and your project will never end.

5. Define what you are testing

Not having a clear-cut testing plan to sign-off on the solution is a sure-fire way to shoot yourself in the foot. What happens all too often is that development ends and the solution goes to the testing team. But the testing team doesn’t test what you thought they would test, or how you thought they would test it. The resulting cry of “it was supposed to do this but it’s doing that” will get you stuck in IT project hell … just when you thought the end was in sight.

Instead, specify early on in the process the exact use cases you want the testing team to go through. It should be understood that sign-off is on those and only those use cases — and that once sign-off is given on those use cases, the solution is ready to go live.

No one wants to live through “the IT project from hell.” Who knows — with these five strategies firmly in mind, your next IT project could be a slice of heaven.