In my short experience I find the estimation process incredibly arbitrary. I work for a software agency (though today is my last day before moving on) and it’s crazy to see how estimations differ between projects and clients.
One project that stands out to me right now is one which faced huge amounts of unknown unknowns, yet none of the estimations changed. Granted the estimations were for FE and BE work which was broken down to a coarse granular level, and that work will still exist, but the resolution of the unknowns resulted in additional work items being made that would either augment or invalidate other work items. I wonder if that’s just that particular client however as they’re very favourable of the vanity metrics on Jira.
I wasn't familiar with Hubbard, but I'm reminded of my experience.
In my first management role, I was on a team with a big estimation problem. There were many unknowns and it was frustratingly difficult for the team to know when they would be done. On the other hand, I was impressed with how much we had to be right. The Marketing folks needed to buy ad space in advance. The Sales team needed to plan their activities and reach out to major customers. The Manufacturing team had to plan when to buy parts inventory and ramp up production. None of these stakeholders would be satisfied with the engineers saying "It's too hard to say."
Instead of asking the teams for estimates and holding them accountable for meeting them, we asked the teams for ranges of dates that they felt comfortable with. When will you be done if things go well? When will you be done if there are unforeseen problems? We didn't try to measure the confidence to 50% or 80%. We just let each team determine their own range. Some teams were much more confident in their abilities to estimate their work. They had done similar things before. They had narrower ranges. Other teams working on newer features were more wary about what could go wrong. They had larger ranges. The project managers had to think differently, but they were able to pick a ship date with an acceptable level of risk.
The estimates could have been better, but that would have taken more time. That time would be better spent doing the work and learning from what went wrong than doing more planning to anticipate better what might go wrong.
The overall project was large - months, not days. So, the next step was to have the teams think about indicators in their work. How can we tell now whether we're tracking toward the short end of the timeline or the long end of the timeline? The closer they get to done, the more confidence they should have in the estimated dates.
Regularly looking at the indicators and reassessing the risk allowed us to make re-scoping changes to the project plan necessary to reduce the risk. Should we move a component from one team to another that had similar skills and was running ahead of schedule? Should we cut a feature with an unacceptable level of risk? Should we skip some "low-priority" testing? (I know, I know…) Should we switch to the simpler design that was rejected because of issues less important than shipping on time? It's critical that these discussions are blameless and focused on delivering the whole product. But they're exactly the discussions that were needed.
Thank you for sharing your insights and experiences regarding project estimation methodologies in software engineering projects. While your perspective on estimating delivery time with probability is intriguing, my firsthand experience and observations lead me to a different conclusion.
In software engineering, time is often regarded as a hard constraint, and for good reason. Time-bound commitments are fundamental in various aspects of life and business, where stakeholders require certainty and reliability in delivery schedules. As you rightfully highlighted, commitments on time are essential for building trust and maintaining accountability within teams and with external stakeholders.
Solid Arguments Against Flexible Timelines:
- Stakeholder Expectations: Stakeholders, whether internal or external, often require firm commitments on project timelines to plan their activities and investments accordingly. Promising delivery within a probabilistic timeframe may lead to uncertainty and dissatisfaction among stakeholders, jeopardizing project success.
- Risk of Misinterpretation: Estimating delivery time with probability introduces ambiguity and complexity into project communication. Stakeholders may misinterpret probabilistic estimates as flexible deadlines, leading to confusion and misalignment of expectations.
- Impact on Team Morale: Uncertainty surrounding project timelines can negatively impact team morale and motivation. Teams thrive on clear goals and objectives, and uncertainty regarding project deadlines may undermine their sense of purpose and commitment to project success.
Examples of Non-Negotiable Time Constraints:
- Regulatory Deadlines: In industries such as healthcare, finance, and aviation, compliance with regulatory deadlines is non-negotiable. Failure to meet regulatory requirements within specified timelines may result in legal consequences, financial penalties, or reputational damage.
- Product Launches: The launch of new products or services often involves fixed deadlines tied to market opportunities, promotional campaigns, or competitive pressures. Missing product launch deadlines may result in missed market opportunities and loss of competitive advantage.
- Contractual Obligations: Contracts with clients or partners often include explicit deadlines for project delivery. Failure to meet contractual deadlines may result in breach of contract, financial penalties, or damaged business relationships.
In addition to the risks associated with flexible timelines, probabilistic delivery dates introduce a significant challenge in managing complex projects with multiple dependencies. When multiple teams or stakeholders rely on probabilistic delivery dates with an 80% certainty, the cumulative effect of uncertainties can magnify, leading to potential delays and disruptions across the project ecosystem.
Drawing a comparison to music, where timing and precision are paramount, can further illustrate the importance of fixed deadlines in project management. Much like playing music to a specific rhythm, project teams must adhere to predefined timelines to ensure harmonious collaboration and successful outcomes. While improvisation and creativity have their place, straying too far from the established rhythm can lead to discord and missed opportunities for synchronization.
In conclusion, while flexibility in project scope and approach (the "What" and the "How") is crucial for adapting to evolving requirements and constraints, the timing ("When") aspect of project management remains steadfast. While some may argue that even the “what” is non-negotiable, it inherently holds more flexibility than the delivery time. Generally, the order of flexibility tends to follow this sequence: When < What < How. Nevertheless, a steadfast commitment to project timelines is indispensable for fostering trust, upholding accountability, and ultimately ensuring project success, especially within complex projects characterized by multiple dependencies.
Thank you for engaging in this discussion, and I look forward to further exploration of project management methodologies and best practices.
In my short experience I find the estimation process incredibly arbitrary. I work for a software agency (though today is my last day before moving on) and it’s crazy to see how estimations differ between projects and clients.
One project that stands out to me right now is one which faced huge amounts of unknown unknowns, yet none of the estimations changed. Granted the estimations were for FE and BE work which was broken down to a coarse granular level, and that work will still exist, but the resolution of the unknowns resulted in additional work items being made that would either augment or invalidate other work items. I wonder if that’s just that particular client however as they’re very favourable of the vanity metrics on Jira.
I wasn't familiar with Hubbard, but I'm reminded of my experience.
In my first management role, I was on a team with a big estimation problem. There were many unknowns and it was frustratingly difficult for the team to know when they would be done. On the other hand, I was impressed with how much we had to be right. The Marketing folks needed to buy ad space in advance. The Sales team needed to plan their activities and reach out to major customers. The Manufacturing team had to plan when to buy parts inventory and ramp up production. None of these stakeholders would be satisfied with the engineers saying "It's too hard to say."
Instead of asking the teams for estimates and holding them accountable for meeting them, we asked the teams for ranges of dates that they felt comfortable with. When will you be done if things go well? When will you be done if there are unforeseen problems? We didn't try to measure the confidence to 50% or 80%. We just let each team determine their own range. Some teams were much more confident in their abilities to estimate their work. They had done similar things before. They had narrower ranges. Other teams working on newer features were more wary about what could go wrong. They had larger ranges. The project managers had to think differently, but they were able to pick a ship date with an acceptable level of risk.
The estimates could have been better, but that would have taken more time. That time would be better spent doing the work and learning from what went wrong than doing more planning to anticipate better what might go wrong.
The overall project was large - months, not days. So, the next step was to have the teams think about indicators in their work. How can we tell now whether we're tracking toward the short end of the timeline or the long end of the timeline? The closer they get to done, the more confidence they should have in the estimated dates.
Regularly looking at the indicators and reassessing the risk allowed us to make re-scoping changes to the project plan necessary to reduce the risk. Should we move a component from one team to another that had similar skills and was running ahead of schedule? Should we cut a feature with an unacceptable level of risk? Should we skip some "low-priority" testing? (I know, I know…) Should we switch to the simpler design that was rejected because of issues less important than shipping on time? It's critical that these discussions are blameless and focused on delivering the whole product. But they're exactly the discussions that were needed.
Thank you for sharing your insights and experiences regarding project estimation methodologies in software engineering projects. While your perspective on estimating delivery time with probability is intriguing, my firsthand experience and observations lead me to a different conclusion.
In software engineering, time is often regarded as a hard constraint, and for good reason. Time-bound commitments are fundamental in various aspects of life and business, where stakeholders require certainty and reliability in delivery schedules. As you rightfully highlighted, commitments on time are essential for building trust and maintaining accountability within teams and with external stakeholders.
Solid Arguments Against Flexible Timelines:
- Stakeholder Expectations: Stakeholders, whether internal or external, often require firm commitments on project timelines to plan their activities and investments accordingly. Promising delivery within a probabilistic timeframe may lead to uncertainty and dissatisfaction among stakeholders, jeopardizing project success.
- Risk of Misinterpretation: Estimating delivery time with probability introduces ambiguity and complexity into project communication. Stakeholders may misinterpret probabilistic estimates as flexible deadlines, leading to confusion and misalignment of expectations.
- Impact on Team Morale: Uncertainty surrounding project timelines can negatively impact team morale and motivation. Teams thrive on clear goals and objectives, and uncertainty regarding project deadlines may undermine their sense of purpose and commitment to project success.
Examples of Non-Negotiable Time Constraints:
- Regulatory Deadlines: In industries such as healthcare, finance, and aviation, compliance with regulatory deadlines is non-negotiable. Failure to meet regulatory requirements within specified timelines may result in legal consequences, financial penalties, or reputational damage.
- Product Launches: The launch of new products or services often involves fixed deadlines tied to market opportunities, promotional campaigns, or competitive pressures. Missing product launch deadlines may result in missed market opportunities and loss of competitive advantage.
- Contractual Obligations: Contracts with clients or partners often include explicit deadlines for project delivery. Failure to meet contractual deadlines may result in breach of contract, financial penalties, or damaged business relationships.
In addition to the risks associated with flexible timelines, probabilistic delivery dates introduce a significant challenge in managing complex projects with multiple dependencies. When multiple teams or stakeholders rely on probabilistic delivery dates with an 80% certainty, the cumulative effect of uncertainties can magnify, leading to potential delays and disruptions across the project ecosystem.
Drawing a comparison to music, where timing and precision are paramount, can further illustrate the importance of fixed deadlines in project management. Much like playing music to a specific rhythm, project teams must adhere to predefined timelines to ensure harmonious collaboration and successful outcomes. While improvisation and creativity have their place, straying too far from the established rhythm can lead to discord and missed opportunities for synchronization.
In conclusion, while flexibility in project scope and approach (the "What" and the "How") is crucial for adapting to evolving requirements and constraints, the timing ("When") aspect of project management remains steadfast. While some may argue that even the “what” is non-negotiable, it inherently holds more flexibility than the delivery time. Generally, the order of flexibility tends to follow this sequence: When < What < How. Nevertheless, a steadfast commitment to project timelines is indispensable for fostering trust, upholding accountability, and ultimately ensuring project success, especially within complex projects characterized by multiple dependencies.
Thank you for engaging in this discussion, and I look forward to further exploration of project management methodologies and best practices.
Warm regards,
Alain