Projects exceed their estimates both in cost and time. Why? Bad estimation would be an initial thought. If you know your estimates will be off by a wide margin is it possible to minimize the range? Common practice dictates to get better estimates which means get the problem broken down to smaller measurable units, estimate each of them, aggregate results and add a magic number to the total estimate. What if instead of trying to get more accurate estimates we focused on getting more predictable work outcomes?
What are the common causes of estimation failure:
Problems in comunication means also that the team is lacking skills, not technical ones but people skills. Once again having lots of newbies will bring a project to it's knees just trying to understand the problem domain, software methodologies and practices, tooling and team inner workings.
Late detection of any issue is perhaps an extension of problems in comunications but there are cases where the hairy stuff really hides. It takes a really good analyst, designer or any other role to be filled in order to find this kind of problems. Which makes my point valid again, you need people who can look at something from various angles, playing various roles and detect any anomaly as fast as possible. It may not be him who solves the problem but first detection is always criticaly timed. Either it is found when there are lots of options to choose from or when there is little that can be done on a reasonable time.
As for unknowns perhaps you are already seeing where I'm going to. Yes, qualified staff is the only real choice. An unknown means that maybe there is no real solution now, but they just may be able to create one from scratch.
Now, the point where I begin to wonder is: what does it mean to be qualified? It does not mean to have a masters degree or PhD in computer science, even a bachellors degree is not what I mean. I belive being qualified to fill a role means being able to tackle the challenges required by that role, known and unkwnown. Who is able to do that? The ones that are good thinking on their feet. The ones that like the role and keep updating themselves, finding new techniques, tools and not sitting on their ivory towers regurgitating whatever was cannon knowledge 10 years ago.
I really don't have a clear conclussion to this train of thought but I fear that software houses here in my country are not striving to have more cappable engineers but instead they are contempt with just more 'engineers'. I will confess that I have not read 'The mithical man month' but it seems that neither did them and they haven't even heard about it yet.
Disclaimer: I'm no SCRUM expert nor project manager, this are my views and attempts to get this problem fixed. Perhaps I am reinventing the wheel but this is my take on this.
Some afterthoughts.
Training does not equate to capability
Projects need cost reduction.
I say: bite the bullet. Raise quality engineers to decrease project risks and scheduling blowups.
What are the common causes of estimation failure:
- Difficult problem to solve / Too big problem to solve
- Problems in comunication
- Late detection of inconsistencies
- Underqualified staff
- Unknown.
Problems in comunication means also that the team is lacking skills, not technical ones but people skills. Once again having lots of newbies will bring a project to it's knees just trying to understand the problem domain, software methodologies and practices, tooling and team inner workings.
Late detection of any issue is perhaps an extension of problems in comunications but there are cases where the hairy stuff really hides. It takes a really good analyst, designer or any other role to be filled in order to find this kind of problems. Which makes my point valid again, you need people who can look at something from various angles, playing various roles and detect any anomaly as fast as possible. It may not be him who solves the problem but first detection is always criticaly timed. Either it is found when there are lots of options to choose from or when there is little that can be done on a reasonable time.
As for unknowns perhaps you are already seeing where I'm going to. Yes, qualified staff is the only real choice. An unknown means that maybe there is no real solution now, but they just may be able to create one from scratch.
Now, the point where I begin to wonder is: what does it mean to be qualified? It does not mean to have a masters degree or PhD in computer science, even a bachellors degree is not what I mean. I belive being qualified to fill a role means being able to tackle the challenges required by that role, known and unkwnown. Who is able to do that? The ones that are good thinking on their feet. The ones that like the role and keep updating themselves, finding new techniques, tools and not sitting on their ivory towers regurgitating whatever was cannon knowledge 10 years ago.
I really don't have a clear conclussion to this train of thought but I fear that software houses here in my country are not striving to have more cappable engineers but instead they are contempt with just more 'engineers'. I will confess that I have not read 'The mithical man month' but it seems that neither did them and they haven't even heard about it yet.
Disclaimer: I'm no SCRUM expert nor project manager, this are my views and attempts to get this problem fixed. Perhaps I am reinventing the wheel but this is my take on this.
Some afterthoughts.
Training does not equate to capability
Projects need cost reduction.
I say: bite the bullet. Raise quality engineers to decrease project risks and scheduling blowups.