Just Say "No"!

In one of the mailing lists I frequent, someone asked why some businesses just can't seem to "get it" with respect to delivering business value in the form of automated systems.  Most of the process that fall under the Agile umbrella have their roots many decades ago, and companies were using these techniques successfully before I was even born!

So why does this happen constantly in the IT world?  What's the root cause?  Could it be as simple as people not saying the word "No"?  Could it be as simple as the members of a development team not having the courage to say, "This is insane.  We simply can't do it.  I am not going to do it."

Here's a little tale drawn from my years in the software development business.  While intended to be humorous, nothing in this has been fabricated - I've seen and heard all of this occur:

Business Person: We want all of this, yesterday, for free and it has to be perfect.

Manager: I'm sure my team can do it!


Manager: Awright, team, how long do think this will take?

Team: Maybe about 8 months if all the stars align and we change the universal gravitational constant.

Manager: Cool!  You have 4 months to do it.

Team: But...

Manager: And, I've hired a top-notch Project Manager to run the show!  C'mon, you folks are superheroes... I KNOW you can get it done!

Team: But...

Project Manager: Awright... it's time to plan the work and work the plan!  We have 3 months to get this baby airborne so we'd better get on it now!

Team: But we were told 4 months!

Project Manager: That, my friends, is called "buffer"!

Team: But, there's not way we can get all this done in that time!

Project Manager: Nonsense - we have the plan right here that says so.

Manager: The Project Manager has a plan - of course you'll get it done in 3 months.

Team: OK, we'll try.

(2 months and 28 days after project start...)

Manager: How's it going Project Manager?

Project Manager: Everything's trending green, boss!

(3 months after project start...)

Project Manager: Boss, looks like we're going to be a little longer than we thought.

Manager: What?!  You just said a couple of days ago that it was all good.

Project Manager: Yes, well the team hasn't completed everything yet.  80% of the tasks are 90% complete.  Our Earned Value chart shows it right here.

Manager: Hmmm... OK.  How much longer do you need?

Team:  About 5 mon.....

Project Manager, interjecting: Hey, I own the schedule!!  It should be ready any time now.  After all 80% of the tasks are 90% complete.  I'm sure we'll have this ready to ship by the 4 month mark.

Manager: OK, that's what we told Business Person.  Tell you what, I'll hire another 5 people to speed things up so we can make it.

Team: But...

(3 months and 28 days after project start...)

Manager: How's it going Project Manager?

Project Manager: Everything's trending green, boss!

(4 months after project start...)

Project Manager: Boss, looks like we're going to be a little longer than we thought.

Manager: What?!  You just said a couple of days ago that it was all good.

Project Manager: Yes, well the team hasn't completed everything yet.  90% of the tasks are 75% complete.  Our Earned Value chart shows it right here.

Manager: Oh, so 90% of the tasks are complete.  We must be really close.

Project Manager: Uh, yeah... 90% complete... that's the ticket!

Business Person, excitedly entering the room: Hey, is my system ready?!  I can't wait to see it for the first time.

Manager: Uh, not quite.  We're really, really, close though.

Business Person, with palpable disappointment: But you said it would take 4 months!

Manager: Well, this stuff is very complex.  It's on a computer after all.  Project Manager, can you explain?

Project Manager: Sure, boss.  Right now, 90% of the tasks are 80% complete.

Business Person: Oh, so the system is 90% complete?

Project Manager: Uh, yeah... 90% complete... that's the ticket!

Business Person, obviously adept at simple math: So if it's 90% complete after 4 months, it should be 100% complete after 4.4444444 months, right?  Hell, we'll round up the decimal part to 0.5 since I love you like a brother, so you've got two weeks to finish.  We need that system in place no later than that or we will lose out on a major market opportunity.

Manager: OK, I understand that.  But, dude, you shouldn't pressure the team with a schedule like that.

(later, after Business Person leaves)

Manager: Hey, Project Manager, did you like how I shielded the team from Business Person's schedule pressure?

Project Manager: I'm inspired by simply being in your presence.

Team: But there's no way we can finish all the work left in two weeks?  It just won't happen.

Project Manager: But the schedule says you will.

Manager: OK, time for some more management.  What do you need to get this done?  More people?

Team: No!!  That slowed us down the last time you added people!

Manager: Pizza brought in while you're working overtime?

Team: We already get that for ourselves... we haven't seen our families in weeks!

Manager: Ah, I know... digital picture frames for everyone, loaded with pictures of your families!  Consider it done!

Team: Boss, we just can't get all the development and testing done in 2 weeks!!!  It's simply impossible!

Project Manager: I've got it!!  Let's compress the testing cycle, and that will buy us more development time!!

Manager: That's why I pay you the big bucks!

Tester on Team, muttering: I hate my life.

(2 weeks later, at demo of the system)

Manager, proudly: Here you go... one shiny new system!

Business Person: Cool, let me try it out.... hey wait, that isn't what I wanted.

Project Manager: But that's what the requirements document said.

Manager: I'm sure that's what you told me 4 and half months ago.

Business Person: No it wasn't.  Besides, after we acquired that company 2 months ago several business processes changed and now this part of the system isn't required!  Ugh.  OK, let's try this...

Team: You might not want to click that...

Business Person: What the hell?!

Manager: Uh oh.

Project Manager: I hear my Mother calling...

Business Person: I've never seen a computer do that before.

Manager: I'll call Facilities...

Team: Time to polish up the resume.

Contractors on Team, calling their pimps: Hey, how are you? I'm becoming available in the next few hours...

OK, so I haven't actually witnessed a Project Manager say that his Mother was calling... I'll claim dramatic license for that one. ;)

However, what would have happened if the people on the development team had simply said "No" to an unrealistic schedule at the very start?  Would they have been fired?  If so, it likely would have been a good thing for them in the long run.

Most people fear the repercussions of disappointing others.  If they said, "No" to the Manager at the start, he would have been disappointed and it may not have been very pleasant.  Compare that, though, with the long term implications of simply putting up with imposed deadlines, fixed scope and fixed budgets.

If you want to stop the insanity, just say "No".


Mark Bostleman said…
The answer can't be "No" unless the business can also say "No" to the market - which they can't.

Instead, the answer could be "No, but...what we could have in 2 months is X so that you can get started and then Y two months later if that's the right next step once we see X working".

Whether you can get a business to think about software that way seems like the real challenge.
Dave Rooney said…
Yes, that's exactly the way it should work. I wish I saw that more often.
vwdiesel said…
The problems I have seen appear to stem from the bits of the organization (business included) not being able to think about things in incremental fashion - incremental delivery (like outlined in the first comment). This goes deeper than the business though - design, IA, etc. also see the system only in its 'complete' state rather than how the system will evolve over time. That, in my opinion, is the major short coming of companies... it is really hard to hear the developers say NO BUT and then attempt to deliver something incremental when the entirety of the organization doesn't see ANYTHING in that way.
Ilan Pillemer said…
What I do is this.. I say I want to make it clear that it will not be possible in this time frame for reasons (a) (b) and (c). You can still go ahead with this plan as its your decision and not mine. But I take this opportunity to make it clear that I disagree with the decision and I will say "I told you so" when it does not work out. After I say "I told you so" at least once... then my words become heeded. I have found in the sofrtware development industry one achieves status and recognition by accomplishment and vision. So I don't say "No". That is simply rude and aggresive and confrontational. I give a reasoned and detailed account of why it will not work out; as well as a recommendation on what we should offer. And if my reasoned explanation turns out to be right; the next time the manager in question will listen.
Jan Machacek said…
The way I like to see it is that the IT department's answer should always be yes, we'll do whatever you want. But we're not moving the deadlines and we can't get any more work done, so we take it the new stuff you're asking us to do is more important than everything else. Right?
And then let the business decide.

I think the 'no' answer applies to questions (and pressure) like
* can you put in some extra time this week?
* let's just delay the deadline, only by a week
* just hack it together, we'll worry about refactoring | testing it later
sanj sahayam said…
I totally agree. Programmers need to be more "professional" when given unrealistic requirements. There's always the chance that you could fired for such insubordination. Maybe it's a chance we need to take. I wrote a post on some similar ideas -> http://bit.ly/f2fbYO
Anonymous said…
We say "No", "That's impossible," and "It will take at least 12 months and $500,000 more than what is in the sales contract" - on an unfortunately regular basis.

A few days later we hear, "Remember that prospect I mentioned a few days ago? They signed the contract. Start working on their project plan, it needs to be done by next week. And be reasonable about the timeline, once we get the plan done we need to stick to it. They want to be live in 5 months."

... and then we wonder if anyone was listening when we said, "NO."
Dave Rooney said…
@anonymous Yes. And how well has that worked for your organization? How many happy repeat customers are there? How big is your defect database? Can you quantify your technical debt? How many times have you rewritten your product because it couldn't be extended anymore?
Dave Rooney said…
@Jan Interestingly, I can think of situations where you could (and possibly should) say Yes to those things:

* Something unforeseen was encountered, but could be addressed with a few extra hours of work in order to hit a release deadline

* If scope can't be variable, then something else must be. If the schedule can be variable, then that's fine.

* You may want to incur some technical debt in order to meet an important deadline like the Christmas shopping season or perhaps a trade show.

Note, though, that all of these situations require that the people involved understand the implications and that each one is temporary:

* working constant overtime burns people out eventually, killing their productivity

* constantly slipping schedules will erode customer confidence in your ability to actually ship something

* you have to pay off that debt at some point, and the longer you wait the more it costs to pay it off

Orange Juice Test. It works.