Wow, so much of this articles applies flawlessly to the software engineering field. This is frustratingly common. The PO/PM identify new/changed features and put the work on the roadmap. They ask...
Wow, so much of this articles applies flawlessly to the software engineering field.
The tremendous schedule delays and cost overruns ... were also a result of “excessive optimism”
This is frustratingly common. The PO/PM identify new/changed features and put the work on the roadmap. They ask how long it will take, receive non-committal or vague answers back from the engineers, decide on how long they think it should take, and then tell upper management the date that it will all be done. Estimating effort is a very difficult task, even for experienced engineers, and many aren't very good at it at all (I'm not). This PO/PM-driven time frame rarely takes into account the time to test and deploy the changes; their definition of "done" is whatever they can successfully sell to upper management as a milestone victory to get promoted out of the team that now hates them. Failure to deliver can certainly be the fault of the development team, and I've seen that as well - engineers approach a problem without sufficient planning or customer research, and halfway to the deadline, find out that their entire approach is faulty.
It's just my experience that more often, it's the PM team.
Particularly, project managers are “overly optimistic” about how much effort developing and testing new technology will take
In my case what they told me was double your estimate and take to the next order of magnitude lol (so 1 day -> 2 weeks, 1 week -> 2 months, 1 month -> 2 years). Especially if it is a team working...
In my case what they told me was double your estimate and take to the next order of magnitude lol (so 1 day -> 2 weeks, 1 week -> 2 months, 1 month -> 2 years). Especially if it is a team working in different parts of the project.
If you were an engineer, how would you remedy this? I work on the product side, and we develop our effort estimates together with our dev teams, acknowledging up front that the figures aren’t...
If you were an engineer, how would you remedy this? I work on the product side, and we develop our effort estimates together with our dev teams, acknowledging up front that the figures aren’t perfect. We developed this process having already gone together through the hell you so aptly describe, none of us wanting to continue that cycle - from the execs to the PO, PM, engineers, and analysts. Would love to hear thoughts on other approaches.
Sure, thanks for replying. I've thought about this for the past couple hours, and I think I have down what I want to answer with. I think there are 3 things that can help everyone involved:...
Sure, thanks for replying.
I've thought about this for the past couple hours, and I think I have down what I want to answer with. I think there are 3 things that can help everyone involved:
Experience
As I and several people have pointed out, proper estimation is a skill, and something that developers are often not good at (I'm not - I tend to underestimate). A team who has more experience working together will not only work faster, but also estimate better. Developers will be able to give better estimations, and the PO/PM will know whether they tend to under or over estimate and help shore up what's going to be reported. It's on the developers for this one.
Honesty
I debated about how to phrase this, as I certainly don't want to point fingers. I think honest reporting of progress is important for the successful delivery of a product, whether internal or customer-facing. Unfortunately, I've seen team members report that they're behind schedule to their manager / team leaders / PM/PO, only to attend a meeting the following week where upper management reports that the team has reported that they're ahead of schedule. All team members need to honestly report and carry feedback on where the team stands. If everyone is ahead of schedule, that's great, but it's more important to clearly and honestly convey status to upper management.
Trust
I thought about putting this under experience, as that's usually how trust is gained, but I'll call it out separately as I'm thinking of a different group of people: upper management. I've seen PM/POs come back from meetings with upper management, having gotten their ears chewed off about release dates and stakeholders, etc. The PM/PO took it for the team so the rest of the team could keep working without being weighed down by the "feedback." If teams give good estimates and honestly report status, good and bad, they should be trusted to carry through with their delivery without being the next verbal punching back on deck or being micromanaged, which weighs heavily on the PM/PO.
All of this ties, unsurprisingly, into good communication.
I’ve shared your post here with our dev lead, he had a hearty, bittersweet laugh and agreed your analysis is spot on. Thank you for your thoughtful response, it’s been helpful for me and our team...
I’ve shared your post here with our dev lead, he had a hearty, bittersweet laugh and agreed your analysis is spot on. Thank you for your thoughtful response, it’s been helpful for me and our team as we work on improving our own processes.
It also helps to add in a 'shit happens' factor. Always pad in a little extra time so that when the flu goes around the office, or someone quits, or some prod server goes up in flames for a week...
It also helps to add in a 'shit happens' factor. Always pad in a little extra time so that when the flu goes around the office, or someone quits, or some prod server goes up in flames for a week due to unrelated issues, you still end up on time. In the rare event you don't use up the extra time, you can finish early and treat everyone to a company lunch or a three day weekend or do something to say thank you.
Good call. We’ve attempted to back into something like this by looking at a couple of years of staffing history. Vacations, sick time, training, hiring, new babies, bereavement, unfulfilled...
Good call. We’ve attempted to back into something like this by looking at a couple of years of staffing history. Vacations, sick time, training, hiring, new babies, bereavement, unfulfilled new-hire hopes - it goes on and on. EOD, it’s really not possible to predict real work hours exactly when a team is small, so it’s best to just assume it will all happen and plan accordingly. It’s not “padding” - it’s wise.
I've been fairly optimistic myself about James Webb for a long time now, but the delay to 2021 has me more worried than before, especially because of NASA's request for additional funds. It's...
I've been fairly optimistic myself about James Webb for a long time now, but the delay to 2021 has me more worried than before, especially because of NASA's request for additional funds. It's looking to be about twice as expensive as Hubble was (~$4.7 billion).
NASA has canceled some programs because of cost and time overruns, Martin says, but these have been smaller projects costing several hundred million dollars, a pittance compared to Webb’s lifetime cost of $9.6 billion. It’s the biggest astronomy missions—the most complex, technically challenging efforts—that are at the greatest risk of missing targets and deadlines, and the most difficult to say no to, especially when so much has already been invested. “Once you’ve spent $9 billion, the thinking would be: What’s another billion?” Garver says.
I'm sure Congress isn't pleased by the prospect of spending another $860 million on this telescope, as the article rightly points out. Perhaps NASA needs to rethink its development process somewhat to better suit this age of impatience. However, I feel that the knowledge we could gain from launching the JWST ultimately outweighs the budgetary concerns laid out here, just like Hubble.
In my experience in industry what happens is features just keep getting dropped as the due date approaches. I am not sold that this approach is better for NASA's goals.
In my experience in industry what happens is features just keep getting dropped as the due date approaches. I am not sold that this approach is better for NASA's goals.
Wow, so much of this articles applies flawlessly to the software engineering field.
This is frustratingly common. The PO/PM identify new/changed features and put the work on the roadmap. They ask how long it will take, receive non-committal or vague answers back from the engineers, decide on how long they think it should take, and then tell upper management the date that it will all be done. Estimating effort is a very difficult task, even for experienced engineers, and many aren't very good at it at all (I'm not). This PO/PM-driven time frame rarely takes into account the time to test and deploy the changes; their definition of "done" is whatever they can successfully sell to upper management as a milestone victory to get promoted out of the team that now hates them. Failure to deliver can certainly be the fault of the development team, and I've seen that as well - engineers approach a problem without sufficient planning or customer research, and halfway to the deadline, find out that their entire approach is faulty.
It's just my experience that more often, it's the PM team.
There it is!
The difference between a good engineer and a bad one is the Scotty factor.
Anyone operating without that tool in their kit is going to have bad times.
Haha that's great. I was told years ago to take an estimate, and round "generously".
I was always told to double the initial dev estimate and add 6 months.
That's good advice!
In my case what they told me was double your estimate and take to the next order of magnitude lol (so 1 day -> 2 weeks, 1 week -> 2 months, 1 month -> 2 years). Especially if it is a team working in different parts of the project.
If you were an engineer, how would you remedy this? I work on the product side, and we develop our effort estimates together with our dev teams, acknowledging up front that the figures aren’t perfect. We developed this process having already gone together through the hell you so aptly describe, none of us wanting to continue that cycle - from the execs to the PO, PM, engineers, and analysts. Would love to hear thoughts on other approaches.
Sure, thanks for replying.
I've thought about this for the past couple hours, and I think I have down what I want to answer with. I think there are 3 things that can help everyone involved:
Experience
As I and several people have pointed out, proper estimation is a skill, and something that developers are often not good at (I'm not - I tend to underestimate). A team who has more experience working together will not only work faster, but also estimate better. Developers will be able to give better estimations, and the PO/PM will know whether they tend to under or over estimate and help shore up what's going to be reported. It's on the developers for this one.
Honesty
I debated about how to phrase this, as I certainly don't want to point fingers. I think honest reporting of progress is important for the successful delivery of a product, whether internal or customer-facing. Unfortunately, I've seen team members report that they're behind schedule to their manager / team leaders / PM/PO, only to attend a meeting the following week where upper management reports that the team has reported that they're ahead of schedule. All team members need to honestly report and carry feedback on where the team stands. If everyone is ahead of schedule, that's great, but it's more important to clearly and honestly convey status to upper management.
Trust
I thought about putting this under experience, as that's usually how trust is gained, but I'll call it out separately as I'm thinking of a different group of people: upper management. I've seen PM/POs come back from meetings with upper management, having gotten their ears chewed off about release dates and stakeholders, etc. The PM/PO took it for the team so the rest of the team could keep working without being weighed down by the "feedback." If teams give good estimates and honestly report status, good and bad, they should be trusted to carry through with their delivery without being the next verbal punching back on deck or being micromanaged, which weighs heavily on the PM/PO.
All of this ties, unsurprisingly, into good communication.
I’ve shared your post here with our dev lead, he had a hearty, bittersweet laugh and agreed your analysis is spot on. Thank you for your thoughtful response, it’s been helpful for me and our team as we work on improving our own processes.
It also helps to add in a 'shit happens' factor. Always pad in a little extra time so that when the flu goes around the office, or someone quits, or some prod server goes up in flames for a week due to unrelated issues, you still end up on time. In the rare event you don't use up the extra time, you can finish early and treat everyone to a company lunch or a three day weekend or do something to say thank you.
Good call. We’ve attempted to back into something like this by looking at a couple of years of staffing history. Vacations, sick time, training, hiring, new babies, bereavement, unfulfilled new-hire hopes - it goes on and on. EOD, it’s really not possible to predict real work hours exactly when a team is small, so it’s best to just assume it will all happen and plan accordingly. It’s not “padding” - it’s wise.
I've been fairly optimistic myself about James Webb for a long time now, but the delay to 2021 has me more worried than before, especially because of NASA's request for additional funds. It's looking to be about twice as expensive as Hubble was (~$4.7 billion).
I'm sure Congress isn't pleased by the prospect of spending another $860 million on this telescope, as the article rightly points out. Perhaps NASA needs to rethink its development process somewhat to better suit this age of impatience. However, I feel that the knowledge we could gain from launching the JWST ultimately outweighs the budgetary concerns laid out here, just like Hubble.
In my experience in industry what happens is features just keep getting dropped as the due date approaches. I am not sold that this approach is better for NASA's goals.