What are some of your best tips/recommendations to ensure that you properly plan enough time when developing software?
The biggest issue I've run into is having "known-unknowns". At the start of a new project (either no code developed or revising someone else's code), developers do not know exactly how long it might take to implement a requirement. It could be as early as 2 weeks, potentially 4 weeks, or maybe 6 weeks if things are much more difficult than expected. There have been times even the most pessimistic estimate was not enough.
Once the team is comfortable with the code and understands how everything is connected, they are able to provide more accurate estimates. But the learning curve can be very difficult to plan appropriately for the PM. Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Karrie,
I have spent almost four decades of my life dealing with estimations in software development, and find it more of an art than a science. Here are some truths I have put together on this subject:
- Creating an estimate from ambiguous requirements creates exposure not easily rescinded.
- The more time you spend contemplating an estimate, the shorter it gets.
- Application Architecture, Design or Development without Visualization leads to functional impairment.
- Any approach absent of theory finds its basis leveled when openly challenged.
- Metaphorically injecting oneself into a life-cycle, awakens knowledge.
Creating a good estimate requires "architectural awareness" (i.e., AA) in both the business and technical delivery domains. An individual who properly leverages AA will have the ability to challenge-out from another, or personally delivery a qualified estimate, let alone deliver what is being asked for.
The truths above (along with others) all tie together as a strategic approach for getting higher quality estimates and deliverables. However, to start, I would recommend that you require the developers to architecturally visualize the work-areas they are estimating, which would include representing the relevant life-cycles. When properly done, the visualization will have varying constructs of interconnected layers and components, each of which should have an estimate assigned which can simply be added up and then multiplied by an increase factor of your choice.
Although an art form, that which can be visualized is then open to being challenged, and anything that is challenged in the site of many has an increased opportunity to sustain and prove out.
Food for thought. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Certainly an art more than a science, and even still, can't always expect it all within the lines. Saving Changes...
Talking about art, while software is not a work of art writing it to some extent is. Developers, especially when they are working on complex code, need inspiration which many times simply does not come immediately.
I would say that the similitude between art and making software is the main reason you can't accurately estimate the completion of software parts.
Also many times developers work on a peace of code just to discover that what they wrote does not work for all cases and changing the code they have written so far is too complicated. Good time for a rewrite from scratch :D.
As a PM you should focus less on trying to improve the accuracy of estimates and instead focus on explanation to the customer why the software is late.
I have been involved in many software projects and they are always late, no matter what you do.
What's funny is that even if everybody knows that you can't accurately estimate software completion everybody wants plans and estimates. As a software development PM you write planning documents although you know that most likely they are not realistic but you have to do it anyway.
...
1 reply by George Freeman
Jun 30, 2019 12:34 AM
George Freeman
...
Adrian,
As Andrew elegantly pointed out, you can’t always expect estimation to be within the lines on any given approach, but that doesn’t stop a good developer, analyst, technical lead or project manager from doing everything possible to improve estimating techniques and approaches as they progress on a given project or in their career.
Your statement that a project manager should "focus on explaining to the customer why the software is late, versus spending much time on improving the accuracy of estimates," is contrary to principles of quality that is part of all of our roles (developers, leads, analyst, PM’s, etc.). Should a PM be involved in the low-level estimating process, absolutely not. However, the project manager has a responsibility to fine-tune approaches (through having or leveraging expert opinion) to meet the objectives of the project, and that includes the realm of estimating.
We all recognize the difficulties in estimating the development of software, but should these difficulties discourage us from executing all reasonable due-diligence in the estimating process. Shouldn’t we seek out advice from experts and constantly improve the process or should we just say, "everybody knows that you can’t accurately estimate software completion", therefore - why try.
I don’t know one developer who likes making estimations - I get it. However, we should recognize that none of us would have jobs without the process we know as estimating. If projects ran on a “true blank check” (i.e., no structure, planning or estimating) then you have it, no estimations are necessary. But that does not happen, therefore we accept this need and work hard on improving it – hopefully in collaborative ways.
Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Jun 29, 2019 9:59 PM
Replying to Adrian Carlogea
...
Talking about art, while software is not a work of art writing it to some extent is. Developers, especially when they are working on complex code, need inspiration which many times simply does not come immediately.
I would say that the similitude between art and making software is the main reason you can't accurately estimate the completion of software parts.
Also many times developers work on a peace of code just to discover that what they wrote does not work for all cases and changing the code they have written so far is too complicated. Good time for a rewrite from scratch :D.
As a PM you should focus less on trying to improve the accuracy of estimates and instead focus on explanation to the customer why the software is late.
I have been involved in many software projects and they are always late, no matter what you do.
What's funny is that even if everybody knows that you can't accurately estimate software completion everybody wants plans and estimates. As a software development PM you write planning documents although you know that most likely they are not realistic but you have to do it anyway.
Adrian,
As Andrew elegantly pointed out, you can’t always expect estimation to be within the lines on any given approach, but that doesn’t stop a good developer, analyst, technical lead or project manager from doing everything possible to improve estimating techniques and approaches as they progress on a given project or in their career.
Your statement that a project manager should "focus on explaining to the customer why the software is late, versus spending much time on improving the accuracy of estimates," is contrary to principles of quality that is part of all of our roles (developers, leads, analyst, PM’s, etc.). Should a PM be involved in the low-level estimating process, absolutely not. However, the project manager has a responsibility to fine-tune approaches (through having or leveraging expert opinion) to meet the objectives of the project, and that includes the realm of estimating.
We all recognize the difficulties in estimating the development of software, but should these difficulties discourage us from executing all reasonable due-diligence in the estimating process. Shouldn’t we seek out advice from experts and constantly improve the process or should we just say, "everybody knows that you can’t accurately estimate software completion", therefore - why try.
I don’t know one developer who likes making estimations - I get it. However, we should recognize that none of us would have jobs without the process we know as estimating. If projects ran on a “true blank check” (i.e., no structure, planning or estimating) then you have it, no estimations are necessary. But that does not happen, therefore we accept this need and work hard on improving it – hopefully in collaborative ways.
...
1 reply by Adrian Carlogea
Jun 30, 2019 9:38 AM
Adrian Carlogea
...
Hi George,
I did not say that PMs, developers, etc should quit completely on trying to make good estimates, all I said is that they should not put a large amount of effort into this activity as the chances of success are small.
I had once an interview and the hiring manager asked me what would I do if I am close to a dead-line and find out that there is no chance to deliver on time. I told him that I would work harder with the team, even extra-hours to try to complete on time. He insisted that the assumption in his question was that I would never finish on time.
This was the most important question he had and I failed it with my answer. Then he told me the right answer is that you must have a very good relationship with the customer and be transparent in communication. As long as the customer knows you are doing your best effort and you are very helpful with them they would accept delays much better and they would give you extra time to finish.
It is all about people's skill and good stakeholder management. This does not mean that you should give up completely on producing good estimates it simply means that you should consider other activities more important for the success of the project.
As Andrew elegantly pointed out, you can’t always expect estimation to be within the lines on any given approach, but that doesn’t stop a good developer, analyst, technical lead or project manager from doing everything possible to improve estimating techniques and approaches as they progress on a given project or in their career.
Your statement that a project manager should "focus on explaining to the customer why the software is late, versus spending much time on improving the accuracy of estimates," is contrary to principles of quality that is part of all of our roles (developers, leads, analyst, PM’s, etc.). Should a PM be involved in the low-level estimating process, absolutely not. However, the project manager has a responsibility to fine-tune approaches (through having or leveraging expert opinion) to meet the objectives of the project, and that includes the realm of estimating.
We all recognize the difficulties in estimating the development of software, but should these difficulties discourage us from executing all reasonable due-diligence in the estimating process. Shouldn’t we seek out advice from experts and constantly improve the process or should we just say, "everybody knows that you can’t accurately estimate software completion", therefore - why try.
I don’t know one developer who likes making estimations - I get it. However, we should recognize that none of us would have jobs without the process we know as estimating. If projects ran on a “true blank check” (i.e., no structure, planning or estimating) then you have it, no estimations are necessary. But that does not happen, therefore we accept this need and work hard on improving it – hopefully in collaborative ways.
Hi George,
I did not say that PMs, developers, etc should quit completely on trying to make good estimates, all I said is that they should not put a large amount of effort into this activity as the chances of success are small.
I had once an interview and the hiring manager asked me what would I do if I am close to a dead-line and find out that there is no chance to deliver on time. I told him that I would work harder with the team, even extra-hours to try to complete on time. He insisted that the assumption in his question was that I would never finish on time.
This was the most important question he had and I failed it with my answer. Then he told me the right answer is that you must have a very good relationship with the customer and be transparent in communication. As long as the customer knows you are doing your best effort and you are very helpful with them they would accept delays much better and they would give you extra time to finish.
It is all about people's skill and good stakeholder management. This does not mean that you should give up completely on producing good estimates it simply means that you should consider other activities more important for the success of the project.
...
1 reply by George Freeman
Jun 30, 2019 9:58 AM
George Freeman
...
Hi Adrian,
Thank you for your response! Great advice - well stated and right on target.
Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Jun 30, 2019 9:38 AM
Replying to Adrian Carlogea
...
Hi George,
I did not say that PMs, developers, etc should quit completely on trying to make good estimates, all I said is that they should not put a large amount of effort into this activity as the chances of success are small.
I had once an interview and the hiring manager asked me what would I do if I am close to a dead-line and find out that there is no chance to deliver on time. I told him that I would work harder with the team, even extra-hours to try to complete on time. He insisted that the assumption in his question was that I would never finish on time.
This was the most important question he had and I failed it with my answer. Then he told me the right answer is that you must have a very good relationship with the customer and be transparent in communication. As long as the customer knows you are doing your best effort and you are very helpful with them they would accept delays much better and they would give you extra time to finish.
It is all about people's skill and good stakeholder management. This does not mean that you should give up completely on producing good estimates it simply means that you should consider other activities more important for the success of the project.
Hi Adrian,
Thank you for your response! Great advice - well stated and right on target. Saving Changes...
Interesting discussion, no comments following from a distance, thanks for bringing up this topic! Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Definitely, transparency plays a significant role here. Set expectations, align on the definition of what estimates are, include a ROM, and remain transparent with the client. As more is learned, better able to refine. Additionally, as we learn more, it can help in future efforts. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
Also, I know most people here will hate this answer, but there is a #NoEstimates movement in software development.
There are plenty of resources out there if you search for it. I won't pretend to be a master of No-Estimates techniques, but I've been on a team that practiced this. It was liberating to acknowledge that estimates are usually wrong and instead focus on writing good code. As a PM, the challenge is the same: maintaining good relationships and trust with your stakeholders and sponsors. Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Interesting subject – and wearing my enterprise hat:
If I take the viewpoint that “No Estimates” refers to the non-estimating-action of the hands-on software development team, then I would say that is appropriate in many environments and is something that I have practiced. However, it is caveated by the existence of a proven architect who has done all appropriate due-diligence, coupled with patterned “tribal-knowledge” of similar projects by leadership.
In other words, we can free the software development team from the burden (practical and psychological) of doing estimations, but that does not mean that they are free from accountability structures related to their development efforts.
Although I have briefly heard about the #NoEstimates movement, I haven’t given it much strategic thought as I have always largely discounted individual developers estimates in light of a proven architect’s opinion – as one cannot give much credence to estimates that are not presented in life-cycle terms. Saving Changes...
