Business will often ask for all they can get when funding a project. Sometimes those things aren't necessary for project success. It is necessary to be willing to identify the "nice to haves" on a project and make sure that they don't impede project success.
Years ago I was assigned to a project that needed to touch ten different and widespread locations, remove the infrastructure currently in place (Westinghouse terminals), and replace it with a distributed environment. To accomplish this, we needed to create a desktop image that was locked down to permit only specific applications. We would have to rewire each location with CAT 5 SE, and we would have to assemble an installation team that could go to each location. We had 16 weeks.
I was told that each location had been surveyed for the existing environment. The appalling lack of information from those surveys is a rant for another blog. I was told that all the circuits had been ordered for each location. This was a true statement by the end of the day it was given to me, but at the time it was not. I was told that I had accurate counts for all the workstations I needed. If you are following the trend, you know that didn't happen. Even though someone had been "working" on this project for months before it was handed to me, very little had actually been accomplished.
I figured out what had to be done and how long it would take. I also figured out that there were a whole lot of "nice to haves" in the project, and in order to accommodate the 16-week schedule, the "nice to haves" had to go. Even if it meant not delivering a location.
I drew up a comprehensive plan and presented it to the business. When they saw the list of things that I deemed to be out of scope for a 16-week delivery, you would have thought I had just kicked them in the shins. All those things were deemed "critical" to project success.
Back to the project plan and back to the technical teams. Was there any way to do all that was wanted within the time period specified? No. And the senior IT exec was willing to communicate that to the business senior exec. Buy-in was achieved, and we thought we were on track again for delivery.
Or not. While the business senior exec had agreed with the IT senior exec that we would not deliver those items deemed out of scope, he either didn't communicate that to the business leaders I was dealing with or they decided to push to see how much they could get.
This saga continued through the implementation. Due to budget issues, it was cheaper to fly me to each location to oversee installation than to get a senior tech and fly him around. And with each location, new out-of-scope issues arose. The Monday morning quarterbacking sessions were attended by my boss. The business would show up and say, "You didn't take care of this." My boss would remind them that it had been agreed that the item had been deemed out of scope. The business would remind my boss that the item had been placed back into scope. I would remind the business that they hadn't approved the additional expenditure to place the item back into scope. The business would remind me that I worked for them. My boss would remind the business that I worked for him. Every week.
At the end of the project, I ran the project-completion meeting. I made very certain that the decision makers were ALL in the room. I ran through the completion list I had created from what we agreed to deliver. Then I asked for sign-off from the business. As I anticipated, the manager I had already had way too many meetings with objected to signing off because there were all those out-of-scope items that he wanted. I presented the business with a project plan to provide all those out-of-scope items, a time line in which they could be completed along with a budget.
Needless to say, I didn't have anything to do with "Phase Two" of that project. But I learned a valuable lesson: Sometimes the best thing to do is say "no." As long as your leadership is standing with you and you can validate the limit, I say set it. Considering that the "nice to haves" on that project would have cost an additional $500,000 and produced no savings or value add, I don't think that saying no was the wrong thing to do. In this case, descoping and declaring victory was the best course of action.