Every late project I’ve been a part of has had one thing in common: We didn’t say no enough.
No to ourselves, to try to ‘future proof’ the system.
No to our customers who wanted the system to do ‘just one more thing’.
No to the business people who insisted on working overtime to deliver the ‘just one more thing’ customers asked for.
French Culture is intriguing in this regard.
There’s a particularly relevant quote from the article: “Answering ‘non’ gives you the option to say ‘oui’ [yes] later; [it’s] the opposite when you say ‘oui’, you can no longer say ‘non’!”.
Think about that. When you say yes, you can no longer say no.
And it’s true. We want to be accommodating, we want to give our customers and stakeholders what they want. And we somehow believe that by saying ‘yes’, we’ll be doing that.
What we’re actually doing is we’re adding time or money (or both) every time we say yes to a feature request, enhancement, bug fix. Software is a strange beast that way: If you don’t build a feature, it doesn’t exist. Not building a feature is free. If your business is deadline or date focused, not building a feature helps ensure you meet the deadline.
It’s by no means scientific, but the next time you either ask or are asked to say “yes” to something, think of it this way: Every yes adds time until whatever you’re working on will be shipped.
Big request: 6 weeks
Medium sized request: 3 weeks
small request: 1 week
That also causes a dilemma: The time you should say no the most is at the beginning of the project, when you know the least. Save the “Yes” for later or late in the project, when you have a better understanding of whether you can afford to add scope. Say no at precisely the point in the relationship where everyone is expecting ‘yes’.
That’s hard. That’s also a crucial way to build trust with deadline-driven stakeholders.