[Rhodes22-list] 26 Ways To Know Your Software Development Project Is Doomed

[michael meltzer]

26 Ways To Know Your Software Development Project Is Doomed

 

- Esther Schindler, CIO

 

Despite all our efforts to make every software development project a
success, some are cursed from the very start. Here are 27 early warning
signs-all, alas, real-world experiences-that an enterprise software
development project is headed for a death march.

 

1.      The project name changes for the third time in as many months.

2.      The development manager decides that it is better to write a
completely separate version of the software for the U.K. rather than to
internationalize a single version.

3.      The requirements definition is begun four months after development
started.

4.      The newly hired director of R&D proudly informs the board of
directors that the project will be 99 percent completed six months ahead of
schedule, and assures the board that the software can ship directly to
clients without going through beta testing.

5.      You are a Web developer. You open the ZIP file with the HTML
documents the client produced for the site scripts you need to integrate
with the Web application. And you discover the client's HTML documents are
all Microsoft Word files, saved in HTML format.

6.      You realize the reason the company hired you as a consultant is to
referee a dispute among two competing departments over which technical
platform to use.

7.      The memo says you will develop a 64-bit application using a 16-bit
platform.

8.      The developer doesn't understand the spec document and continues to
develop anyway. And the QA team doesn't know how to test, but they "test"
anyway.

9.      When you see the project budget, you realize that over half of it
was spent on a Web designer to create a Photoshop mock-up of the home
page-with no regard to whether that design is feasible. Or with any
attention to the thousands of pages of content that will exist underneath
that home page.

10.   The user or client requests new features instead of focusing on bug
fixing and performance enhancements.

11.   You find a list of 16 software development best practices and realize
that not a single one of them is being followed.

12.   You are asked to port your project from Windows to MS-DOS.

13.   The technical project manager asks you to compose the list of user
requirements-without consulting any actual potential users.

14.   People started sending notes "to file" rather than to each other. The
notes are alibis about why the sender has nothing to do with the upcoming
(but unacknowledged) failure.

15.   Status reports are seen as insubordinate.

16.   The new CIO replaces all the people who have deep organizational
knowledge with outsiders from his old firm.

17.   It is a big project and is named Project Iceberg. Or it's the third
time the company is trying to pull this off, and the project is code-named
"Phoenix." Somehow, you don't believe this one can spring from the ashes.

18.   Even the customers who got the free version are pissed off.

19.   The manager of your mission-critical project (handling 80 percent of
the company's revenue) has three months exposure to the technology of
choice, and is training four brand-new developers at once. The manager is
given a three-month project deadline.

20.   You learn that management had to insist that the interface definitions
be checked into version control after the first code freeze.

21.   They change the project manager and relocate the whole project from
one city to another. (You consider yourself lucky that the cities are on the
same continent.)

22.   The QA team is told, "We've only allocated three weeks for testing"
(on a project that has lasted six months already). Or QA is told, "The date
is fixed. We have to have all this functionality by that date."

23.   The program manager decided to try Agile methodology "to save time."

24.   In a previous era, pre-cell-phones and ubiquitous Internet access: You
get screeching abuse from a new project manager hired three days ago in New
York, after you return from three days locked in regional CIO meetings in
Frankfurt. Why? Because you hadn't responded to the e-mail messages she had
sent (and which you didn't get), and you hadn't updated her "project
dashboard" that you knew nothing about.

25.   Management decides to spend a million dollars on a $20,000 project.
Then the managers start agreeing with computer company salespeople that the
$1 million in software requires $2 million of hardware. Meanwhile, a
secretary purchases an off-the-shelf PC and a shrink wrapped CD containing
some new office automation packages. She implements the project during her
lunch break. (Arguably, we should count this one as a success.)

26.   The lead developer tells you that maintaining a complete history of
all database updates is a requirement for the application, but he hasn't had
time to (read: doesn't know how to) design a data model for it yet. So he
decides to go ahead and start with the Web front end and worry about it
later. And this is the lead developer.

27.   The business line leader/project funder says, "Get creative." This
happens after management reduces the project headcount by 20 percent. And
after the IT team pulls out the hardware that had been slated for recycling,
saying it's your project's new hosting environment.

 

That's a list based on input from dozens of software developers and IT
professionals. But, alas, it is incomplete.