Slashdot Mirror
95% of IT Projects Not Delivered On Time
An anonymous reader wrote " The Globe and Mail reports that 'A new report conducted by market research firm Info-Tech Research Group says 95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.' The article goes on to discuss the reasons for this pervasive (perceived?) problem. The article mentions Info-Tech's reasons: unrealistic time frames, staff shortages, and poorly defined project scope. However, the article's author lays the blame with vendors."
I'd say its actually closer to 100%.
Actually, it really depends on who they would ask in a company. Whether it be
the business executive (probably a higher estimate)
the IT middle manager (lower estimate)
the IT worker (who would think that they are on time)
or the customer (who sometimes have unrealistic expectations)
I was going to be the first post, but I could not get it in on time.
San Francisco Photographers
95 per cent of information technology groups "are not delivering some number of projects on time or to the full satisfaction of the business executive."
:-) I say that joking, but have seen discussions like this almost erupt into fist fights as the sales staff makes promises to customers that are either 1) blatantly false or 2) concepts under development and are nowhere near "production".
Could it be that marketing is always overselling the product? Seriously. I cannot count how many times I have heard (in the past now I am in science), "oh, yeah....well, you need to include feature X because we told customer Y we already had that feature". This is often followed up by the engineer muttering under his/her breath "Dumb jock.
So, this is another example of why pre-announcing products is a baaaaad idea. Treat your customers with honesty and announce the product when it is ready and not before. Again, this is why vaporware only serves to irritate your customers and build expectation of a product that is not always delivered.
I also believe the fundamental problem is that managers these days (in many cases) no longer come from the ranks and are not engineers. So, they do not always understand what is involved in 1) building the codebase 2) testing code base 3) proper interface design 4) end user testing 5) documentation 6) making sure it does not suck.
The last point is where most executives seem to get hung up. More often than not in most companies, executives really have no idea of what makes good code and all too often, what makes a good product. Come on now, a good portion of executives can barely use their personal computers to answer email or browse the Internet. When you have companies run by executives and managers that have come up through the ranks, you are much more likely to get quality which often is much more important than meeting an arbitrary deadline.
Visit Jonesblog and say hello.
95% of the time, the business changes their mind about the project and/or doesn't know what they want, anyway.
...but it's more a paperwork problem : Here, I had to wait for very long time before some stupid tasks finally got executed expectedly... Like a Java install in order to run a planned Tomcat service...
Trolling using another account since 2005.
Thanks /. a copy of this story now sits on my boss' desk.
Introducing Microsoft Vacuum 1.0 The first Microsoft product that doesn't suck.
The trick to succeed is if you can always find someone else to blame for.
Well, it is better to have a project late but stable than to have it on time and full of bugs. Microsoft et al, take note.
There's a huge difference between 95% of firms not delivering a project ontime, and 95% of all projects being late.
My sig is blank, I typed this by hand.
The Globe and Mail reports that 'A new report conducted by market research firm Info-Tech Research Group says 95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.
The answer to this problem is change, and isn't change always the answer?
Consider if you will for a brief moment the vast difference between the average executive and the average programmer. Programmers are generally broad-picture thinkers who solve largely complicated problems that regular folks can't possibly wrap their heads around. The executive runs on a schedule and uses reports and correspondance to understand what is going on, because business folks have to judge their employees and projects.
These two groups are forced to work together, and we expect good results? We need someone to interpret between these two groups! The HR department can't regularly serve in the interpretive capacity, but perhaps they should.
Managers generally don't want to give the programmers the whole picture, because management often believes that they are superior in rank to programmers, placing the programmers on a need-to-know-basis, only. Huge mistake.
What programmers and managers need to do is realisticly approach their solutions together. They need to be honest with each other. They need to share each other's thoughts and feelings about the subject matter. It's not happening today.
The programmers need to come to the table and care about their customers a little more. The managers need to come to the table and care about their programmers a little more. The customers need to be more specific and realistic about how far their dollar can go. Then deadlines will be met and promises kept and successful solutions provided to customers.
I encourage a no-holds-barred approach to project management. The superior product is developed using the Agile method.
The dangers of knowledge trigger emotional distress in human beings.
95% of IT project specifications are what the user WANTS rather than what the user NEEDS. When they get what they want, and discover its not what they need, of course they wont be satisfied.
Oh, its late...
If brevity is the soul of wit, then how does one explain Twitter?
A study shows that 95% of clients don't know what they want.
Anyone who reads this site knows that this site is (probably) the reason 95% of IT Projects not being delivered on time. My PM just lost 2 minutes to this post when I could have been writing Rose models like I'm suppose to!
-Teiresias
... and the other 5% never ship at all. (ie Duke Nukem Forever)
Trolling is a art,
Isn't it ironic that Slashdot is linking to an article speculating on why IT projects are completed late, that will then be speculated upon by hundreds of Slashdot users, during typical business hours?
We are all busy reading slashdot. *runs*
95 per cent of information technology groups are not delivering some number of projects on time.
Zero's a number.
TFA does not say "95% of IT projects not delivered on time". It says "95 per cent of information technology groups are not delivering some number of projects on time..." Big difference.
I'm sure that 95% of IT shops have little to no software engineering. Until IT Depts. as a whole start to realize the value of things like defect tracking, estimation, time tracking, coding standards, and the like there will be no improvement in this area.
It is not necessary to impliment the full-blow SEI CMM to produce good software on-time. If developers would take the time to first make reasonable estimates of how long it will take to finish a project and then track how much time they actually put into it, we might start to see some improvement.
On the management side, when managers start to realize that software is not developed instantly and that problem solving takes time we might be able to reduce the number of features that are packed into a piece of software without extending the schedule.
Free as in speech, free as in beer, or free as in lunch?
..is almost done. Should be ready by the end of the week (crosses fingers)! I'm just about ready to implement the final touches on the UI. Right after I read slashdot, that is... and maybe check my email, and some of the other boards online. Shit, after that, it'll be lunchtime!
Yeah, sometime after lunch, it'll almost probably definitely maybe get done. I promise.
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
Headline: "95% of IT Projects Not Delivered On Time"
Body: "95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive."
Is it 95% of the groups being late with some projects, or 95% of the projects being late? Not at all the same thing.
Road Construction Projects? or Pentagon Contracts?
I'd say the glass is one twentieth full rather that nineteen twentieths empty.
Us: We can do that for $x in 12 months.
Customer: But Joe Bloggs says his company can do it for $x/2 in 3 weeks!
Us: That's simply not possible.
Customer: Well, for that sort of savings we're going to give them a try.
11 months later and $x^2 later they're still waiting for Bloggs to finish but by then we're on the dole and Bloggs is laughing all the way to the bank.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
I have to agree with the article's comment on vendor's salesmen being overzealous. I used to work for one of those vendors, I was constantly going into a customer site after the sale to implement what was sold. I was part of the Professional Service team.
I said "our salesman told you our product could do what ??? " way too many times.
I remember the first time I heard someone ask, "Is this deadline hard or soft?" I was just the video guy, so I kept my mouth shut and didn't laugh. The lead didn't even blink, and said, "Well, it's mostly firm, but a launch date hasn't been announced publicly, so we'll see at the end of the month." Good thing I didn't laugh.
It's not offtopic, dumbass. It's orthogonal.
More interesting is how one could measure open source projects. Will Debian Sarge be released "on time"? If a version of KDE needs two RC's, does that make it "too late"?
Well, quite obviously, it's a problem with how deadlines are chosen, combined with peoples' natural work tendencies (where they work up to a deadline and get it done sometime soon after).
This isn't "oh no evidence of every company doing some particular thing wrong 95% of the time." It's a general property of this type of project.
To put it differently, if 95% of people are voted above 9 on hotornot, it means there are some parameters to the voting or the choices or the statistics. Not that the world is incredibly attractive.
xkcd.com - a webcomic of mathematics, love, and language.
Same goes for every other type of project when the management who decides the time tables are not working on the project itself or defines narrow objectives at the beginning of the project instead of saying Q1 then updating later to March and then on a specific date.
Then they are either padding their project plans way too much, or are really not trying to do anything new.
It doesn't matter how much time I spend in the pre-planning stage, meeting with users, coming up with all the needs and feature requests. Once the project is in progress, and specially as you start demoing it, the end users will start adding requirements that had never come up before no matter how detailed you tried to be. And of course all the "wouldn't it be nice if"s.
Sometimes some of the new requirements or wants involve going back and rewriting a good chunk of code, or changing the DB design, etc, no matter how carefully you wrote your code and flexible the code may be.
Thats cuz i spend all my time on /.
False claims by individual salespeople suggest a short-sighted approach aimed at getting the deal done, hitting the sales target and moving on to the next prospect.
Case closed.
I'd be morelikely to conclude that this means the schedules are simply wrong. it's so difficult to plan a correct schedule, and asking developers how long they think XYZ will take doesn't really work well.
Have there been any advances in scheduling technology? Like profiling developers over the types of software they write, etc.. ?
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
"This will take 12 months to roll out properly" Management set the deadline at 3 months. This is typical of every company I've ever worked at. There is also the issue of giving an accurate estimate before the users know what they want. I am most happy with the RUP process for delivering timely projects that meet user expectations.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
That 95% not-on-time rate is for Canadian I.T. projects. So once you factor in the conversion it's only 78% for US I.T. projects.
The only way to solve this is for IT folks to strangle the idealistic and unrealistic expectations of the suits. If they say they want it in a month, and you know that it will take more on the order of six weeks while supporting other day-to-day business, tell them they can have it in two months. If they are aggressive about the one month deadline, then tell them that other projects will have to halt or suffer, or that you need more staff even on a consultancy basis (ie. more cost). If they can't fit within any of these parameters, you are working for a jerk who needs to be assassinated and are justified in the following behavior:
1. Lower your work quality and apply those energies to a job search while at work
2. Find ways to make other systems fail in such a way that they are majorly inconvenienced by you having to pay attention to their pet project
3. Assemble as much ammo as you can to prove to the board that your boss is a clueless asshole
Simple really. I've done it before myself and it works wonders.
"Could it be that marketing is always overselling the product?"
I work with OCR/ICR technologies. NO SALESPERSON should EVER be allowed to sell this without taking a month long training course about what it actually does.
I can't count the number of times customers were expecting 100% accuracy because thats what the salesman sold them.
I don't think this is specific to IT. I bet 95% of all human deadlines are missed....
As I'm sure everyone else who's had to design, deliver, test, present, and repeat again and again, there are lots of things that can push back delivering projects on time. I was told early on by someone wiser than me that when planning a project to figure out the number of hours you figure something will take and multiply it by 2 or 3. That's a good rule of thumb that makes the eventual completion closer to the actual intended date.
Then again as things increase in scale there are more things that can go wrong and hold things up. In the category of what can "go wrong" the biggest time waste are what customers want for the "Gee Whiz!" features that don't add any appreciable functionality, but take up most of the time.
I believe I read in here once that 90% of the project is completed in 10% of the time, and the last 10% takes 90% of the remaining time.
This is almost always because the scope of a project changes between when it's initially described and when it's delivered. A majority of projects I've been involved with fall into one of two categories:
1) requirements are agreed on, seem reasonable enough, but then detailed specifications are drawn up and client keeps pushing to add more things to specs until you have a 120 page document that will take 2 years to deliver. If, however, you tell the client it will now take 2 years vs. the 5 months you said when you were looking at a 2 page requirements document, they will cancel the project, and if they weren't paying for the requirements phase, forget about collecting any money for them (why you should always get paid for all phases of project planning). Since you can't do this, the client will eventually get upset, even though it's their own fault.
2) Project is delivered very early in prototype form, only to have the client say they want 50 more features that they forgot to describe in the requirements process, but they refuse to pay more, and refuse to acknowledge that the time frame must be pushed out to accomodate their new requests.
Yes, I've managed client relationships before and large (multimillion dollar) implementation and customization projects. I have reasonably good people skills, and still found these problems generally insurmountable when my client's company had a completely nontechnical person in the role of project sponsor and manager on their side.
The best predictor of success of a project in my experience are the lines of reporting and control in the client's company, and the existence of some technical knowledge in a position of responsibility and authority. If their CIO or President or whoever is the ultimate decision maker has a senior arhitect or tech VP that knows their shit AND functions as a trusted aid in the decision making process, these issues can usually be bypassed. If there is no senior source of technical knowledge, you can kiss the entire project's ass goodbye. Try to get as much money as possible from the client while it's going on, but forget about the project being "successful" in how its received by management.
First of all, the report focuses with Candian firms.
Second of all, rather than delving in to the varied array of processes and methodologies prevalent in the software development arena and reviewing advantages and disadvantages of each, the report goes in lenght talking about Vendor issues. I dont have a clue why.
Right from the Waterfall approach, or having no approach as well, we have RUP, XP and a mix of each playing itself out for the last few years. In my past projects, I have implemented each or a customized version of each and has varying levels of success. The biggest issue that I have so far seen is the lack of adequate knowledge in each methodology that someone who starts implementing any approach, either loses interest and resorts to a quick fix at which point the process starts to wither and die. More over, to some of the developers I have worked with, its not process, its documentation. CRC Cards is not a design tool, its documentation, its impediment to writing code. Much of it has to do with no academic background in best design or coding practices. They have heard of design patterns, and probably has used MVC to death, but when it comes to designing a system, its back to "lets start writing code rightaway and maybe the design will flesh out over time". The system gets built, but it suffers from Simplicity, it has very low quality.
I have seen a lot of firms talk about having a process, they love throwing RUP in the air, but nary a project which has successfully or much less adequately implemented any sort of process. They talk about Use Cases/ User Stories, but when the project gets kickstarted, they resort to SRS documents or less. And then they forget to adequately keep them up to date. Many even have Requirements management tools like Requisite Pro which hasnt seen daylight yet. Fuck the tools, atleast have a damn process. Many dont even define success at the outset of a project, no acceptance criteria either. They end up in a deathly downward spiral towards absolute failure dragging their clients with it.
I love XP, I love it for several reasons. Having a Client involved during all phases of the project, much less have a day to day interaction with the team is a phenomenal idea. I have had great success with this, but it becomes a bit of a problem, when the project is outsourced. No amount of communication (documents/mail/phone) can stand up to having a person next to you to tell you whats important and whats not. I love pair programming even though I could never fully implement it, when the client doesnt believe in it. I have tried pair design and have had great success. I have a few developers reviewing Test First Design and this has limited success as well. Limited, since the developers rebel, having low discipline and patience to write tests as they code. They are tutored and trained in the ways of "lets code first, maybe manually test it later and let the QA worry about it".
I would like to hear about other's experiences as well.
Rapid Nirvana
Another study shows that 100% of customers that don't know anything about computers think programmers pull code out of their ass on command.
I don't see this as a human failure but more of an unrealistic expectation with limited resources. In short any project will encounter any number of problems along the way most of which were never dreamt of during the meeting room planning phase. The best planners try to learn from past experiences to plan for the semi-cyclic stuff but in the end there are too many variables that will interfere. From the mundane (a server blows up taking out internal development for a couple of days) to the rare (a developer is run over by a bus).
Who can ever plan for that? The best scheme I've seen is make a solid "best situation" plan, set key miletones to check "sanity" along the way, and then double it.
...or to the full satisfaction of the business executive
Every "business executive" I've ever worked with is disappointed with the results of their request if, at the end of the day, the IT department is unable to do the impossible. It's all about managing expectations.
"Hey, helpdesk. Yeah, I just dropped off a spool of yarn over in Finance. I need you to make it into a magic carpet by 5 so I can fly to Europe. What's that? All you can do is fix my e-mail? Ok then, just do that."
Executives ask for the moon and settle for less, it's in their nature. They are never "fully satisfied".
No battles to the death are recalled. Mumpsman can hit to attack and cause brainsmashing.
Could be seen as 95% of IT projects not given enough time for completion by marketing
The only things certain in war are Propaganda and Death. You can never be sure which is which though
Unsatisfied Executives?!! Un-be-LIEVE-able! There are only two facts you need to know about executives to understand this report: 1) an $executive is NEVER satisfied 2) if you have any questions about the eventual success of any given project, see point 1.
Here will be an old abusing of God's patience and the king's English.
95% of all IT projects are scheduled incorrectly...i.e. by marketing and not engineers.
Correction: 95% of Schedules are Wrong
I'll agree with this wholeheartedly. Besides the developers you've already mentioned there are plenty of Suits that push for insane deadlines so they can show a good side to the customer then beat their people so to speak when they don't make those insane deadlines.
This not only happens in the I/T department but in Engineering as well.
If the Suits made realistic schedules not only would the world move along at a more comfortable pace most likely but people would get the delivery times they were quoted.
"Bah!" - Dogbert
We had some very good project management classes in college. During one, the lecturer asked us to give answers to a pop-quiz, but we could give the answer as a range, for example, for "How long is the Danube" you could guess "1000-1500km" with no limits.
Even with the benefit of fixing our estimates as we liked, the entire class did very poorly. The morals of the story were
a) people are over optimistic in the accuracy of thier predictions
b) even, in our case, when we could have given zero-to-infinity ranges, we tied ourselves to restrictively narrow frames.
I thought it was fascinating, it's one of the few classes I remember vividly.
Properr formance
Prior
Planning
Prevents
Piss
Poor
Pe
+-+-+-+-+-+-+ "I don't know what's wrong with you, but I'm quite sure it's hard to pronounce."
Wasn't this story supposed to be run yesterday?
I'll turn into a supernova and burn up everything. Well I'll turn into a black little hole and you'll turn into string.
... they get what *WE* (programmers) want. Thats why they wont be satisfied.
This is news?
Yeah and I bet every civil engineering project, every 3 course dinner ordered and every travel plan made went totally as scheduled.
SHIT HAPPENS.
Tom
Someday, I'll have a real sig.
I am in a small (8 programmers company). Even with this little people, management only gets involved once every few months in a review of the project, and this reviews always add new "features" (some of them forcing to rewrite a good part of the project and changing its philosophy).
The project itself was thought to use a prototype life cycle, adding new features and rewritting and redesigning it when needed. Of course, there has never been time to rewrite it now that we know (or we think we know) what we want, so we have to fight with code that sometimes does just the opposite of what would be logic.
The project management has tried to manage this adjusting more and more time for "bug tracking" and "alpha testing". Pointless, because more time in these stages gives the company management more time to add features.
Of course, when something crashes the company management feels that the one to blame are the programmers instead of them.
And by the way, I'm not Dilbert.
Why can't
I suppose this was modded Funny because it is true. I have not seen a project yet that hasn't resulted from project bloat. As the project progresses new deliverables are tacked onto the end. One can try and have the project plan set in stone at the beginning, but it never works because all the new stuff is "critical to the business".
So how can any project meet it's deadline under these circumstances? (that was rhetorical. no need to actually answer)
-- Thou hast strayed far from the path of the Avatar.
The fault isn't just with the Vendors, it's with always management, management, management. Or the lack thereof. The management on the vendors sideb, but also on the customers' side. What ever happened to "the buck stops here?".
Nowadays, what I'm seeing (at least with VC backed startups) is that there's an utter slapdash approach to things. It's "make the quick hustle so we can sucker someone else into buying the company". Screw real engineering work.
This leads to the infamous death marches, and late deliverables. Plus completely unsupportable infrastructure, as the goal is to grab the quick cash, and let the next poor sucker deal with the problems.
So be very wary of new VC startup technology. Don't avoid it; just understand that it's quick-buck snake-oil that's being pushed, for first generation technology these days.
The other management issue that pisses me off is trying to short schedules. I give an honest estimate, and ones which almost always turn out to be accurate; and what do I get back? It's "can we trim these"? Or "how about we add more people and do it quicker"? Anyone who's read the mythical man-month knows the latter approach has severe constraints, and too often doesn't work.
But there's no concern about reality. No wonder schedules slip.
The really good managers are far and few these days. Now, it's mostly quick-buck artists. You'd better believe most IT projects are going to fail, when there's no attention paid to real engineering.
I already work late 95% of the year
95% of the support people I have to call for additional information speak English as a second language
95% of all projects are scoped by non-technical people who don't really understand what they are asking for
...and that is just the stuff off the top of my head, if I really stop to think about it I might weep. And none of you politically correct whiners start up with the whole "xenophobe/global economy/blah blah blah" nonsense, 95% of phone support people suck no matter what language they speak but when I have to call MS at 3a.m. to get an unsupported HotFix it makes it that much harder when I have to repeat myself 3 times.
As a consultant who takes lots of short term contracts over the last 25 years, I've seen a WIDE sampling of the industry.
This number was high 25 years ago and we were promised then that more processes would reduce the number of faild projects.
It has not.
I agree with most posters that management is to blame almost all the time, for a variety of reasons.
A process-based shop typically adopts processes so they can:
1. Add lots of billable documentation specialists,
2. Avoid responsibilty for bad decisions by pointing out: But we're CMM Level 3!
I've seen the highest success rates at shops that are results-focused rather than process-focused, where CMM & its allies are used as a subset of many tools rather than as sacred cows worshiped in their own right. The very highest successes I've seen had almost none of these processes beyond version control and coding standards, but that may have been because the teams involved where way above average.
And that is the delemma: Without good decisions & people, these processes won't help, and with the good decisions & the best people, they are not needed as much.
There is not nearly enough love in the world, but there is far too much trust.
They state:
"95% are not delivering some number of projects on time or to the full satisfaction of the business executive."
This could means that 99% of the projects attempted were delivered on time by all IT groups which is a more, or it could mean 99% of the projects were delivered late. By using the phrase "some number" this statistic is utterly general, and wholely useless.
Oddly enough, later in the same report they state "the majority of IT projects are in fact delivered on time" which really what counts.
The fact that IT groups do not deliver on time 100% of the time should be no surprise. The fact is that there simply aren't any professions which bat 100.
Botton line, stat is completely pointless.
Rich...
Pretty much the only stuff that happens on time is either totally assembly-lined OR has enormous slack deliberately built into the estimation process OR both.
E.g. "How long will this Oil Change take?" will either be "about 30 mins" (in which case come back in an hour) or "come back this afternoon" (i.e. it will take half an hour sometime during the day).
The core of the problem is that more and more people have completely unreasonable expectations. I'm surprised how few people I see around me who are cynical enough to say "show me" when someone makes a preposterous claim.
Companies expect to cut staff year after year without losing productivity. Some organizations are so bloated that this works well the first few passes, but there becomes a point where the results of this approach are harmful. The people looking at the budget figure if they saved 20% on staff expenses over each of the last 2 years, they should do the same thing this year.
Vendors lie. Salespeople lie. Any organization that is purchasing any product, technology or otherwise based on the statements of salespeople and vendors is failing to perform due diligence. I frequently see complaints about products not working as expected, or products being sold under claims that are revealed by technical support to be completely untrue, but only after the purchase has occurred. When this happens, nobody is willing to lose face and increase their losses by taking the vendor to court for outright fraud.
Only the cynical pessimists seem to be successful due to setting expectations low enough that they can be pleasantly surprised with the results. Has IT gotten such a bad shakedown that there aren't enough grizzled old veterans on these projects?
- Crow T. Trollbot
Poorly defined project scope and continuously changing project scope are the main reasons for this.
It's a moving target.
Yes, there are methodologies and processes available that help with scheduling. A major problem though is that *both* management and line employees often do not buy into these processes, they see them as just getting in the way of the project. And in someways they are right, it does slow you down a bit, but over time you develop the capability to do much more accurate estimates.
For people who don't want the inefficiencies of a heavy weight process methodology like CMM, it's often better to look at more agile methodologies.
I think many companies have trouble deciding between what is more important: 1) getting a product out the door as fast as possible , or 2) being able to more accurately predict when a product will be ready.
Excerpt of a typical meeting. Note that the day is Friday.
Manager: When can you have X finished.
Programmer: I need two weeks to do what the client asked.
Manager: I told them you were almost finished can you have it by Monday?
Programmer: I didn't start until yesterday I need two weeks.
Manager: Ok the client is expecting it to be ready Monday you'll have to work the weekend.
Programmer: I was planning to work over the weekends to get it finished it two weeks.
Manager: (Clearly Frustrated) I need it Monday. The client will have to punchlist what does not work.
The above exchange is very close to what was actually said. If this was the first company where I had heard that conversation I'd be bolting. Unfortunately no matter where I would run there would be a manger and programmer having the same conversation.
10: PRINT "Everything old is new again."
20: GOTO 10
Hmmmm...I wonder what "Info-Tech Research Group" sells.../ Consulting%20Methodologies.aspx
http://www.infotech.com/Products%20and%20Services
(Stolen shamelessly from someone else...)
A Product can be:
1) On time
2) On budget
3) Feature complete.
Pick any two.
[ Monday is a terrible way to spend one seventh of your life. ]
In many organizations, IT is pure overhead, like building maintainance. Management has a natural bias against things that cost money but don't generate revenue, at least directly.
Not the entire picture, but a part of it in my experience.
org.slashdot.post.SignatureNotFoundException: ewg
I know at my company whenever an I.T. project is not completed on time, it's my fault, and not my direct managers. I think he said it had something to do with me not shaving or my shoes or something...
" ...to the full satisfaction of the business executive"
Man... don't even get me started on this subject.
How about companies where stake holders and decisions makers and execs knew their ass from their elbow when it comes to a computer? I bet most of those projects are reasonably on time because they understand what planning is - the thing that no client ever wants to pay for becuase it's a "waste of time and money".
Like I said, don't get me started... I mod this article flamebait.
SCOTTY - (conspiratorially) And how long will it really take you?
GEORDI - (puzzled) An hour.
SCOTTY - (shocked) Ye didna tell him how long it was really going to take you?
GEORDI - (irritated) Of course I did.
SCOTTY - Oh... Laddie. You've got a lot to learn if you want them to think of you as a miracle worker!
5% of IT projects are delivered on time.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I'm aware of the various obvious reasons (unrealistic deadlines/expectations, poorly defined requirements, scope changes, staff shortages, sabotage and other "real-world" issues, etc.), but I'm curious to know peoples' thoughts on a couple things:
First, how much of an effect does the fact that many universities/colleges in North America are pumping out rather mediocre, assembly-line Java programmers have on a project's changes of success?
Second, I've seen a lot of hype over offshore outsourcing, but not much in the way of actual case studies showing its success compared to in-house or traditional regional outsourcing. Anyone have any good anecdotal info here or maybe a few links that cut through the marketing hype (which is why Google wasn't of much help here when last I looked)?
putfwd.com - 1GB Free file storage with a twist
I've had customers complain about a product not meeting their expectations. Of course, the expectations being missed were never promised! The customer just assumed it would be there or "can't remember" when it was promised.
Maybe I'm just crazy, but am I the only the one that thinks it's a bad idea to base a critical part of your project on technology with which you have no experience? It would seem to me that a few dummy projects should be developed using the new technology to give the developers a feel for how it works (if it works) before forking over wads of cash to the vendor.
- Failure to Understand Business Need
- Trying to Solve Training/Documentation Issues via Engineering
- Scope/Requirements Creep
Join me next week as I discuss the problem with dumbing down your architecture so that you can hire morons for less money to maintain it when all your best talent gets fed up with their 2% raises and quits."I have never won a debate with an ignorant person." -Ali ibn Abi Talib
And a lacko of respect for how difficult software can be to engineer. Managers want everything done tomorrow, and unlike engineering a skyscraper or a bridge, managers don't understand software--they can't see anything tangible, and they see a gui mock-up and think its 99% done.
Sorry if I sound cruel or mean to managers, but I've seen it over and over and over again. Managers are far too often people who:
a. Have never written software
b. Were bad software engineers, so they got promoted to management.
[FromTheMorning]
Management usually does not have a good idea what happens on a day to day basis. Now it should be said that both we (IT staff) and management need to work together to solve this, but the end result is that, when asked whether they have the resources to work on a project, our uninformed management answers incorrectly. This results in over-subscribed staff who cannot easily focus on getting a particular project done on time. Instead we have to allocate small chunks of time for each of many projects just make sure we have made some progress when our customer calls. Little progress on lots of projects means none get finished in a reasonable amount of time.
Annoy a Conservative...
AKA "95% of IT Projects Scheduled Impossibly by Managers". "On time" is defined by PHBs. Too many of them respect programmers/admins so little that they think we just push a magic button on the right day, and the computer generates some products. So they think they can do the same, like FedEx and MS Project were compilers.
Expectations - Deliveries = Disappointments
--
make install -not war
Non-performance clause
I'd say that close to 100% of my projects are not ready "on time".
Actually I'll amend that. Almost all of them are done according to the original specs on or ahead of time. But then you find out changes need to be made. "Only these two people will ever need access to this" becomes "oh, when I said 'these two people' I wasn't referring to all the other people who'll also need to use it". Or "this is, for sure, the complete feature set we'll need for the forseeable future" becomes "well we need to add A and B and C because I didn't think about them before". Or (my favorite) "we're setting it up this way to force consistency" becomes "well the users don't like it, so can we personalize how it works for each person?".
#DeleteChrome
^^^ enuff said.
www.rexguo.com - Technologist + Designer
How many non-IT projects are done on time?
;)
Let's see... Boston's Big Dig. Nope. Designing a new aircraft carrier... nope. Red Sox winning the World Series... badly delayed
I wonder if in general it's creative projects or maybe highly complex projects that suffer lousy under-estimates for completion dates. Many software projects (i.e., MS Longhorn) are both.
On an unrelated note: I wonder how project planning estimate accuracy correlates with the experience level of the person making the estimate. Because if the IT industry tends to burn out the young people os that there are't many older IT people, that could contribute as well.
IT projects overrun. Film at 10. On second thoughts, make that a quarter past.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I've got a project due tomorrow. I finished it this morning, but I really really really don't want to get started on the next project. So I'm going to read /. until tomorrow morning.
The Statue of Liberty is America's lawn jockey.
Where I work, we have no deadlines. It's great. I'm done with a project when I'm done with a project. Anytime the boss comes around to check up, just reply, "It's going great," or "I'm making excellent progress." The guy in the cube across from mine was able to work on a for loop for about a month using this technique. That's right, a for loop. The chance for doing little to nothing is great, which leads to a stress-free work environment.
BDR Gear
Outdoor gear, MREs, and more!
This is good. Actually, I will see this as my new definition of sarcasm. To read about this on Slashdot of all places... :-)
Ah that is good to hear, but it sounds like it gets clumped in with things like Software Engineering, Documentation, etc. Things not necessary to ship a product, but things which in the end can screw everyone over if they aren't there.
I think many companies have trouble deciding between what is more important: 1) getting a product out the door as fast as possible , or 2) being able to more accurately predict when a product will be ready.
I really believe that the things i mentioned above will assist in #1. Maybe not on the project that the better schedule methodologies are first applied, but down the line on projects dependant on it etc.
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
Ooooooo! We're not satisfying the oil haired, Nazi-shitbox driving MBA douches. Who gives a flying fuck? Gosh, I'm real concerned I'm not enthralling some degenerate jackass who goes to a local four star hotel just to bang underage hookers and do lines of blow. Those people are the scourge of the world. Don't like it, power-tie boy? Do it yourself.
Written requirements.
Doesn't the headline of this post conflict with what the article says? It's not 95% of IT projects, it's "some number" of projects by 95% of IT groups.
Even if these groups deliver only half of their projects on time, and we were to assume that all groups have approximinately the same number of projets, it's not anywhere near "95% of all IT projects."
The article says that only 5 percent of the groups responded that they were "always on time." A more accurate headline might be, "95% of IT Groups don't purport to be flawless."
"Someone's gotta have some damn perspective around here!" -- Commander Susan Ivonova, Babylon 5
if(internal project){ // CONTRACTORS! HERE BE DRAGONS! // VENDORS! GOOD LORD, HIDE THE WOMEN, KIDS, AND FARM ANIMALS!
;)
if(doneByEmployees){
if(manager.clueless){
if(manager.schedule.isRidiculous()){
project.lateness.reason = "Employees came, they saw the schedule, they laughed, then they did the project in its natural timeframe";
} else {
project.lateness.reason = "Employees came, they saw the schedule, something went wrong, all hell broke loose, then they finished the project as fast as they could, considering";
}
} else if (manager.isEvil) {
project.lateness.reason = "Employees hate him anyway and ignored his sadistic schedule. General sentiment of 'fuck it, I'm on salary' prevails, manager crashes and burns, employees get reassigned, everybody sings 'ding dong, the witch is dead' and goes to Starbucks for coffee";
} else {
project.lateness.reason = "Unforseen problems arose, employees did their best to deal with them, stakeholders wouldn't budge on schedule, so the project was late.";
}
} else {
project.lateness.reason = "maximization of billable hours (duh)";
}
} else {
project.lateness.reason = "Incredible, absolutely amazing scope creep, maximization of billable hours, platform/system/vendor changes midstream, refusal to engage in technology transfer as extortion technique, total screw up of vendor, outsourcing to country without indoor plumbing (but assume they can handle high technology), etc, etc, etc";
}
Did I miss anything?
Farewell! It's been a fine buncha years!
Duh! All Enterprise IT projects are like custom cars of the 20's and 30's. Each one is hand crafted by a small group of skilled craftsmen (coders, artists, project managers, etc.). No two implementations are the same and the users are just not that sophisticated. Every Enterprise Graphical User Interface I have seen is just an electronic version of "how we have always done it".
/bin, /sbin, kernel, etc. that we have been through in the last 5 years. 10 years ago most Enterprse systems did not exist, were running windows 3.1, consoles or just purple ink memo's.
Outsiders (the clients upper management) will apply time measurements to IT projects as if they are building bridges or building cars. These are unrealistic because both those industries have been around for 50+ years. The IT industry is immature and still growing. Just think how many languages you have to know just to do your job? Or how many versions of compilers, or how many changes in OS, dll, registry, configs,
Come on, until there is standadization in tasks (what the client wants to do), interfaces (how the client wants to do it) and tools (how we make it so), all IT projects will be optimistically scheduled and all projects will be under time pressure from the beginning.
I won't even start on budgeting of projects...
Ok, I'm down off the soap box.
-- Andy
I blame Slashdot
Think about it for a second. Who gives the final yes or no on a program time frame, the programmers. They are the final word and now, a lot of them just plain suck.
Software is the ONLY industry where people are expecting to get paid for not delivering what they promise. Would you buy a car from a dealer that says "Sorry, it doesn't have wheels yet but in a few weeks we will get them to you" but it is entirely expected that programmers will "include that feature later".
It is bullshit. We deal with vendors for all of our really big projects. Not one of them has ever delivered on time. They all deliver something when they say they will but it is never what we paid them for.
No project time line is defined by management regardless of what anybody says. Management may request a date but unless the company agree to it then it is arbitrary.
It seems most places don't take into account time for testing and bug fixes thinking that it will work the first time. This is almost never the case with big projects. Back to the car analogy, it is like getting your new ride then finding out the brakes don't work then being told "we are working on it but can't be sure when it will be fixed". This gives them plenty of time to do they work they couldn't fit in the first time around because they decided to lie about the time frame to get the contract.
I have finally moved into a position when I am not only working with but also deciding who the vendors for our big projects will be. The ones that give unrealistic time frame are automatically sent packing regardless of if they are low bid. I would rather pay for quality design up front then pay for it later in a slew of bug fixes and updates.
And this is a problem because...?
As a developer, most of the time I couldn't give two craps in a tin can about what Darth Veep thinks. He is, after all, a rep from the Dark Side.
On the other hand, meeting the design goals, generating maintainable code, facilitating the QA process--those are important.
Writing software on a delivery schedule promulgated on the premise that "we need this revenue in Q2!" is short-sighted bordering on the moronic, and a great way to guarantee failure across the board.
One trend I've noticed with increasing frequency is for a suit to push for an "aggressive schedule" only to move on to another organization before the results of their actions can be felt.
I spent most of last year on a project like this. I personally spent almost 3200 hours on the project, and I know the rest of the staff was working 50-60 hour weeks the entire time. We managed to bring the project to a successful completion on time, but our Manager and his Director were both gone (to the same other part of the company) before the project was due to be delivered. The result of this was that we spent as much money as planning a much more reasonable schedule, but were specifically directed to take short cuts to create a barely workable solution that would create more work in the future.
In the end, a lot of projects either fail or are minimally usable as a result of poor management decisions. The irony is that the decisions are made in the name of saving money, yet the projects cost as much or more than if a more reasonable approach were taken.
"If you can't deliver this project by the end of Q3, I'll find someone who can." --PHB
PHBs don't care about reality. They just want a manager who will agree to whatever unrealistic schedule the PHB pulls out of his ass. If the project manager refuses to knuckle under to the PHB and sticks to reasonable schedule estimates, he/she will be fired. Then the PHB will bring in some toady who'll commit to whatever random schedule and of course be late.
Duh!
UTF-8: There and Back Again
...ain't taking enough chances. If you are never failing it means you're not pushing hard enough. Those are the ones that are or at least will be in trouble soon.
You can legislate morally you can't legislate morality
It all comes down to a couple of things:
-managing expectations
-realistic definition of on-time (and use of a good roadmap presentation).
It doesn't hurt to underpromise and overdeliver either.
Failure to do these things, which means you had better know your vendor well either from experience or direct communication, will result in off schedule / below expectations delivery.
Blogging because I can...
No, see, he had the spec wrong. He asked for COFEE (sic), not coffee.
My experience with the "business executives" (or at least the sales managers who usually are the first ones to complain about late projects) has been that they just loooove to make the client happy and will do ANYTHING to keep them that way.
This most often includes them telling the client things like, "Absolutely, we can include that feature with the current development. I'm sure it's not a big deal". Then going back and telling the PM or even the programmers themselves that "I've already told them we could slip that feature in there so let's just go ahead and do it. It's not a big deal, right?"
[Greedy|stupid|sycophantic] sales guys will sink a project faster than you can say "let's do lunch".
GET FREE APPLE STUFF!
Thats because all IT projects involve users who are constantly saying "It would be nice if it did...."
Exactly the point. I don't know why this isn't totally obvious. Once somebody makes an estimate and establishes a schedule, no matter how they arrived at it, everything that doesn't measure up is deemed a failure. In almost 30 years of programming I've rarely seen an incompetent project team goof off or in other ways screw up a project. But I can't think how many times everything is going just fine, it's just not going the same as somebody 6 months ago thought it would. The staff is put under tremendous pressure to meet the pie in the sky deadline, features get cut, the customer is not satisfied and the project is deemed a failure. Those projects didn't fail, the estimate failed, and more often than not the estimate was simply designed to agree with what somebody higher up the food chain pulled out of their ass. How hard is it to see where the problem lies?
There have been many attempts to improve estimates by profiling code... a current one in vogue is called TSP - Team Software Process. These methodologies tend to be very top-heavy with record keeping, and assume that people work in ways that they really don't. For example, you don't think about only the UI for 11 minutes and then only the middle tier for the next 13 minutes. But that's the way you have to log your time. So your history data tends to be very approximate. On top of that you always have to factor in what fraction of time a developer is actually going to be doing productive work, which can be anything. Where I work we use 50%. So in the end after doing all that bookkeeping, you end up with a schedule based on making your best estimate and doubling it, which is how a lot of people who have no methodology do it anyway.
Even internal projects are this way. I got one from accounting for some tracking software with requirements in December. I wrote the code and tested it and then showed it to accounting.
At the end of January, it was still not implimented. Accounting came back with a fistful of more things it "should do". I added them and by mid-Feb it was being "beta tested" by the departments.
Of course, this added another fist full of requirements, reports and other assorted stuff they wanted added.
Bottom line was that for something that was a "small two week" project in December, I'm still adding code to at the end of March.
In this case, it was a failure to plan, and a distinct failure to include all personnel who would be involved in it. I tried to coordinate this from the start, but A doesn't want to talk to B, who doesn't want to talk to C. A's philosophy is "they'll use what we give them." And of course, this whole "it's not done" delay is my fault. Then, and I loved this, my department lead's thought was - Well, you're handling this, I'll just not get involved at all and help with anything.
Realistic expectations and documentation would seem like such a common sense approach - but it never happens.
GP
The consequence is that most IT groups go into a project with little or no idea what the vendor software does. What actually happens is that they have to play around with the software for 2 or 3 months to get an idea of what it does. Then, if they're lucky and the software actually meets some business need, they can then say what the schedule actually will be. Most often the vendor software has no business use and the IT staff is in the position of implmenting a doomed project, one that fails management expectations, management being the idiots that made the purchase decision.
I was given three months to work on a project. At the end of the three months I announced that the project was completed. I've spent three months since then "following up" and getting it finished. But on paper, it was done at the end of last year.
Free MacMini
Second, the article shows some flaws as well. Because 5% reported that they are always on time and budget, the researchers concluded that 95% were not. That's bad science, letting the observed lead to conclusions about the unobserved.
Finally, the larger the project, the harder it is to define an end point. Tweaking a screen to change a color is certainly doable, but may take weeks to get to in the project list. Implementing a major project that requires lots of unknown elements, such as a system conversion, cannot be considered a plan, but an estimate. And when it comes to estimates, it's very hard to get *anyone* to be less than optimistic.
For an interesting read on project planning and estimating, check out Elihu Goldratt's book, Critical Chain, which shows the application of his Theory of Constraints to project management.
95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive
Considering that "on time" and "satisfactorily", when the deadlines and satisfaction criteria are devised by business executives, are mutually exclusive, I'd expect the number to be even higher.
That's why the company I work for does fixed-time, fixed-price projects with measurable business results. We get projects done on time, and we solve actual, quantifiable problems. Our overall record is far above the industry average.
Normally, I'm not one to shill for "the man", but how often do you get the chance to work for a company that actually does things right? I won't say the name, though.
I will say that the vendor situation is a bad one; often (not always) vendors are dictated by the clients, and those vendors want the business we have in addition to their own, so things can get quite sticky.
Conversely, a qualified vendor that works with you instead of against you is worth their weight in gold, and we'll send those folks other business.
7) enter the market too late.
I have never worked in a company (only academic... sweet...), but can imagine 7) is why 1) to 6) are neglected.
It's because there isn't project management in place, or the project management is weak.
I work in a place that just recently started implementing Project Management. The biggest problem I see is that if you don't have buy-in by upper management you'll be fighting a battle of critical change requests on a constant basis.
We just had one project take place that was mandated but never went through PM at all. Not even a requirements document was produced. It was a nightmare that touched 75% of the I.T. staff.
Had PM actually been followed the process would have started back in November of 2004 and then the blame would have been off the plate of I.T. But for fear of stepping on toes I.T. management decided not to follow its own procedures.
How come nobody every picks laziness as a reason for delayed and unfinished projects? I believe that if there are enough committed and hard-working people around, any feasable project can be implemented satisfactorily and on time. Of course, this is far from being a perfect world. People do need to recognize that they are overwhelmingly lazy and find ways to combat it rather than delude themselves more.
Probably also thanks to /. your project is late in the first place...
So what does this prove? ;)
Knight37 - Once a Gamer, Always a Gamer
Of course 95% of IT projects are not completed on time. Unfortunately, the only way to get management to agree to do a project is to underestimate the costs and the time it will take. Same thing is true for an outside project. Everyone else is lying to the potential customer about how long it will take and how much it will cost. In order to compete, you have to lie, too. Once management/customer signs up, they're on the hook, and you can start making excuses as to why it is late and costing more money. ... will be fired.
Another problem is that once a project is started, the promised full time resources are only given to you part time, and they tell you that you can't have any full time programmers until your project is bringing in revenue. This way your project doesn't actually cost anything. The programmers are working 8 hours a day on other projects, and since management has decided to call programmers exempt, any time they work over 8 hours doesn't cost the company anything. Of course, when the programmers start quitting because of all the overtime, management won't hire more programmers, but will just consider the programmer leaving an added bonus, as the existing programmers can now just work X% more for the same salary in order to get the work done, and the payroll has actually gone down!
Ultimately, when the project fails, as it clearly must do, all of the people who were peripherally involved with the project or who were just working on it during overtime will be reassigned to other projects, while the people who were full time dedicated to the project and poured 16 hours or more a day into it in a desperate attempt to make it fly despite all of the roadblocks erected by management
A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts, "Excuse me, can you tell me where I am?"
The man below says, "Yes, you're in a hot air balloon, hovering 30 feet above this field. " "You must be an engineer", says the balloonist. "I am", replies the man. "How did you know?" "Well", says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone."
The man below says, "You must be in management." "I am", replies the balloonist, "but how did you know?" "Well", says the man, "you don't know where you are, or where you're going, but you expect me to be able to help. You're in the same position you were before we met, but now it's my fault."
There are 2 kinds of people in this world. Those that can keep their train of thought,
A big bear in any IT department is panic projects interrupting planned projects. Managers who do not plan effectively need their projects done yesterday and whine up the chain of command to get a planned project delayed for the panic project.
One way to provide an incentive for planning would be an internal SLA. If you plan ahead and give us x weeks to complete your project, your cost center gets billed y. If you didn't plan and we have 36 hours to complete your project, you get billed 2y or 3y. If you can justify it to your bottom line, we'll do it for you.
bun-fhuinneog agam!
It's not that they're not delivered on time, it's that their time estimates are underestimated. Badly.
stuff |
My schedules usually walk on the very thin edge of what I think is possible, what the other party wants, and what I can get away with. Make a deal. You can always try to bend it afterwards...
I stop reading Slashdot and get back to my work, I can deliver that portal code next week...
Speaking of which...
With the first link, the chain is forged.
"So how can any project meet it's deadline under these circumstances? (that was rhetorical. no need to actually answer)"
But still, there's a proper answer to your question: by adjusting the deadline whenever the project plan changes, of course.
Typical trend (simplified):
Client: those are the specs. When will it be done?
Vendor: By july the first
Client: OK
(one month later)
Client: Do you know what? We thougth it would be rrrreally interesting to add functionallity X to your product. Can it be done?
Vendor: of course yes.
Client: OK. And will it be in time?
Now it is the vendor choice to say either...
A: Well, it will need two weeks to develop, so deadline needs to be moved to july the 15, and project cost need to by rised by X$. Do you agree?
or...
B: Of course, same cost, same date (and then, to the develop team: "hey boys, forget about the two weeks we planned for testing, we'll develop function X instead").
Actually this seems to say that 95% of IT shops deliver some of their projects late. Huh? This is a very unclear statement and an example of what you can do with statistics. So, do 5% of IT shops ALWAYS deliver on time? I doubt it. What number of IT shops are ALWAYS late? Can't really say. To get into the 95%, it sounds like an IT shop can have a perfect record and be a day late on one project to qualify. I hate statistics.
A most overlooked advantage to owning a computer is if they foul up there's no law against wacking them around a bit.
95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.
Am I the only person reading this as "95% of IT groups don't deliver projects on time EVERY SINGLE time or to the full satisfaction of the business executive. (who is usually clueless about IT, doesn't want to hear about licenses, scalability, etc. and just wants it to do everything they can imagine at very low costs...oh, and never break down)?
If you mod me down, I shall become less powerful than you could possibly imagine.
Get this:
- I scope a project
- I pitch it to mngmt
- Their response -always- is "be quicker"
- My response is, quicker means either: less qualiity, or more money, ypou pick.
- They say, you get neither.
- Ill say, sigh, Ill -try-
- It gets delivered on my original timescale
- They fuss about the project being "too late"
Do what -smart- project managers do: overestimate everything.
There is one major reason for the failure of organizations (IT or not) to deliver projects on time, and all other reasons are secondary to this one: Organizations typically have to be competitive in a bidding market in order to have customers choose them over other organizations. This inherently leads managers to grossly underestimate the time necessary for a complete project cycle, and testing is usually thrown out the window. By the time the deadline rolls around, there is no longer any time for testing. The customer needs/wants their new product that they just spent X thousands of dollars on in whatever semi-working condition they can get it.
It is the economic drive to be competitive that is the root cause for the delay for projects in all fields.
I don't know, but what you fail to realize is that sometimes marketing must 'oversell' the product. Not all software development is done in monopoly or near-monopoly markets. I know this from first-hand experience. I used to work for a small shop which developed custom and semi-custom embedded systems, and the competition was fierce. When I first started there I used to wonder why the company promised costs and delivery dates which always turned out to be unrealistic. Finally it was explained to me that if we didn't do it, then our competitors would get the contracts. The funny part is that those competitors were all playing the same game. The situation punishes honesty, so I'm glad I got out.
Now I have some sympathy for those 'idiots in marketing'; after all, they're the ones who are pulling in the contracts.
My life is an open book ... up to a point.
From the article: Info-Tech asserts that the top three "perceived" reasons for project failures include unrealistic time frames, staff shortages and poorly defined project scopes
A good project manager will convince the customer about the unrealistic time frames, he will estimate cost and timeframe based on resources available, he will allocate reserves based on the risks taken with the project so it is always finished in time and on budget
HTML is obsolete. It's time for a new, simpler and richer markup language.
*I meta mod all flamebait mods 'unfair'
Your breaking the system. You should not be allowed to meta mod.
Poor judment of human resources department and management.
Resume padding.
Influence traffic AKA it doesn't matter what you know but who you know.
AS long as scope creep exists, IT projects will never come in on time. Scope creep comes in many forms. Developers like to try new coding toys and features which can cause delays. Customers change their mind about scope and implementation which causes delays, bugs, and total rewrites.
The only way to bring a project in on time and under budget is to say, "NO" to scope creep. If a customer wants a major change, explain that they can have it in the next version. If developers start dragging in new coding toys, stop them immediately. I know I know, easier said than done.
you're some sort of Agile Process Improvement Consultant, right?
...researchers have discovered that today ios Thursday.
Love your country always, but respect your government only when it deserves it. -- Mark Twain
There's a 98 percent coorelation with people using Microsoft Project to plan their projects too.
I think that means anyone who uses software to plan a project is entering the assumptions incorrectly, such as:
1. Assuming everyone has 100 percent of their time to devote to your projects, even though 10 percent is admin and 40 percent will be firefighting.
2. Assuming all the pieces will be there on time.
3. Assuming all code will work correctly with no real testing and no real Q&A and no real customer feedback or alpha or beta testing and no bugfixes later.
4. Assuming training will magically occur.
Basically, what I learned in the Army as a Sergeant is still true today - ASSUME makes an AZZ out of U and ME.
-- Tigger warning: This post may contain tiggers! --
95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.' I would imagine most of the projects are given or required to have a deadline that is not possible to meet. End users have unrealistic expectations as well. And those providing the service may not be able to even accurately estimate the time for delivery. Finally, unless the specifications are frozen, feature creep becomes a problem. Because the client will want to add more stuff to the project without extending the deadline.
Without a good project methodology, I would recommend giving a flexible deadline, so that after a period of time a newer estimate could be given.
"You'll get nothing, and you'll like it!"
So, 51% or more of the projects are delivered on time and on spec.
BUT if you've EVER missed a deadline or been off-spec, then you get counted as bad.
If you deliver 99 projects on time and on spec, but fail on 1 project, you're counted the same as if you failed on 100 projects.Right.... that tells me that the "answer" to this "problem" isn't technology. The "answer" is to have the IT managers take a few marketing classes and spread the bullshit to the "business executives".Again, all it takes is 1 failure to be lumped in that group. No matter how many successes you've had.
"So, you've solved world hunger, the arms race, poverty, racism, nationalism and have single handedly established a viable human colony on Mars. But we're really concerned about that jay-walking ticket from last year. Let's focus on what you can do to prevent such a failure in the future, okay?"
are made up on the spot. The other 58.222% are inaccurate.
open4free ©
I work in a small company where my bosses are geeks too..
My CEO is a mechanical engineer and a bio physicst
My other boss has a Bachelors Physics Engineer with a Masters in Business Admin
My other boss has a Bachelors in Comp Sci
So for now I don't have to deal with any PHB or Jocks telling me what to do.
Some of the projects that I've worked on were late cause:
The specs we given to me all broken down into a requirements doc. I implemented the proj according to the specs and finished it b4 the deadline. But guess what happened, the specs were not quite what they wanted and it got changed a couple of times.
Even after my many suggestions to implement some sort of CMS for project tracking/communications it always gets thrown into the "later" category. If things are organized and communications is good in my exp a project gets finished so much faster. Sending multiple e-mails per project a day doesn't really help out..
Or very little time is spent on process planning.
Although you're point is valid, but could it be that 95% of IT projects have some changes in the specs AFTER the schedule has been made? Is it just me or do you also see a correlation here?
"... or to the full satisfaction of the business executive."
I've been working in IT for quite a while and of course projects run late (they do in every area of business), many posters have noted it's because of change, unreal expectations to begin with or sales/marketing folks who are afraid to tell the truth to the customer.
Regardless, I think the quote that strikes me the hardest is the one above regading "to the satisfaction of business execs". One area that I think *everyone* in IT and on the business management side of any organization need to work on is sitting down and creating real expectations that will lead to satisfaction. All too often I hear execs complaining about why we can't get ALL of the projects done NOW! or I hear "this isn't what I wanted!" or they come down hard on managers for delivering something late when in fact it's the execs inability to properly set his expectations clearly.
I also lots of issues with a fundamental understanding of the business goals and requirments by the IT side and vice versa where the business folks have no idea what they really want from the IT side. In "theory" business analysts are supposed to fill that gap but in reality it's all too often that some exec says "we need e-commerce! now!" and expects that in a month they'll have a fully functional catalog and website w/ b2b portals and automated billing, etc. Even more realistic they don't even know what that means but they read it in the airplane magazine and so they feel they need it. Even if it was built fast and exactly how they wanted (assuming they could describe it), I also see that they (the business side) rarely are prepared to alter their operating or business process to meet the new technology. Thus I think many feel "unsatisfied" with the technology projects they commissioned.
It's a mentality that IT (or better said "technology") will solve all the business problems and instantly make the company or department more streamlined and thus more effecient. While this isn't a myth and is achievable, I think the expectations of the business side rarely match the ability of technology and the people delivering it.
As an IT manager I expect the dead on truth in terms of schedule, timing, effort, etc. no matter how bad it is or how much I won't like it. If I ever step in to the executive role, my philosophy will not change. I will expect perfection but demand reality. My technical prowess easily exceeds the executives I work with now, but coming soon are younger and more adept executives who I think begin to change the tone. However, that doesn't mean the demands will be less, in fact it could be greater upon the IT staff, because the IT managers of today who move to exec roles will know what an IT shop is capable of.
I think the art of meeting the business goal is just that, an art. One hand it's hard science of scheduling and measuring, but it's also managing the people involved. If your IT project is late, it's maybe because you, your group or your boss isn't very good at what you do (unlikely) but more than likely it's because no one was able to set the expectations up front or as things changed and thus the projects slide in to a murky hole of blame shifting and cover-up all to appease some exec who didn't really have a clear idea of what they wanted in the first place and who isn't really ready to cope with the new IT beast they're about to unleash anyway.
-s
The important thing was to GET the contract and then work out the details.
When I first started, I lost a lot of opportunities to others who quoted 1 week for a 4 week project and then took 4 weeks to do it.
And management bit EVERY TIME. It's like they have that short term memory problem from "50 First Dates" and "Memento."
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
...still working on my answer...
GET FREE APPLE STUFF!
blah blah blah Microsoft sucks blah blah blah
Anyone else really getting sick of this?
MS Project dosen't plan projects, PM's do.
Garbage In, Garbage Out.
Or maybe 90% of IT time estimates are to low.
Sindri Traustason.
I'm a software developer now resident in the USA for about 5 yrs. Preivious to that I've been a developer and consultant working all over europe.
In my experience, a much higher percentage of European projects are delivered on time than US ones. The simple reason is that in Europe, engineers are more respected and are usually tightly involved with the requirements gathering/planning phase.
Unfortunately in the US it usual practice to keep engineers away from clients and only involve them when everything is already agreed on paper. This means that the engineer gets a garbled requirement to work from, and the technical decisions have already been made/commited to by someone without any technical skills (i.e. sales or management).
The net result is that the engineer is expected to implement someone elses bad design that usually misses important aspects or doesn't address the actual problem, in a hopelessly optimistic timeline. Furthermore god help the engineer if the customer isn't kept happy.
its 95% of IT companies haven't met a deadline at some time. its says it right in the submission.
Just getting ahead of those who would try to make this point without the obvious (I hope) humor.
The project is late because I spend half of my day filling out TPS reports, and making sure they have the right cover sheet on them.
the growth in cynicism and rebellion has not been without cause
wow, this article's been posted since 9:45 and a quick CTRL-F on the page isn't finding any references to The Mythical Man Month. I figured somebody would've recommend it.
NERDS!!!!
These problems are not at all limited to IT projects. I would wager that 95% of ALL projects of ALL kinds are delivered late, or not at all.
And when I say late, I mean the originally conceived due date, not the constantly-amended, only-finalized-when-the-project-is-about-to-ship "ontime" delivery date.
There are four main reasons why projects slip:
1) Feature creep (Bloat)
2) Project procrastination (Parkinson's Law)
3) Overestimation of task-times
4) Multitasking
#1 is obvious. EVERYONE says "why don't we just add this one extra thing...it'll be snap..." Right.
#2 is less obvious. I don't refer to laziness. People are just busy with a million things (read: stupid, pointless meetings that sap productivity) and so they delay working on something until it's more urgent, because someone is screaming for something else right NOW.
#3 is devastating. Everyone involved in a project adds their own little padding to their estimation of the time it will take to do something. They think, "I can probably do it in X hours, but I don't want to be late, so I'll estimate 2X hours."
Since EVERY single person in the project is doing this all along the way (including the project manager), it's impossible for the project not to be delivered late, especially since even these doubled time estimates can't be met because of #2 above ("Oh, I have twice as much time as I need, so I'll do this part later.")
#4, multitasking, is the reason for #3. Since we all have to put up with constant interruptions, like pointless meetings, chatty co-workers, bosses' (yes, plural) questions, and other projects, we are never able to focus and get the really important parts done QUICKLY. The human mind can be a truly immense intelligence, but with so many tasks fragmenting our focus, few people reach their daily potential.
The point? A lot can be done by simply sticking to a plan, scheduling aggressively, and then arranging for everyone to leave your people the f&*# alone, and they'll amaze you with what they're capable of.
However, the typical uppity-up's response is to blame the employees who do the work. It would be much closer to the truth for them to blame themselves, as they dictate the environment that keeps people "multitasking" to death and never achieving their best.
I haven't read the article, so this may be redundant, but so far, the comments haven't focused on this aspect of projects going awry.
Caveat: the point I'm making shouldn't be taken out of context. There are a number of issues that are causing delay, but the one below hasn't gotten it's "fair share" of exposure.
In the current implementation that I'm involved in, there are a number of issues that we've had issues with simply due to the vendor over selling the product. Whether we are caught not getting what we were told was available, or we are having to spend resources to get what wasn't actually in place (vaporware), both situations result in delay and were the direct effect of Sales selling something that Engineering didn't have.
Marketing often gets blamed and, in this case, IT is being scrutinized, but I believe it's often the reality that the Sales people, and/or the Sales Cycle, is faulty. I want to distinguish between Marketing and Sales here. Sales did a "bang up" (yes, I'm being sarcastic) job selling to our Executives and the Executives should bear responsibility for mandating a poor choice. The reality of the situation, though, is that the implementation team (both Vendor and Client), of which IT is only a part of, is burdened with "making it happen within budget and deadline".
Hopefully food for thought...
The article does not say 95% of IT projects are not delivered in time. It says only 5% of the IT groups surveyed (in Canada) SAY they always deliver on time.
So, 95% of those IT groups admit to [at some point in time] not delivering a product in time.
Put the requirements in a contract, have everyone sign it. Explain to the customer that if they wish to change these requirements, they are welcome to renegotiate the contract.
(If you do this, do your damnedest to not agree to a due date, of course. =D )
I think it's because the people that set the deadlines make unreasonable demands and don't understand the requirements they are making upon the programmers.
Three programmers without a CEO can create a video game that generates millions of dollars of income. What can three CEOs create without a programmer?
That must be it ....
Of course some companies (think MS) even have worldwide "launch" events yet never deliver their "secure OS". Even more amazingly, they get customers to pay big bucks to "upgrade" (re-grade? regress?) from one non-delivered product to another non-delivered product.
Paul
www.opencouncil.org
Open
It's a pain in the butt but customers will get exactly what they want and they'll know exactly when they're getting it.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
We had this issue at a manufacturer I worked for. Management went to engineering and wanted time estimates for each category of product. This way, if a new customer wanted something similar to what was in our catalog, they'd know how long it would take. They swore up one side and down the other that they would not oversell the estimates.
Three weeks later Management announced a new contract for a product that was listed as "8 weeks start to finish" by Engineering. They told the customer 8 weeks, but the customer said they needed it in 4 or no deal. Management caved and agreed to 4.
The customer was shipped beta crap at 4, just to meet the terms of the contract. In reality, this is what the customer EXPECTED to happen.
Engineering had a fit. We asked management flat out "why didn't you just tell them 'no'. If you want it done right, it'll take 8 weeks.' We got a lot of standard bullshit and tap dancing about wanting to please the customer.
The sad part was this was a one-time, really small contract and it wouldn't have mattered one whit to say no -- other than PR value. Hell, the contract was done a break-even and didn't make a profit! (It was an auto-manufacturing company and the client was Rolls Royce).
It all stemmed from Management's inability to communicate to the client that "this was a real, not bullshit, time frame. Anyone who claims to do it significantly faster is lying to you."
-Charles
Learning HOW to think is more important than learning WHAT to think.
Maybe it's a shift in how things are being labelled.
This month's Software Development magazine has an article (P22 - No More Chaos. Checked their site and the article itself is not online, but it is listed on the main page.) that says that they were unable to find any actual failed projects in 2004, even after surveying 10,000 US companies!
So maybe instead of projects failing, they are just taking the extra needed time to get them done right, but then getting thumped for being late.
"Well Mr PHB, either that project is late, or we write it off as a failure. What's going to look better?"
Since my Ask Slashdot was rejected (and this is an appropriate place), I'll ask it here...
My company is starting an aggressive CMM project to reach Level 3 (we're at Level 0.5 now). Will this stifle innovation or really help us in our projects?
Successfully condensing fact from the vapor of nuance since 1998.
Look....
;)
Programming is math. And math is hard. For starters, 99.9999% of all math is random and impossible to understand in the technical, math sense (proove) (extrapolation from Godel and Turing and Chaitin and Cantor...and yes, it really is 99.999....%).
When you sit out and design something to match a real-world process, you do fine. Then, you change something, you'll never know the impact of that change. You can't design for it in advance. A change of 1 character in the design could litterly require the entire code to be rewritten. You cannot prove how big your impact will be. Ever. That is why programmers get frustrated when customers change their mind "o but I just want it in this differnt order," "godamnit now i have rewrite half the loop..."
That is because good programming isn't just about being "smart", or about "planning"... most of the times, you are running against the fundamentals of understanding the algorithms in question, even with something as simple as lists or hashs or whatever.
The fact of the matter is is that programs are late because of bugs, and there are bugs because of the fundamentals limitations of math/the universe. You can't just smart them away cause you're some genius coder. All the genius coders write in their own designed language that best matches their thought processes and is easy to rewrite (i.e. they just gave up and went with LISP) with the assumption that they are going to rewrite most of the damn thing anyway at all stages of the game and the quicker they can rewrite it the better.
And that is why all these languages are getting closer and closer to LISP was 40 years ago...python, java, smalltalk, etc etc etc....automatic memory management and fast re-write cycle is the best way to write code for 100% of all projects (sans anything with 100,000+ intensive simultaneous users or an airplane code or something when you are bearing up against the engineering portion of things).
That's just my opinion. But I think it's fairly accurate. I've been programming from birth it feels like and I studied the math and I now I write for a large corporation where every schedule slips all the time and I have to deal interpreting customers and figuring out what they want and all I have say is:
There is no magic bullet and there NEVER WILL BE. Read Godel, Turing, Chaitin, etc. You'll be better for it. You're not going to fix your problems by using OSX instead of Windows or Oracle triggers instead of MySQL+PHP or Object Oriented instead of functional or procedural or XML web services instead of TCP/IP and binary. None of those things fucking matter, ok, fanbois? They're corporate games, that's it.
The best you're going to get is to find a language that fits how your brain thinks and that you can rewrite things in QUICKLY (i.e., don't even bother with the write-compile-link cycle... write it in LISP then have something covert the LISP to compiled code at some later day after you've profiled it)...
o, and a good text editor
and if management gives you shit, tell em to jump off a cliff. it's their only job to schedule, and if they aren't smart enough to schedule things with the understanding that schedules change for things that have nothing to do with how smart or good someone is as a programmer, they're worse than worthless anyway and you'd best find a new boss quick.
I agree that not only 95% but atmost 100% IT companies deliver the product out of time. They show some problem, or even do not show the progress on the schedule. I have even collected the statistical data here. I have found the same case here.
Yes, you missed something. Can you add a print function?
It's not like there is some universally defined deadline calculation system for IT projects. Now, if this were an airline, it'd be obvious if it's late or early. A given plane can only fly so fast and the time to board and prep a plane are fairly well known. Late is late.
With IT projects, every one is new. They include elements from previous projects, but each are fairly unique. So, if most of the projects are late, it is as just as likely to be from a too-short estimate as from a too-long completion time. I see these stats about IT projects all the time and it always says the same things to me....
One or more of the below must be true:
1. IT workers are generally slackers. Somehow it is known exactly how long their jobs should take, but they almost always take longer
2. Project managers are idiots. They keep underestimating IT projects and have never learned from their mistakes.
(Why does the world always assume #1? If you purchased a new moped that you estimated would go 195mph, and it didn't meet your expectations, whose fault is it?)
3. Since it is hard to estimate an IT project, supervisors give a little slack. Project managers take advantage of this by under-estimating in order to get the job approved and they simply beg for forgiveness at the end of the project. It seems to be working. Most of the projects are not completed to spec, yet there haven't been a million PM firings.
You can probably tell which I think is true. As long as late IT projects are tolerated, they will exist. As soon as it is demanded that projects come in under estimate OR ELSE, estimates will start to get padded and projects will mysteriously be under budget and on time. Without changing the staff, training anyone, writing better specs, anyone getting "a clue", suddenly the industry will be in tip-top shape. So stop complaining about why projects are late -- you're missing the point. Deadlines are set by managers, not by the laws of physics. If there was any attemp to actually figure out how long a project was REALLY going to take, then exactly 50% of the projects would beat that estimate.
Another example -- if your pet turtle couldn't run the 10 foot dash in your expected 30 seconds, maybe you'd get angry. Maybe you'd get another turtle. But by the 1000th turtle running right around the 45 second mark, you simply have to stop blaming the turtle and start adjusting your expectations!!!
Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law".
This is my sig, there are many like it, but this one is mine...
group hugs.
Really, why can't we all just get along?
Seriously though, I am both a manager and a developer. I actually think I care more about my customers when doing coding then managing. When I am managing projects I tend to feel the need to strangle people far more often then when I have the chance to actually write code...
Yet another reaction to computer crashes...
Why do you need a new cert? Are you changing the public domain name of the web site? If the domain name stays the same, it should be simple to move the cert.
Oh, you're one of those IIS guys who use the horribly abstracted tools provided to deal with the certs.
Learn to use OpenSSL from the command line, or at least learn to use the raw Certificates snap-in for MMC (Open MMC, select Add Snap-in, pick Certificate and Local Machine (Not current user) and then the rest I'm not explaining now. There might be something on my web site, I think, that goes into more details.) rather that the training-wheels version you get from inside the IIS Manager. The raw Certificates snap-in allows you to change the machine name, but it's tricky and obscure.
I've moved the same cert from IIS, to Apache, and back again. It's a pain in the ass with the Microsoft tools that try to treat the whole thing like it's a single key, when in fact it's two keys (Public/Private). Absolutely obvious with OpenSSL, but hidden from you for some strange reason with IIS.
As others have pointed out, all projects are "late". This phenomena is not unique to IT projects. I put "late" in quotes because the projects are usually delivered on time -- from a realistic standpoint -- but the manager has to lie about the cost and time to be assigned the project in the first place.
There are two type of managers. Let's call them "Honest Joe" and "Sleazy Bob". Both want to lead the project and must meet with the executive who can approve the project. This is how it goes.
Executive: "Hi Joe. Tell me you much this project will cost and how long it will take."
Honest Joe: "It's going to cost five million dollars and will take about eighteen months".
Executive: "Thanks, Joe. You're fired. Before you clean out your office, could you stop by Bob's office and tell him I want to talk to him?"
Bob walks in...
Sleazy Bob: "Wow, I really like your tie. You know, I saw that tee shot you made on number four yesterday. Absolutely amazing. Did you ever consider going pro?"
Executive: "Thanks, Bob. Now about this project. How much will it cost and how long will it take?"
Sleazy Bob: "Six months and a half a mil."
Executive: "Sounds great. Get on it".
Eighteen months and five million dollars later the project is complete and Bob gets promoted.
If I had a nickel for every time I've seen this scenario play out, I wouldn't need a job anymore.
This doesn't say 95% of projects are late. It says 95% of groups are delivering some projects late -- or the business executive isn't completely happy with the product after it's completed.
I mod down pyramid schemes in sigs.
This reminds me of a paper I read several years ago that gave a mathematical proof showing that objective estimation of software complexity is impossible. The same author has since provided some supplementary notes as well that are a good read, and even a PDF of some slides from a talk he gave.
Being a math weenie myself, I gave a short presentation of the results to my development. Afterwards, my manager pulled me aside & told me to stop wasting valuable development time since we were already behind our schedule.
Sigh.
If there is a budget, if it will realistically cost 10 grand, say 15 and go "Look we have an extra 5k for you!"
Unfortunately in the business world, when you succeed in this fashion they expect you to work miracles next time under truly unrealistic conditions. Sucks.
No sig for you!!
Did I miss anything? ;)
Aside from the memo about readable code, no.
Are they delivered on it, and how much of the delay is in IT projects is IT related.
For example a project may be delayed because, the programs are busy working on multiple project, this is not directly related to IT, but could mean, that finding more programmers is an issue
And most importantly, is this problem IT specific, and the emphasis here is ont the I, how much of the delay can be blamed on the T
How many of high tech project is delayed? Maybe managers just can't forcast how much time and effort high-tech jobs take, this is not exaclty the fault of engineer, but actually a failure in the management domain! If the job is simple they succeed to predict how long it will take to finish, if not, they fail, kinda sounds obvious.
When I here statics like this, I remember statics like, 60% of people in jail are black, is it really because they are black, or more because they are poor, and it just happens that more black people are poor, know what I mean! We can reduce poverty, but we can't (at least not desirable) to change peoples color, and even if we can, that won't guaranty reduce the jail population.
My last company hit the trifecta of all three.
A man driving a backroad across country came upon a cowboy out driving cattle. He stopped, got out, and said to the cowboy, "If I can tell you how many cattle you have, would you give me your smallest cow?" and indicated the animal he desired.
:(
"My smallest cow, you say? Well, why not, give me your estimate," replied the cowboy.
"Sir, you have exactly 400 head of cattle," the man said after some contemplation.
"Wow, that's exactly correct," said the cowboy surprised. So, the man walked over, picked up his prize and put it in his trunk. The cowboy, concerned for the animal, asked, "Now, if I can tell you your profession, would you let me win back the animal?"
The man, somewhat taken aback, agreed with a chuckle, "Sure."
"Sir, you are a consultant," said the cowboy without hesitation.
"Wow. That's pretty impressive. How did you know?"
"Well, you came out of nowhere telling me that you could give me an answer to a question I didn't ask for a price that was over the top," said the cowboy with a stern look. "Now give me back my dog."
--Wish I knew who to attribute this to
If we told them the truth about how long it will take, and how much it will cost, they would never let us do it.
Did I miss anything? ;)
:P
Proper indentation ?
Eventually, both men concluded they must be near (insert fuckedcompany here).
... but i'll say it again:
You can have it:
Cheaper
Faster
Better
Pick two
Whereas the managers (not all, but too many of them, are unrealistic)want:
Free
Now
Perfect
[what?]
My only solace is that, like most CTO's, he's largely clueless about IT.
...then this morning my manager decided to replace the foundation when I was finishing putting on the shingles.
Life, the Universe, and Everything... in my image.
95 per cent of information technology groups are not delivering some number of projects on time or to the full satisfaction of the business executive.
While the "late" part of the 95% of projects is a sizable portion, I bet the "full satisfacion" part is as bad or worse.
What executive even really knows what he wants well enough to recognize it when he sees it. Sometimes, the hardest part of a job is getting the boss at the top to understand the requirements well enough to understand what should be delivered. As a one time consultant, I know that many clients really don't know what they want, but they certainly do know what they don't want. Often, half the battle is convincing them your solution is what they want (assuming it is a good solution) and maintaining their expectations within the realm of the reasonably possible. ("What do you mean you can't port this VB enterprise system to Linux over the weekend?")
Meeting the specs (including the schedule) is hard enough, but the satisfaction of the higher ups is often completely unrelated this.
You are in a maze of twisty little passages, all alike.
I have two thoughts concerning this statement:
1. In probably most cases management DID come through the ranks - just not the "IT" ranks, and why would they? IT departments "serve" the business, they are rarely "THE" business itself. I would be quite concerned if the managers of the Lab where I work came from IT - what the hell would they know about running a lab?
2. As far as expectations go, many of these are driven by "demand" - often economic but in many cases they are often legislated. For example, some "shit" happens, peaople die, public is outraged and so Government X passes regulation Y dictating such and such must now be done. Business Z now has to implement Y by deadline T REGARDLESS as to how long the IT dept. says it will take. If IT says it will take a year and it takes a year, then they think they are on time. But the Business may have been dealing the repercussions of the "late" implementation for several months.
"asking developers how long they think XYZ will take doesn't really work well."
Really? They're the people who actually have to do the work, surely they're the *only* ones who know how long something will actually take. If you don't believe their answers, you have bigger issues than your project's schedule.
You mean... Windows Longhorn will not meet its deadline?
I honestly can't tell if you're being snide or funny :)
That said, I think developers themselves often underestimate the time they need to do something, they themselves don't factor in all the actual things requires, like documentation and simply bug tracking/fixing.
Though I think Scotty had a decent rule, just multiply all your estimates by 4, then you'll seem like a miracle worker when you get it done much quicker.
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
Please stop using the building something as an analog to software "construction".
There are hugh differences between building something and building software;
1. The bridge goes from point A to B and is x units long and y units wide and carries z amount of weight etc etc
2. The bridge is made of steel and concrete and other physical substances with known properties. Steel of composition blah, will hold up a known amount of weight, bending a known amount per unit of length, etc.
Software has to do what? I don't know we'll tell you as you go, and change it if we do tell you.
Software is made up of what, other software. What does IE do when run on this M$ OS running that plug-in - who knows?
You might as well compare fire to THE SUN, they after all are both "hot".
Software projects are late because of bad management. PERIOD.
Unless and until the PHB recgonize themselves as the problem, there will be no fix, just more blame cast at those weird IT folk.
*click**beep**beep* Scotty, One to Mod up!
I've done my fair share of under-estimating, but my manager (heh) often estimates up to four times less time than my most optimistic estimates. We did a time-cost exercise for a new feature a few weeks back where I said "that doesn't sound right, there's no way two guys can get this done in two days" and everybody just assumed it was me being my "pessimistic" self. Well, let's just say it's not ready two weeks later.
Efffing Marketing/Technology Groups who tell us that most projects aren't delivered on time or on budget or meet expectations. 95% of the time reports from organizations like Info-tech are not statistically sound nor based on a representative sample of the real world.
The rock, the vulture, and the chain
95% of the time, the ones promising delivery dates aren't even TALKING to the IT staff to find out if it's even possible before making promises.
Errr....Not that it happens where I work or anything...wait, today is my last day, what the hell do I care....that's ALWAYS how it happens around here.
Some PHB who doesn't even understand the technology promises it can be delivered in 30 days. Nevermind that we can't even get the equipment in 30 days. Then IT is made to look like "the bad guys" [tm] because we didn't deliver on time.
If this is the case, then use it to your advantage. And I'm not speaking direct directly to the parent, but rather to all. There is a good chance a lot of /.ers out there are smarter than the average joe. If this is the case (which I hope it is), make it work for yourself, not against yourself.
I have never let my schooling interfere with my education.
Houses and software are very similar. There are local housing codes which require builders to adhere to certain standards, but these serve as a bare minimum- they don't guarantee that you have a quality product. Ask anyone who a) watches the development process as their home is built, and b) knows enough to know what isn't being done correctly. A completed house can also be riddled with bugs and deficiencies.
This is why I like XP (Extreme Programming, the good development process with the dumb name). One of its rules is to involve the customer every step of the way. If the customer can see how the project is developing, they are less likely to expect an unreasonable deadline. If they can give you constant input, you're less likely to waste time coding stuff they don't want.
I'm ambivalent about the pair programming aspect, but the rest of XP tends to work really well.
LOAD "SIG",8,1
If an accurate comparison is drawn to other areas of engineering, look at how much it costs to research, test, and build new technology in general. How many BILLIONS of dollars were poured into designing and building and testing the varous components for the space shuttle? Even then, we had the O-ring disaster. There were also problems with tiles that would fall off (loosen?) during re-entry, and probably countless others that we've never heard of.
1. When asked how long you think a project should take, estimate the actual time and double it.
2. When asked when you will be finished, break the project up into phases. Instead of saying it is not finished, tell them you have completed phase 1, and are working on phase 2.
3. Stand your ground. Do not let the manager coerce you into shortening your projections. You may risk losing the project to another programmer who claims to be able to do it in half the time. They will look bad when they fail. You may be given the mess to clean up, and you can point out the outrageous flaws in the code and design.
4. I have been a programmer for over a decade, and experience has taught me that in the long run, shortcuts are not any faster and ultimately make you and your company look bad. A good design is worth the planning time. When working on code written by other programmers, it is best to come to an understanding of it and then go with the flow instead of hacking away at it.
5. Working long hours to meet a deadline is also counterproductive. More mistakes are made, and programmers tend to leave for down time or for greener pastures. Then you have to find and train new programmers, or pay contractors top rates.
I agree with the article that in most cases, the blame lies with the sales reps, who often sell vaporware to get those commissions.
But sometimes, especially with small companies, promises are made because the contract is needed to keep the company afloat. If a company is in this desparate position, it often starts laying off staff, which makes the remaining programmers very nervous, and they need some additional motivation to prevent them from jumping ship.
If they are performing duties that a higher-level programmer used to do, promote them to that position, with appropriate title and salary. If you start calling them up on weekends, nights, vacation days, and holidays, do not complain if they need to take the afternoon off for a hair appointment that was originally scheduled for Saturday....I digress. In tough times, if you want your employees to make sacrifices for you, you need to give them a good reason why.
If you want good estimates for the length of time to accomplish a particular task you use a combination of the following two techniques.
1) instead of asking how long it will take them to accomplish the task, you ask them how long it will take one of their coworkers to accomplish the task (more realistic answers always result).
2) keep records on their estimates and actuals, you will soo have a good multiplier for whatever answer they give you: actual_time = estimated_time_from_developer_x * multiplier_for_developer_x
This works great, hope it helps!
... is getting projects approved by the Powers That Be (i.e. the clients). I work for a small company, and in order to stay in business, our production schedules have to be followed to the letter. Things must be done to schedule even if the computers crashed and there was no contingency time budgeted and we have to work unpaid overtime to get the project finished by the due date. Then we send it off to the clients and wait... and wait... and wait... and wait for approval or changes, often past the final deadline of the entire project. At this point, of course the deliverables are late -- and it always seems to be "our fault".
And of course, a lot of the time there are changes to be made to the final product even if we have been sending daily/weekly rough versions for evaluation as the project develops. Somehow, it's always a case of "This is exactly what I asked for.. But not what I wanted!" -- and the clients don't figure that out until they look at the final, polished, ready-for-the-public version. It drives me absolutely frikkin' nuts. What is the point of demanding progress reports if you don't look at them?
Well, since you asked for it... :-)
For one, your code could benefit from a little bit more consistentcy. 'manager' and 'manager.schedule' are both objects, as indicated by the member access operations; but in the 'manager' context, you access member data directly (the presumably boolean 'clueless'), while in 'manager.schedule', you use a method of 'manager', 'isRidiculous()'. Another naming inconsistency is the adjectival boolean 'manager.clueless' vs. another boolean member of 'manager', 'isEvil', with a verbal name. Direct member data access seems to be the norm in this fragment, although good OOP practices should dictate the use of data-hiding and accessor methods.
By your capitalization scheme, I'll make the assumption that the the platform for this code fragment is Java, so I won't be so bold as to suggest Hungarian notation.
Other than that, no, looks good. :-)
Quit beating around the bush - you're saying we should lie.
You were just being difficult. If you want to upgrade the app, make the business case for that--separately from the migration. Yes, in the long run it may be easier *from your perspective* to do it all at once. But ultimately it's even easier to just do the migration. And sticking to the task at hand reduces the variables and therefore the troubleshooting.
Yes it may cost more to do them separately. But no offense--that's not your problem or your decision. Sometimes splitting projects up over time makes more financial sense to a company than doing them all at once, even though the aggregrate price may be higher.
CONTRACTORS! HERE BE DRAGONS! - well, I contract for living for already 4 years. Maybe something is wrong with me, but my projects are either on time or on their natural time or on supernatural time (that's when you work for over 12 hours a day to deliver.)
But on 2 projects I worked I saw exactly what you mean by DRAGONS, they do exist unfortunately.
You can't handle the truth.
Duh!
Most projects are delivered on CD-ROMs.
Chris: "Well, why do you go into the closet?"
Mitch: "To get my clothes, but thats NOT why HE goes in there."
Chris: "Of course not, he'd never fit in your clothes. Think about these things Mitch. 20 points higher than me huh, thinks a big guy like that can wear his clothes?"
They Live, We Sleep
People who come up with the schedules have no clue what it takes to build software.
...richie - It is a good day to code.
...for each time you saw this scenario:
Let's be generous, and assume you've seen this scenario four times per day: that's USD0.20/day.
Assuming you don't work on weekends, that's USD1.00/week.
If you don't take holidays, that's USD52/year.
I'd always assumed the cost of living in the US was a bit higher than that.
Pretend that something especially witty is here. Thanks.
Canadian information technology groups can't seem to get IT right.
A new report conducted by market research firm Info-Tech Research Group says 95 per cent of information technology groups "are not delivering some number of projects on time or to the full satisfaction of the business executive."
and why is the heading in slashdot "95% of IT projects" while the actual statistic is "95% of IT groups have SOME late projects"?
This seems pretty misleading to me!
(1) Technology inherently advances, but many of your end users don't. For example, a database driven feature-rich web application may be just the thing your client needs; however, end-users think of and use solutions they are already comfortable with - they would rather pass around a spreadsheet via email rather than utilize the web app. Often times, the inability for end-users to think of new technology that could benefit them creates a brickwall between them and the develper. The developer has his blinders on because he's getting off about designing a sophistocated system, and the end-user has his blinders on because he can't possibly think why anyone would need anything but Excel (because it already does everything). These problems lead right into my second and third points:
(2)The invariable amount of disconnect between the end-user and the developer causes problems in the initial design specifications of the project - the developer over-analyzes the situation and tries to leverage new technologies (which I call over-technification), often times over-designing something incredibly simple. Due to this over-designing (and other factors), many IT projects suffer from point (3): poor design specs. For whatever reason it may be (complexity, lack of client understanding, over-technification, etc.) the developer can be left to create the design specs by himself without the assistance and review of the client. The greater problem will come down the line because the expert on the end-product functionality shoudl really be the client - they know the nuances and exceptions encountered in their data and tasks. The developer doesn't understand these subtle things that the client knows about. As the client's role in design specification lessens, we see more and more of my fourth point appearing.(4) As the client begins to see an emerging product based on the initial specification, they realize they forgot something (or the developer forgot something). This leads to scope creep - a customer now wants to add more features. Some times, this will lead to a complete redesign in the project, other times not; however, it always results in an increasing timeline.
(5) My last point is in regards to the "moving target". Due to scope creep, redesign, and changing needs from the customer, developers are preasured into adding features instead of completeing the agreed upon specification and then beginning a new project lifecycle to incorporate the new features. These circumstances create the moving target - a project that never seems to have an ending-point. This is both a developer's and a customer's nightmare.
...the fault rests on whoever is associated with the project and this is how: A) The manager, for not having the required experience in this field to correctly or approximately estimate the length of time required for a project. This falls on the old addage, "an emergency on your part, does not constitute an emergency on mine." Tip: Don't wait til the last f*cking minute to tell me about something critical. B) The person assuming responsiblity for the project. Since it's your ass on the line, cover it, speak up, and let your voice be heard. Don't let the project close badly while your nuts are in the door - get my drift? If you think it'll take you 3 days longer to get something done and DONE RIGHT, then tell the boss ahead of time, don't wait til the day the project is due. C) Vendors. Yeah, we all know how to love, hate, talk badly about, and even promote their businesses, but the one thing the vendors have to do is put your crap in the mail. All YOU have to do is stay on top of them and make sure you get the goods. Don't stand around waiting for something to arrive when you can surely work on something else to help pass time. I can actually relate to these problems with vendors though. We ordered NetScreen boxes from Juniper Networks. The only catch is, they took over 4 weeks to get here. Why, you ask? Because they sat on someone's desk at the U.S. Customs office near the border of Canada for nearly 3 weeks. So, despite vendors not putting things in the mail on time, we also have to take into consideration the other factors in the delays such as weather, terrorism, U.S. Customs, the Emperor of China having a parade, stuff like that...
-- Game Developers: Stop porting badly-textured games from crappy console systems!
... bridge-building as a discipline is thousands of years old; software engineering is a few decades old. And that bridges typically serve a single, simple purpose, whereas software depends on the complex interaction of thousands of elements that are not well-understood.
All true. And there's another important reason that bridges and buildings don't need as much testing as software: With bridges and buildings, you can order all the components to spec and (aside from the occasional corruption), you can rely on the components matching the specs. You order steel beams of a given size, alloy and strength, that's what you get. Bolts have the composition and shear strength that you ordered. You can use the numbers in your models to calculate the strength of the resulting structures.
With software, for everyone (except Open Source programmers), you are required to use components (OS, compilers, runtime libraries) that are proprietary, can't be inspected, and very often fail to correctly implement what's in the sketchy documentation that's available. You must test everything, so you can discover the underlying failures of the mandated components. If you find that something fails in a critical function, you can beg and plead to have it replaced with something that works, but the vendor can take their good time, or deny your request entirely. Sometimes you can spend extra time rewriting the component, but if it's sufficiently low-level (i.e., inside the OS), this isn't even possible.
So, if you're a programmer, most of your structures are build on unstable, shifting sand. Your tools are inadequate for the job, break at inopportune times. The pieces of your structure fail in unpredictable ways. You are forced to do extensive testing, because engineering calculations just aren't possible when all your materials have unknown defects.
And the jobs are usually so complex that exhaustive testing would take centuries on the fastest machines. So you deliver something that you know will fail. But you shrug, because you understand that it's what the customer wanted. Otherwise, they wouldn't be buying computers that were built to hide the details from the programmers. Everyone understands that if a foundation is unstable, the whole structure is unstable. So if they are buying unstable computers, they must want the software that runs on it to be unstable, too. Right?
I've done a few jobs where I could do a proper engineering job, because I had precise specs (i.e., access to the code) at all levels below my code. This is possible on a few real-time systems. But I don't even dream about it with most jobs, because I know up front that I'm not permitted to see the inner details of some of the things that I'm required to use. I know very well what the end result will be. But it's what the client wants.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
The statement is "are not delivering some number of projects on time or to the full satisfaction of the business executive."
Not delivering the project at all would count as not delivering it on time.
For example: If it was supposed to be here yesterday and it never got here, then it wasn't delivered yesterday.
Most people, even those who know better, assume that
software is like building a house. It isn't. It isn't like building anything in most cases. It is more like research and development.
If a software solution already is built, it should be bought. There is no building involved just some configuration (see office suites, database engines, music players as examples).
If there does not exist an application which meets your specifications and you decide to create one, by definition this is research and development. Since it has never actually been done, no one knows how difficult it will be. So all estimates are bogus.
Same for large scale IT projects (e.g. merging the networks of you companies after company A buys company B out). Since it has never been done (this is the first time the companies have merged) all estimates are usually bogus.
putting the 'B' in LGBTQ+
95% of IT Projects Have Ridiculous Schedules
1. Take the amount of time you think you will need to do the job.
2. Multiply by two.
3. Change to the next higher unit.
Thus we allocate 2 days to do a 1-hour task.
Recently I ran across a cute bit of history to illustrate how shoddy builders can be. It seems that Boston was the first known city to pass a building ordinance. Some time in the mid 1600's, they passed a law that made wooden chimneys illegal.
Think about this. They found a need to pass that law. This means that builders were building houses with wooden chimneys. Those builders knew exactly what they were doing. They did it anyway, and managed to sell the houses to gullible buyers.
Few pieces of software get as bad as this.
Actually, these days Boston is facing a similar situation. The "Big Dig" project to put the main north-south expressway underground is nearly complete. But it's springing lots of leaks. It's mostly below the water table, and the walls in a lot of places have very sub-standard construction. In some cases, they apparently filled what should have been concrete-filled spaces with construction rubble, and poured concrete around it. Joints and seams weren't properly sealed. And so on. Warnings from people involved in the construction were casually buried and never read by the right people. The managers responsible have long since moved on to new jobs, and the new managers are seeing a lot of finger pointing their way while they try to recover from the mess left by their predecessors. Sound familiar, anyone?
And there was a nice new bridge, which did have several design flaws. They were all minor, and could be fixed, for a small extra charge. But, strictly speaking, the bridge wasn't built correctly the first time. The engineering was good enough that the problems could be fixed before they became serious.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
"Good enough for government work."
75% of statistics are made up on the spot
It is all about being competive. When someone asks you for a time frame and you give them a good estimate you will not get the job because they find that your competitor says they can get it done in half the time. So when selling your services you need to give them the best estimate (assuming that everything works right). I like the Rule of 6 where the time it takes you to do the project multiply it by 6 then you get the best estimate. But if you tell them that it will take you 1 week to do a small program and your competitor says it will take 1 day. They will go with the 1 day. Then they produce a junk program in a day and spend the rest of the week modifying it to do what the customer wants.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
...who get absorbed and obsessed by the minutiae of things and lose (or never possess) the "big picture", which is always the domain of the right-brained visionaries who can see, but can't do, as opposed to the left-brainers who can do, but can't see.
Communicating through written or spoken words will always fuck things up between both camps.
It's really no surprise that software deliverables are so frequently late. The most important information for predicting the timeline doesn't become available until the project is already underway.
In a well executed project, the majority of the effort should go into the design phase with QA and actual coding dividing the remaining time more or less equally.
Unfortunatly, management demands timelines up front for various reasons. At that point, all anyone can really do is pull a number out of the air and pad it.
To make matters worse, in a bid situation, there's always someone out there who is more than willing to under-estimate the timeline in order to secure the contract. They know that by the time it becomes clear they won't make the deadline they can weasel out of any penelties due to change requests and then string the client along just 2 more weeks at a time. The big companies are especially likely to do that since they can easily drag out any threatened legal action long enough to not be worthwhile for the customer.
Going back to the popular building analogy, imagine how things would be if the client expected the architect to prognosticate when the building will be occupied in the first week while the requirements (including the building's location and size) are still under discussion! I imagine we'd be reading about how most buildings open late and over budget.
You forgot one of the best parts: "You are in an elevated position. You did not work to ascend to that position; you are merely that high due to being full of a large quantity of hot air."
Laughter is the best medicine, but in certain situations the Heimlich maneuver may be more appropriate.
A survey / study like this one is completely meaningless unless some effort is also expended on assessing the quality of the milestones and deadlines which are used to gauge whether the project was delivered "on time". Otherwise a project which isn't completed by some date which was simply plucked out of the air looks exactly the same as one for which significant effort was expended to determine a realistic and economic completion date.
If a project fails for reasons of an "unrealistic time frame", then the real question is why the schedule was unrealistic, not how the development team screwed up. IT project management should probably spend some time gazing into a mirror and re-examining its own processes.
licet differant, aequabitur
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
In my experience it goes something like this.
1. A high level description of the system is put together with a high level estimate of man power and resources needed. Commitments are made and deadlines specified based on these.
2. As detailed planning and then development proceeds - either formally or informally through the developers - additional requirements and requirements changes are identified. This is a good and necessary thing, but is often not controlled properly.
3. Original estimates are never adjusted, or insufficiently adjusted under pressure to deliver in the timeframe originally specified.
4. Repeat 2 and 3 until a working system is put together late and with a budget blowout, or worse make changes so difficult to implement that the project fails, or worse yet the stake holders never come to agreement on what the system should have been like and allow the project to fail without any part being implemented.
5. Bitch about project being late, over budget and not delivering what was required.
A good manager, given the right authority will insist on clear detailed designs and adjust at point 3 correctly. This only happens 5% of the time.
These posts express my own personal views, not those of my employer
The article does not say that "95% of IT Projects are not delivered on time." It is saying that 95% of IT Groups are not delivering some projects on time. Those are two completely different stats.
Heh! You got me there... It was a one-off joke, so I didn't really do a proper object design. I don't code like that for real, of course (digs toe in floor and blushes).
:)
Anyway, That was really supposed to be more like java-ish pseudocode. If it was Java, I'd have included classes for everything, including a superclass "Employee" which could be subclassed to "Manager", "Developer", "Consultant" and "EvilVendorRep" (although I don't know if you can classify those as "employees" because you generally have to invoke them with animal sacrifice so they might not actually be human).
Although... That gives me an idea: if we did it that way, we could make sure that the Consultant classes had trouble with infinite looping in a few of their methods (maximization of billable hours, eh?). And the Vendor classes would have to have a dozen different almost identical forms, all of which are nearly impossible to tell apart, take almost the same parameters, are described identically in the documentation... But then, behave in completely different, randomized ways!
The manager class wouldn't do much, but it would pop up endless annoying nag windows. Heh...
Farewell! It's been a fine buncha years!
The article said 95% of groups have delivered something late, but the /. header makes it 95% of IT projects are late.
/. headers lately. Maybe RTFA isn't enough?
I've seen a few other such corrections to
rd
To be fair, there are good contractors and bad ones (although the good ones seem to be in the minority).
;)
If you're a good one, good for you!
No hard feelings I hope.
Farewell! It's been a fine buncha years!
95% of groups delivering "some percentage" of projects late does not equal 95% of project delivered late. Granted I wouldn't be shocked at that either.
I wish Firefox had "highlight matching brace". *sigh*.
might be Baxter Black
The first 90% of the works take the first 90% of the time and the last 10% takes the other 90% of the time. This rule applies even when you try to take it into accountat the planning stage.
[taken from a very old "Mrphy's laws of computing" poster"]
Never underestimate the bandwidth of a truck load of tapes
Well it can be worse ..
A small company I worked in hired a new sales guy who was desperate because we had nothing he could sell - the company only had finished products which either were written for a special customer and could not be sold, and unfinished products which he couldn't sell either.
The managements solution was to fire everyone involved, including the guys who could have worked on producing something in the first place. Not the worst solution cost-wise, but not going anywhere either.
Morale: It's ok if everyone involved gets fired, but of course management won't fire themselves.
I'm still trying to figure out what people mean by 'social skills' here.
It's not 95% of IT projects that are not on time, its 95% of IT groups deliver some projects not on time. Sheez!
Yes, defensive coding practices. Not to even mention accessing fields directly. And even more fun, if using them directly as condition variables.
r ojectType(ProjectTypes.INTERNAL))) {
//...
//...
//...
Of course deep adressing is pretty evil thing too, but you don't seem to care about encapsulation at all. And I would guess that you haven't encountered any design patterns in your life. (just like I still haven't found my grammar skills)
Just a short clue to the right path (I'm lazy):
if (null != project
&& null != project.getProjectType()
&& Project.getProjectType().equals(ProjectTypes.getP
ProjectImplementer i = project.getImplementer();
if (null != i) {
if (i.getType() == ProjectImplementer.TYPE_EMPLOYEES) {
} else if (i.getType() == ProjectImplementer.TYPE_CONTRACTOR) (
}
} else {
throw new UnexpectedStateException("Guilty party not found. Therefore start packing");
}
}
In our fast pacing business domain please remember to use thread synchronisation properly, to ensure that projects state doesn't change while your code executes.
Most intelligent comment I have read here so far.
If a project fails due to lack of specing, planing, and selling the stages of the solution then its the managers fault and not the programers. Too many incompentant managers are still employed and meanwhile everything is not planned but rather outsourced as a result.
MRP, ERP, and business process engineering should be taught at computer science and MIS students. Instead only MBA's know about them.
http://saveie6.com/
"Software projects are late because of bad management. PERIOD."
Horseshit. Software projects are late or nonfunction just as often because of inept, pompous or arragant programmers.
What are the design constraints of a bridge? It generally solves a simply stated problem - get X lanes of traffic from point A to point B. And failure is not acceptable. Due to these constraints millions of dollars and years of planning and construction are available. This might be comparable to the Shuttle software discussed a few weeks ago, but not any projects I have worked on.
Consider the construction of a house, or an addition to an existing domicile. Price is a significant factor, and the customer has many arbitrary constraints (call them "aesthetics"). In many cases the customer isn't sure what they want until they see what they don't want, which requires rework. There is no official certification process for most construction trades - only specialties like electrical wiring. So it is difficult to know how good a crew is until you work with them. Many (if not most) construction projects like this run over budget or over schedule.
I think writing business software is more like building a house. The constraints are unique and vague. The workers vary in their abilities. And the customers are cheap bastards. Projects in this environment have very little chance of coming in under budget and on time.
I was going to make the same observations.
I really think most people dont bother even reading the article around here.
The astounding thing is that 5% of IT departments have PERFECT TRACK RECORDS!!
If I had mod points I would give them to you.
No one has a right to their *own* opinion. They have a right to the TRUTH.
Sorry, in our company we all are certified or will be. But none of our management is. Management almost always wins.
Anyone else really getting sick of this?
No.
Another guy who doesn't get that A) IT WAS A JOKE, and B) IT WAS SILLY PSEUDOCODE.
What is this, an asperger's convention? Lay off the coffee, man, you're gonna give yourself a heart attack.
BREATHE.
Farewell! It's been a fine buncha years!
Umm... Sorry about that. The indenting looked great when I was typing it, but then, in the page, well...
Farewell! It's been a fine buncha years!
Another guy who doesn't get that A) IT WAS A JOKE, and B) IT WAS LOUSY JAVA CODE.
What is this, an asperger's convention? Lay off the coffee, man, you're gonna give yourself a heart attack.
BREATHE.
Take any non-IT department and ask them if they've ever delivered any project late. Would you expect the number who said "no" to this question to be more than 95%?
In my experience there are two guilty parties to this. First are the Programmers who optimistically (or dishonestly) underestimate.
Then there are the Managers who will not accept an honest estimate, or worse will not accept that an honest estimate is not possible. They insist on a 'date', then insist on a date that is sooner than that, then complain when 'their' date is not met, and blame the IT dept.
In Soviet Russia, the coffee brews YOU!
(so sorry!)
1. The bridge goes from point A to B and is x units long and y units wide and carries z amount of weight etc etc
Software has to do what? I don't know we'll tell you as you go, and change it if we do tell you.
Well, that's the difference between a good specification and a bad specification. Every designer will see the latter, we only hope that we see some of the former. We all get our specifications changed in the middle of the project, but some companies know how to put out a change order and some don't. Software is exactly like any other area of design in this respect. Okay, people generally have a better idea of what they want with a physical thing (not always), but you generally get a lot more leeway with how and what you create in software.
2. The bridge is made of steel and concrete and other physical substances with known properties. Steel of composition blah, will hold up a known amount of weight, bending a known amount per unit of length, etc.
Software is made up of what, other software. What does IE do when run on this M$ OS running that plug-in - who knows?
Well, that is one sign of a more mature field. Thousands of people over thousands of years have figured out how to make decent steel reliably. I can get certs on every piece of steel I buy to prove what it is and where it came from. People's lives are at stake. Software companies don't hold themselves to those kind of standards. Not because they can't.
But, engineers run into similar problems. Before you build a building or a dam, you have to send a geologist out to check the site. If the base you're building on isn't good enough, you cut it out and pour a new one. Sometimes the material you need doesn't exist. The batteries are too heavy, or the steel can't handle the heat. Life sucks. You keep cutting until you get to something you can work with and build up from there. If you can't, you have to inform the customer that you can't deliver the product they want.
Software is made of other software? That means all your problems can be blamed on bad programming. Not something warping or annealing when you welded it. Not dissimilar materials welding together during transport. Not rubber that was stiff when it got cold. Not a bad batch of steel from the mill. Not corrosion or weathering. Not two parts on the opposite ends of their tolerances. Computers are digital logic systems. Things are usually either right or wrong. The real world is completely analog, and everything is a compromise between what you really want, what you can afford, and what is physically possible.
Software projects are late because of bad management. PERIOD.
Bad management by the managers, as well as bad management by the programmers. Blaming others won't make you a professional. Try holding yourself to a higher standard.
Oh, wait...
Did y'all contribute to our OSDN survey? I would like to see those results...
and it isn't unique to IT.
I design hardware and firmware for embedded systems. Routinely I am asked for estimates of how long a project will take. Without exception, every project has had the time frame chopped in half. Why? Because of some insight into the required goals or a marketing target that simply had to be met? No, just because "that's ridiculous!"
Then starts the endless recriminations for missing the project's deadline. One asshole that I worked for even resorted to creating a "wall of shame" that showed the shortened timelines and how "late" the project was currently. That shit stopped when I posted my original timeline underneath it and how each goal had been met. All of it disapeared from the wall one weekend and I was criticised in my next review for "not being a team player".
Fuck 'em, just fuck 'em! As long as we have technically inept people making these kind of idiotic arbitrary decisions, of course every project will be late!
the blame rests elsewhere, considering they get hired by people who want to pay someone for a detailed study that says someone ELSE screwed up. Remember the SNL skit about the delivery company that stamps your packages "received" three days earlier when you need off the hook for the package being late? Same idea here. Another way to say this is, "95% of our client-sponsored reports conclude that it was not our client's fault."
I'd guess it's more like 99% of companies are not delivering *some number of projects* on time or to the full satisfaction of the business executive.
It's not just IT, when do projects ever come in on time and on budget and to spec? Never. Well not never but outside of a 7th grade history class, almost never.
On paper you have "On Time", "On Budget", "To Spec" for everything, that's why you set them, however in reality 99.9% of the time you can only actually have 2 of them and most companies care about it being on budget, and as a result of scope creap it's usually way over due or crappy.
Happens all the time, my advice to consultants, always do one of the following
double the price (so you can add help)
double the timeline (so you can do it with what you have)
Avoid halving the specs becausse they will assume it's a result of inability. Plus for most companies they like to cry poverty but in the end they can afford a lot more than you think and still feel they got a bargain.
You'll actually end up with happier clients, most of the time.
What gorgeous code, even though its an example. Enlighten me, oh great one.
When will you engineers that code get this? Probably never because engineers only listen to themselves and occasionally other engineers.
Imagine you have two bridge building teams. Both the teams have this magic machine - If you enter the exact specifications of a bridge into the machine it will be built instantly! You can use the machine as many times as you like.
Now, imagine the first team worked like you traditionally do when you design and build a bridge, and only used the magic machine one time at the end of the project, when they where absolutley positively sure their bridge design was correct.
The other team uses the machine all the time. In the beginnig they have lots of errors in their bridge design, but as they build and test several new bridges their design improves.
Now, which team would you guess builds the best and cheapest bridge in the shortest timeframe?
This is where the analogy between bridge/house building and software design utterly fails. There is NO COST OR INCONVENIENCE in building software. Just click compile.
Even if your management knows how to make realistic deadlines and budgets (and, of course, not all do), they won't be able to use them, because all of your company's business would then be lost to a competitor who is over-promising.
For some reason, the managers at my company look at this as an interesting challenge (really! even when not trying to motivate "resources"), whereas I look at it and see endless hopelessness. My guess is that the truth is somewhere in the middle.
This is what "race to the bottom" is all about; all semblance of quality is squeezed out until you are cranking out the cheapest product possible, at razor-thin margins.
We don't polish our prototypes up at all.
However, if we were billing hourly and the customer wanted to stop at the prototype big deal. We're still billing for all the work we've done and we'll move on to the next project.
Normally though, wireframing and prototyping are in or near the discovery phase of a contract so we're guaranteed the entire amount to finish it.
With a clause that says if we go over 20% of the estimated time we'll bill for everything beyond that 20%.
But like you said, you have to educate the customer what the difference is between a prototype and a finished product.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
1. Always get 50% of the money up front.
2. Require a personal guarantee in addition to the companies guarantee that the contract will be paid upon completion.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
This is a public service announcement
The above poster is a posting WHORE, is just plain ugly, and read it. He's a moron! Likes XP? I bet he liked all of those services that are automatically on when you boot up that allow people to send you messages.
LOOOOOOOOOSER.
www.slightlycrewed.com - Because aren't we all?
It's a know-your-newest specifications; to stay in trend with the latest technology...
It's a learning curve, you need to learn the language while working in it, examples do it, tryouts do it, learning the basics of script programming and security (which they do not teach at schools?!?). I am referring to buggy perl scripts that are on the net...
I see the trend "in Dreamweaver you can make a site in a week" thing, so the layout gets made, it gets imported, converted to sleazy html, which could be optimized to html4 in no time.
This makes the people that try to follow the standards look awfull, because the "visuals(1)" are the same but the underlying code is crappy. Dreamweaver outputs code that's sometimes completely off the standards; contains buggy java script code crashing out Firefox -> and it gets mostly delivered like that to the customer.
(1) The visual thing is there - "marketing" would be happy, the customer paid and there-u-go!
Standards are nice to get to, because you are sure it works when it needs to work with full coverage...
Don't shoot the pianist, but pianist, listen to the sheet-of-music u got!
Coding by hand is less fast than using Dreamweaver, but, there are middle-ways like using Dreamweaver as basic and optimizing/tainting/cleaning out the code by hand afterwards ...
Those things take time, if you would need three months for a project it means setup time, work time and ending time; the ending time are te finishing touches a painter does to his painting, the ending of a book and the ending of a movie; just the same with such projects...
A system administrator who wants more system-administration-days
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..