Slashdot Mirror
Identifying (and Fixing) Failing IT Projects
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.'"
Captain Obvious is writing articles again.
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.
Badass Resumes
at least a large part of the problem are the incompetent masses that we refer to as "IT specialists". I'm surrounded by them.
Your consultants are all Elbonian
This reads like an Alcoholics Anonymous meeting:
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
That 31%-flat-failure rate sounds just about right; about a third of the projects I've worked on over the last 15 years have been complete flops (with the usual list of various reasons from "bad idea to begin with so it needed killin' " to "we changed bosses and since your project wasn't the new boss' idea..."), but I'd have to challenge the notion from TFA that they "produced nothing useful", because I've learned something I didn't know and wouldn't have otherwise known from each of them -- in other words, I'd count them all as at least partial successes because I personally gained something from them.
This space intentionally left (almost) blank.
Seriously.
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.
Got Trader Joe's? friendwich.com RSS feeds work now!
When management wants a project that IT knows is bound to fail, our company will sometimes hire an outside consultant to run the project. That way, half way through the project, as we miss milestones, we can fire the consultant and blame it all on him. He gets paid, and we get out of the blame. Win-win.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Half of all outgoing port 80 requests are to slashdot.org.
The cake is a pie
From TFA: "Small, discrete and often" are the guidelines for the milestones for a successful project. And from the Agile Manifesto: Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. From TFA: "Make sure everybody really agreed to what the project is going to do," he says. "Make sure everyone has the same goals even when they have conflicting agendas." And from the Agile Manifesto: Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. This is just another shoddy example of "journalism" from an IT rag whose job it is to produce buzzword-laden tripe that can be used to get advertisements in front of tech weenies. Ultimately, the actual value of the articles in mags like CIO.com are marginal at best, and usually only slightly more interesting than the advertisements!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
'Twas the night before implementation and all through the house,
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!"
I haven't read the article but I would bet good money that they are allowing clueless managers and CEOs who gave very bad requirements in the first place, to determine if something was a success or failure. In other words, software is only as good as the initial requirements and design. If your client / customer is clueless then they will give you some hand-waving description of what they want ... something like "Listen, we need a new computer system that kind of does what the old one does, but just works better and makes more profits for us! Now hurry up and make it work, Code Monkey! Now excuse me while I retire to my executive suite / relaxation salon and get my manicure."
6 /01/30/dilbert20060121046729.jpg
( Not that I'm bitter or anything. )
http://blogs.warwick.ac.uk/images/steverumsby/200
I can throw as many stones as I wish; my house is made of transparent aluminum.
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 we didn't waste all the time and money.
4) Reuse disk space. Find a scapegoat.
Engineering is the art of compromise.
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.
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 and for attrition; and code reviews, pair programming, and unit testing frameworks that make the work of mediocre programmers more repeatable.
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?
What about management? Does this project suit the goals of the new manager? Manager usually have to "solve" a "problem" to justify their salaries. Coming in and seeing a project this big
Will the business even NEED a project that was designed 5 years ago? It doesn't take that long to put up a office tower.
Failing Projects come form endless TPS reports and useless meetings As some time you spend more time of them then your real work and they are the only places the that the bosses get any info about the Projects as they are so dumb they waist IT time on showing them how do email 1-2 times a week and other easy things then the IT people don't have the time to fix things with the people who do the real work on the Projects.
I gotta say, I always take this kind of stuff with a grain of salt. As an IT manager (director, or whatever the hell you want to call it) I've got a little perspective on it.
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.
----- obSig
In 1994, the researchers found that 31 percent of the IT projects were flat failures. [...] As of 2006, the absolute failure rate is down to 19 percent.
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?
One almost has to wonder if the current 35% "success rate" is for truly successful projects, as opposed to ones where the only criteria for success was completing it. An article from WorseThanFailure (previously TheDailyWTF), originally intended to explain why the site's name had changed, does a nice job of explaining just why "success rates" can be misleading.
* Q
P.S. If you don't get this note, let me know and I'll write you another.
If you'd dig a little deeper, I'd say you'd find the real root of the problem is that certain people working on the project aren't any good at their jobs, particularly management.. unfortunately any attempt at "fixing" the project will envolve the input from the same people that made the initial bad desicions .. so what is the solution? Obviously, not hiring people that aren't any good at their jobs.... but what if the person who is in charge of hiring people isn't any good at his job?
If you aren't part of the solution, there is much money to be made in prolonging the problem. (My second favorite de-motivator)
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.
That's all part of the consulting game, but you have to play fair. Offer a fixed-price contract with no early termination penalty, or provide an escape clause that pays some fair amount if the contract is terminated early. I've known a couple of projects that badly burned some consultants, because management knew the project was going to fail, but they still put the contract out light on the rate but heavy with incentives. And what really sucks is, you'd like to say "Boy, you'll never catch me working for someone like that", but when they're one of the major players in town, you know you may have to play. Unless you're happy writing VB front ends to Access databases...
Just junk food for thought...
How could I tell this article was written by an IT project manager? Plenty of vague buzzwords and friendly-sounding phrases, zero mention of technical skills/information, and most importantly - no coherent definition of what an "IT project" is. Many IT projects "fail" because many IT project managers don't have the slightest clue what they're managing.
> "As of 2006, the absolute failure rate is down to 19 percent," Johnson says. "The success
> rate is up to 35 percent."
They redid the study excluding government projects?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Fix it: pick a new xml parser, and start again from scratch.
please excuse my apathy
Make sure everyone's vote counts: Verified Voting
All they have to do is identify the problem and then fix it. What's the issue?
The formula is simple: (clear plans to produce features) / (features promised to customer or end user).
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")
I am officially gone from
Projects with unclear goals, and unclear measurements for success, tend toward failure. Unfortunately, committees tend to design exclusively these, because being vague is how you keep your job. In case a project fails, describe it vaguely, so you can blame someone else and move on. This motif is repeated through human society, even politics. Who's to say the Iraq war wasn't one of those 31% of scope-creep, vague-goal projects?
technical writing / development
I have been designing and managing IT project for 12 years. The keys to successful deployment are simple:
1. Understand the business need.
2. Understand the limits & capabilities of your team and software/hardware.
3. Identify a real budget.
4. Get full scope documentation and don't let it change. (all add on requirements are Phase II+)
5. Make sure the person leading the project is not also doing end user support.
6. Hire my company to actually do the work.
7. Profit!
Given that it is almost impossible to get process documentation out of the internal client most IT projects fail before they even start.
I am happy to say we hit over 98% successful completion on IT projects. Strategic comes before tactical, but you must have both.
Timing is everything
As a contractor (aka freelancer) software engineer and analyst i have over the years learned to spot a number of indicators which are usually associated with the kind of groups/companies where software projects tend to be late and/or not deliver what the business needs. Here's a couple of indicators for that kind of place:
- 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.
1) Fail early, fail often. 2) Early optimization is root of all evil. 3) Good horizontal communication. The problem is that it is in the human nature of bad managers to will project towards success. And, to continue on point touched by the first article, some cultures (to some degree Indian) makes developers hide failures "to please manager". Which compromizes communication. Given that it is especially challenging to follow these 'agile' rules on big projects. I just witnessed how brilliant, smart, flexible engineer and capable communicator was fired by his strong-willed boss who likes to succeed through personal overtime and lacks ability to manage complexity. Which is one of the main main tasks of modern software manager. On the base of it successful agile management approach is based on flexibility in ideas and communication. And on a big sign on the door: 'Strong willed work maniacs are not welcome!'
"Woe is the girl/guy with no authority brought in to get the project back on track."
It's called "responsibility without authority". That's a key concept. If you recognize the situation, you learn to either change it or get out fast, as this situation ALWAYS leads to disaster, with your name on it.
I find this article very annoying.
.. and conclude that things are improving, and then attribute the improvements to things like .. This awesome new, expensive, proprietary project management software.
.. excuse me, but I have NEVER seen a project that was conceived AND executed solely by any number of 'project managers', using any form of project management tools, meetings, and other justifications for their existence.
.. after 1994, an SQL engine is something tangible that you can download of the internet and get your hands dirty with the source code. Ditto with 'internet enabling' your applications - Ditto with having a real freely available and portable C compiler - ditto with having a raft of languages (perl, PHP, etc, etc) that open up new possibilities.
.. software projects are more successful. But can you simply attribute that to a small selection of expensive, proprietary project management tools ? WTF, I dont think so.
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.
What if the project is to save $X by outsourcing/offshoring and it is going bad?
The PHB's can't admit they are wrong and it isn't going well? Who gets the bad performance review? Why those who aren't management and had nothing to do with the bad decision in the first place.
Project management is not a profession. It is a joke.
Just a dude. Stuck in IT.
I don't think that was the point of the article. While I agree that for software development things like Agile, XP, and better languages and tools have allowed for greater project success, I do think tools can be useful.
You don't use a bug/issue tracking system? How do you prioritize what you should be working on? Does the company you work for have several things going on at the same time? Do you do specific work for individual customers, and if so, how is this communicated?
I don't think "shiny/proprietary software" is the sole cause for greater project success. But, the article is dead on in explaining how tools like this can help.
From your post I can only assume that: 1) You have only ever worked for bad technical managers, 2) The company you work for is small and doesn't have enough information/customers to see any benefit to having a system help you track this, or 3) You are a typical embittered software developer with a god complex who thinks the only real contribution made to your company comes from your developement team.
Really enjoyed reading that one.
.. at all. Yes, they were all disasters.
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 the moment that is quite unique - tiny organisation with a tiny staff, making an absolute killing in the fuel industry. The engineering is done properly, but the software development is totally cowboy style, and 1 man to 1 project.
The only parts that are done 'right' are the pre-project analysis and the requirements gathering - which we try and get close to (an ancient) DoD 2167a standard on. Other than that, its all cowboy style. Zero consistency between developers, and each working in a skillset totally alien to the others. A simple peer review of code is therefore pointless, so there is no margin for mistakes - at all. It seems to work because the $ margins are there, and each developer is a disciplined coder and tester up to a point (of their own code only, so you can imagine what up to a point means). Despite this recipie for burnout, its also a remarkably low pressure environment, with lots of fun social activity as well. This place has to be some weird sort of exception.
One other point I have just realised in reflection - although all deadlines are driven entirely by sales, the small handful of coders here really do have final say in just about all decision making processes related to THEIR code. Even to the point of altering requirements and re-writing customer contracts to suit. There is a 2-way respect/trust thing between the managers and the staff, and the customers as well.
We also drink together outside of work - staff, management, investors and customers all party together after hours when appropriate.
Its not unusual for a customer to drop in on their way through to a another city, talk turkey with the actual developers for a while, and then head out together after work and get smashed.
Weird but good.
I wish I hadn't wasted my mod points this morning.
That was one of the most insightful posts I've ever seen on Slashdot.
*sigh* back to work...
In other words, software is only as good as the initial requirements and design.
And yet, I've seen countless startups come up with great and successful software without any requirements. Or when they had an initial design, end up with a product completely unlike it -- and far better.
That's not to say that bad mgmt can't kill a project -- it sure can -- but if mgmt came to a good team and said "make something like what we had before, but better", and then left them alone for a year, do you really think they wouldn't be able to deliver?
Mgmt doesn't do this, of course. They micromanage, or provide inadequate tools, or require unrealistic timetables. But *those* things kill projects, not lack of requirements.
Do you really think Steve Jobs wrote out a detailed design document for Mac OS 1.0 in 1981 and handed it to the programmers? Nah, they hacked on it until they figured out what it was supposed to do, and how.
I doubt in this anti-worker climate that abortive failure of offshoring is an option. It just means it's delayed, especially with Cohen & Grigsby in the picture.
Thank the business lobby, and Ford/Reagan for giving businesses their thunderbolts for this.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Blame the customer for putting up with IT's shit. After all, outside of software businesses, IT systems are NOT the core products of most companies. If a department says it needs a system to do 'X', thats what they should get. Fully buzzword-compliant IT systems may be a feather in the CIOs hat (or a gold star on their resume when they jump ship to which ever systems supplier they just burned their companies millions with), but that's not the business the company is in. Also, blame the customer for the existence of the CIO position in the first place. Management in a company should understand their own business processes to the point that they don't need another department to tell them how to do their jobs.
Blame corporate management for not keeping tabs on both the customer organization who is too lazy to take an active role in their own business process re-engineering and would rather just throw their requirements over the fence and see what comes back. Blame them for nurturing IT departments that encourage this sort of thinking. And blame the people in mahogany row for not biting the bullet and pluuing the plug on sunk costs. I think quite a few 'challenged" systems would probably fall into the failed catagory if anyone had the balls to confess to the board of directors that a few hundred million (I've actually seen billion dollar plus black holes) have just been shoveled down a rathole.
Have gnu, will travel.
I don't think that was the point of the article
.. the entire article is simply a platform for these 3 individuals to voice their opinions and tout the beneifts of their product. There is nothing more to the article, no analysis, no debate, no investigative journalism. Its just an advertorial. I am surprised that you cannot see that.
.. anyway, that made me smile even if it did impress the heck out of you. (Oh - btw - I am assuming that you did your homework too, and researched who these people were, the ones who's opinions you strongly agree with).
.. but who really knows ?
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, executive vice president of the Center for Project Management, a software project management consultancy and education firm in San Ramon, Calif
And thats it
By all means though, feel free to follow up on the article, and have a look at the people being quoted.
I particularly liked reading through 'The Center for Project Management' website (which I did before writing my original comment above), and I must admit that their premier product did prompt me crack a smile. If I may quote straight from their website, ie. their uniquely original "Culture Model Approach", which is a "proven and tested Project Process Architecture (PPA(TM)). CPM's principles-based, four-phase, 24-step methodology"
You don't use a bug/issue tracking system? How do you prioritize what you should be working on? Does the company you work for have several things going on at the same time? Do you do specific work for individual customers, and if so, how is this communicated?
Geez, I dunno. We have this MilStd-498 thing, and then there is this big stack of documents about DDx interop stds for Aegis development, and I think 'the company' mentioned there might be some other projects happening
We are yet to be enlightened by the Culture Model Approach, we desperately need to get some proven and tested Project Process Architecture (PPA(TM)). CPM's principles-based, four-phase, 24-step methodology happening around here SOON, or we are so obviously fucked !
I don't think "shiny/proprietary software" is the sole cause for greater project success. But, the article is dead on in explaining how tools like this can help.
I respect your opinion on that. I personally havent been exposed to the same proven and tested Project Process Architecture (PPA(TM)) that your company must be using, so I cant judge.
From your post I can only assume that: 1) You have only ever worked for bad technical managers, 2) The company you work for is small and doesn't have enough information/customers to see any benefit to having a system help you track this, or 3) You are a typical embittered software developer with a god complex who thinks the only real contribution made to your company comes from your developement team.
From YOUR post, I can only assume that :
1) You cant tell the difference between an advert and a article.
2) You dont know me at all.
I think someone at the CIO level understands that the basic premise of this discussion is that standardized tools and processes can help increase the likelihood of project success. How? By communicating information like cost overruns and projected schedules early enough in the project timeline so that corrective action can be made. Data like this can help managers understand when a project is failing before it becomes apparent to everyone already working on it (by that time it is usually far too late).
Any good software development process (Scrum, Agile, etc.) is based on similar principles. However, tools and process templates are often helpful in order to formalize these best practices regardless of the size of the company.
I don't think anyone is going to rush out to any of these vendors/consultants immediately after reading this article. I think *most* people get the idea that these "experts" are merely representative of an industry trend at large. Is it advertising? Perhaps this may raise some visibility to the providers mentioned in the article, but there is no talk of specifics and/or why these specific tools/teachings are superior to alternatives. I'm pretty sure CIO magazine gets no benefit by quoting from 3 people that work for companies that 99% of its readers have never heard of.
Obviously, I don't know you, but I would be very surprised to learn whether you were functioning in a management role based on your cynicism about these kinds of tools. This isn't about some bullshit tool that pointy-haired managers deploy to help him/her to manage a development team regardless of whether they have any technical skills. This is about scaling your business to effectively track where you are at on your work.
Good tools make good practices more efficient. I'm surprised that you're not using ANY tools for tracking work. This sounds like chaos.
I only responded to your post because I see this attitude all the time with developers. And, granted, there are a ton of crappy tools out there that simply CREATE MORE WORK rather than help eveyone get on the same page (think M$ Project, for example). But I've seen development teams work much more effectively together by using project management/issue tracking software than they did without.
You have written off the article because they quote from 1 vendor and 2 consultants. How would you have written it? Who would you use? A CIO that would "endorse" the solution he/she chose to bring in house? Regardless of the approach, as soon as you mention ANY specific tool or PM practice, it becomes an "advertisement".
A high failure rate could indicate a willingness to take risks and try new things. The fact (at least according to TFA) that the rate of project failures is half the 1994 rate could mean that project management has improved across the industry, but I think it's much more likely that the cause is just a change in the nature of the projects. Project managers in a post-dot-bomb world may be less willing to take risks. At the same time, there now exist best practices for many business-oriented computing tasks where there were none in 1994.
If I were a CEO and my CIO told me that he'd gotten the software project success rate up to 100%, I'd be strongly inclined to fire the guy and replace him with somebody more willing to try things that might not always work out.
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.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
MANAGEMENT
"Drawing closer to world domination, keystroke by keystroke."
I'm fairly shocked that "with all the originally specified features" is considered necessary for a project to be considered successful. It's extremely rare for the business needs for a project to be stable over anything more than a few months, which means that for any long-term project the features you deliver _must_ be flexible if your project is actually going to be successful. Couple that with a lack of understanding by users of what they really want/need and going along with original requirements is a recipe for disaster.
My Journal
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. Just to have the super change their mind the next school year and rip the whole thing out and move it to a new building. The tables and computers got scattered (there was older stuff in the new location, so the software had to be installed again - more labor), the floor was left with holes. All new electrical outlets sat empty. The only thing fully salvagable was the software license that cost over 50K. many hours of workpower, planning and troubleshooting wasted, without a thought or a care.
When I started I asked for the requirements spec, I was handed a 10 page document that had a cad drawing of the modules with lines connecting them. It then had some system requirements that were way too low and a 8 page summary of the system. That was it. The system is 75% done, with the remaining 25% falling to me, my team and an outsourcing company. The thing is there is no way to know if that 75% is actually done, seeing as there is no spec. My manager tells me I should "do what feels right" and "make it the way you think the user wants it".
We have sold this system to 10 companies already, with a delivery date of September. I am the "resident software expert" with exactly 2 months of real experience. Every customer wants something different, so each system is customized. The problem is what they want was never agreed upon and now 2 months before release new requirements are still coming in.
Then on the issue of testing we have no test cases or test plans. We have 2 weeks allocated for testing, thats right 1.5 years developing and 2 weeks testing with no set procedure. We're told to "throughly test each module as we see fit". To my teammates this means running it for a day to see if it crashes then saying it works.
Sensing the flop my manager pulled me into his office and asked me "how do you develop software properly". I explained various things like agile and waterfall to him and he was amazed. He said next project he wants me to help him do it right.
Granted we are an OEM equipment manufacturer that normally produces circuits, but they have no clue how to manage or build software. You know it's bad when the college grad can see the failure looming. I basically started here set on a course for failure. I just hope I don't get canned when this explodes.
Dilbert: Aahh...It has the sweet smell of an unnecessary assignment.
Wally: Yes, I can smell it from here.
Dilbert: Feasibility of using non-existant software.
PHB: Stop being you!
Wally: Hee,hee!
Friends don't let friends line-dance.
Start using Critical Chain Project Management and many of the issues plaguing today's IT projects become a thing of the past.
There are no silver bullets for silver bullets
There are a small number of factors that are very strongly linked to project success (ie delivery on time, on budget and on quality). None of them are related to specific methodologies, or SW tools, or any other flavour of the month.
Stakeholders Do you have a single empowered sponsor? Are decisions taken fast enough? Are other stakeholders happy? Benefits Case Is this going to be useful (in the intended way) for whoever is paying for it? Will you be able to prove it? Work and Schedule The obvious one. Do you have a realistic plan? Are you meeting the plan? Do you believe the progress reports? Risk Are you managing Risks (bad things that might or might not happen)? Are Risks identified and planned against? Do you regularly revise/monitor Risks? Team Do you have the people/skills you need to deliver? Are they happy? Are they informed? Do they have the right training? Do they have a decent working environment? Scope Is the Scope feasible? Are the requirements and their boundaries firmly defined in a fixed way? Do changes to Scope result in changes in plans, deadlines and costs? Delivery Team Benefits Is it good for whoever is delivering the project? Will they get paid (enough/as planned)? Will it enhance their reputation?Get those right, and you're in with a fighting chance. Screw up on one or more, without doing something about it, and you're in trouble. So you're continually monitoring, right?
Not just IT projects, If I recall my project management class at Harvard, more than 50% of all business projects fail to meet all deliverables on time, or on cost. It turns out most of the projects that fail are due to some sort of "because the higher executives said to do this". Few people who make the really top decisions in any large project are willing to make the tough choices when the project team tells them that the project will suffer due to a lack of resources, or is behind schedule.
- Get the right people on board. Make hard decisions early about who should be there and who shouldn't. You'll save yourself much pain and anguish down the line.
- Do a good, thorough job in the requirements process. If you don't do this, take the million dollars you have budgeted and blow it on a Hunter Thompson style weekend in Vegas. At least you'll get some good memories out of the deal.
- Make the business people stick to the requirements they set. I hate the phrase "scope creep," but it is a real, living beast that will devour all before it.
- Straight from Agile, but get some early wins. There is no replacement for a group feeling of success.
Just the benefit of my recent experienceWho needs requirements? We just charge off into the wilderness, then when we get bored with management blowing off our request for more requirements, we do it our own way, the project is declared Finished and everyone goes home a winner!
Actually, my boss the CIO is a pretty damn clever guy. He reports directly to the CEO, and can usually get most of what he wants. By adopting the above process he's pretty much running the show as far as defining the company's business processes. Since he know what he's doing. it's not a bad deal.
BTW This won't work at a place that has competent project managers in departments other than IT.
I've written a small online book 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 important thing is to figure out what end-users actually want, not what they think and say they want. Sure, in a perfect world they could actually tell you what they want - but this ain't a perfect world. This involves a lot of watching users work and asking questions as they do their job.
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 thing, or a progam thing. DLL hell ensued. Process: debug problem, relink, recompile. Next day, retest. OK, so software passes testing. Next - software distribution - a process that itself needs testing in dev environments. Package software. Hit button to distribute to X000 clients. Some Windows NT, some older.
So much to go wrong, so many people involved. I'm not saying there isn't complexity in modern environments, but standards, and particularly web based apps take so many variables out of the equation.
"In 1994, the researchers found that 31 percent of the IT projects were flat failures"
If the government is the one conducting the IT projects, then the rate of flat failures increases to 96% on a good year.
The whole article reads like a Dilbert cartoon. Metrics and various forms thereof, stupid pithy phrases like "projects do better in a positive environment"...
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, it'll die, either slowly or quickly, metrics or not, it'll die.
Traditional development, Agile development, none of it matters, if the people aren't interested in what they're doing and building.
If their priorities are elsewhere, it won't matter how much you measure it, or how easy you make it for them to make changes mid-stream.
+++OK ATH
I've somehow managed to never see that before, but I'll be printing and posting a copy of that fine work right above my desk (with the aforementioned last line highlighted and bolded!)
This space intentionally left (almost) blank.