Posted on 04/09/2014 5:11:04 PM PDT by ImJustAnotherOkie
I've been to project meetings and they drive me nuts. People repeating what other people say,
The dead give away was in the title.
How Misperceptions Mean We Almost Always Get It Wrong
.
What is this 'We' kemosabi. Can the author explain the basic principles I stated above?
Then there are some who have negative efficiencies.
Putting together a competent staff larger than two or three quickly becomes problematic.
Plus mission creep.
yep, mission creep, plus on long term projects, technological advances and in some cases, obsoletion…..(is that a word)
Oh, I could tell you stories ...
IT people [I call them Programming Weenies] have absolutely no clue as to what users want or need. They don’t live in the real world.
They take an established piece of software or a program, then put in all these unnecessary bells and whistles because they think it is neato-keen.
At the same time, they remove existing features that the users absolutely want and need - declaring them to be irrelevant. They also take existing features that they are going to keep and then put them in new places, so the users have to hunt-and-find them.
Then, they declare Victory ...
If you’re doing something that’s already been done by the same group it isn’t that hard to estimate time. When it is all a big unknown - that’s what you get for a time estimate... Bugs and/or poor documentation on interfaces to third party modules/sub systems can blow the whole thing up real fast time wise...
When they solve the problem of 90% of “software developers” being either barely able to string code together, or incapable of just “getting the job done”, then I’ll start listening.
Until then, 90% of estimates are crap, 90% of project deadlines are unrealistic, 90% of buzzwordy BS is exactly that, and 90% of “software developers” can keep finding another line of work.
And yes, ultimately we have fired or otherwise ensured the discontinuance of employment for 90% of the developers we’ve hired.
Hence pair programming is as fair as teamwork can really go, heheh.
In all seriousness it's more like 10000x. 10x is more like novice programmer over clueless newbie...
I’m currently working with a full team that believes in this methodology. Aint life grand.
Management.
And, when you point out a bug or flaw in the "New And Improved" software, they smile at you and call it a "Feature" - and then proceed to give you a 23-Step Rube Goldberg type "Workaround" instead of fixing the damn thing ...
I think the biggest factor in under-estimating software projects comes down to people: client expectations, software analyst’ skills in requirements-gathering, availability of business SMEs to help design and test, readability of the program, understanding of business rules and processes, etc. A good project manager has to properly manage the ENTIRE team, including the software development folks, as well as the customer.
Mission/scope creep, constantly changing requirements from the client/business, levels of beauracracy that rival anything the government can throw in your way, and finally, multitudes of clueless, useless, counterproductive management.
I've been on projects where we did detailed interviews and created massive, well-organized and detailed requirements. In most cases when we delivered the software we got a collective: "Huh? This is not what we asked for."
So then we tried the UI sample screens approach where we worked with them to identify what all of the user interface screens would look like, and collected the requirements through interaction with the clients. But then when we delivered the actual software, again we got the "Huh? This isn't what we wanted."
Until the users could actually interact with the application they really didn't grasp what they wanted it to do or how they wanted it to work. I really think it comes down to the fact that very few people are capable of thinking abstractly.
You almost have to build the application from scratch with continuous input from the user community to avoid rework. But of course the user community is already overworked and doesn't have time to spend helping you create the application that may eliminate their jobs.
So you gather enough requirements to get started knowing that whatever you build the first time will look nothing like the final version and you pray that the users will give your application enough time to identify all the missing requirements.
You’ve played this game before, I see.
In my career in IT, the major issues leading to not bringing in a project on time and on budget are:
1. Broad finish dates driven by upper management, often management that is not in IT or does not have an IT background.
2. Failure of management to take the council of experienced IT professionals who do have experience in providing estimates. Often I have seen that given a set of broad requirements and a rough estimate that states “We estimate we can complete this project in x months”, management will state “That’s great. You will need to get this project done in 1/2 that time or 2/3 that time.
3. Poor requirements.
4. Scope creep, which quite often is driven from point 2.
5. Once it becomes obvious a project is in the ditch and will not come in on time, adding inexperienced resources in an attempt to cut the time to deliver. Adding these resources results in time wasted due to training new resources and rework.
I do find that developers often do underestimate the time needed to complete a task, but by the time a project is at the point of individual estimates for specific sets of work, the failure of a project has already been set in motion by factors far above estimates from a developer.
The article is interesting, but seems rather academic and not based upon the realities in business.
In my career in IT, the major issues leading to not bringing in a project on time and on budget are:
1. Broad finish dates driven by upper management, often management that is not in IT or does not have an IT background.
2. Failure of management to take the council of experienced IT professionals who do have experience in providing estimates. Often I have seen that given a set of broad requirements and a rough estimate that states “We estimate we can complete this project in x months”, management will state “That’s great. You will need to get this project done in 1/2 that time or 2/3 that time.
3. Poor requirements.
4. Scope creep, which quite often is driven from point 2.
5. Once it becomes obvious a project is in the ditch and will not come in on time, adding inexperienced resources in an attempt to cut the time to deliver. Adding these resources results in time wasted due to training new resources and rework.
I do find that developers often do underestimate the time needed to complete a task, but by the time a project is at the point of individual estimates for specific sets of work, the failure of a project has already been set in motion by factors far above estimates from a developer.
The article is interesting, but seems rather academic and not based upon the realities in business.
MANAGEMENT will REDUCE the estimate! Winner! Winner! Chicken dinner!
you gotta hire someone good just to spec it out BEFORE you can estimate how long to get it done (and how much)
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.