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?
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?
-