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

[Brad Haslett]

Michael,

Without naming names or going into specifics, an airline I'm familiar
with bought a scheduling software package off the shelf several years
ago without beta testing. They had been warned to run it side-by-side
with their manual schedule building process, but nope, they plugged it
in and started printing (with few restrictions on the 200 or so
parameters it considered).  The company was in contract negotiations
with a very weak union (about 60% membership) but once the "optimizer"
software spit out the new schedules, membership shot-up to 90% and the
software quickly became known as the "sodomizer".

Ah, the law of unforeseen consequences.

Brad

On Wed, Dec 17, 2008 at 11:26 AM, michael meltzer
<mjm at michaelmeltzer.com> wrote:
> 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.
>
>
>
>
>
> __________________________________________________
> To subscribe/unsubscribe or for help with using the mailing list go to http://www.rhodes22.org/list
> __________________________________________________
>