Fog Creek Software
Discussion Board

"We're in a time crunch on this project..."

" we don't have time to interview the users"

Just had to share.


Tuesday, March 11, 2003

You know what I said about maybe development should look in the mirror?  I take that back.

big bog
Tuesday, March 11, 2003

Oh please. I've come across the following:

"... so we can't waste time planning. We have to jump right into implementation."
"... so we don't have time to test. Just test it while you develop it."

Along with "We have a demo at 2pm, so we have to stop all development at 1:30."

(OK. Not exact quotes.)

What I wonder, though, when managment uses lack of time or money as an excuse to do things wrong (even if it will cost them more time and money later) ... who does have all the time and money they want? (Besides MS, maybe.)

I mean do they think that, at the companies with best practices, the management is sitting around saying, "Folks, time and money are no concern!"


Joe Grossberg
Tuesday, March 11, 2003

Management isn't thinking.

I'm not bashing management; I think that this sort of response is a natural human reaction to a crisis.  Instead of thinking hard, you react.  It's the "fight or flight" response.

This is where a compassionate voice from the ranks can gently provide a rational perspective before it's too late.

Brent P. Newhall
Tuesday, March 11, 2003

I think the problem is with the "compassionate" and "gentle."  I mean, it's unfortunate that most of us programmers are both quiet and optimistic, and it pretty much has to devolve to snowball's-chance-in-hell before we (read I) notice it past our optimism and to life-or-death before we (read I) intentionally break ranks and mention it...

How do you notice things going bad before they're terrible?  And more importantly, once you've done that, how do you give the hint?  And how do you know they've taken it? 

I mean, I've tried saying "This is terrible," before, and rarely do I get any response I can't interpret as "We're in a hurry to meet a deadline for business reasons you don't (need to) know, probably having something to do with the sales guy's commission.  Please stop having an opinion; if we wanted you to have one we'd've told you so.  Real opinions are for managers only; for you to have one is insubordinate and rude and drags down everyone's morale."

Tuesday, March 11, 2003


It's just not your week, is it!?

Did you try to talk to mgt about this? Did you show them any evidence that shows that failing to involve users at the beginning is a blueprint for failure?

I've been told this same thing to, but I persisted with management and made them sit down and listen to me while I showed them why the approach wouldn't work and then, more importantly, asked them to explain to me how they felt the project was going to be success without involving the users.

In my experience, most managers want success, they are just ignorant of how to attain it. Normally, when I clearly communicate the risk and dangers of just jumping in, they usually listen to me. (Not always, though)

So go talk to them!

Go Linux Go!
Tuesday, March 11, 2003

1) We've been pushing for user interviews since the beginning (about four weeks ago).

2) Last week we, the architecture team, decided to stop padding around and confront management with our belief that the deadline was unrealistic (deliver a full client/server case management system for 2000 law enforcement officers by 9/30/2003. Let me point out again that we started four weeks ago and we're in the requirements stage)

3) So when managment reacted badly to *that*, well, it's been pretty unpleasant.

4) The request to meet with the key manager (who was eating lunch and reading email at the time) got us a meeting scheduled for 8:30 tomorrow morning.


Tuesday, March 11, 2003


I once explained that it's a "law" of software that, all things equal, cutting the schedule increases costs and decreases quality (e.g. bugginess, poor design for future enhancements, etc.) and my boss snapped that she had been managing for longer than I had been coding.

I don't see where you get the "quiet and optimistic" bit from. In my (limited) experience, most programmers are realistic and no quieter than most.

I think if people are quiet, it's because they're resigned to the fact that it's unrealistic to expect some people to listen, instead of viewing them as a complainer.

Joe Grossberg
Tuesday, March 11, 2003

Philo can you tell us which jurisdiction this is being rolled out in - I rather fancy increasing my bank balance in the last months of this year!

I'd be rude as hell; inform the management that if they don't do all the work with the users the software will be full of holes, and bring as many cases as you can find between now and the time you have the meeting.

COST THE SCENARIO OUT. Give them the costs of overrun when they find they have to change things mid-contract. Ask them innocently of their legal department has been informed of the addtional liability they may have if their defective software causes the  law enforcement department to malfunction and they are sued for punitive damages as a subsidiary who did not take due care in the process at the design stage.

You probably won't win because human stupidity is a pretty powerful force  and software development is where history repeats itlself in an endless loop.

Stephen Jones
Tuesday, March 11, 2003

Haha, that brought back such fond memories of projects doomed from the start.  Classic disaster.  Hopefully, you're a consultant. 

It's amazing such naive prject mgmt still exists. 

Tuesday, March 11, 2003

Ah yes. It's always heartwarming to see sacred software engineering principles sacrificed in the name of expediency.

UI Designer
Tuesday, March 11, 2003

Learn to ask with a straight face, "Is this supposed to work after we deliver it?" as if you don't want to be disloyal by exposing a scam.

Fondly remembering a disasterous system, that I got brought in on to "just finish up the user interface and help roll it out" after a programming whiz (who only sucked up to the VPs) left the company.  It was supposed to keep track of the budgeting process, but only had one set of hours remaining on project.  If an engineer logged into the system, entering expected hours overwrote the budget.  If someone entered the budget hours, vice versa.  There was no possibility in the system for discrepency between budgeted and actual hours.  Slick.  I explained the whole thing nicely and went back to school.

Contrary Mary
Tuesday, March 11, 2003

As most developers can attest, unrealistic timelines for software projects are a common problem.

Being given an end date (9/30/2003) before your group has even come up with any type of estimates (schedule, costs, etc.) is not that unusual, however, the odds are very good that things will NOT work out as well as your company hopes they will.

I think the general problem is that your group has to work by a set of rules (i.e. software development process), but others in your organization don't want to or feel they don't need to play by those same rules.

The salespeople in your organization seem to be capable of  making up their own project estimates or they seem to have the power to agree to client's business demands which of course you then have to live with.

Imo, if your organization's sales people didn't recieive their commissions until the customer was satisfied then things might work differently in your organization. Also, management would have an incentive manage the customer relationship and let the techies do what they do best.

Sounds like your IT department desperately needs to hire someone who has the clout and the balls to stand up to upper management.

If management won't listen to your group and compromise (i.e. by accepting a stripped down version of the product) then if I were you I would keep my head down, my mouth shut, and do all I can to CYA. If an executive or even a project manager has committed to a project being completed in six months, do you really want to be the messenger who gets shot?

Realistically, the only options you seem to have available to you are:

1) Quit
2) Do what you can to make the project a success and hope for the best

What ever you decide to do make sure your resume is up to date!

One Programmer's Opinion
Wednesday, March 12, 2003

If you've got no requirements then you've got one less set of contraints.

You've got time as a constraint, but perhaps one option is to de-scope features - it is more useful to come back with 'according to our estimates, this time enables us to give functionality x', where x is the set of features you guys think you are capable of delivering within the time constraint.  However you'll obviously still have to spend some time with the users to work out what the features are that are actually needed!

I'm sure this would go down in flames, as the need is to have all the features, all working, in the arbitrary timescale...

Wednesday, March 12, 2003

Right at the very top of your "Top 10 Risks" list for this project at number one put:
1. Poor alignment with customer requirements leads to client not signing of on final deliverable. Probability 96%.
Proposed solution: Interview clients for use cases.
Status: risk reported, solution proposed, awaiting aproval
Make sure the other nine points are reasonable too by tomorrow morning.

Just me (Sir to you)
Wednesday, March 12, 2003

[[ You probably won't win because human stupidity is a pretty powerful force  and software development is where history repeats itlself in an endless loop ]]

Can't say it any better.

Evgeny Goldin
Wednesday, March 12, 2003

"There comes a time in the history of a project where it's necessary to shoot the engineers and start production."

I don't know who said it, but it's often true. :)

Mark Newman
Wednesday, March 12, 2003

And how do you feel when management decides that moment is before the design has been started?


Wednesday, March 12, 2003

This being given an absolute end-date before any real estimates have been done rings a bell with me.

When you get this deal, the most common case is that you have to replace some old legacy system where the vendor is withdrawing support for the old version, and wants a bagfull of money to upgrade to a recent version.

Even though vendors usually announce end-of-life-dates for their old products way ahead of time, it always comes as a chock to management that you cant replace a 10 year old legacy system in four or six months. Management usually wakes up every year, inspecting support deals with vendors, and then spend 6 months arguing if they should pay for a new system out of the left or right pocket.

The estimates is then retrofitted given the original dates; and everybody seem to know they are mostly irrelevant. When the project later fails and goes way over budget nobody remembers the initial restraints that were put on the planning and estimates.

Wednesday, March 12, 2003

Read IT/software disaster stories like these at:,10801,53014,00.html

- AMR Corp - After 4 years and $125 million in development, [the project] crumbled in 1992 when it became clear that [the project] would miss its deadline by as much as 2 years. [The project] died and AMR Corp took a $109 million write-off.

- When it launched a $35 million enterprise resource planning (ERP) project way back in 1993, FoxMeyer Corp. was a $5 billion drug distributor in Carrollton, Texas. Now it's bankrupt. It wasn't the fumbled IT project alone that destroyed FoxMeyer, but that was a critical contributor [...]

A few quotes from the article:

- The root causes of IT failures haven't changed a bit over the years. Miscommunication, hazy goals, "scope creep," inept leadership, pitiful project management - you've heard, if not heeded, it all before.

- Bruce Webster, a director at PricewaterhouseCoopers in Washington recently studied 120 IT lawsuits filed since 1976, and he said he's convinced that most flops could be avoided if people simply knew the time-honored best practices of systems development.

- "There's a natural tendency to get overly committed to something, especially when there are no clear signals telling you you are off course," said Mark Keil, an associate professor at Georgia State University in Atlanta.
Though specific individuals might learn from their own mistakes, those lessons aren't transferred to any collective IT consciousness.

- In IT groups, everyone below Webster's "thermocline of truth" knows the project is sinking, while everyone above it thinks things are fine. Senior executives can be oblivious. They aren't involved enough, they don't want to have to face a failure, or underlings are afraid to tell them, he explained.

Philip Dickerson
Wednesday, March 12, 2003


give us an update after your meeting this morning. Might make life bearable for those of us in similar situations.

Just me (Sir to you)
Thursday, March 13, 2003

One thing that really amazes me is that while production level people (i.e. coders, designers) are expected to be even more and more competent than ever before (cost saving and all that), incredible leeway is given to management in terms of (lack of) competence - when they can gate the productivity of so many people, and potentially waste so much company money.

Whatever happened to the responsibility side of possessing authority? That bit was probably given to the developers.

Thursday, March 13, 2003

The phrase is
"You can delegate authority, but you can never delegate responsibility"

This seems to be one more thing that bad managers have backwards - my ever-loving management team at work have honestly admitted, when pressed, that they are trying to delegate responsibility but not authority.


Thursday, March 13, 2003

*  Recent Topics

*  Fog Creek Home