75% of sw projects miss target date, Why?
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
In my experience, this almost always occurs because management (and sometimes programmers) don't feel the need to properly scope out the design and integration tasks required to implement features. Management usually expects programmers to come up with time estimates after the functional spec is signed off. This is because most managers think building a software product is like baking a cake. If you know what the cake should contain and how big it should be, you should be able to accurately estimate the preparation time, given the requirements. Unfortunately (or fortunately), developing software is not the same as baking cakes. Every cake we make is different. Only one of my 5 jobs (in the last 17 years) has followed the proper procedure. I believe it had to do with the fact that the VP of engineering had more than 20 years of software management experience behind him. Having an MS in EE/CS didn't hurt either - he *knew* what was involved in the software development process. We followed many XP rules and were amazingly successful in meeting our release dates. Sadly, my current job leaves a lot to be desired... X| /ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com
-
So let me ask, how do you mange feature creep since you seem to be part of the $25:-D. Regarding setting target dates before the requirements have been completed, how does one actually determine, given a set of requirements, how long a project is going to take? Alternatively, given a time frame, how does one determine what can or can't be done? Since this is a problem that we all have, would be interested in any potential solutions or best practices.
The reasons my team has been successful: 1) Collectively the team is good at ball parking how long a project will take (i.e. we also take into account the external factors that reduce actual development time to 50% or less of actual work time). 2) We have a *VERY* good manager who can take out ball parks and further adjust the target date taking into consideration factors we may not be priveledged to know, and for the idiosynchrasies of individuals on the team (for instance, my own estimates usually run a little high as I expect the worst, while a colleagues estimates run a little low since he's not as good at figuring in the external factors). 3) We've almost always been allowed to set the target date, at least within reason. The few times that the date has been set for us I guess we were "lucky" that we were able to finish on time... but see the next point. 4) When required we've been willing and able to work a *LOT* of extra hours to meet a deadline. 5) In general, the team I'm on has the right mix of talents to be able to pull off "miracles". In other words, I'm not sure that any of us could be as successful if we were on another team. If you're looking for more concrete solutions, don't look at us ;). However, there are a lot of books on this topic, and the XP process tries to address some of the problems discussed here. William E. Kempf
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
You get what you pay for. Everyones trying to make money, trying to see how close to the bone they can go, with complex development, with changing requirements, and a wide variety of talent (programmers, and managers on both sides). Following a strict procedure generally works well (our current project is like this) but is expensive (getting customer signoff, testing signoff at various points). A couple of projects ago we had hardly no process but got it done on time as well - this gave the client a lot more functionality at a reduced cost but was HIGH risk/ lucky.
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
For me, the problem is two-fold: I am ridiculously optimistic, and have a bad tendency to continually re-design everything as I implement it. Because of the first (which may have more to do with lack of experience than general temperament), I will always give a lowball estimate of the time required to complete even the simplest of tasks. Because of the second, something starting out as a quick and simple implementation will grow quickly into a confusing monolith. I have to consciously force myself to move on in a project, or I will stall short of completion. Once again, this may be mostly due to lack of experience. And if words were wisdom, I'd be talking even more.
The Offspring, I Choose
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
Poor planning, and only poor planning. Any good plan should allow for a certain amount of feature creep, unexpected problems, and for uninterupted funding (bar some extreme unforseen event). ________________ David Wulff http://www.davidwulff.co.uk Sonork ID: 100.9977 Dave …
-
I don't think it's too bad. Software development is very special: you can add features on the fly, and this is what developers often do (not to defend lack of design, but I don't believe that a software project where everything is specified before coding starts will have high quality). Imagine airplane manufacturer changing specs while they go? (Or even improving the plane without a spec, becuase of "obivous" improvements). Yes, we often delay our projects, but we often come up with much better systems than originally planned. Vagif Abilov COM+/ATL/MFC Developer Oslo, Norway
Well, I would have to disagree somewhat. While change is always part of software development it has to be managed. Unfortunately, my experiences have been with large software companies where we tend to get killed (in the market) if a software product is not released on time (i.e sales has set a certain expectation, competitors are also upgrading their products and get to the market before us, etc) For internal projects, it probably doesn't matter quite as much. With that said, I'm still looking for best practices in managing feature creep and mis management. I have some ideas, but still thinking about it.
-
So let me ask, how do you mange feature creep since you seem to be part of the $25:-D. Regarding setting target dates before the requirements have been completed, how does one actually determine, given a set of requirements, how long a project is going to take? Alternatively, given a time frame, how does one determine what can or can't be done? Since this is a problem that we all have, would be interested in any potential solutions or best practices.
You don't set target dates before requirements are known, period. Management will tell you it's just for 'planning' purposes, but as soon as you give them a swag it will be cast in stone. My projects were usually mixed hardware and software design tasks. Requirements analysis and definition came first, and change control was enforced. Each module, hardware or software, had an interface control document that could not be changed without all affected signing off. Tedious, but effective. Feature creep was allowable, but only if it came with money and schedule relief. Developers should be left alone to develop - as project manager it was my job to protect them from administrative bullshirt and intercept the annoyances that would interfere with them. No fun, but that's how you earn the title and perks. Give the team clear, immutable requirements, keep the imbeciles out of their way, and you'll get a clean product on time, within budget (assuming you know when to shoot the engineers yourself, and move to production).
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
That's an easy one to understand... but not to fix. Here's a nice example: 1) Customer and Sales department meet to discuss project. 2) Some kind of technical sales person draws up a proposal. These proposals are "usually" fairly short, couple pages that kind of outlines what was discussed... an extraordinarily loose set of requirements for the project. 3) Often times at this point the development company is in competition with other companies for the contract. 4) Estimates are drawn up to go after the business. Here's the fatal flaw. We have a really good technical guy here that uses his 15-20 years of experience in our field (even though programming wise he's way out of date now for current technologies), sophisticated estimation tools, project tracking of projects done for the customer before and/or projects very similar to the one being requested, and his magic Eight ball to come up with an estimate that should make the company money, meet the customers budget, and beat out the other companies for the contract. 5) This estimate is accepted by the customer so we proceed with requirements. "Ohhhhhhhhh. THAT'S what you want. Ohhhhhhhhhh. You mean it has to be a web application, not web-enabled. Ohhhhhhhhhhhhh. You want it to do that too? You never mentioned that. Dude (technical guy), you estimated it would only take me 3 days to write my own embedded XML Parser from scratch?!?!??"... etc. etc. etc. 6) Requirements are completed and an engineering estimate (a re-estimate) is done. This estimate shows that the original estimate was off by about 45% but the customer won't allow the dates to slip and the company (trying to deal with the recession) doesn't have the manpower to add enough resources to make the dates and/or the problem just can't be broken down into enough pieces that adding more resources would actually help the situation. Anyway, the key (I think) is to break up big projects into two main projects, a requirements spec, and the project. That way the requirements can be solidified up front and signed off on by the customer. Then the project lead can get involved to create a "sound" estimate from the beginning. Now, this assumes: 1) Your project lead has alot of experience in estimating. 2) The customer is quick to respond to questions. 3) You have the right mix of people: personalities and expertise. 4) There aren't too many external dependencies. Good luck, Matt
-
I'm no expert but some recommended reading. Debugging the development process by Steve Maguire. Peopleware Rapid Development by Steve McConnel Have a look at this site, http://www.joelonsoftware.com/navLinks/fog0000000247.html. It's got a lot of good information and links. Michael :-)
hey Michael, just a thought. So if mis-management around of variety of things seems to be the problem, what if there was a defined (sw delivery) process where everyone in the organization knows what is to be expected. In other words, for a given milestone if you will, what are the documents expected to be delivered as well as an established milestone exit criteria. If the criteria is not met and management moves on to the next phase at least you can document that this part of the process was not complete and therefore part of the cause these problems. Nothing better than showing management what caused the problem. Just a thought
-
You don't set target dates before requirements are known, period. Management will tell you it's just for 'planning' purposes, but as soon as you give them a swag it will be cast in stone. My projects were usually mixed hardware and software design tasks. Requirements analysis and definition came first, and change control was enforced. Each module, hardware or software, had an interface control document that could not be changed without all affected signing off. Tedious, but effective. Feature creep was allowable, but only if it came with money and schedule relief. Developers should be left alone to develop - as project manager it was my job to protect them from administrative bullshirt and intercept the annoyances that would interfere with them. No fun, but that's how you earn the title and perks. Give the team clear, immutable requirements, keep the imbeciles out of their way, and you'll get a clean product on time, within budget (assuming you know when to shoot the engineers yourself, and move to production).
But when you bid a contract, they tend not to like a delivery date of 'whenever'. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
Because the initial estimate wasn't worth the paper it was written on. I hate to say it - but I think the average person is likely to way underestimate the ammount of time it requires to do something. Then you add to that the requirements are usually very incomplete - and it gets even worse. Dale Thompson
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
Simple. It is because 75% of all projects are done in VB or Java. :-D "There's a slew of slip 'twixt cup and lip"
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
Oh, and also because there is a slew of slip 'twixt cup and lip. (Meaning: A lot of unexpected stuff can go wrong while trying to accomplish what you said you could do.) "There's a slew of slip 'twixt cup and lip"
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
-
Would be interested in knowing what you believe is the reason for most projects to miss their target date. Feature creep, unrealistic expectations, etc. Inquiring minds want to know. What problems have you encounted to make a project go way off base?
-
hey Michael, just a thought. So if mis-management around of variety of things seems to be the problem, what if there was a defined (sw delivery) process where everyone in the organization knows what is to be expected. In other words, for a given milestone if you will, what are the documents expected to be delivered as well as an established milestone exit criteria. If the criteria is not met and management moves on to the next phase at least you can document that this part of the process was not complete and therefore part of the cause these problems. Nothing better than showing management what caused the problem. Just a thought
No process can overcome bad management. It does help to have a defined process to give guidelines. But defining what documents should be delivered at what stage of the software project does not solve the more basic problems of requirement gathering. Every project has to define if all needed requirements are known, to give them priorities and plan the releases I am a signature virus! Help me spread and copy me to your sig! Ooops I am infected
-
But when you bid a contract, they tend not to like a delivery date of 'whenever'. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
True enough, but I'm not familiar with consulting... There's got to be some way to lock down the change requests or you're doomed from the start.
-
No process can overcome bad management. It does help to have a defined process to give guidelines. But defining what documents should be delivered at what stage of the software project does not solve the more basic problems of requirement gathering. Every project has to define if all needed requirements are known, to give them priorities and plan the releases I am a signature virus! Help me spread and copy me to your sig! Ooops I am infected
I agree, however what seems to be lacking is a process for requirements gathering as well. Here are the steps, documents, use cases, what ever the company needs in order to properly define requirements. I have worked for several companies that 1) either did not have an understanding of what requirements gathering is 2) had a process but because it was in some binder somewhere, no one followed. I'm suggesting this as a visibility tool into the process, but also help to determine what mistakes were made( i.e. missing steps in the req process). Once mistakes are learned you could subsequently add them to the process there by ensuring that its not missed for the next project.
-
Poor planning, and only poor planning. Any good plan should allow for a certain amount of feature creep, unexpected problems, and for uninterupted funding (bar some extreme unforseen event). ________________ David Wulff http://www.davidwulff.co.uk Sonork ID: 100.9977 Dave …
David Wulff wrote: Any good plan should allow for a certain amount of feature creep, unexpected problems, Very true David ! Regardz Colin J Davies
Sonork ID 100.9197:Colin Logic merely enables one to be wrong with authority. -- Doctor Who :jig: :jig: :jig:
:jig: :jig: :jig: -
True enough, but I'm not familiar with consulting... There's got to be some way to lock down the change requests or you're doomed from the start.
Actually, change requests are usually written into the contract. And you get to charge money for that. Lots of money. But for an assortment of reasons, the numbers submitted might not be realistic. Poor understanding of the spec. Lowballing the contract to get it. etc... Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?