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

[Herb Parsons]

I thought you were submitting a joke, not a reality script.


michael meltzer 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
> __________________________________________________
>
>
>   

-- 
Herb Parsons