Mixing
Tapering management's expectations on a research project
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
5
down vote
favorite
How does one set realistic milestones in R&D activities? Management wants to include milestones in research projects in the R&D arm of a company. I see the value of tracking progress in research, but I’m not convinced milestones are the right way, at least not the way we define them. My past experience is I’ve often found others working towards the milestones rather than being upfront about issues at stake as discoveries are made, since this is the standard management evaluates them to.
For example:
Month 1: solidify a strategy to solve problem A
Month 2: have program done to solve problem A
However, the problem A is more complex than originally thought, and you need to invent a strategy to solve the problem for delivering a quality product to customers. This will take more than one month.
software-industry management project-management
asked May 14 '16 at 16:00
user2183232343
283
suggest improvements |Â
up vote
5
down vote
favorite
How does one set realistic milestones in R&D activities? Management wants to include milestones in research projects in the R&D arm of a company. I see the value of tracking progress in research, but I’m not convinced milestones are the right way, at least not the way we define them. My past experience is I’ve often found others working towards the milestones rather than being upfront about issues at stake as discoveries are made, since this is the standard management evaluates them to.
For example:
Month 1: solidify a strategy to solve problem A
Month 2: have program done to solve problem A
However, the problem A is more complex than originally thought, and you need to invent a strategy to solve the problem for delivering a quality product to customers. This will take more than one month.
software-industry management project-management
asked May 14 '16 at 16:00
user2183232343
283
@Joe This question is raised based on a fear developed at my previous job and to better plan for it in the future should it come up again. My current employer does not institute rigid milestones on R&D activity, but they might do so shortly.
– user2183232343
May 17 '16 at 1:45
suggest improvements |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
How does one set realistic milestones in R&D activities? Management wants to include milestones in research projects in the R&D arm of a company. I see the value of tracking progress in research, but I’m not convinced milestones are the right way, at least not the way we define them. My past experience is I’ve often found others working towards the milestones rather than being upfront about issues at stake as discoveries are made, since this is the standard management evaluates them to.
For example:
Month 1: solidify a strategy to solve problem A
Month 2: have program done to solve problem A
However, the problem A is more complex than originally thought, and you need to invent a strategy to solve the problem for delivering a quality product to customers. This will take more than one month.
software-industry management project-management
asked May 14 '16 at 16:00
user2183232343
283
How does one set realistic milestones in R&D activities? Management wants to include milestones in research projects in the R&D arm of a company. I see the value of tracking progress in research, but I’m not convinced milestones are the right way, at least not the way we define them. My past experience is I’ve often found others working towards the milestones rather than being upfront about issues at stake as discoveries are made, since this is the standard management evaluates them to.
For example:
Month 1: solidify a strategy to solve problem A
Month 2: have program done to solve problem A
However, the problem A is more complex than originally thought, and you need to invent a strategy to solve the problem for delivering a quality product to customers. This will take more than one month.
software-industry management project-management
asked May 14 '16 at 16:00
user2183232343
283
asked May 14 '16 at 16:00
user2183232343
283
asked May 14 '16 at 16:00
user2183232343
283
asked May 14 '16 at 16:00
user2183232343
283
283
@Joe This question is raised based on a fear developed at my previous job and to better plan for it in the future should it come up again. My current employer does not institute rigid milestones on R&D activity, but they might do so shortly.
– user2183232343
May 17 '16 at 1:45
suggest improvements |Â
@Joe This question is raised based on a fear developed at my previous job and to better plan for it in the future should it come up again. My current employer does not institute rigid milestones on R&D activity, but they might do so shortly.
– user2183232343
May 17 '16 at 1:45
@Joe This question is raised based on a fear developed at my previous job and to better plan for it in the future should it come up again. My current employer does not institute rigid milestones on R&D activity, but they might do so shortly.
– user2183232343
May 17 '16 at 1:45
@Joe This question is raised based on a fear developed at my previous job and to better plan for it in the future should it come up again. My current employer does not institute rigid milestones on R&D activity, but they might do so shortly.
– user2183232343
May 17 '16 at 1:45
suggest improvements |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
accepted
I provide the different flavors of estimates. Here are two extremes:
R/d (mostly research, just a little development)
This is blue-sky work. I point management at the biggest possibilities assuming the best resources possible with no guarantees of success. We fantasize about what is possible and strive to define the problem more than solve it completely.
r/D (this is development with the illusion of being research)
The reality of most projects are that they are really targeted towards integration into products. For these efforts, I strive for the most practical solutions with realistic timelines with realistic budgets and realistic resources. I often provide a sliding scale of outcomes and probabilities
- We'll get this done with 90% chance success and 90% on-time/on-budget
- We'll get this done with 50% chance of success and 90% on-time/on-budget).
In product development in small / mid-sized companies, there is rarely real R/D like graduate school, the government, or large companies. All R/D in industry is applied and has limited time and budget. Therefore, the only thing left to play around with is the performance.
answered May 15 '16 at 0:11
user3533030
56525
suggest improvements |Â
up vote
1
down vote
A research schedule is a best estimate. Any schedule is a best estimate.
Handle it the same way you would a dev schedule: Here is where we expected to be at this point, here's what we've learned, if our original estimate was overoptimistic here is a revised best estimate based on what we have learned.
If management objects, have an estimate ready for what it would take to make you confident you could meet the original target date: more manpower (beware mythical-MSN-month effects), more investment in tools, purchasing something commercially rather than developing it in house, etc. Deciding whether they can afford that investment is their problem, as is deciding whether to accept revised schedule, out to cancel the effort entirely.
Odds of that last are unlikely, though they may reduce the scope. Ideally, this will be in a way that produces something useful by the original date, then adds the rest on a continuing basis which can be published/patented/rolled out as a subsequent version/addition. That's often a better although in any case. Quoting researcher Steve Boies: "Make it work, make it good, make it great." Implicitly: in that order.
If they flat-out refuse to accept your new estimates, which are bbased on the same expertise that cause them to ask you to lead this effort, all you can do is say "well, I'll do my best, but I've told you my current expectations."
Don't panic. Management appreciates estimates that they know how to plan around, even if it isn't what they would have preferred to hear. And they understand that estimating is an imperfect skill that t takes time to learn.
If dealing with someone who really can't be flexible about this, the lesson learned is the one everyone has to learn: when resonating schedules, allow time for the unexpected. After 30 years in my profession I'm still learning how much pad to add.
answered May 14 '16 at 17:45
keshlam
41.5k1267144
suggest improvements |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
I provide the different flavors of estimates. Here are two extremes:
R/d (mostly research, just a little development)
This is blue-sky work. I point management at the biggest possibilities assuming the best resources possible with no guarantees of success. We fantasize about what is possible and strive to define the problem more than solve it completely.
r/D (this is development with the illusion of being research)
The reality of most projects are that they are really targeted towards integration into products. For these efforts, I strive for the most practical solutions with realistic timelines with realistic budgets and realistic resources. I often provide a sliding scale of outcomes and probabilities
- We'll get this done with 90% chance success and 90% on-time/on-budget
- We'll get this done with 50% chance of success and 90% on-time/on-budget).
In product development in small / mid-sized companies, there is rarely real R/D like graduate school, the government, or large companies. All R/D in industry is applied and has limited time and budget. Therefore, the only thing left to play around with is the performance.
answered May 15 '16 at 0:11
user3533030
56525
suggest improvements |Â
up vote
3
down vote
accepted
I provide the different flavors of estimates. Here are two extremes:
R/d (mostly research, just a little development)
This is blue-sky work. I point management at the biggest possibilities assuming the best resources possible with no guarantees of success. We fantasize about what is possible and strive to define the problem more than solve it completely.
r/D (this is development with the illusion of being research)
The reality of most projects are that they are really targeted towards integration into products. For these efforts, I strive for the most practical solutions with realistic timelines with realistic budgets and realistic resources. I often provide a sliding scale of outcomes and probabilities
- We'll get this done with 90% chance success and 90% on-time/on-budget
- We'll get this done with 50% chance of success and 90% on-time/on-budget).
In product development in small / mid-sized companies, there is rarely real R/D like graduate school, the government, or large companies. All R/D in industry is applied and has limited time and budget. Therefore, the only thing left to play around with is the performance.
answered May 15 '16 at 0:11
user3533030
56525
suggest improvements |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
I provide the different flavors of estimates. Here are two extremes:
R/d (mostly research, just a little development)
This is blue-sky work. I point management at the biggest possibilities assuming the best resources possible with no guarantees of success. We fantasize about what is possible and strive to define the problem more than solve it completely.
r/D (this is development with the illusion of being research)
The reality of most projects are that they are really targeted towards integration into products. For these efforts, I strive for the most practical solutions with realistic timelines with realistic budgets and realistic resources. I often provide a sliding scale of outcomes and probabilities
- We'll get this done with 90% chance success and 90% on-time/on-budget
- We'll get this done with 50% chance of success and 90% on-time/on-budget).
In product development in small / mid-sized companies, there is rarely real R/D like graduate school, the government, or large companies. All R/D in industry is applied and has limited time and budget. Therefore, the only thing left to play around with is the performance.
answered May 15 '16 at 0:11
user3533030
56525
I provide the different flavors of estimates. Here are two extremes:
R/d (mostly research, just a little development)
This is blue-sky work. I point management at the biggest possibilities assuming the best resources possible with no guarantees of success. We fantasize about what is possible and strive to define the problem more than solve it completely.
r/D (this is development with the illusion of being research)
The reality of most projects are that they are really targeted towards integration into products. For these efforts, I strive for the most practical solutions with realistic timelines with realistic budgets and realistic resources. I often provide a sliding scale of outcomes and probabilities
- We'll get this done with 90% chance success and 90% on-time/on-budget
- We'll get this done with 50% chance of success and 90% on-time/on-budget).
In product development in small / mid-sized companies, there is rarely real R/D like graduate school, the government, or large companies. All R/D in industry is applied and has limited time and budget. Therefore, the only thing left to play around with is the performance.
answered May 15 '16 at 0:11
user3533030
56525
answered May 15 '16 at 0:11
user3533030
56525
answered May 15 '16 at 0:11
user3533030
56525
answered May 15 '16 at 0:11
user3533030
56525
56525
suggest improvements |Â
suggest improvements |Â
up vote
1
down vote
A research schedule is a best estimate. Any schedule is a best estimate.
Handle it the same way you would a dev schedule: Here is where we expected to be at this point, here's what we've learned, if our original estimate was overoptimistic here is a revised best estimate based on what we have learned.
If management objects, have an estimate ready for what it would take to make you confident you could meet the original target date: more manpower (beware mythical-MSN-month effects), more investment in tools, purchasing something commercially rather than developing it in house, etc. Deciding whether they can afford that investment is their problem, as is deciding whether to accept revised schedule, out to cancel the effort entirely.
Odds of that last are unlikely, though they may reduce the scope. Ideally, this will be in a way that produces something useful by the original date, then adds the rest on a continuing basis which can be published/patented/rolled out as a subsequent version/addition. That's often a better although in any case. Quoting researcher Steve Boies: "Make it work, make it good, make it great." Implicitly: in that order.
If they flat-out refuse to accept your new estimates, which are bbased on the same expertise that cause them to ask you to lead this effort, all you can do is say "well, I'll do my best, but I've told you my current expectations."
Don't panic. Management appreciates estimates that they know how to plan around, even if it isn't what they would have preferred to hear. And they understand that estimating is an imperfect skill that t takes time to learn.
If dealing with someone who really can't be flexible about this, the lesson learned is the one everyone has to learn: when resonating schedules, allow time for the unexpected. After 30 years in my profession I'm still learning how much pad to add.
answered May 14 '16 at 17:45
keshlam
41.5k1267144
suggest improvements |Â
up vote
1
down vote
A research schedule is a best estimate. Any schedule is a best estimate.
Handle it the same way you would a dev schedule: Here is where we expected to be at this point, here's what we've learned, if our original estimate was overoptimistic here is a revised best estimate based on what we have learned.
If management objects, have an estimate ready for what it would take to make you confident you could meet the original target date: more manpower (beware mythical-MSN-month effects), more investment in tools, purchasing something commercially rather than developing it in house, etc. Deciding whether they can afford that investment is their problem, as is deciding whether to accept revised schedule, out to cancel the effort entirely.
Odds of that last are unlikely, though they may reduce the scope. Ideally, this will be in a way that produces something useful by the original date, then adds the rest on a continuing basis which can be published/patented/rolled out as a subsequent version/addition. That's often a better although in any case. Quoting researcher Steve Boies: "Make it work, make it good, make it great." Implicitly: in that order.
If they flat-out refuse to accept your new estimates, which are bbased on the same expertise that cause them to ask you to lead this effort, all you can do is say "well, I'll do my best, but I've told you my current expectations."
Don't panic. Management appreciates estimates that they know how to plan around, even if it isn't what they would have preferred to hear. And they understand that estimating is an imperfect skill that t takes time to learn.
If dealing with someone who really can't be flexible about this, the lesson learned is the one everyone has to learn: when resonating schedules, allow time for the unexpected. After 30 years in my profession I'm still learning how much pad to add.
answered May 14 '16 at 17:45
keshlam
41.5k1267144
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
A research schedule is a best estimate. Any schedule is a best estimate.
Handle it the same way you would a dev schedule: Here is where we expected to be at this point, here's what we've learned, if our original estimate was overoptimistic here is a revised best estimate based on what we have learned.
If management objects, have an estimate ready for what it would take to make you confident you could meet the original target date: more manpower (beware mythical-MSN-month effects), more investment in tools, purchasing something commercially rather than developing it in house, etc. Deciding whether they can afford that investment is their problem, as is deciding whether to accept revised schedule, out to cancel the effort entirely.
Odds of that last are unlikely, though they may reduce the scope. Ideally, this will be in a way that produces something useful by the original date, then adds the rest on a continuing basis which can be published/patented/rolled out as a subsequent version/addition. That's often a better although in any case. Quoting researcher Steve Boies: "Make it work, make it good, make it great." Implicitly: in that order.
If they flat-out refuse to accept your new estimates, which are bbased on the same expertise that cause them to ask you to lead this effort, all you can do is say "well, I'll do my best, but I've told you my current expectations."
Don't panic. Management appreciates estimates that they know how to plan around, even if it isn't what they would have preferred to hear. And they understand that estimating is an imperfect skill that t takes time to learn.
If dealing with someone who really can't be flexible about this, the lesson learned is the one everyone has to learn: when resonating schedules, allow time for the unexpected. After 30 years in my profession I'm still learning how much pad to add.
answered May 14 '16 at 17:45
keshlam
41.5k1267144
A research schedule is a best estimate. Any schedule is a best estimate.
Handle it the same way you would a dev schedule: Here is where we expected to be at this point, here's what we've learned, if our original estimate was overoptimistic here is a revised best estimate based on what we have learned.
If management objects, have an estimate ready for what it would take to make you confident you could meet the original target date: more manpower (beware mythical-MSN-month effects), more investment in tools, purchasing something commercially rather than developing it in house, etc. Deciding whether they can afford that investment is their problem, as is deciding whether to accept revised schedule, out to cancel the effort entirely.
Odds of that last are unlikely, though they may reduce the scope. Ideally, this will be in a way that produces something useful by the original date, then adds the rest on a continuing basis which can be published/patented/rolled out as a subsequent version/addition. That's often a better although in any case. Quoting researcher Steve Boies: "Make it work, make it good, make it great." Implicitly: in that order.
If they flat-out refuse to accept your new estimates, which are bbased on the same expertise that cause them to ask you to lead this effort, all you can do is say "well, I'll do my best, but I've told you my current expectations."
Don't panic. Management appreciates estimates that they know how to plan around, even if it isn't what they would have preferred to hear. And they understand that estimating is an imperfect skill that t takes time to learn.
If dealing with someone who really can't be flexible about this, the lesson learned is the one everyone has to learn: when resonating schedules, allow time for the unexpected. After 30 years in my profession I'm still learning how much pad to add.
answered May 14 '16 at 17:45
keshlam
41.5k1267144
answered May 14 '16 at 17:45
keshlam
41.5k1267144
answered May 14 '16 at 17:45
keshlam
41.5k1267144
answered May 14 '16 at 17:45
keshlam
41.5k1267144
41.5k1267144
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f67165%2ftapering-managements-expectations-on-a-research-project%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
@Joe This question is raised based on a fear developed at my previous job and to better plan for it in the future should it come up again. My current employer does not institute rigid milestones on R&D activity, but they might do so shortly.
– user2183232343
May 17 '16 at 1:45