Identifying (and Fixing) Failing IT Projects 144
Esther Schindler writes "Often, the difference between the success and failure of any IT project is spotting critical early warning signs that the project is in trouble. CIO.com offers a few ways to identify the symptoms, as well as suggestions about what you can do to fix a project gone wrong. ' The original study (which is still sometimes quoted as if it were current) was shocking. In 1994, the researchers found that 31 percent of the IT projects were flat failures. That is, they were abandoned before completion and produced nothing useful. Only about 16 percent of all projects were completely successful: delivering applications on time, within budget and with all the originally specified features. "As of 2006, the absolute failure rate is down to 19 percent," Johnson says. "The success rate is up to 35 percent." The remaining 46 percent are what the Standish Group calls "challenged": projects that didn't meet the criteria for total success but delivered a useful product.'"
Only 16 percent? (Score:5, Funny)
I have to feel that this number would be much higher if project managers would just learn to allocate an infinite budget and an unlimited timeframe.
Re: (Score:2)
Not just "minds". But also people. (Score:2)
Try planning a project that will take 5 years and $10 million.
People WILL leave the organization during that time. They will be replaced. If it was a tech, will the new tech do things the same way as the old one? Will you have hammered down your p
Re:Not just "minds". But also people. (Score:4, Interesting)
Try planning a project that will take 5 years and $10 million.
People WILL leave the organization during that time. They will be replaced. If it was a tech, will the new tech do things the same way as the old one? Will you have hammered down your process so that s/he will HAVE to do it the same way?
Will any tech worth his salt WANT to do things the same way as the old guy without questinging anything? Personally when I enter a new company, a large part of "getting adjusted" is fighting every foreign idea tooth and nail. I come to terms with them shortly, but I can't accept them as useful until I see them.
Re: (Score:2)
There are two items I see which always cause problems. One, failure to properly identify and document the requirements. Two, failure to resist scope creep or requirements change. In almost every case, these are a failure of management on up. Usually at the behest of marketing. Worse, I find the more input marketing has in large projects, the more screwed the project will become.
For whatever reason, the vast majority of companies refuse to treat project requirements as a p
Re: (Score:2)
Kinda like when my company decided to replace their functional but distinct HR, travel, an
Re: (Score:2)
Re: (Score:2)
Agreed. In fact, agile development methods consider it a success when this happens: one of the stated aims is to deliver the best value for the business, and if that is best delivered by not producing software, it's the deve
Re: (Score:2)
problem (Score:4, Funny)
Re: (Score:2)
Idiots will seek jobs, perhaps idiots will hire them?
Or to make a direct statement, management needs to own the issue of
who they hired.
Re: (Score:2)
Several possibilities:
1) HR is blatantly incompetent at recruiting IT workers;
2) The recruiters that HR outsourced to are blatantly incompetent at recruiting IT workers;
3) The idiot is someone's brother-in-law (or other forms of nepotism);
4) Management refuses to offer a salary/benefit package that would allow for the appropriately talented worker to be hired;
5) The idiot involved is good at selling themselves in an interview;
6) Time ra
Re: (Score:2)
Quite. They are still responsible ( in the causation sense )
"I kid you not, the beta of the next version of our product is being managed by the marketing director"
Oh, I believe you. I worked at a place where the VP Eng walked off
one day, and they appointed the marketing director to head the department.
I think that company was already headed for the dustbin by that point,
and decision-making like that is probably why.
"I really didn't want to be in a position to dus
Re: (Score:2)
First sign (Score:3, Funny)
AA meeting? (Score:2, Insightful)
Step 1: Get everyone to admit the project has a problem
Step 2: Figure out what that problem everyone admits is wrong really is
etc...
Sam
Re:AA meeting? (Score:5, Insightful)
> Step 2: Figure out what that problem everyone admits is wrong really is
1. We admitted we were powerless over this schedule -- that our project had become unmanageable.
2. Came to believe that a Power easier to blame than ourselves could restore us to schedule.
3. Made a decision to turn our will and our lives over to the care of the Consultant as we hired Him.
4. Performed an overreaching and mindless team-building exercise.
5. Admitted to the Consultant, to ourselves, and to the CEO the exact nature of our incompetence.
6. Were entirely ready to have the Consultant take over our jobs duties.
7. Humbly paid the Consultant to fix it for us.
8. Made a list of all persons we had harmed, and became willing to make suck up to them all.
9. Sucked directly up to the CIO wherever possible, except when to do so would involve our beating him at golf.
10. Continued to perform team-building exercises, and when we thought it was silly, we still faked it to HR.
11. Sought through kickback and corruption to improve our friendship with the Consultant as we understood Him, paying only for Coverage of Our Asses and the budget to carry that out.
12. Having had a Machiavellian awakening as the result of the project's inevitable failure, we fired the Consultant and resolved to carry the blame to other departments, and to re-hire the Consultant next year so that we can practice these principles when the next project goes off the fucking rails too.
Re: (Score:2)
Re: (Score:2)
Sounds like MY career, anyway... (Score:5, Insightful)
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Why Aren't You Jumping Off the Sinking Ship? (Score:5, Insightful)
Most IT projects I've been involved with that got to some difficult points suddenly had no one willing to discuss them, much less do anything.
Woe is the girl/guy with no authority brought in to get the project back on track.
Re: (Score:2, Insightful)
Hey, at least I get good salary and benefits! Coding a huge web application by myself for 7 months wasn't so bad: I like coding and money. Now I just hope they find something else for me to do... I hate being underworked.
consultants (Score:5, Insightful)
As long as you're up front about it (Score:3, Insightful)
Re: (Score:2)
Or moving to a different town?
Re: (Score:3, Interesting)
Re: (Score:2)
That deserves a repeat. You work for a good CIO with a vision and spine. As this article didn't tap into why many I/T projects really fail. Here are some of what I have seen:
Number one symptom (Score:5, Funny)
Re: (Score:2)
-nB
Re: (Score:2)
Re: (Score:2)
I'm safe then; on my projects the ratio never falls that low.
Re: (Score:2)
Article is self-contradictory (Score:5, Insightful)
From TFA:
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Give them the environment and support they need,
and trust them to get the job done.
Re: (Score:2)
Ultimately, the actual value of the articles in mags like CIO.com are marginal at best
Not so! Without these articles, how would CIOs sound clued-in when they gathered around the luau table during that big "experience sharing" conference at an island resort? How else would they know when to nod sagely while someone else relates their tale of SAP implementation? Or when to raise their eyebrows in appreciation of one of their peers' business savvy when they hear about how one of them deftly juggled a crisis during cutover from their legacy system to the new web-based one when they discovere
Re: (Score:2)
Bing! Go to the head of the class - this is really rather well stated. The phrase 'buzzword-laden tripe' is a particular jewel, and I hope you won't mind if I use the ever-lasting shit out of it.
Re: (Score:2)
You make it sound like the advice of the article is to do agile development, but that's really not what it's saying at all. Yes, a couple of their suggestions happen to overlap with agile methods, and one of the people they're quoting is an agile propo
Re: (Score:2)
Project Management is not the same thing as Programming Techniques. Milestones are not the same as software deliverables. Also
These are good ideas even if you are not doing Agile Dev
Re: (Score:2)
I think delivering working software frequently is bullshit.
Already, you sound smarter than the average... eh...
It greatly multiplies your work.
Yeah, much easier to deliver software that, eh, doesn't work? I'll agree with that.
It's like I'm building a car but at various stages the consumer demands to come in a start driving it around.
Oh, I get what you mean, now. is the "frequently" part that multiplies your work, not the "working" part...
It's a lot more work to repeatedly get things release worthy than to just keep moving along on the project.
Write quality stuff to begin with, stuff that's properly layered, properly abstracted, with high-quality error reporting and a debugging framework built in, and you'll be amazed at what you can do!
Also giving frequent releases leads to scope slippage and creeping featurism.
Really? I find the exact opposite.
Let's say I'm asked to write softw
Re: (Score:2)
I thank the client, and do Y. A week or two later, they get Y. Then I hear a whine about B. So I write it, and and a week or two later, kick out the software with B enabled. A few bug reports later, and everybody's happy.
Notice that features A, C, and Y turned out to be unnecessary! This happens ALL THE TIME
So scope slippage and creeping featurism "happens ALL THE TIME" but yet "I find the exact opposite."
Look when you have a small number of clients say less t
The last line of this classic explains it all... (Score:5, Funny)
Not a program was working not even a browse.
The programmers hung by their tubes in despair,
with hopes that a miracle would soon be there.
The users were nestled all sung in their beds,
while visions of inquiries danced in their heads.
When out in the machine room there arose such a clatter,
I sprang from my desk to see what was the matter.
And what to my wondering eyes should appear,
but a super programmer (with a six-pack of beer).
His resume glowed with experience so rare,
he turned out great code with a bit-pusher's flair.
More rapid than eagles, his programs they came,
and he cursed and muttered and called them by name:
On update! on add! on inquiry! on delete!
on batch jobs! on closing! on functions complete!
His eyes were glazed-over, fingers nimble and lean,
from weekends and nights in front of a screen.
A wink of his eye, and a twitch of his head,
soon gave me to know I had nothing to dread.
He spoke not a word, but went straight to his work,
turning specs into code; then turned with a jerk;
And laying his finger upon the "ENTER" key,
the systems came up and worked perfectly.
The updates updated; the deletes, they deleted;
the inquiries inquired, and closings completed.
He tested each whistle, and tested each bell,
with nary an abend, and all had gone well.
The system was finished, the tests were concluded.
The users' last changes were even included.
And the user exclaimed with a snarl and a taunt,
"It's just what I asked for, but not what I want!"
Yes, it does indeed. (Score:2)
The problem is usually awful requirements (Score:3, Insightful)
( Not that I'm bitter or anything. )
http://blogs.warwick.ac.uk/images/steverumsby/200
Re: (Score:2)
Yeah, you may be right, but there's really no reason to be bitter, this stuff happens all of the time in the software industry.
Here's a pretty extensive blog posts with some thoughts on the subject. [blogspot.com] http://gatesvp.blogspot.com/2007/07/where-do-thing s-go-wrong-in-software.html [blogspot.com]
Basic premise is that the bitterness is probably misplaced. Truth is, the guys giving "bad requirements" don't really know any better, I mean, they don't know how to program. If they knew how to program, they wouldn't need us. So
Heuristic methods (Score:4, Insightful)
Spotting a failing IT project: If it's a project, and it involves IT, then it's failing. (The summary's cited statistics bear this out).
Fixing a failing IT project: Rewrite the laws of economics. (My experience bears this out). This may involve fiat, chemical means, or founding a new religion.
Changing definition of success (Score:2)
There have been some bona fide improvements in software development over the past 15 years: longer variable names, language-supported encapsulation, and inline documentation tags that allow for larger teams a
Failing Projects come form endess TPS reports and (Score:2)
Grain o' Salt (Score:5, Insightful)
There's quite a few projects that we arguably start (probably even close to the figures quoted) that we don't finish. They're not failures, often I (me, not the department or project managers) had no intention of completing them anyway. Here's why some don't get done:
1. I can't get it past the budget process. There's a time and place to pick your battles. Maybe throwing HR's new whiz-bang software project under the bus to make the operations manager's project swim along is worth it. It doesn't mean HR's project is a failure.
2. We start a project to investigate a new technology. Hey - sometimes (dare I say most of the time?) the new stuff doesn't work as advertised. Sure, we've got an older 802.11b network running side-by-side our 802.11g. We looked at ripping it out and starting to get into the 802.11n, but it's not worth it right now. But the exposure to 802.11n was worth it. We'll revisit it next year (when Cisco gets an n product.)
3. The "nice to do" list also creates some "failures". Boy, right now we need a strong asset tracking system. Well, screw it. We can track the licenses on paper as we've been doing. We've got more important things to worry about.
However, the shit that needs to get done, gets done. That new accounting system? Hell yeah we're going to get that right.
Re: (Score:2)
Your first example about balancing the HR project with the operations manager's project seems more about resourcing and scheduling multiple projects than one or the other individually being a failure. The inability to meet HR's schedule expectation is a project management failure, since embarking on that project without knowing it can be finished on time and budget is a failure.
I work for a large multinational engineering contractor, an
Re: (Score:2)
...I can say that a project isn't necessarily a failure if you are smart enough to back out of it in safety before it becomes a total catastrophe.
It is still a failure if nothing concrete is delivered, i.e. a totally aborted project. Of course, well documented lessons learned, particularly for investigating use of newer technologies, is something concrete. If the learnings aren't well documented, then this also is a failure, as far as a company is concerned, as the people who had the experience can move on, taking their knowledge with them.
From a company viewpoint, if you are "backing out" of a project, you still have expended some resources, so
SAT Effect (Score:3, Insightful)
I have serious doubts that IT projects have made any significant improvements in management efficiency in the last decade or so. More likely the people estimating timelines, budgets and features have learned from their mistakes and simply set the bar much lower than they did in the early 90s.
It's the "SAT Effect" (tm). Why actually improve performance when you can simply tweak the metrics by which you measure?
This is not about moving goalposts (Score:2)
Pardon, but as someone who's managed projects, it's a bit more than "tweaking metrics" or "moving
Re:SAT Effect (Score:4, Insightful)
You make it sound like a such a bad thing. I don't necessarily think it's just about "lowering the bar", but instead an issue of having realistic expectations. In 1994, having a dedicated IT department was still relatively new for many companies. To put it in perspective, people were still using Windows 3.1. The Internet wasn't even a blip on the pop-culture radar, and (IIRC) Netscape was just being released around that time. Most people understood practically nothing about computers and networks. In a lot of colleges, CS was still a relatively new major, and many colleges didn't even offer IT-specific majors yet. For a long time, the "computer experts" came out of other majors relating to math, engineering, and science.
So it wouldn't surprise me at all to learn that the managers of IT projects in many companies had practically no idea of what they were doing. I wouldn't be surprised to hear that they had silly expectations about how things would work or what their new systems would allow. After 13 extra years of seeing the reality of computing and being frustrated by computers, one would think their expectations would be lowered somewhat.
Re: (Score:2)
Were any of them REALLY successful? (Score:2)
Re: (Score:2)
If you aren't part of the solution...... (Score:5, Insightful)
Seriously, though the classic problem with IT projects are two-fold: 1) Unclear Requ2irements and, 2) Scope Creep. Unfortunately, while IT is bemoaned as incompetent, the truth is that most of the users are even more incompetent, yet the IT departments ask the users for INFORMATION.
IMHO, You have to assign someone from IT to LEARN THE BUSINESS before trying to create solutions. For example, if you are creating an application for a Shipping Department, send people from IT to go work in shipping for a week and UNDERSTAND how the department operates and how it can be improved. Asking the users what they need without true understanding leads to disaster and inefficiency. If you gain understanding and insight into how to create a solution, you can make real improvements and possibly even eliminate inefficient/useless tasks and save labor.
Scope Creep.... The old, hey while you are at it, could you just add one more feature to the program? You have to respond NO, but we will add that to the feature list for version 2.0 of the application. Imagine if Henry Ford tried to add all the features we have on the modern automobile to the Model-T. The Model-T wouldn't have ever been delivered. Creating software is an iterative process and just like car models you have to stop adding features at some point.
Good Luck! Just remember, the problem is rarely technical.
Re: (Score:2)
Based on that sentence, may I suggest that you also consider: 3) Poor QA?
Re: (Score:2)
I am assuming this project has good DBAs and good programmers. Most shops have these, but these poor folks find themselves drowning in nebulous requirements and SCOPE CREEP.
Personally, I operate on the "It co
Re: (Score:2)
A person with a functioning brain. The real world must frustrate you to no end.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The two are one and the same, of course, because they both mean that the program you're writing might not be the one that's actually needed.
IMHO, You have to assign someone from IT to LEARN THE BUSINESS before trying to create solutions.
This is an interesting approach, and it certainly has merit. Another option, one espoused by the agile development community, is to have someone who already kno
Re: (Score:2)
Re: (Score:2)
If I had a dollar for every time a softie had blamed unclear requirements or scope creep for a project's failure - I still probably wouldn't have much with the way the dollar is plunging
Point is, the world moves on, needs move on, things develop. If you and your methodology can't cope then I'm afraid IT'S YOUR PROBLEM. You need a different development methodology, a different approach that's more flexible. Its no good saying "this is the twentieth time a project has suffered from requirements creep" - its
Re: (Score:2)
And this is why projects fail. Imagine building a house for a customer that comes out to the job site and asks the builders to make DAILY or HOURLY changes. Suppose he wanted to resize the basement after it had been poured. This would change the entire structure of the house, not to mention make the foundation weaker. The point is that it is RISKY, INEFFICIENT, and COSTLY to change a design in progress.
Re: (Score:2)
Hey man, I love your "spend time on the floor" concept. I'm behind that 100%, truth is, if I could convince everyone of the importance of this, I would book in a site visit to every client we worked for. I don't think that I have that sway yet.
Of course, with Scope Creep, the biggest issue I've seen is usually the manager. Even with full-out change requests forms, I've seen managers lose stuff, or make non-transparent decisions about features. The best driver for controlling creep is having a next step. P
Any changes in methodology or sample? (Score:4, Funny)
> rate is up to 35 percent."
They redid the study excluding government projects?
Identify it: does it use xml? (Score:2)
The metric I tend to use most often (Score:2)
In successful projects, that comes out to something like 80% or higher, while in unsuccessful projects you see at best 30%. The way this ratio is kept high is that in the initial planning stages you keep a technology guy in the room who can say no to the sales and end users (or sometimes "yes, but it will take you another 4 months and $300,000")
Not just IT (Score:2)
How to spot the places where late is normal (Score:5, Insightful)
- The bigger/more-complex projects have little or no analysis.
- There is neither a formal Requirements Gathering stage nor (in Agile Programming) an easilly available user/user-representative with which to discuss business features.
- Delivery of a project to a client is an unstructured process. In other words, there is no list of standard types of documents and deliverables to deliver which is common across projects.
- Project planning does not have a built-in margin for unforseen problems and sometimes relies from the start in people working extra (unpaid) hours to make the budget.
- Sales dictates the deadlines without consulting (or consulting but then ignoring) the technical side.
- There are no specialized Testers.
- There are no standardized software components, software frameworks, good practices or documentation for use across the company.
- There is a vast number of software languages, software libraries or frameworks of different versions used across the projects done in the company. Similar projects use different languages/libraries/frameworks and/or use different major versions of those. Developers are totally free to choose the languages and libraries they want to use for the projects. Maintenability is not taken into consideration in the choice of languages/libraries which instead are chosen on the basis of "cool sounding", "fun" and "CV enhancing".
- The project manager has little formal or informal power within the company beyond his subordinates (this is harder to spot but a surprisingly good predictor of failure).
There's quite a lot more, but these are some of the more obvious ones and i've seen all of them already more than once.
More in general, what software development environments where late or failed projects are common share is a failure to organize and/or a failure to prepare and/or lack of "soft skill" from project management and/or ignorance of the characteristics of the software development process.
Mod parent up (Score:2)
Ive worked a number of projects (mostly defence related) that cover all the points above in spades, and they were all a joy to be part of.
And Ive worked on large projects in large organisations that do none of the above
Smaller organisations sometimes get away with it, because they have to - they dont have the meat in the budget or resources to do things 'properly'. Most of these 'survive' somehow, but not forever.
I have found one at th
Re: (Score:2)
The requirements process is also a k
Annoying (Score:5, Insightful)
So a bunch of companies (who all sell expensive proprietary project management software) get their heads together and conduct a study on project success/failure ratios
Umm
Projects are successfully delivered by good coders with good tools, and a thorough understanding of the requirements. There have been RADICAL advances since 1994 in the way that software is built, and its these advances more than anything else that lead to successful projects.
Coincidentally, Prior to 1994, if you were working in software, you were working blindfolded with one hand tied behind your back. By 1995, this Linux thing starts gaining momentum, and very quickly we see this massive rise of open source projects in a huge number of areas. Prior to 1994, an SQL engine is some mythical binary blob that you have to purchase from Oracle or others
Suddenly, as a software coder, the blindfold is removed and you have both hands free to work. Whatever problem domain you are likely to encounter, you can easily find open source projects that have already dug very deep into that problem domain, and have code and design discussions open for general peer review.
So its no surprise that in this new and extremely fertile post-1994 world
Another thing to note is that the core developers in a lot of projects are older and wiser now. Many are well past the wrong side of 40 and still coding day and night for the sheer joy of the art. Perhaps they have also grown more politically savvy, and know how to take management speech, distill the essential elements out the mouths of managers, and then go away and do the project their own way regardless. Except this time, they know how to twist it so the 'managers' can feel like they deserve some credit for the project as well, whilst at the same time keeping them discretely out of the way - so that the project itself can move forward smoothly.
Maybe that is one benefit of shiny new project management tools - it gives the managers something to occupy their time with, so they can keep out of the way.
Re: (Score:3, Insightful)
Almost like building a house. Once the plans are drawn, the ressources allocated, etc, if the project is managed correctly, its almost impossible for the coders to screw something up.
Re: (Score:3, Insightful)
*sigh* I can tell you've either never worked on anything with complexity, or paid attention when you did.
Right, Mr "I'm so smart, I can fix everything with software development tools". Who does the following for your projects?
Re: (Score:2)
I hear your anger, but it's CIO magazine, not codeproject.net. You're right, programmers are the actual generators. I have this theory I can "fallacy of management", which is the concept that managers are responsible for project delivery and are therefore "worth more" than the people that "work under them". Managers tend to be good talkers and it's very common to subscribe to the "fallacy of management", so management can actually get away with pretending that they are the most important piece of the projec
Re: (Score:2)
Well, I do - I think the whole point of the article was to make 'project management tools' look good, and to provide 'editorial content' that should sell more ads for their little magazine.
Lets see who they exclusively quote in the article
- Scott Johnson, CEO of AtTask, an Orem, Utah, maker of project management tools.
- Jim Johnson from the Standish group, who are offering to sell the reader a copy of the report on which the article is based.
- Raj Kapuor, e
Blame the ..... (Score:2)
If you're not failing, you're not trying. (Score:2)
Re: (Score:2)
Interesting business sense you have there.
Sponsorship (Score:2)
No project sponsor from the business side (usually in high places), or - even worse - there are multiple "sponsors" from multiple departments (usually using the project as a war by proxy entity for their departmental feuds).
In both situations I wouldn't come near the project with a gas mask and asbstos suit.
And that's no bad thing (Score:2)
What's worse is.. (Score:2)
What's worse is getting a project done on time and under budget and having nobody notice and nobody care and think it was just normal. But what is even worse, is doing this, then have the 'boss' change their mind and rip the whole thing out behind your back. I work for public schools and have it found it shocking how much this goes on. An example is a 25 computer lab I built in an old classroom that involved computers, tables, wiring, electrical, tables bolted to the floor, new AC, new paint, etc, etc.
It Helps To Plan To Fail (Score:2)
I've written a small online book [alcohen.com] on my experiences in managing technical projects.
One of the biggest mistakes I see is that managers don't recognize that there will absolutely be some failures within the project, i.e., approaches that turn out not to work. It's important, when one can, to move high-risk stuff to the beginning of a project, and even have a "pre-project" phase where the unknowns are explored and conquered, leading to a much better spec, and much better time and cost estimates.
Another
What I'm guessing (Score:2, Interesting)
I did systems support in a big financial in 1997. Software was written in C++ on Windows. Builds would run overnight. Something wrong? Could be an OS t
Projects fail when people don't give a shit (Score:2)
Most of the BS these guys are spouting helps them with "peer recognition" but their real workers probably want to hurl, if they even read the article.
What a crock of shit. There's a few grains of truth hiding underneath all that bullshit, but bring a shovel.
People care about the project, it'll do well. People don't give a rat's ass about the project
With Major Hopeful's help (Score:2)
The phases in a doomed project seem to be:
1)Can we ignore it? Maybe the probelms will just go away and our asses will be saved.
2)Can we fix it? Take some corrective action to save the day.
3)The project is doomed. Can we reuse some of it? At least then w
Re: (Score:3, Insightful)
How many civil engineering projects are planned by someone with someone with little to no experience and implemented mainly by fresh graduates? Software's often lack of physical safety issues and low visibility of mistakes make the seat of our pants approaches way too common. My personal favorites are the schedules that assume no one will ever get sick or tak
Re:With Major Hopeful's help (Score:5, Insightful)
One problem I see, is that many IT projects begin with the goal of making the project manager look good.
The proper way to start a project is: How can we fix BAD THING. Instead of the usual "We should migrate this to SAP cause that would look so cool on my review".
Many times IT projects become a destination, instead of a method to reach the companies destination be it ( manufacturing / sales / service ).
Mod parent +1 insightful (Score:2)
That was one of the most insightful posts I've ever seen on Slashdot.
Re: (Score:2)
(already at +5 for so no point in mod'ing)
Re: (Score:2)
Re: (Score:2)
I have to wonder, though, if the growing "success" of IT projects isn't related to more inhouse development. Back in 1994, large projects almost always relied on external consulting agencies like Anderson. These services were very poor at delivery, in part because of their lack of understanding of how each business worked. Staff employees usually had a better understanding, but even in large corpora
Re: (Score:2)
Your methodolgy is out of date, and you are ignoring best practices. Modern thinking is that you designate a scapegoat before you begin to collect your requirements.
Re: (Score:2)
A prevalent reaction is to adopt an attitude "We have invested so much money and human resources into this project that we can't afford to fail!"
Sometimes you just need to cut your losses and pull out ("cut and run?") of a misguided or doomed project. There is such a thing as going further and faring worse.
Re: (Score:2)
I'm in a situation where the preliminary analysis was wrong on several, severe cases, so the project scope is ending to be on an order of magnitude greater than what was originally anticipated. We're bei
Even when it fails, offshoring still proceeds. (Score:2)
Thank the business lobby, and Ford/Reagan for giving businesses their thunderbolts for this.