Saying No to overly complicated cloud projects

Saying "No" will keep a project on track and your credibility intact.

Of course this is heresy. User-centered design is at the core of good UI. It would be political suicide for IT to say "No" to powerful users. IT engineering exists to serve the business, not order it around.

All those statements are true. But so is this: Saying "Yes" when the answer really needs to be "No" is an invitation to a project failure. Improper expectations don't just hurt budgets and schedules. They damage credibility-and, in the end, they force you to expend resources when you shouldn't have to.

Saying "No" Part of a Painful Conversation

Unfortunately, the longer the project takes, the greater the likelihood of the scope creep that is the bane of project management. It's hard to know which form of scope creep is worse-explicit (adding features to compensate for being late) or implicit (when users cry, "But I thought the system would just work that way").
Of course, you can try to resolve this by having an air-tight spec. Have fun with that-it's rarely effective, and it usually mires you in microscopic thinking that guarantees you'll miss something important.

It's no accident that Agile advocates short projects and minimalist specifications. The goal is to have the team with a small number of deeply motivated and detail-knowledgeable people moving as fast as possible down the field. It's also no accident that an Agile increment is called a scrum, from the root of the word scrimmage.

There's no market for bad news, so nobody wants to be the person saying no all the time. Let's take it one step further-in many cases, if you clearly say "No," you're asking for retaliation, often in the form of an even more firmly stated requirement. That's just how people act.

Keeping that in mind, here are three conversational tactics for saying "No" that I have seen succeed.