September 1, 2015 at 11:12 am
For example, a defendent doesn't tell an attorney how go about building his defense (generally speaking), and a patient doesn't tell a physician how many stitches they expect to see after the surgery. The outcomes in the area of legal defense and medicine are standardized.
Just my two cents, but this points to a defect in client management. A strong project manager, business analyst and systems analyst should be able to nail down those requirements in a neat and organized fashion. Proposed deviations from the plan must be managed, such as "hey, that's a great idea, we'll put that on the parking lot for the next version" or "sure, no problem, that'll just be XXXX more money" as a scope change.
It's not something that comes natural to us as technologists, but it is certainly possible to reign in the client so that they both have a positive experience and get what they asked for. New learning is bound to happen during the project, so stay nimble and budget on smaller sprints or other agile-esque approach so that the client feels in the loop.
Thanks for reading.
Tim McKay
September 1, 2015 at 11:45 am
Steve Jones - SSC Editor (9/1/2015)
Yes, very true. We need to deal with it. I think we also need to set better expectations, as well as perform better.We do ask lots of questions. The problem is the answers aren't often known, or revealed.
I agree. It is when the answers aren't known or revealed then we have to determine a range based on our assumptions in order to help provide an estimate.
This is why a risk assessment is helpful.
If the business is just trying to determine should they even pursue something there are multiple approaches.
You can have the business problem presented and then have people go off and estimate based on a lot of missing information.
You can also have the business tell you what they are willing to invest in having the problem solved. For example. the business is willing to invest 4 weeks of the teams time to make "X" happen. Does the team think they can do it?
In both cases you still have all of the same questions, but depending on the project duration and scope sometimes one approach reaches that high level business answer much quicker.
An estimate is a conversation that we want to lead us to a shared understanding. Part of that conversation should include that an estimate is a ultimately a guess based on what we know.
If one side is not comfortable with the estimate those areas of unease can be further explored to resolve questions and provide better estimates.
I find it very helpful to not only list out what is included in an estimate, any known assumptions, and also call out items that we specifically discussed but are not included in an estimate.
Ultimately, we have to execute on what we said we would do.
You can start getting crazy inflated estimates if a team, through experience, finds that whatever they estimate is going to be the exact number or they do not typically get any useful details on a project.
September 1, 2015 at 11:55 am
tim.mckay (9/1/2015)
Just my two cents, but this points to a defect in client management. A strong project manager, business analyst and systems analyst should be able to nail down those requirements in a neat and organized fashion.
Maybe, but clients aren't always simple or easy to deal with. Ultimately, they pay the bills or sign the checks and you can't always force logic or reason on them.
However certainly many PMs don't do a good job of managing either side well.
September 1, 2015 at 12:03 pm
Again, is there any data to back up any of these statements about programmers, doctors, lawyers, etc?
412-977-3526 call/text
September 1, 2015 at 12:21 pm
robert.sterbal 56890 (9/1/2015)
Again, is there any data to back up any of these statements about programmers, doctors, lawyers, etc?
To backup which statements? That estimates are bad?
You should be able to do some google searching and pull some data into power query to answer any specific question you have.
September 1, 2015 at 12:30 pm
I'm asking for the experience of the group.
Here are the search results:
http://programmers.stackexchange.com/questions/16326/how-to-learn-to-make-better-estimates
http://www.entrepreneur.com/article/58326
http://pcaobus.org/Standards/Auditing/Pages/AU342.aspx
412-977-3526 call/text
September 1, 2015 at 12:43 pm
If I have to paint an 8ft x 16ft wall then I can tell you with a fair degree of accuracy how long it will take having painted several such walls in my life.
I've rarely had development projects with much similarity between each other so the estimates are SWAG estimates. Speculative Wild *** Guess.
I've found that IT tends to be to timid in managing its own affairs which leads the business to force decisions on IT that it doesn't have the expertise to do so. How many times have you heard the phrase "we are waiting for a decision"?
The approach I try and take is as follows:-
You would be amazed how often this works. Of course you have to accept responsibility for the results but if you are the subject matter expert perhaps you should!
September 1, 2015 at 1:01 pm
Steve Jones - SSC Editor (9/1/2015)
xsevensinzx (9/1/2015)
I'm not really seeing the connection between the first linked stories in the first paragraph.A solution--which is what the doctor is aiming to apply--is totally different than the benefit from the solution, which is the process of feeling better.
Maybe, but there are lots of medical issues where the doctors don't know. They try one thing and then another. Especially when you have joint issues, skin fungi, and plenty of other issues.
Don't compare a shot to building software. A shot is like setting up SQL Server or IIS. I can tell you how long that will take. The process of diagnosis and therapy often is open ended, with doctors being unsure of outcomes.
I just went through something like this with a friend. A broken bone in a finger, and the estimates by the doctor of healing time and treatment were off by over a factor of 100%.
I hear what you're saying and I am nitpicking here for good reason I hope. I still look at these as apples and oranges because depending on the product, service or simply a solution must satisfy a need.
If those needs are identified ahead of time, then they can help you estimate what you need to do in order to satisfy those needs. If those needs are unknown and could change down the road, then iterative processes like being able to deploy major versions, updates and hotfixes (v0.0.0) can be factored in the original solution way before the product, service or solution goes to market.
Thus, the product, service or solution is always pretty straight forward. Managing the long-term, changing and unknown benefits of what you created (i.e.: the open ended) happens way after the original estimates have happened.
September 8, 2015 at 2:30 pm
Knut Boehnert (9/1/2015)
The trouble with being a developer and estimates is that estimates tend to be wrong. As a developer I do not want to be wrong.I want to get it right, first time and every time.
That plus most managers often taking an estimate and hew the date/time in stone makes a developer more than reluctant.
Learning when it is ok to fail is a wonderful experience for developers. Especially on something easy like estimates.
It does not hurt to get better in estimation and it is a skill like every other one. Experience and practice will hone it.
And to do about managers? Either a list of 25 points of pre-requisites attached to the estimate (most will never read it) or some sort of blunt instrument in reach will help with 99% of all the "But you said...".
Well said.
December 7, 2015 at 4:52 am
It seems to me that the established professions either have a more rigorous framework for estimation and change control (e.g. construction) or have expectations of the unknown accepted in advance (e.g. legal and medical).
We have plenty of the unknowns and lack of control of the scenario yet are expected to have the accuracy of the more rigorous working conditions.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 11, 2015 at 8:17 am
Gary Varga (12/7/2015)
It seems to me that the established professions either have a more rigorous framework for estimation and change control (e.g. construction) or have expectations of the unknown accepted in advance (e.g. legal and medical).We have plenty of the unknowns and lack of control of the scenario yet are expected to have the accuracy of the more rigorous working conditions.
I think we have some parts of our industry with this. The group that writes space shuttle software, some medical software companies, etc. They worry about testing and ensuring they have rigorous methods for handling issues. Certainly embedded programmers do better here. Not perfect, but then again, plenty of construction/mechanical/electrical/etc engineers aren't perfect either.
December 11, 2015 at 8:32 am
xsevensinzx (9/1/2015)
I'm not really seeing the connection between the first linked stories in the first paragraph.A solution--which is what the doctor is aiming to apply--is totally different than the benefit from the solution, which is the process of feeling better.
The doctor should know some pretty good exacts on how long it takes to do surgery, to apply a shot and so forth. This is because the doctor has done this a million times before and the results are almost always the same. When I say results, I'm not referring to the benefit of feeling better, but the results of the solution being applied.
The feeling better though, could differ from patient-to-patient. As you may here from cancer treatments, not every case is the same. Everyone is different and thus customized treatments are needed. The knowledge of those treatments in regards to time and resources is pretty exact. The reaction from the patient is not so exact.
That being said.
Using the above examples. If you do something long enough that includes the same approaches, then you can get better at estimating time and resources. If the solution is unpredictable, many changing variables and so forth, then yes, it's going to be difficult to do those estimates.
But, you can't compare those to exact solutions that never change. As a developer, I try to fit people into exacts to help better understand estimates.
I love your optimism. I have yet in my 20+ years received a request to automate an end-to-end process that *never changes*. There's always something that has to be reviewed, overridden, redirected, poked, prodded, etc.... One of the most constant items I've found in my estimates is baking in that ability to change the textbook process, just to handle all of those cases that "didn't read the textbook".
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 21, 2016 at 11:42 pm
I m facing to manage documents & records web content for long time,Shamrock Solution Helped helped me when i was in Problem.
September 26, 2016 at 11:56 pm
Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.:cool:
October 6, 2016 at 1:06 am
It's all about software estimates 😉
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply