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...
Welcome to software development projects. That is the reality, software development tasks can't be accurately estimated unless they are trivial. But even trivial tasks may uncover more complicated things and you may end with tasks that take much longer.
In order to try to solve this problem Scrum was invented in requests the tasks to be split into very small tasks (user stories) that are easily manageable. In reality even the user-stories may turn out to be complicated to estimate and splitting the tasks can cause other issues that in turn would make the project to take much longer to complete than expected.
As a PM even if you are a developer or not there is not much you can do about this. Maybe add extra time and don't let developers know about this so that they think the dead-line is sooner. :P
Also if your code ends up with too much technical debt you will see that developers would take again much more time to complete tasks even if the tasks don't look to complicated.
If you are not a developer yourself you will never really understand this things but you can get used with them. :)
...
1 reply by Karrie Dash
Jun 28, 2019 12:46 PM
Karrie Dash
...
What is the best way to determine how much extra time to add? What message do you relay to your clients about the unknown time needed to really complete the project?
Welcome to software development projects. That is the reality, software development tasks can't be accurately estimated unless they are trivial. But even trivial tasks may uncover more complicated things and you may end with tasks that take much longer.
In order to try to solve this problem Scrum was invented in requests the tasks to be split into very small tasks (user stories) that are easily manageable. In reality even the user-stories may turn out to be complicated to estimate and splitting the tasks can cause other issues that in turn would make the project to take much longer to complete than expected.
As a PM even if you are a developer or not there is not much you can do about this. Maybe add extra time and don't let developers know about this so that they think the dead-line is sooner. :P
Also if your code ends up with too much technical debt you will see that developers would take again much more time to complete tasks even if the tasks don't look to complicated.
If you are not a developer yourself you will never really understand this things but you can get used with them. :)
What is the best way to determine how much extra time to add? What message do you relay to your clients about the unknown time needed to really complete the project?
...
1 reply by Adrian Carlogea
Jun 28, 2019 1:33 PM
Adrian Carlogea
...
There is no best way, this is something that you learn from experience.
You always give customers estimates for when the work is going to be completed. If you fail to deliver on time you need to explain the customer that the work was more complicated than it was. If you manage to explain in such a way that he does not loose hope than you are a extraordinary PM. :)
Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
It's difficult to get good estimates on any project. Software development projects are notoriously bad. It's partly because of the "unknowns" that you mentioned, and also because software can be so complex. It's just very difficult to think through everything that needs to be done until you start doing it. This is why so many software organizations have abandoned predictive planning projects in favor of incremental software development. It lets your developers focus on what they can accomplish in short duration iterations and adjust as they learn more.
I would recommend finding a way to use relative estimates, as well. It's very difficult to say exactly how long a certain story/requirement will take to develop, but it's much easier to compare two requirements and decide which one is larger. Don't tie your requirements to a clock or a calendar, just have your team "size" their requirements in relation to one another, and then keep track of how much they can accomplish. After a few iterations, you can start forecasting milestones based on empirical data and improve these estimates with each iteration.
Important: Make sure your team estimates independent of management. Software developers are extremely vulnerable to pressure, and they will tell your stakeholders what they want to hear. If there's a customer or an executive in the room who wants a deliverable in 2 weeks, the team will agree to that deadline even though they know it will take 2 months. Remove the management distractions every time you estimate so they can be honest with themselves. Take it upon yourself to do the math and deliver estimated dates to your stakeholders.
There are a lot of specific techniques to accomplish this if you do some searches.
...
1 reply by Bob Thomas
Jul 26, 2019 12:16 PM
Bob Thomas
...
Wade's "Important" comment is truly important! Management will pressure teams to complete work to the point that the schedule is meaningless. And then the managers complain when the project runs over or the product is buggy.
To this day, I am amazed at tasks that seem small, but are big and others that seem big, but the developer completes them quickly.
Wade makes a great point about keeping the estimates independent of management. I have been literally told "Tell me what you want the estimate to be, and that's what I'll put. The work will take as long as it takes." The PM working as a liaison between the development team and management can be critical to getting realistic estimates, rather than those that keep the negative attention off them while they do their work, until it's clear that those estimates are a fantasy. Saving Changes...
@Wade: yes but no matter all the advises and the "techniques" the software will always be late and with lots of defects. When Microsoft for example lunches a new major update of Windows 10 (every 6 months) disaster strikes. :D They fix the defects but then after 6 months a new major release and we start again. Small iterations (and 6 months for an OS are small) is not always good.
Usually the Management in software development firms is composed of former developers so they know what it is like to have pressure on you but if you don't tell the customer what he wants to hear he/she would not contract you to deliver the software.
This is the biggest problems companies underestimate in order to win contracts if you are honest you may end up in the situation that no one would give you the work. Saving Changes...
What is the best way to determine how much extra time to add? What message do you relay to your clients about the unknown time needed to really complete the project?
There is no best way, this is something that you learn from experience.
You always give customers estimates for when the work is going to be completed. If you fail to deliver on time you need to explain the customer that the work was more complicated than it was. If you manage to explain in such a way that he does not loose hope than you are a extraordinary PM. :) Saving Changes...
We use scrum/agile in the office and for most projects, this works well for everyone, including the clients.
But it is harder to work on the projects where the customer wants to know if we can complete the project in time for the demonstration they have planned at a conference in 6 months. Even if we do release planning and if the unknowns are discovered, the PM needs to be able to communicate to the client if we may or may not be able to complete the project in time for their demo. I very much prefer to tell my clients as soon as I know that something may be delayed or we need to take a different approach as soon as possible. Waiting last minute to deliver bad news when good news has been promised for more than half the project is what I believe makes most customers irate.
...
1 reply by Wade Harshman
Jun 28, 2019 5:09 PM
Wade Harshman
...
You're absolutely right about delivering bad news early.
If you're team is using the scrum framework, are you using stories and story points? If so, you can use a burndown chart to help these discussions with the customer. Your product owner should be able to forecast how much can be completed by a certain date, or conversely, what dates are realistic for a certain amount of work. As with all estimates, they will become more accurate as you get closer to the release (as the hurricane approaches landfall).
Is it perfect? Of course not, estimating never is. This is just one technique, but it's an effective one to use when negotiating with customers.
Adrian, you could pad your estimates to meet deadlines. Many PMs do this in many types of projects, software development included. This gives you some wiggle room with your developers, but it doesn't solve the real problem. The PM will, in effect, lie to their stakeholders and to their teams, and the development team will eventually learn that they always have more time after the deadlines that were originally announced. In the long run, it's better to be honest about your estimates -including your (lack of) confidence in those estimates.
Scrum/Agile does not help, software will still be delivered late. Scrum makes it even worse as developers struggle to keep the velocity high and take shortcuts resulting in technical debt and many bugs. When technical debt becomes hard to manage developers would refactor their code that would take a lot of time.
What you are asking is simply impossible. You can't provide such answers to customers. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
Jun 28, 2019 1:39 PM
Replying to Karrie Dash
...
We use scrum/agile in the office and for most projects, this works well for everyone, including the clients.
But it is harder to work on the projects where the customer wants to know if we can complete the project in time for the demonstration they have planned at a conference in 6 months. Even if we do release planning and if the unknowns are discovered, the PM needs to be able to communicate to the client if we may or may not be able to complete the project in time for their demo. I very much prefer to tell my clients as soon as I know that something may be delayed or we need to take a different approach as soon as possible. Waiting last minute to deliver bad news when good news has been promised for more than half the project is what I believe makes most customers irate.
You're absolutely right about delivering bad news early.
If you're team is using the scrum framework, are you using stories and story points? If so, you can use a burndown chart to help these discussions with the customer. Your product owner should be able to forecast how much can be completed by a certain date, or conversely, what dates are realistic for a certain amount of work. As with all estimates, they will become more accurate as you get closer to the release (as the hurricane approaches landfall).
Is it perfect? Of course not, estimating never is. This is just one technique, but it's an effective one to use when negotiating with customers.
Adrian, you could pad your estimates to meet deadlines. Many PMs do this in many types of projects, software development included. This gives you some wiggle room with your developers, but it doesn't solve the real problem. The PM will, in effect, lie to their stakeholders and to their teams, and the development team will eventually learn that they always have more time after the deadlines that were originally announced. In the long run, it's better to be honest about your estimates -including your (lack of) confidence in those estimates. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Two must read: "The mythical man month" and Barry Bohem´s "Software Economics" in particular the Cone of Uncertainty. All you need to know about software estimation is there. Saving Changes...
