Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Anatomy of a Runaway Project

kdawson posted more than 6 years ago | from the off-the-tracks-and-ploughing-up-dirt dept.

Businesses 326

JCWDenton recommends a piece by Bruce Webster revealing some insights into a failed multi-million-dollar IT project. "The following document is the actual text — carefully redacted — of a memo I wrote some time back after performing an IT project review; names and identifying concepts have been changed to preserve confidentiality (and protect the guilty). The project in question was a major IT re-engineering effort for a mission-critical system; at the time I did this review, the project had been going on for several years and had cost millions of dollars; it would eventually be canceled and the work products abandoned. The memo itself provides an interesting glimpse into just how a major IT project can go so far off the tracks that nothing useful is ever delivered."

cancel ×

326 comments

Sorry! There are no comments related to the filter you selected.

Irony (-1, Offtopic)

damn_registrars (1103043) | more than 6 years ago | (#23826585)

Anyone else find it ironic that this story about runaway development projects came right after the story on the release of wine 1.0?

Considering how many different sets of expectations exist for wine, one would expect it to be on the verge of becoming a runaway project itself...

Re:Irony (3, Insightful)

smeat (18128) | more than 6 years ago | (#23826707)

Other than the fact they are delivering something...

Re:Irony (3, Funny)

pitchpipe (708843) | more than 6 years ago | (#23826711)

How about Anatomy of a slashdotted server?

Re:Irony (4, Funny)

Stormwatch (703920) | more than 6 years ago | (#23827297)

I wonder if their server is the failed project...

Re:Irony (1)

Zwicky (702757) | more than 6 years ago | (#23827915)

We're killing the Internet!

Re:Irony (4, Insightful)

IamTheRealMike (537420) | more than 6 years ago | (#23826725)

I dunno, for it to be ironic Wine would have to have shared some of those characteristics, but it really doesn't.

In particular, the key problem with FUBAR project appeared to be Mr Bob Winsom, whoever he is, who was clearly not technical or competent but believed he was. Wine is led by Alexandre Julliard, who is every bit as competent and skilled as Linus Torvalds himself, if not moreso, the primary difference being that Linus quite a loud person and AJ is not.

Wine has taken a long time to reach 1.0 (a rather arbitrary line in the sand) because Windows is a huge codebase, which is very difficult to match exactly to the expectations of the apps running on it. At its peak Windows had over 5000 engineers working full time on it, something Wine has never had.

Re:Irony (5, Funny)

jd (1658) | more than 6 years ago | (#23826945)

The thing is, 5,000 engineers horsing around isn't the same thing as a 5,000 horsepower engine.

Re:Irony (2, Funny)

smitty_one_each (243267) | more than 6 years ago | (#23827489)

For all the crap output may equal that of 250 score horses.

Re:Irony (5, Funny)

192939495969798999 (58312) | more than 6 years ago | (#23827889)

Like I always say: Winsom, lose some.

Re:Irony (5, Funny)

smitty_one_each (243267) | more than 6 years ago | (#23828187)

That's the first time in 1,640 posts you've said "Winsom, lose some", you big fibber.

Re:Irony (3, Interesting)

Enleth (947766) | more than 6 years ago | (#23826957)

I don't see a similarity, really.

Wine is actually an example of something extremely rare - a project that looked like it was doomed from the beginning, took millenia to get to the current state, but achieved usefulness anyway. Most of the time it works and when it doesn't, most of the time it's just common bugs, not incompleteness.

Re:Irony (2, Insightful)

Dystopian Rebel (714995) | more than 6 years ago | (#23827101)

Anyone else find it ironic that this story about runaway development projects came right after the story on the release of wine 1.0?
Sir, it is not ironic at all, unless Alanis Morissette is your English tutor.

In any case, the project to which Mr Webster refers is clearly Microsoft Windows Vista.

Was the project... (-1, Troll)

RyansPrivates (634385) | more than 6 years ago | (#23826589)

...the Firefox 3 Release?

\.ed already? (0)

Anonymous Coward | more than 6 years ago | (#23826653)

Not even 3 comments before the article was \.'ed to death.

Re:\.ed already ? (3, Informative)

bfwebster (90513) | more than 6 years ago | (#23827409)

I'm a bit stunned myself. The article had been picked up by reddit and FARK prior to Slashdot, but even so, I've had another post on my blog previously linked to by Slashdot [slashdot.org] without server problems. I've already contacted my hosting company to find out what's going on.

Re:\.ed already ? (1)

olyar (591892) | more than 6 years ago | (#23828155)

The difference (I'll bet) is that the prior link included enough of the original article for the vast majority of slashdotters to just read that and then dive into the discussion.

I'll freely admit that I only RTFA on about 5% of Slashdot stories. This story was one of those where I was on the way to follow the link, because it sounded very interesting not just for the subject matter, but for the actual content.

Text of Article (4, Informative)

gammygator (820041) | more than 6 years ago | (#23826709)

The site is acting like it is soon to be slashdotted...

Anatomy of a runaway IT project

By bfwebster on Jun 16, 2008 in Main, Management, Project Failure

[Welcome to reddit and FARK visitors!]

The following document is the actual text -- carefully redacted -- of a memo I wrote some time back [i.e., several years ago] after performing an IT project review; names and identifying concepts have been changed to preserve confidentiality (and protect the guilty). The project in question was a major IT re-engineering effort for a mission-critical system; at the time I did this review, the project had been going on for several years and had cost millions of dollars; it would eventually be canceled and the work products abandoned. The memo itself provides an interesting glimpse into just how a major IT project can go so far off the tracks that nothing useful is ever delivered.

Note that the "ABC" consultants were a small part of the overall project team and had been brought in relatively late by "BigFirm" in an attempt to get the "FUBAR" project into production; they neither initiated nor managed the project. [NOTE for those of you who have written or done Google searches: "Bob Winsom", like all the other names in the memo as transcribed below, is a pseudonym.]

CONFIDENTIAL MEMORANDUM -- EYES ONLY

Over the past two weeks, I've conducted confidential off-site group interviews with all of the ABC consultants working on the FUBAR project. I did this at [ABC manager's] request, after a few of these consultants spoke privately about FUBAR with him. The feedback was consistent and raises serious doubts about whether the FUBAR project, as currently pursued, can ever yield a successful production deployment.

This report groups those comments into several broad areas. It is relatively unfiltered and extremely direct (no withholding). It represents the private comments of ABC consultants who have little to gain and possibly much to lose by being so blunt. These are not the whinings of purists picking nits. These are the grounded assessments of top-notch IT professionals who have among them a century or two of experience bringing projects to completion -- particularly those involving [specific IT] technology -- and who are down in the FUBAR trenches every day. QUALITY OF WORK AND EFFORT

ISSUE: Several consultants said -- and the rest pretty much agreed -- that far too many of the deliverables, artifacts, and activities (e.g., algorithms, source code, system configuration, design/architecture documents, testing, defect tracking, scheduling etc.) are substantially below any acceptable professional standards and represent a profound threat to FUBAR ever going into production.

EXAMPLES: The code base is very fragile. A lot of it is bad old code that BigFirm didn't have time to rewrite two years ago, but now is five times its original size and even worse. One consultant said he took a code listing, picked pages at random, and found problems on every page he selected. There is pervasive hard coding of what should be adjustable parameters or at least meaningfully named constants (e.g., # of [key items] hard-coded throughout with the literal value '3, a constant named 'ninety_eight'). Builds take all night. App releases don't run acceptably, if at all, in a production environment. Developers check in files that won't even compile.

RISKS: The FUBAR project keeps being touted as a world-class development team, but it is not producing world-class, or even minimally-professional, results. This already shows up in the project delays and quality issues of the releases to date. What the team is producing will not only be very difficult to support and modify, it will in all likelihood be unusable, resulting in a complete failure of the FUBAR project. PROJECT PLANNING AND EXECUTION

ISSUE: Project planning and execution is all to often poor or missing completely. Milestone dates, usually unrealistic if not impossible, are based on political considerations or wishful thinking, not bottom-up grounding. Necessary and useful activities are delayed or canceled with the justification "We have no time for that", but the project phase ends up taking as long or longer than if the activities had been carried out. Dates are set, but nobody scrambles until the last minute. Risks are not actively tracked or managed.

EXAMPLES: Count how many times FUBAR ever produced a production-quality deliverable on anything close to a scheduled date. Even the current effort probably requires a year to get something into production, but the schedule says four months. Managers create work tasks, but then never track progress or completion. One ABC consultant created a risks document; Bob Winsom [BigFirm's FUBAR project manager] took it over, and no one has seen it since.

RISKS: FUBAR is massively late. You lose credibility and influence. QUALITY ASSURANCE AND PROCESS

ISSUE: Quality assurance appears to be low-priority concept within the FUBAR project. In the opinion of several consultants, the current person in charge of it is not particularly strong or competent. There appears to be a systemic inability to establish good testing criteria and methods to gauge FUBAR's progress toward production. What software lifecycle process is in place is often not followed. No independent group or person acts as the 'gatekeeper' to judge acceptability and control release into production.

EXAMPLES: [Key process] calculation -- the core of BigFirm's business and profits -- was being (and may still be) done incorrectly in FUBAR; it had never been previously checked for correctness through all these years. Likewise, performance expectations have been based on the presumption of FUBAR distributed over multiple systems, processors, and threads, yet no one ever tested to see if those implementations would work until recently -- and they didn't. The build environment needs to be overhauled. The defect tracking process is poor, particularly the practice of writing up defects not against the current release but the release in which the defect is scheduled to be fixed -- so as to keep the number of defects down for the current release.

RISKS: BigFirm leaves itself open to potential liabilities, not to mention crippling its own core business. In the meantime, the effort to transition directly into the Rational Unified Process (RUP) is not being given sufficient time and will likely grind development to a halt.

ARCHITECTURE

ISSUE: FUBAR doesn't have a viable, consistent architecture. The irony is that FUBAR itself is not a big, complex problem; it is a relatively straightforward problem that has been made big, complex, and possibly unsolvable in the current implementation. Initiatives to rearchitect are started, abandoned due to "schedule pressure", then restarted months later.

EXAMPLES: The project has gone through a series of architects, who have either left or been asked to leave. While they are here, they usually are neither listened to nor given the authority to be an architect. Technical decisions are made by people lacking the background, such as Bob Winsom, who may fancy himself an architect and was quoted as saying, "I haven't found an architect I like yet."

RISKS: FUBAR never stabilizes enough to go into production for any length of time, or if it does, proves to be extremely difficult to support or enhance. APPLICATION PERFORMANCE

ISSUE: FUBAR was never properly architected and designed for the performance required. There is a current effort to increase performance after the fact, but the implementation makes that impossible. To make things worse, developers are having to scale the performance of and debug a seriously flawed application at the same time, making it very hard to stabilize the application.

EXAMPLES: Two consultants rewrote the 140,000 lines of [original obscure language] into 4200 lines of Java. The Java version runs as fast on a laptop PC as the original version runs on a high-powered UNIX server.

RISKS: Despite heroic efforts (that will probably make the application even more difficult to modify and support) and lots of hardware, FUBAR will probably reach some fraction of the currently-desired performance -- possible as little as 15% to 20% of that required, possibly as much as 80% -- and then go no further. STAFFING

ISSUE: Many of the people involved in FUBAR -- developers, testers, team leads, managers -- lack the qualifications, insight, or experience to make FUBAR a success. The project is overstaffed for the actual complexity of FUBAR, possibly for political reasons (i.e., promotion/stature based on the number of people supervised).

EXAMPLES: Many of the examples listed above reflect this problem.

RISKS: This problem leads in part to all the issues previously listed: poor quality of work, poor quality assurance, poor scheduling and delivery, poor architecture, poor application performance. Besides the potential failure of FUBAR itself, this issue tends to be self-intensifying -- that is, the qualified people become frustrated and leave (or are hard to recruit in as replacements), while those less qualified or capable stay around. [A reference to the "Dead Sea effect" written many years ago.] [BrandName team management approach] PRINCIPLES

ISSUE: Mid-level management tells the developers that mood, sincerity, and commitment are everything, and that with them "we can accomplish anything." At the same time, the principle of granting sincerity appears to be used to justify a lack of accountability and consequences.

EXAMPLES: Repeated statements in team meetings, one-on-ones, and so on.

RISKS: Loss of credibility. Such assertions don't hold water. I can be in a great mood and have a team of very sincere and committed people, but if we try to build a commercial airliner without the proper expertise, requirements, engineering, materials, and testing, the plane will crash and people will die, assuming it ever gets built and off the ground (which is extremely unlikely). The fallacy that software is somehow different is just that -- a fallacy, and one that costs corporations millions (if not billions) of dollars a year in missed schedules and failed projects. When it comes to engineering, sincerity and commitment, while important, can never substitute for expertise and quality of work.

INTELLECTUAL HONESTY

ISSUE: There isn't enough intellectual honesty within the FUBAR project. Managers reject or explain away bad news and real problems, looking instead for people who will tell them what they want to hear.

EXAMPLES: Several developers and team leads have sought to escalate these issue and concerns up the management chain, but the issues appear to always get stopped, usually at Bob Winsom. [The "thermocline of truth", with a very discrete boundary.] The FUBAR project is represented as something that has never been done before, and the staff as a world-class development team.

RISKS: The lack of intellectual honesty in project management is a form of codependency and enabling that is all too easy to fall into. Unfortunately, reality eventually intrudes, and when it does, you run the very real risk of looking dishonest or incompetent.

CLOSING REMARKS

As I said, this is a very blunt (and very confidential) memo. It represents the opinions, experiences, and observations of these ABC consultants, and there are undoubtedly points with which you take issue or disagree. Do not let that blind you to the fundamental reality that there are some profound problems and flaws with the FUBAR project that will not go away until the project team acknowledges and addresses them. Indeed, it will be hard enough to make them go away even then.



Kind of scary, isn't it? The interesting part was that BigFirm had implemented, corporate-wide, a "team management" methodology (from an outside firm) that was based on "mood, sincerity, and commitment". As an overall corporate management approach, it might well have been effective; I just don't know. But BigFirm thought that it would also solve their IT problems.

Nope, it didn't. ..bruce..

Re:Text of Article (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#23826885)

Fucking karma whore. Go away. The server is working just fine.

Re:Text of Article (4, Interesting)

IamTheRealMike (537420) | more than 6 years ago | (#23826915)

It's sort of interesting, in a vague way, but you can read much more dire and funny stories on (the highly recommended) the daily WTF [thedailywtf.com] . My favourites would have to be the hotel reservation system from hell [thedailywtf.com] , the story of VirtuDyne and the digital donkey [thedailywtf.com] and a case of the MUMPS [thedailywtf.com] .

Re:Text of Article (1)

Kevin72594 (1301889) | more than 6 years ago | (#23827431)

Off Topic, but why does it seem like the daily WTF is coming up so often lately? I've seen it in probably about 80 percent of the stories I've read in the past week.

Re:Text of Article (0)

Anonymous Coward | more than 6 years ago | (#23827967)

Because 80% of the stories you have read are IT WTFs.

Re:Text of Article (3, Informative)

bfwebster (90513) | more than 6 years ago | (#23828179)

I also strongly recommend The Daily WTF, and Alex Papadimoulis (who runs WTF) and I have linked to and commented on each other's posts.

Also, remember that this was a professional memo written to a high-level manager at BigFirm. It wasn't written to be amusing. :-) ..bruce..

Re:Text of Article (4, Interesting)

idontgno (624372) | more than 6 years ago | (#23826973)

thermocline of truth

Damn. That's the exact phrase I've been looking for. I don't know how many times I've seen hard truths and unpleasant realities float up the organization and stop dead about 3 management levels below where someone could do something about it. Just like sonar, the people "listening" above the thermocline will never hear anything occurring below it.

Re:Text of Article (1)

192939495969798999 (58312) | more than 6 years ago | (#23827867)

The author wasn't really involved in a FUBAR project unless he was fired for circulating "such an inflammatory memo".

Re:Text of Article (0)

Anonymous Coward | more than 6 years ago | (#23827929)

As if ABC didn't have enough to worry about with bad ratings and all... huh?, what's that? Oh, nevermind.

Re:Text of Article (2, Interesting)

Anonymous Coward | more than 6 years ago | (#23827969)

Wow.

It's scary how much this resembles the ongoing debacle in the company I currently work for, as our "new" workflow application sucks millions of dollars into a black hole (and will continue to do so for the same reasons as the article talks about).

Everyone who actually has to use it, hates it. None of the developers has ever talked to any of the end users. It is fundamentally broken in design (most end users are on a WAN or the internet, but it is designed to be used on a high-speed, low latency network with functioning QoS). The sheer amount of FAIL in this project is staggering. Yet it continues to have money poured into it, all because it is the CEO's son's idea.

Meanwhile, the "old" workflow - which made us market leaders - has been left to languish and subsequently the competitive advantages it gave us have all but disappeared (we used to have technology years ahead of any competitors - but that was years ago). The true tragedy is we had plenty of smart people who not only explained why the project was doomed to failure, but offered (and in some cases implemented, only to be slapped down) functional and viable ideas to improve the existing tools. I expect all these people will have finally given up and left by the end of this year (as I probably will).

(Of course, this is far from the only issue causing our current drain-circling, but it certainly isn't helping, and it's happening for the same reason our other problems are - nepotism and incompetent management.)

IT Project Managers (1)

COMON$ (806135) | more than 6 years ago | (#23826737)

I view these problems as a direct result in regards to a lack of IT project managers. Even being a seasoned IT professional I wouldn't even begin to imagine the difficulties in managing a large IT project beginning to end. In my experience I have noticed in run-away projects or in slow moving projects, the problems usually are attributed to a change of project managers. I would urge any company with an IT project to do whatever they can to maintain their PMs with any incentives possible. Because the fallout is financially distressing to ANY company.

Re:IT Project Managers (4, Interesting)

Ngarrang (1023425) | more than 6 years ago | (#23827225)

"ISSUE: There isn't enough intellectual honesty within the FUBAR project. Managers reject or explain away bad news and real problems, looking instead for people who will tell them what they want to hear. "

This has easily been the #1 reason I have personally witnessed for project failure. I am in the process of witnessing it right now, even, with what seems like a relatively simple project. The suits and supervisors along the way are either not responding to requests for information, or change their request for features.

Re:IT Project Managers (5, Insightful)

JaredOfEuropa (526365) | more than 6 years ago | (#23827255)

I view these problems as a direct result in regards to a lack of IT project managers.
I find that there's a rather shocking lack of senior, competent technical personnel in general. On a lot of larger projects, there's not a great deal of senior devs to go around so a couple of them end up as dev lead / team lead even though their managerial skills aren't so great. There's no testers to be had so the developers end up doing the testing, and the user acceptance tests end up poorly written aand poorly facilitated. Junior developers have far too much leeway in writing code because there's not enough seniors to coach them, or even do proper code reviews. Application and infrastructure architects are too busy to give each project the attention it deserves, and as a result performance and scalability are not built into the design, and are often not even tested for before release.

In short, a lack of senior staff means a lack of attention, coaching and oversight. If you have too many juniors, your project is going to take a lot longer to correct "newbie" mistakes, and these mistakes are caught later after they're made as well. Either allow for this extra time, or end up with crappy code.

Sadly, the idea has taken hold with upper management that IT is simply a commodity, and as a result most IT shops have become piss-poor at identifying and nurturing talent. They expect junior developer to become "mediors" automatically after a few years, where in practice they have picked up a ton of bad habits on which they've never been corrected. And I expect the shortage to increase in the future... more and more professional IT staff are starting to look for ways out.

Re:IT Project Managers (5, Insightful)

COMON$ (806135) | more than 6 years ago | (#23827479)

Exactly, all of which cascades from a lack of project management. IT project managers are soooo rare no adays that everyone is scrambling to hire them. A good IT project manager will manage each of the problems you noted above. Sys Admins and Dev Gurus are not Project managers. But they get put in the position of being one constantly because upper management doesn't know the difference. It is a completely different skill set. You wouldn't make a simple accountant a CFO or your HR manager a CEO. Sure there is an aspect of accounting to beinging a CFO and there is an aspect of HR to CEO but those are well defined fields that people know how to sniff out good fits for them. However the Professional IT project manager is such a new concept that general managers think any IT guy can fit the bill.

It all comes down to the fact that somehow the common business sense that people have in every other area seems to go out the window while they are thinking about IT.

Re:IT Project Managers (1)

wondergeek (220755) | more than 6 years ago | (#23827825)

Spot on! Wish I had mod points for you.

But they must be competent (5, Insightful)

Anonymous Coward | more than 6 years ago | (#23827397)

It is unfortunately common to knee-jerk a development problem by adding more management.

A project manager who doesn't actually have the skills it takes to make a project successful will be as bad or worse than no project manager at all. Hiring/retaining more of them will just multiply the problem.

It is very difficult to interview for and find good project managers. The talent pool is just teeming with people who are not skilled developers, and would to love to have a job that is, essentially, just telling other developers to do their jobs. There is tremendous incentive for people who are not competent to be a project manager (or much of anything else, for that matter) to fight tooth and nail for PM jobs. When you hire such a person, your project usually fails, or if it does succeed it is despite, and not because of, the best efforts of your project manager.

Another problem: the best project manager in the world won't get you results if you disempower him or her. I have seen it happen often that the executives see a project slipping and shift into micromanagement mode. At that point, the project manager just becomes a mouthpiece, and the company has robbed itself of the value of their paid talent. If you can't trust your project manager to tell you when a goal cannot be achieved, or when more time must be allocated to some task that doesn't have obvious functional benefits, or that a deadline must be extended, then you have either hired a lemon or you are involving yourself too much in his job. In either case, your project will suffer because of it.

Ok, I will stop ranting now. The bottom line is...more management doesn't solve problems. The right amount of *competent* and *properly empowered* management does.

Re:IT Project Managers (2, Insightful)

glgraca (105308) | more than 6 years ago | (#23827405)

I think we have too many already. The real problem is either that they don't say what needs to be said because they don't want to make waves (they'll twiddle with their Project schedule and pretend that all will be alright) or that upper management simply won't take no for an answer (and will tell them to twiddle with their Project schedule to make it alright).

Re:IT Project Managers (5, Interesting)

dedazo (737510) | more than 6 years ago | (#23827667)

Not really. I've worked with shitty PMs but also with good ones (in large projects) where the fault lies entirely on the people above them.

On a project a few years ago (your typical Fortune 500 $LARGE_COMPANY here), our PM was forced to declare that a large release that had taken 6 months to get to "it's kinda working" was "complete" and shipped to UAT even though system testing was incomplete and all we did was give the end users a pile of steaming shit. But the director of the group got to "meet" his deadline, and therefore get his much-desire performance rating.

Of course fixing bugs once the app is in UAT is four times as difficult as in the integration environment, with the corresponding lag in defect correction time. So UAT went on and on and on... until it was supposed to be the final release date. Said users were hysterical and pissed off, and said director was out of his fucking mind trying to come up with inventive ways to ship said steaming pile of shit to production while blaming someone else for the smell of said pile.

His first executive action was to fire the PM and have him escorted out of the building (he was a contractor like me). His second action was to request that the Offshore Solutions team add four more developers to the already swelled-beyond-comprehension development team in India. You know, throwing bodies at the problem. The next thing was to go to his VP and claim that he had been misled by the PM, who by this time was checking out the classifieds at home and therefore unavailable for comment.

In the end, we all went through the usual death march and shipped the thing about three weeks late. The director got his rating (not his fault you understand) and the users had to deal with the remnants of the steaming pile of shit. I get paid either way so no skin off my ass.

Projects are late (or they fail) because the people who are supposed to be in charge of delivering them have no fucking clue as to how software is developed. Fix that problem, and you'll ship all the software you want on time and under budget.

I'm fortunate to be in a project right now where the guy in charge is a former developer who doesn't require a bonus to pay his mortgage, and all the two PMs do is move little bars on an MS Project file while mercifully leaving me and my team alone to actually write the software. We've released two major versions of the app so far the past two years and are on track to deliver the third version sometime this October. On time and under budget. The secret? Iterative development (SCRUM-like) with heavy user involvement in feature sprints. No waterfall bullshit for me anymore, thank $DEITY.

/Rant over, back to work.

Re:IT Project Managers (1)

COMON$ (806135) | more than 6 years ago | (#23827925)

Very insightful!

That is what I was getting at. In my opinion you need PMs with some real world experience working in projects. After all you need to know what is going on below before you can paint the big picture. However, a PM should only report to the CEO, cut out all the bull. Get the project scope and draw out the details then let the PM take over. Don't fire, rehire or expand without the PM's explicit permission. At best the CEO should be asking members of the project team to review the PM to make sure they are competent but other than that, the project should be hands off to anyone not building said item. Every time a PM leaves, moves on, or gets screwed with you start to see scope creep and all your devs start to look at classifieds.

who is Bob Winsom (1)

rescue me (1067874) | more than 6 years ago | (#23826741)

Was he singled out for a reason ?

Re:who is Bob Winsom (1)

bfwebster (90513) | more than 6 years ago | (#23826909)

"Bob Winsom" is a pseudonym. The individual referenced was the FUBAR project manager at BigFirm. ..bruce..

Re:who is Bob Winsom (3, Funny)

sxtxixtxcxh (757736) | more than 6 years ago | (#23827575)

says the guy coincidentally sharing initials with "bob winsom"

Re:who is Bob Winsom (1)

bfwebster (90513) | more than 6 years ago | (#23828207)

Trust me, the original project manager's initials weren't "BW". But that's a good catch. I chose "Bob Winsom" because I couldn't find anyone by that name via Google. ..bruce..

Interesting line (4, Insightful)

UnknowingFool (672806) | more than 6 years ago | (#23826769)

Two consultants rewrote the 140,000 lines of [original obscure language] into 4200 lines of Java. The Java version runs as fast on a laptop PC as the original version runs on a high-powered UNIX server.

Come on now, COBOL isn't that bad. :P. But seriously Java isn't the language you would use for high performance but rather high portability. That says a lot about how bad the original code was.

Re:Interesting line (5, Insightful)

Chirs (87576) | more than 6 years ago | (#23827017)

Depending on where the bottlenecks are, Java could do reasonably well. (And I say this as a professional kernel developer that works mostly in C, assembly, and shell scripting.)

The bulk of most apps is not a hot path and therefore the language is not as important. Even in the hot paths, algorithms often count more than the language. Once a suitable algorithm is determined, performance-critical things are often best written in other languanges (and if it's really critical, in assembly).

Re:Interesting line (4, Interesting)

jd (1658) | more than 6 years ago | (#23827137)

Java isn't the language for highly compact code, either. The original could have been any one of a hundred business languages, but most archaic business languages are fairly compact. That they could get such a high level of compression does show bad coding.

ObOwnExperience: One time, I had to do some maintenance work on a very large piece of badly-written and cruft-ridden code, ended up rewriting large tracts of it, reduced its source size by an order of magnitude and the binary size by three orders of magnitude. Also found some buffer overflow Heisenbugs which the previous maintenance guys had known about but bypassed by padding the object files. There's something... bothersome about corrupting a file in order to make a bug not be visible.

Java can be performant server side (5, Informative)

SuperKendall (25149) | more than 6 years ago | (#23827229)

But seriously Java isn't the language you would use for high performance but rather high portability

That old myth? That hasn't been true for many years now, for server side code anyway (which this was describing). Modern JIT compilers make java as fast, and sometimes faster (since you are optimizing code as it runs and not statically beforehand).

But no language will help you if you lack discipline or the ability to code (both of which seemed lacking in this case).

Re:Interesting line (1)

glgraca (105308) | more than 6 years ago | (#23827541)

For portability, there's no way Java could beat Perl: http://www.cpan.org/ports/

Re:Interesting line (3, Informative)

bfwebster (90513) | more than 6 years ago | (#23827551)

Come on now, COBOL isn't that bad. :P. But seriously Java isn't the language you would use for high performance but rather high portability. That says a lot about how bad the original code was.

The point of that observation was exactly that: a rewritten version in Java, running on a laptop (and we're talking about a laptop several years ago), was faster than the original implementation on much-higher-powered hardware. It was also nearly 2 orders of magnitude smaller (in LOC). ..bruce..

Re:Interesting line (1)

pushf popf (741049) | more than 6 years ago | (#23827791)

Come on now, COBOL isn't that bad. :P. But seriously Java isn't the language you would use for high performance but rather high portability. That says a lot about how bad the original code was.

All it really means is if all you have is a hammer, all the problems look like nails.

People use what they know. As projects get later, they tend to use what they know best.

Re:Interesting line (1)

msormune (808119) | more than 6 years ago | (#23827963)

Well, there's other things good about Java, such as massive support from other Java developers across Internet, literature and major vendors that come to mind...

I want names. (1)

Spy der Mann (805235) | more than 6 years ago | (#23826779)

or at least a hint, so we can understand better the reality we live in. It could as well be SCO or some mediocre company - in that case, it would be meaningless. But what if it was Yahoo! or Microsoft?

Re:I want names. (5, Funny)

JaredOfEuropa (526365) | more than 6 years ago | (#23826857)

But what if it was Yahoo! or Microsoft?
From what I've read, it could have been any company I've worked for.

Re:I want names. (0, Interesting)

Anonymous Coward | more than 6 years ago | (#23827377)

Could have been any large company I worked for too in the late 90's early 2000's.

The last big company I worked for like that had the same memo written up about the project I was working on. It was reviewed by management and they interviewed 100+ developers on the project the following week.
 
It was concluded that the report was right. The next day, the management called a 10am meeting to tell us that after 10 years the project had been canceled. March 31, 2001 more than 300 people were given 2 hours to clean out their desk and leave the building.
 
People took everything that wasn't nailed down.
 
A year later after checking up on the project and finding out that there was a release less than 6 months after the mass layoff that the project had been outsourced to India.

Re:I want names. (1)

DaveV1.0 (203135) | more than 6 years ago | (#23827909)

It could have been the large telecom company I left several months ago.

It could also be the large telecom company I current work for.

This is about Vista, isn't it? (nt) (5, Funny)

starX (306011) | more than 6 years ago | (#23826805)

From TFA:


The FUBAR project keeps being touted as a world-class development team, but it is not producing world-class, or even minimally-professional, results. This already shows up in the project delays and quality issues of the releases to date. What the team is producing will not only be very difficult to support and modify, it will in all likelihood be unusable, resulting in a complete failure of the FUBAR project.


Sounds like Vista to me...

except for the part about (3, Informative)

Reality Master 201 (578873) | more than 6 years ago | (#23827015)

Rewriting 14,000 lines of the project in [obscure language] as ~2000 lines of Java, and that the product ran on high end Unix servers.

You fail It (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23826819)

and/or distRibute thi8gs in

I get the impression (5, Funny)

g0bshiTe (596213) | more than 6 years ago | (#23826827)

That "FUBAR" project is Duke Nuke Em Forever.

Re:I get the impression (3, Funny)

teknopurge (199509) | more than 6 years ago | (#23826953)

Yeah, must be. I can't wait to see Duke move, frame-by-frame, in Java....

(and I actually really like Java)

Re:I get the impression (3, Insightful)

cduffy (652) | more than 6 years ago | (#23827455)

Now, now -- by the time DNF comes out, JVMs will run faster than hand-optimized assembler.

Re:I get the impression (0)

Anonymous Coward | more than 6 years ago | (#23827173)

Should be modded "Funny", not insightful. I highly doubt DNF was originally coded in COBAL.

Other than that point, yeah it sounds like what I have heard about DNF's development.

Re:I get the impression (1)

jd (1658) | more than 6 years ago | (#23827207)

You can't possibly fit Duke Nuken Forever onto a high-end Unix server. Everyone knows the minimum spec is now one of those Intel 80-core wafers and 640 terabytes of RAM. And that's for the title screen. They've not written the rest yet.

Re:I get the impression (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23827439)

Readers of the British magazine Private Eye might get the ideal that BigFirm was British Telecom (BT) and that the project might have something to do with centralised medical records. However, such a suggestion would be entirely misleading and completely wrong. -- Strobes

Full text of article (0, Redundant)

ironicsky (569792) | more than 6 years ago | (#23826843)

Since its already \.'d Note that the âoeABCâ consultants were a small part of the overall project team and had been brought in relatively late by âoeBigFirmâ in an attempt to get the âoeFUBARâ project into production; they neither initiated nor managed the project. [NOTE for those of you who have written or done Google searches: "Bob Winsom", like all the other names in the memo as transcribed below, is a pseudonym.]


CONFIDENTIAL MEMORANDUM â" EYES ONLY

Over the past two weeks, Iâ(TM)ve conducted confidential off-site group interviews with all of the ABC consultants working on the FUBAR project. I did this at [ABC manager's] request, after a few of these consultants spoke privately about FUBAR with him. The feedback was consistent and raises serious doubts about whether the FUBAR project, as currently pursued, can ever yield a successful production deployment.

This report groups those comments into several broad areas. It is relatively unfiltered and extremely direct (no withholding). It represents the private comments of ABC consultants who have little to gain and possibly much to lose by being so blunt. These are not the whinings of purists picking nits. These are the grounded assessments of top-notch IT professionals who have among them a century or two of experience bringing projects to completion â" particularly those involving [specific IT] technology â" and who are down in the FUBAR trenches every day.

QUALITY OF WORK AND EFFORT

ISSUE: Several consultants said â" and the rest pretty much agreed â" that far too many of the deliverables, artifacts, and activities (e.g., algorithms, source code, system configuration, design/architecture documents, testing, defect tracking, scheduling etc.) are substantially below any acceptable professional standards and represent a profound threat to FUBAR ever going into production.

EXAMPLES: The code base is very fragile. A lot of it is bad old code that BigFirm didnâ(TM)t have time to rewrite two years ago, but now is five times its original size and even worse. One consultant said he took a code listing, picked pages at random, and found problems on every page he selected. There is pervasive hard coding of what should be adjustable parameters or at least meaningfully named constants (e.g., # of [key items] hard-coded throughout with the literal value â3â, a constant named âninety_eightâ(TM)). Builds take all night. App releases donâ(TM)t run acceptably, if at all, in a production environment. Developers check in files that wonâ(TM)t even compile.

RISKS: The FUBAR project keeps being touted as a world-class development team, but it is not producing world-class, or even minimally-professional, results. This already shows up in the project delays and quality issues of the releases to date. What the team is producing will not only be very difficult to support and modify, it will in all likelihood be unusable, resulting in a complete failure of the FUBAR project.

PROJECT PLANNING AND EXECUTION

ISSUE: Project planning and execution is all to often poor or missing completely. Milestone dates, usually unrealistic if not impossible, are based on political considerations or wishful thinking, not bottom-up grounding. Necessary and useful activities are delayed or canceled with the justification âoeWe have no time for thatâ, but the project phase ends up taking as long or longer than if the activities had been carried out. Dates are set, but nobody scrambles until the last minute. Risks are not actively tracked or managed.

EXAMPLES: Count how many times FUBAR ever produced a production-quality deliverable on anything close to a scheduled date. Even the current effort probably requires a year to get something into production, but the schedule says four months. Managers create work tasks, but then never track progress or completion. One ABC consultant created a risks document; Bob Winsom [BigFirm's FUBAR project manager] took it over, and no one has seen it since.

RISKS: FUBAR is massively late. You lose credibility and influence.

QUALITY ASSURANCE AND PROCESS

ISSUE: Quality assurance appears to be low-priority concept within the FUBAR project. In the opinion of several consultants, the current person in charge of it is not particularly strong or competent. There appears to be a systemic inability to establish good testing criteria and methods to gauge FUBARâ(TM)s progress toward production. What software lifecycle process is in place is often not followed. No independent group or person acts as the âgatekeeperâ(TM) to judge acceptability and control release into production.

EXAMPLES: [Key process] calculation â" the core of BigFirmâ(TM)s business and profits â" was being (and may still be) done incorrectly in FUBAR; it had never been previously checked for correctness through all these years. Likewise, performance expectations have been based on the presumption of FUBAR distributed over multiple systems, processors, and threads, yet no one ever tested to see if those implementations would work until recently â" and they didnâ(TM)t. The build environment needs to be overhauled. The defect tracking process is poor, particularly the practice of writing up defects not against the current release but the release in which the defect is scheduled to be fixed â" so as to keep the number of defects down for the current release.

RISKS: BigFirm leaves itself open to potential liabilities, not to mention crippling its own core business. In the meantime, the effort to transition directly into the Rational Unified Process (RUP) is not being given sufficient time and will likely grind development to a halt.

ARCHITECTURE

ISSUE: FUBAR doesnâ(TM)t have a viable, consistent architecture. The irony is that FUBAR itself is not a big, complex problem; it is a relatively straightforward problem that has been made big, complex, and possibly unsolvable in the current implementation. Initiatives to rearchitect are started, abandoned due to âoeschedule pressureâ, then restarted months later.

EXAMPLES: The project has gone through a series of architects, who have either left or been asked to leave. While they are here, they usually are neither listened to nor given the authority to be an architect. Technical decisions are made by people lacking the background, such as Bob Winsom, who may fancy himself an architect and was quoted as saying, âoeI havenâ(TM)t found an architect I like yet.â

RISKS: FUBAR never stabilizes enough to go into production for any length of time, or if it does, proves to be extremely difficult to support or enhance.

APPLICATION PERFORMANCE

ISSUE: FUBAR was never properly architected and designed for the performance required. There is a current effort to increase performance after the fact, but the implementation makes that impossible. To make things worse, developers are having to scale the performance of and debug a seriously flawed application at the same time, making it very hard to stabilize the application.

EXAMPLES: Two consultants rewrote the 140,000 lines of [original obscure language] into 4200 lines of Java. The Java version runs as fast on a laptop PC as the original version runs on a high-powered UNIX server.

RISKS: Despite heroic efforts (that will probably make the application even more difficult to modify and support) and lots of hardware, FUBAR will probably reach some fraction of the currently-desired performance â" possible as little as 15% to 20% of that required, possibly as much as 80% â" and then go no further.

STAFFING

ISSUE: Many of the people involved in FUBAR â" developers, testers, team leads, managers â" lack the qualifications, insight, or experience to make FUBAR a success. The project is overstaffed for the actual complexity of FUBAR, possibly for political reasons (i.e., promotion/stature based on the number of people supervised).

EXAMPLES: Many of the examples listed above reflect this problem.

RISKS: This problem leads in part to all the issues previously listed: poor quality of work, poor quality assurance, poor scheduling and delivery, poor architecture, poor application performance. Besides the potential failure of FUBAR itself, this issue tends to be self-intensifying â" that is, the qualified people become frustrated and leave (or are hard to recruit in as replacements), while those less qualified or capable stay around. [A reference to the "Dead Sea effect" written many years ago.] [BrandName team management approach]

PRINCIPLES

ISSUE: Mid-level management tells the developers that mood, sincerity, and commitment are everything, and that with them âoewe can accomplish anything.â At the same time, the principle of granting sincerity appears to be used to justify a lack of accountability and consequences.

EXAMPLES: Repeated statements in team meetings, one-on-ones, and so on.

RISKS: Loss of credibility. Such assertions donâ(TM)t hold water. I can be in a great mood and have a team of very sincere and committed people, but if we try to build a commercial airliner without the proper expertise, requirements, engineering, materials, and testing, the plane will crash and people will die, assuming it ever gets built and off the ground (which is extremely unlikely). The fallacy that software is somehow different is just that â" a fallacy, and one that costs corporations millions (if not billions) of dollars a year in missed schedules and failed projects. When it comes to engineering, sincerity and commitment, while important, can never substitute for expertise and quality of work.

INTELLECTUAL HONESTY

ISSUE: There isnâ(TM)t enough intellectual honesty within the FUBAR project. Managers reject or explain away bad news and real problems, looking instead for people who will tell them what they want to hear.

EXAMPLES: Several developers and team leads have sought to escalate these issue and concerns up the management chain, but the issues appear to always get stopped, usually at Bob Winsom. [The "thermocline of truth", with a very discrete boundary.] The FUBAR project is represented as something that has never been done before, and the staff as a world-class development team.

RISKS: The lack of intellectual honesty in project management is a form of codependency and enabling that is all too easy to fall into. Unfortunately, reality eventually intrudes, and when it does, you run the very real risk of looking dishonest or incompetent.

CLOSING REMARKS

As I said, this is a very blunt (and very confidential) memo. It represents the opinions, experiences, and observations of these ABC consultants, and there are undoubtedly points with which you take issue or disagree. Do not let that blind you to the fundamental reality that there are some profound problems and flaws with the FUBAR project that will not go away until the project team acknowledges and addresses them. Indeed, it will be hard enough to make them go away even then.



Kind of scary, isnâ(TM)t it? The interesting part was that BigFirm had implemented, corporate-wide, a âoeteam managementâ methodology (from an outside firm) that was based on âoemood, sincerity, and commitmentâ. As an overall corporate management approach, it might well have been effective; I just donâ(TM)t know. But BigFirm thought that it would also solve their IT problems.

Nope, it didnâ(TM)t. ..bruce..

Obviously.... (0)

Anonymous Coward | more than 6 years ago | (#23826855)

The runaway project was the web server this story was hosted on....

need maximum verbosity (1)

us7892 (655683) | more than 6 years ago | (#23826911)

Two consultants rewrote the 140,000 lines of [original obscure language] into 4200 lines of Java. The Java version runs as fast on a laptop PC as the original version runs on a high-powered UNIX server

Okay, ummmm, I'm gonna need some more detail on this statement.

Re:need maximum verbosity (2, Insightful)

jellomizer (103300) | more than 6 years ago | (#23827757)

Not to suprising. Older Languges didn't have such a rich default library set.
Obj.sort() (using a fast sorting algorithm) vs. a quick to program bubble sort on the object can obtain performance gains with little extra code. You can write a Web Server in 50 lines in Python vs. 1000 lines in C and still missing functionality in C. That is just because Python has a web server object that intern executes the extra code needed it to run. The same from converting say from ADA to Java. You have a richer languge thus you code less.

Sigh... (4, Funny)

fahrbot-bot (874524) | more than 6 years ago | (#23826923)

I first read this as "Anatomy of Runway Project" and thought of Heidi Klum [bravotv.com] .
I am *so* disappointed with the actual article...

Re:Sigh... (3, Funny)

Hal_Porter (817932) | more than 6 years ago | (#23827581)

Yeah, damn right. Like I want to read about work when I'm web surfing at work.

Was this project even needed? (0)

videoBuff (1043512) | more than 6 years ago | (#23826927)

IT budget and spending has a negative correlation with efficiency of operation of whole enterprise.

ASPIRE (0)

Anonymous Coward | more than 6 years ago | (#23826937)

Sounds like Project ASPIRE in Florida. 70+ million pissed away to replace the aging mainframe state accounting system. That project had everything - a corrupt politically connected contractor, inept management, you name it.

Well first... (2, Funny)

IANAAC (692242) | more than 6 years ago | (#23827005)

You get someone with a heavy german accent who will tell you you are either in or you are out. We'll call her the director. Then we'll get a really tanned queeny man to critique verything you do. We'll call him the Project Manager. Oh and don't forget his sidekick who edits everything you do down. We'll call her QA. Every once in a while there will be a different person who comes in each week and gives his input, which really means nothing to you, since he hasn't seen any of your progress throughout. We'll call him the CEO.

Then there's that person who's "kind of a big deal" and thinks the project is "fierce". That would be the senior administrator.

Oh wait. This isn't Project Runway"?

Re:Well first... (1)

foobsr (693224) | more than 6 years ago | (#23828229)

You get someone with a heavy german (sic) accent who will tell you you are either in or you are out.

It seems I miss the joke (I am German).

CC.

Ouch -- server problems (2, Informative)

bfwebster (90513) | more than 6 years ago | (#23827021)

I have a dedicated server and have had slashdotted postings before that haven't brought the server down. I've e-mail the support team to see what's going on. ..bruce..

From a former employee . . . this sounds like IBM (2, Interesting)

StyleChief (656649) | more than 6 years ago | (#23827071)

I'm sure that there are other similar companies out there, but much of the language and all of the circumstances seem very familiar. Just curious, but how many other companies use the term "deliverables"? IBM, after purchasing Rational Software, decided that it was a good idea to move all projects to this process. About 2003, there was a huge stir within the company to document everything into a "process" and wasted months (nay, years?) in fluff process documentation that yielded no benefit. It is very interesting that their stock is doing so well at the moment. Lots of folks are jumping ship like mad right now . . .

Re:From a former employee . . . this sounds like I (1)

maxume (22995) | more than 6 years ago | (#23827299)

It could well be running up to an implosion (revenues won't necessarily reflect erosion of long term business), but the stock is up on real revenue and earnings growth:

http://finance.yahoo.com/q/is?s=IBM&annual [yahoo.com]

Every company on earth uses "deliverables" (3, Informative)

SuperKendall (25149) | more than 6 years ago | (#23827307)

Just curious, but how many other companies use the term "deliverables"?

All of them. Phrases like that are highly viral and travel through the world management population in under a month.

The article was so generic, it could have described projects I've seen from companies with under a hundred people to a cast of thousands.

Re:From a former employee . . . this sounds like I (1)

Dekortage (697532) | more than 6 years ago | (#23827873)

how many other companies use the term "deliverables"?

Every company I've worked at over the last 15 years has used this term -- from tech companies, to marketing agencies, to international nonprofits. It's universal.

duke nukem will be ready when its ready (0)

Anonymous Coward | more than 6 years ago | (#23827095)

no reason for the fud-meisters to get their knickers in a twist. enough hysterics, lets just let the highly qualified smart people do their jobs.

Anatomy of every project (1)

AutopsyReport (856852) | more than 6 years ago | (#23827099)

This report is little more than a walk through of the textbook examples that cause project failures, and what the possible consequences are. Interesting, but nothing new to those already in the industry. A lot of these symptoms are present in every project (not just the lost-cause ones). Most can attest to this.

With some more detail this firm would make a great textbook example for future students. What was the end result of this project, or is it still active?

Re:Anatomy of every project (1)

bfwebster (90513) | more than 6 years ago | (#23827679)

Remember that this was a memo written for upper management at BigFirm, not a published case study. What caught my attention, when I rediscovered the memo a few days ago, was how pervasive, broad and serious the problems were, all in one project.

As the first paragraph of the post notes, the project was eventually killed. ..bruce..

Seen it before (2, Informative)

UnknowingFool (672806) | more than 6 years ago | (#23827131)

Note that the "ABC" consultants were a small part of the overall project team and had been brought in relatively late by "BigFirm" in an attempt to get the "FUBAR" project into production; they neither initiated nor managed the project.

I've seen this so many times with the big consulting firms. They low ball the bids. Then they send in kids who were just handed their degrees and a manual about some technology and told to implement the technology at a client's site (basically it's the only people they can afford with the bid). It goes downhill because their lack of experience and lack of project management. Later the big consulting firm brings in a subcontractor to fix the issues (mainly because the client refuses to pay anymore and may have milestones/clauses that allow them not to pay). The subcontractor usually is smaller, has more expertise, but costs much more. But they are given a huge and seemingly impossible task. Sometimes they can rescue the project. Sometimes they can't.

Re:Seen it before (1)

bfwebster (90513) | more than 6 years ago | (#23827227)

I've certainly seen that pattern as well, but it's not what happened in this case. In this case, the development team was primarily in-house through most of the project. The consultants were brought in by BigFirm late and in small numbers. ..bruce..

SOUNDS like the typical "mythical man-month" (3, Insightful)

zazenation (1060442) | more than 6 years ago | (#23827153)

approach to project development. "If we hire twice as many programmers, we'll finish it in half the time!"

I ran into this career driven mid-level manager problem-solving approach regularly in the 90's before many of them vaporized (remember DEC?) Time has not changed human nature or incompetent managers.

The PM's of these projects tended to be big on contrived dog-and-pony shows too as I recall.

Cast of Characters (0)

Anonymous Coward | more than 6 years ago | (#23827289)

FUBAR=ASPIRE
ABC=Gartner Group
BigFirm=BearingPoint

Lack of intellectual honesty is endemic (5, Insightful)

analog_line (465182) | more than 6 years ago | (#23827319)

From large companies to small, it's the single biggest problem they all have. Decisions makers don't want to hear the truth, no matter how loudly they protest otherwise. Anyone with intellectual honesty that doesn't have a previously won huge level of trust from a decision-maker is almost invariably thought to be lying. They all want to have their cake and eat it too, and they will throw money at anyone that tells them they can. Even after getting burned by the consequences of their decisions, less than half (in my experience) bother to try and learn from the failure. Most of them blame the honest person (if they did nothing and as a result failure happened) or latch on to the next person willing and able to lie even more convincingly than the last guy.

Re:Lack of intellectual honesty is endemic (1)

rsw (70577) | more than 6 years ago | (#23827831)

I was about to post almost exactly the same thing.

This Christmas I'm going to buy a stack of The Mythical Man-Month [wikipedia.org] s and leave them on all the managers' desks around here...

-=rsw

Agile development solve it all (1)

cyrilc (126593) | more than 6 years ago | (#23827477)

Agile software development [wikipedia.org] is exactly what should be the solution to such mistake.

New runway project (1)

pw1972 (686596) | more than 6 years ago | (#23827487)

Here in Cleveland they have a new runway project at Hopkins that should be kicking off soon. 6L-24R, 7000 ft long, 150 ft wide. Quite an undertaking!

too familiar (0)

Anonymous Coward | more than 6 years ago | (#23827521)


The example is far to familiar, I have worked with lots of successfull projects and also to "dead" multimilion multiyear projects, there are some basic differences:

  - the dead project owners/managers gain more by the hours of coding, than by the results. Example: an internal project who's manager wants to prolong it for years to get an easy paycheck and have an architect aura. Or a consulting project for a high paying customer (a bank or government in best case scenario), obtained as usually on relations.

- the succesfull project owners/managers gain by results (a project negociated as a total sum, not as development time, or a product/service that the software company sells)

The rest is history (the two cases may occur at the same company, on different projects).

Merit? (1, Insightful)

JeremyGNJ (1102465) | more than 6 years ago | (#23827647)

Unfortunately for the author of this memo...it seems to lack credibility.

Almost everything stated is based on opinion. It reeks of "amateur", and would be ripped apart by just about any manager it was given to. Here I will show paraphrased examples of what was written by a managers reaction to reading it:

Memo: It has grown too complex to ever go to production
Manager: Please outline the facets of this project that can be eliminated.

Memo: Some coder on my team found a problem with every page of code he sampled
Manager: What makes this coder more qualified than the coder who wrote it?

Memo: The code base is "very fragile"
Manager: What the fuck does that mean?

Memo: My guys took 140,000 lines of old crappy code and replaced it with 4200 lines of Java
Manager: This guy is one of those "I can do it better using the new language i learned in college" kids

Memo: Many previous project managers have left or not been given the power to architect it properly
Manager: This guy is obviously in over his head and fears his job.

Memo: This project has grown too big, probably due to policial reasons of some guy wanting a big important project
Manager: And you're certainly not going to ruin it for me. Don't EVER use the phrase "political reasons" in a professional document.

Re:Merit? (2, Insightful)

fruitbane (454488) | more than 6 years ago | (#23827959)

Highly-paid consultants with good reputations can be as honest as they want. They've earned the right. They are not employees and can go find a client who And frankly, if money is being poured into a sinking ship, an ethical consultant has an obligation to spell out that a. the ship is sinking and b. you don't understand the details so I have to give it to you in summary form.

Re:Merit? (5, Informative)

bfwebster (90513) | more than 6 years ago | (#23828103)

I'm not sure how carefully the manager you quote read my post, since some of your 'quotes' are wrong (as well as the apparent assumptions as to my own role), and some of the manager's responses are non sequiturs.

I was brought in from the outside specifically to conduct a review and summarize my findings in a memo for one specific person in upper management at BigFirm who was above the FUBAR project and who had grave concerns about it, given that at that point the project was years late and millions over budget, and which showed few signs of making it into production anytime soon.

I was not one of the "coders" -- I was not even a project member -- and I certainly wasn't a "new kid out of college"; I graduated with BSCS in 1978; my first programming languages were 360 assembly, PL/1 and FORTRAN, and by the time I conducted this review, I had personally done professional software engineering (including project management, architecture, and consulting) in a wide range of operating systems and programming languages over quite a few fifferent industries.

The ABC consultants, to a person, were likewise very senior software engineers with many years of hands-on coding experience and well-established track records of successful project delivery.

I'm surprised that an IT manager doesn't know what "very fragile code" means. "Fragile code" means that efforts to modify one section of code -- to fix a bug, add functionality, or improve performance -- frequently results in the code "breaking" elsewhere, usually in multiple places. The opposite of "fragile code" is "robust code".

The memo states clearly that previous architects had left (not "project managers"); the problem was that the FUBAR project manager (with no technical background) kept driving them off and, as the memo notes, fancied himself a software architect.

The syndrome of "kingdom building" through increased head-count has long been a major cause of IT project failure; in this case, there were far too many programmers than the problem actually required.

As for my "amateur" status, I'll simply point here [brucefwebster.com] ; is the manager willing to do the same? (Sorry about the server problems; I'm raising hell with my hosting service, given what I pay each month for a dedicated server.) ..bruce..

 

And a Decent Engineer could respond (2, Interesting)

weston (16146) | more than 6 years ago | (#23828165)

. It reeks of "amateur", and would be ripped apart by just about any manager it was given to.

I have a high degree of confidence that many managers could probably think they were ripping it apart, but my guess is your average slashdot poster (let alone your average decent engineer) could probably respond competently to each charge, were said manager competent enough to have the responses you gave be real commentary rather than contrary rhetoric.

Manager: Please outline the facets of this project that can be eliminated.

"This is part of the problem. The project has been so poorly organized and tracked that no one has a current of outline it. It's possible that we *can't* outline it."

Manager: What makes this coder more qualified than the coder who wrote it?

"As you'll see I mentioned, the developer reviewing the code was aware of widely-known good practices in development -- such as the use of well-named constants, rather than 'magic numbers.' The coder writing the code was either unaware of these or unwilling to apply them, which quite likely means he's less qualified."

Manager: What the fuck does [fragile] mean?

"It means that adding new features without breaking existing ones is likely to be difficult. The poor organization makes it easy to accidentally step on something important to who-knows-how-many other places in the code. It also means the application doesn't have broad ability to handle the set of all possible inputs robustly -- there are enough cases that aren't anticipated in the code (or may not be anticipated -- it's hard to tell with the poor oranization) that it will likely crash regularly."

Manager: This guy is one of those "I can do it better using the new language i learned in college" kids

*rolls eyes* -- the idea that a manager who'd say this is common is a complete flight of fancy. Where the hell are you going to find a manager in corporate America who is hostile to Java and sees it as something "new" that's the province of green college kids?

Manager: This guy is obviously in over his head and fears his job.

"We're all in over our heads here, thanks to the deepening pool of technical debt previous decisions have left us with, and as a competent engineer who's quite capable of finding employment elsewhere on a project that may not have these problems, I'm far more afraid for the company and the customer than I am for myself."

Manager: And you're certainly not going to ruin it for me. Don't EVER use the phrase "political reasons" in a professional document.

"You don't have to pass this on. I'm just telling you the truth. If you'd like my help in getting the politics right, I'm happy to give it, but even an engineer understands organizational politics exist, and it's no use pretending they don't."

Re:Merit? (2, Insightful)

rob1980 (941751) | more than 6 years ago | (#23828217)

The credibility of the memo lies in the fact that the project ultimately did get canceled. Your example manager here is handling criticism by questioning the credentials and credibility of the folks who were more than likely correct in their assessments of the project, which makes him look like he's just puffing out his chest and mindlessly defending a doomed project for fear of losing his own job - instead of, well, actually addressing the criticism.

Re:Merit? (1)

JeremyGNJ (1102465) | more than 6 years ago | (#23828243)

Welcome to Corporate America!

Sounds suspiciously like Wawanesa Insurance... (3, Informative)

ubercam (1025540) | more than 6 years ago | (#23827665)

Check out the story here [winnipegfreepress.com] .

A nice little 3.5 year IT boondoggle that cost a cool $70 million and cost one board member of 19 years his job. It all just came to light last month. It made some pretty big headlines around these parts as well.

I didn't RTFA, however, ... (1)

mandark1967 (630856) | more than 6 years ago | (#23827973)

That said, the article seems to be hosted on his own site where, conceivably, he has posted his resume. Couldnt someone simply research the companies listed against the article me mentions here and arrive at a pretty good idea just which company is being discussed in gory detail here?

This story is false. (0)

Anonymous Coward | more than 6 years ago | (#23828033)

Only the government waste's money. Corporations don't. When corporations spend money on projects, even when they fail, they are *INVESTING* in their future. There is a huge difference here, but slashdot is full of idiot statists who wouldn't understand.

Been there, done that (3, Interesting)

spaceyhackerlady (462530) | more than 6 years ago | (#23828139)

We've all gotten burned on projects that got out of hand, but I often wonder why it happens, over and over. Hubris?

I've seen projects where the requirements document was 1000 pages and growing exponentially. For an email server. I remember one project where it didn't matter if code even compiled: we had to ship what we had, because we couldn't delay any further. I made the mistake of expressing my views to the wrong people on that one, and was told in no uncertain terms to shut up if I wanted to continue working there.

I've seen more than one project fall flat on its face because the original requirements were wrong, like trying to develop PC software for an industry that was 100% Mac.

...laura

Runaway Project Language? (1)

libkarl2 (1010619) | more than 6 years ago | (#23828145)

Two consultants rewrote the 140,000 lines of [original obscure language] into 4200 lines of Java.

Thanks. Now I won't be able to sleep until I know what "[original obscure language]" was used.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>