Canceling a project gracefully
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
23
down vote
favorite
I'm a senior developer on an agile project. In that project, I and two other developers are to port an existing software to another target platform. I don't code, I'm mainly responsible for project management taskss, writing/collecting user stories, maintaining the backlog, organizing sprint demos, sprint plannings, retrospectives, reporting to management.
The project was canceled recently after six iterations due to changing sales expectations and business priorities. We have about 8-10 more iterations to work through to finish the project.
I know that it's not best for morale and motivation to throw out six weeks of work, so how can a project be closed gracefully?
project-management motivation morale
add a comment |Â
up vote
23
down vote
favorite
I'm a senior developer on an agile project. In that project, I and two other developers are to port an existing software to another target platform. I don't code, I'm mainly responsible for project management taskss, writing/collecting user stories, maintaining the backlog, organizing sprint demos, sprint plannings, retrospectives, reporting to management.
The project was canceled recently after six iterations due to changing sales expectations and business priorities. We have about 8-10 more iterations to work through to finish the project.
I know that it's not best for morale and motivation to throw out six weeks of work, so how can a project be closed gracefully?
project-management motivation morale
9
Focus on helping get them assigned to their next task. Being left exposed without coverage is even worse then throwing away 6 weeks of work.
– mhoran_psprep
May 15 '14 at 11:48
1
possible duplicate of How do I survive a failed project?
– IDrinkandIKnowThings
May 21 '14 at 16:07
add a comment |Â
up vote
23
down vote
favorite
up vote
23
down vote
favorite
I'm a senior developer on an agile project. In that project, I and two other developers are to port an existing software to another target platform. I don't code, I'm mainly responsible for project management taskss, writing/collecting user stories, maintaining the backlog, organizing sprint demos, sprint plannings, retrospectives, reporting to management.
The project was canceled recently after six iterations due to changing sales expectations and business priorities. We have about 8-10 more iterations to work through to finish the project.
I know that it's not best for morale and motivation to throw out six weeks of work, so how can a project be closed gracefully?
project-management motivation morale
I'm a senior developer on an agile project. In that project, I and two other developers are to port an existing software to another target platform. I don't code, I'm mainly responsible for project management taskss, writing/collecting user stories, maintaining the backlog, organizing sprint demos, sprint plannings, retrospectives, reporting to management.
The project was canceled recently after six iterations due to changing sales expectations and business priorities. We have about 8-10 more iterations to work through to finish the project.
I know that it's not best for morale and motivation to throw out six weeks of work, so how can a project be closed gracefully?
project-management motivation morale
edited May 15 '14 at 17:09
Vietnhi Phuvan
68.9k7118254
68.9k7118254
asked May 15 '14 at 9:47
user19531
11615
11615
9
Focus on helping get them assigned to their next task. Being left exposed without coverage is even worse then throwing away 6 weeks of work.
– mhoran_psprep
May 15 '14 at 11:48
1
possible duplicate of How do I survive a failed project?
– IDrinkandIKnowThings
May 21 '14 at 16:07
add a comment |Â
9
Focus on helping get them assigned to their next task. Being left exposed without coverage is even worse then throwing away 6 weeks of work.
– mhoran_psprep
May 15 '14 at 11:48
1
possible duplicate of How do I survive a failed project?
– IDrinkandIKnowThings
May 21 '14 at 16:07
9
9
Focus on helping get them assigned to their next task. Being left exposed without coverage is even worse then throwing away 6 weeks of work.
– mhoran_psprep
May 15 '14 at 11:48
Focus on helping get them assigned to their next task. Being left exposed without coverage is even worse then throwing away 6 weeks of work.
– mhoran_psprep
May 15 '14 at 11:48
1
1
possible duplicate of How do I survive a failed project?
– IDrinkandIKnowThings
May 21 '14 at 16:07
possible duplicate of How do I survive a failed project?
– IDrinkandIKnowThings
May 21 '14 at 16:07
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
22
down vote
Use this as an opportunity to learn. I have at least four unambiguously failed projects under my belt, and every one of these taught me something important.
As explained in this fantastic answer,
Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies, that is why they require
N+ years of experience
, it implies they made all the basic, entry level mistakes already and someone else had to pay for them.
This judgement only comes with experience.
Edison invented the light bulb through experiencing failure, not through some raw in-experienced skill...
Even the most skilled don't achieve success without a proportional amount of failure. This is how good judgement is earned...
Explain above to your team members, help them find out how to apply acquired experience to improve in next project(s).
Set up a project postmortem / retrospective. Study how it went, what was done right and what could have been done better. Learn how to apply... oh wait, it is impossible to adequately cover in an answer such a topic without knowing specifics of your project.
For a starting point, refer Conducting a Project Postmortem article by Steve Pavlina:
The best time to conduct a postmortem is about two weeks after a product is released (or for certain products, after the project is cancelled). This allows you to regain your objectivity without forgetting the details. Your memories will still be fresh, and you'll have a good perspective to see the project as a whole rather than focusing too strongly on the most recent work...
Another useful reference is Scott Berkun essay, How to learn from your mistakes:
The learning from mistakes checklist
- Accepting responsibility makes learning possible.
- Don’t equate making mistakes with being a mistake.
- You can’t change mistakes, but you can choose how to respond to them.
- Growth starts when you can see room for improvement.
- Work to understand why it happened and what the factors were.
- What information could have avoided the mistake?
- What small mistakes, in sequence, contributed to the bigger mistake?
- Are there alternatives you should have considered but did not?
- What kinds of changes are required to avoid making this mistake again?What kinds of change are difficult for you?
- How do you think your behavior should/would change in you were in a similar situation again?
- Work to understand the mistake until you can make fun of it (or not want to kill others that make fun).
- Don’t over-compensate: the next situation won’t be the same as the last.
2
+1. To quote/paraphrase many writers (it's entirely unclear who said it first), "Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement." Learning from failures is exactly what's meant by getting back on the horse after you fall off. (... unless you're actually trying to break in a real horse, then it's about teaching the horse, not yourself. Po-tay-toe, po-tah-toe.)
– Brian S
May 15 '14 at 15:02
1
I think we can debate whether this should be considered a "failure" or not, because failure implies (to some?) that somebody made a mistake, and this is not necessarily the case here. Business priorities can change based on new information, so it's possible that a valid decision last week ("continue with the project") becomes invalid this week ("our competitors launched X, stop our project"). Certainly the developers should not leave the project with the idea that they failed somehow.
– Jan Fabry
May 15 '14 at 19:43
@JanFabry good note, I adjusted the wording to account for that. Cancelled project doesn't necessarily mean failure
– gnat
May 15 '14 at 19:49
@BrianS - I keep a fortune cookie fortune with that saying on my desk. It phrases it a bit more pithily, though:Good judgement comes from experience. Experience comes from bad judgement.
– Bobson
May 15 '14 at 21:08
add a comment |Â
up vote
14
down vote
I know that it's not the best for morale and motivation to throw out
six weeks of work, so how can a project be closed gracefully?
It would be far worse for morale and motivation to continue working on a project with no value, so end it cleanly and quickly.
Be honest with the team. Explain that they did great work, but the business reality has changed. People appreciate honesty, and this is the real world of business where this sort of thing happens.
The six weeks are a sunk cost. Unless those weeks produced something of value for some other project, the work is "thrown out" anyway. See if there's anything that can be salvaged for other projects. If not, do a retrospective to see what you have learned, have a project-completion lunch, put the project away, and get on to the next task.
1
The Bard said it best: "If it were done when 'tis done, then 'twere well It were done quickly".
– Spehro Pefhany
May 15 '14 at 12:49
add a comment |Â
up vote
2
down vote
You would check with the people who decided to cancel the project what the chances are that the project might be revived. If the chance is zero, and any work invested has therefore zero value, you cancel immediately. If there is a possibility, you do the minimum work to make it possible to revive the project, say a day or two. Make backups of everything, document everything so things won't be lost.
And then you tell everyone involved that you are very sorry the project is cancelled, give everyone a chance to voice how annoyed they are with that decision and how stupid management is, and then you go on and switch to the next job.
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
22
down vote
Use this as an opportunity to learn. I have at least four unambiguously failed projects under my belt, and every one of these taught me something important.
As explained in this fantastic answer,
Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies, that is why they require
N+ years of experience
, it implies they made all the basic, entry level mistakes already and someone else had to pay for them.
This judgement only comes with experience.
Edison invented the light bulb through experiencing failure, not through some raw in-experienced skill...
Even the most skilled don't achieve success without a proportional amount of failure. This is how good judgement is earned...
Explain above to your team members, help them find out how to apply acquired experience to improve in next project(s).
Set up a project postmortem / retrospective. Study how it went, what was done right and what could have been done better. Learn how to apply... oh wait, it is impossible to adequately cover in an answer such a topic without knowing specifics of your project.
For a starting point, refer Conducting a Project Postmortem article by Steve Pavlina:
The best time to conduct a postmortem is about two weeks after a product is released (or for certain products, after the project is cancelled). This allows you to regain your objectivity without forgetting the details. Your memories will still be fresh, and you'll have a good perspective to see the project as a whole rather than focusing too strongly on the most recent work...
Another useful reference is Scott Berkun essay, How to learn from your mistakes:
The learning from mistakes checklist
- Accepting responsibility makes learning possible.
- Don’t equate making mistakes with being a mistake.
- You can’t change mistakes, but you can choose how to respond to them.
- Growth starts when you can see room for improvement.
- Work to understand why it happened and what the factors were.
- What information could have avoided the mistake?
- What small mistakes, in sequence, contributed to the bigger mistake?
- Are there alternatives you should have considered but did not?
- What kinds of changes are required to avoid making this mistake again?What kinds of change are difficult for you?
- How do you think your behavior should/would change in you were in a similar situation again?
- Work to understand the mistake until you can make fun of it (or not want to kill others that make fun).
- Don’t over-compensate: the next situation won’t be the same as the last.
2
+1. To quote/paraphrase many writers (it's entirely unclear who said it first), "Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement." Learning from failures is exactly what's meant by getting back on the horse after you fall off. (... unless you're actually trying to break in a real horse, then it's about teaching the horse, not yourself. Po-tay-toe, po-tah-toe.)
– Brian S
May 15 '14 at 15:02
1
I think we can debate whether this should be considered a "failure" or not, because failure implies (to some?) that somebody made a mistake, and this is not necessarily the case here. Business priorities can change based on new information, so it's possible that a valid decision last week ("continue with the project") becomes invalid this week ("our competitors launched X, stop our project"). Certainly the developers should not leave the project with the idea that they failed somehow.
– Jan Fabry
May 15 '14 at 19:43
@JanFabry good note, I adjusted the wording to account for that. Cancelled project doesn't necessarily mean failure
– gnat
May 15 '14 at 19:49
@BrianS - I keep a fortune cookie fortune with that saying on my desk. It phrases it a bit more pithily, though:Good judgement comes from experience. Experience comes from bad judgement.
– Bobson
May 15 '14 at 21:08
add a comment |Â
up vote
22
down vote
Use this as an opportunity to learn. I have at least four unambiguously failed projects under my belt, and every one of these taught me something important.
As explained in this fantastic answer,
Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies, that is why they require
N+ years of experience
, it implies they made all the basic, entry level mistakes already and someone else had to pay for them.
This judgement only comes with experience.
Edison invented the light bulb through experiencing failure, not through some raw in-experienced skill...
Even the most skilled don't achieve success without a proportional amount of failure. This is how good judgement is earned...
Explain above to your team members, help them find out how to apply acquired experience to improve in next project(s).
Set up a project postmortem / retrospective. Study how it went, what was done right and what could have been done better. Learn how to apply... oh wait, it is impossible to adequately cover in an answer such a topic without knowing specifics of your project.
For a starting point, refer Conducting a Project Postmortem article by Steve Pavlina:
The best time to conduct a postmortem is about two weeks after a product is released (or for certain products, after the project is cancelled). This allows you to regain your objectivity without forgetting the details. Your memories will still be fresh, and you'll have a good perspective to see the project as a whole rather than focusing too strongly on the most recent work...
Another useful reference is Scott Berkun essay, How to learn from your mistakes:
The learning from mistakes checklist
- Accepting responsibility makes learning possible.
- Don’t equate making mistakes with being a mistake.
- You can’t change mistakes, but you can choose how to respond to them.
- Growth starts when you can see room for improvement.
- Work to understand why it happened and what the factors were.
- What information could have avoided the mistake?
- What small mistakes, in sequence, contributed to the bigger mistake?
- Are there alternatives you should have considered but did not?
- What kinds of changes are required to avoid making this mistake again?What kinds of change are difficult for you?
- How do you think your behavior should/would change in you were in a similar situation again?
- Work to understand the mistake until you can make fun of it (or not want to kill others that make fun).
- Don’t over-compensate: the next situation won’t be the same as the last.
2
+1. To quote/paraphrase many writers (it's entirely unclear who said it first), "Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement." Learning from failures is exactly what's meant by getting back on the horse after you fall off. (... unless you're actually trying to break in a real horse, then it's about teaching the horse, not yourself. Po-tay-toe, po-tah-toe.)
– Brian S
May 15 '14 at 15:02
1
I think we can debate whether this should be considered a "failure" or not, because failure implies (to some?) that somebody made a mistake, and this is not necessarily the case here. Business priorities can change based on new information, so it's possible that a valid decision last week ("continue with the project") becomes invalid this week ("our competitors launched X, stop our project"). Certainly the developers should not leave the project with the idea that they failed somehow.
– Jan Fabry
May 15 '14 at 19:43
@JanFabry good note, I adjusted the wording to account for that. Cancelled project doesn't necessarily mean failure
– gnat
May 15 '14 at 19:49
@BrianS - I keep a fortune cookie fortune with that saying on my desk. It phrases it a bit more pithily, though:Good judgement comes from experience. Experience comes from bad judgement.
– Bobson
May 15 '14 at 21:08
add a comment |Â
up vote
22
down vote
up vote
22
down vote
Use this as an opportunity to learn. I have at least four unambiguously failed projects under my belt, and every one of these taught me something important.
As explained in this fantastic answer,
Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies, that is why they require
N+ years of experience
, it implies they made all the basic, entry level mistakes already and someone else had to pay for them.
This judgement only comes with experience.
Edison invented the light bulb through experiencing failure, not through some raw in-experienced skill...
Even the most skilled don't achieve success without a proportional amount of failure. This is how good judgement is earned...
Explain above to your team members, help them find out how to apply acquired experience to improve in next project(s).
Set up a project postmortem / retrospective. Study how it went, what was done right and what could have been done better. Learn how to apply... oh wait, it is impossible to adequately cover in an answer such a topic without knowing specifics of your project.
For a starting point, refer Conducting a Project Postmortem article by Steve Pavlina:
The best time to conduct a postmortem is about two weeks after a product is released (or for certain products, after the project is cancelled). This allows you to regain your objectivity without forgetting the details. Your memories will still be fresh, and you'll have a good perspective to see the project as a whole rather than focusing too strongly on the most recent work...
Another useful reference is Scott Berkun essay, How to learn from your mistakes:
The learning from mistakes checklist
- Accepting responsibility makes learning possible.
- Don’t equate making mistakes with being a mistake.
- You can’t change mistakes, but you can choose how to respond to them.
- Growth starts when you can see room for improvement.
- Work to understand why it happened and what the factors were.
- What information could have avoided the mistake?
- What small mistakes, in sequence, contributed to the bigger mistake?
- Are there alternatives you should have considered but did not?
- What kinds of changes are required to avoid making this mistake again?What kinds of change are difficult for you?
- How do you think your behavior should/would change in you were in a similar situation again?
- Work to understand the mistake until you can make fun of it (or not want to kill others that make fun).
- Don’t over-compensate: the next situation won’t be the same as the last.
Use this as an opportunity to learn. I have at least four unambiguously failed projects under my belt, and every one of these taught me something important.
As explained in this fantastic answer,
Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies, that is why they require
N+ years of experience
, it implies they made all the basic, entry level mistakes already and someone else had to pay for them.
This judgement only comes with experience.
Edison invented the light bulb through experiencing failure, not through some raw in-experienced skill...
Even the most skilled don't achieve success without a proportional amount of failure. This is how good judgement is earned...
Explain above to your team members, help them find out how to apply acquired experience to improve in next project(s).
Set up a project postmortem / retrospective. Study how it went, what was done right and what could have been done better. Learn how to apply... oh wait, it is impossible to adequately cover in an answer such a topic without knowing specifics of your project.
For a starting point, refer Conducting a Project Postmortem article by Steve Pavlina:
The best time to conduct a postmortem is about two weeks after a product is released (or for certain products, after the project is cancelled). This allows you to regain your objectivity without forgetting the details. Your memories will still be fresh, and you'll have a good perspective to see the project as a whole rather than focusing too strongly on the most recent work...
Another useful reference is Scott Berkun essay, How to learn from your mistakes:
The learning from mistakes checklist
- Accepting responsibility makes learning possible.
- Don’t equate making mistakes with being a mistake.
- You can’t change mistakes, but you can choose how to respond to them.
- Growth starts when you can see room for improvement.
- Work to understand why it happened and what the factors were.
- What information could have avoided the mistake?
- What small mistakes, in sequence, contributed to the bigger mistake?
- Are there alternatives you should have considered but did not?
- What kinds of changes are required to avoid making this mistake again?What kinds of change are difficult for you?
- How do you think your behavior should/would change in you were in a similar situation again?
- Work to understand the mistake until you can make fun of it (or not want to kill others that make fun).
- Don’t over-compensate: the next situation won’t be the same as the last.
edited Apr 13 '17 at 12:48
Community♦
1
1
answered May 15 '14 at 11:16
gnat
3,22873066
3,22873066
2
+1. To quote/paraphrase many writers (it's entirely unclear who said it first), "Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement." Learning from failures is exactly what's meant by getting back on the horse after you fall off. (... unless you're actually trying to break in a real horse, then it's about teaching the horse, not yourself. Po-tay-toe, po-tah-toe.)
– Brian S
May 15 '14 at 15:02
1
I think we can debate whether this should be considered a "failure" or not, because failure implies (to some?) that somebody made a mistake, and this is not necessarily the case here. Business priorities can change based on new information, so it's possible that a valid decision last week ("continue with the project") becomes invalid this week ("our competitors launched X, stop our project"). Certainly the developers should not leave the project with the idea that they failed somehow.
– Jan Fabry
May 15 '14 at 19:43
@JanFabry good note, I adjusted the wording to account for that. Cancelled project doesn't necessarily mean failure
– gnat
May 15 '14 at 19:49
@BrianS - I keep a fortune cookie fortune with that saying on my desk. It phrases it a bit more pithily, though:Good judgement comes from experience. Experience comes from bad judgement.
– Bobson
May 15 '14 at 21:08
add a comment |Â
2
+1. To quote/paraphrase many writers (it's entirely unclear who said it first), "Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement." Learning from failures is exactly what's meant by getting back on the horse after you fall off. (... unless you're actually trying to break in a real horse, then it's about teaching the horse, not yourself. Po-tay-toe, po-tah-toe.)
– Brian S
May 15 '14 at 15:02
1
I think we can debate whether this should be considered a "failure" or not, because failure implies (to some?) that somebody made a mistake, and this is not necessarily the case here. Business priorities can change based on new information, so it's possible that a valid decision last week ("continue with the project") becomes invalid this week ("our competitors launched X, stop our project"). Certainly the developers should not leave the project with the idea that they failed somehow.
– Jan Fabry
May 15 '14 at 19:43
@JanFabry good note, I adjusted the wording to account for that. Cancelled project doesn't necessarily mean failure
– gnat
May 15 '14 at 19:49
@BrianS - I keep a fortune cookie fortune with that saying on my desk. It phrases it a bit more pithily, though:Good judgement comes from experience. Experience comes from bad judgement.
– Bobson
May 15 '14 at 21:08
2
2
+1. To quote/paraphrase many writers (it's entirely unclear who said it first), "Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement." Learning from failures is exactly what's meant by getting back on the horse after you fall off. (... unless you're actually trying to break in a real horse, then it's about teaching the horse, not yourself. Po-tay-toe, po-tah-toe.)
– Brian S
May 15 '14 at 15:02
+1. To quote/paraphrase many writers (it's entirely unclear who said it first), "Good judgement is the result of experience; however, experience is usually gained as a result of bad judgement." Learning from failures is exactly what's meant by getting back on the horse after you fall off. (... unless you're actually trying to break in a real horse, then it's about teaching the horse, not yourself. Po-tay-toe, po-tah-toe.)
– Brian S
May 15 '14 at 15:02
1
1
I think we can debate whether this should be considered a "failure" or not, because failure implies (to some?) that somebody made a mistake, and this is not necessarily the case here. Business priorities can change based on new information, so it's possible that a valid decision last week ("continue with the project") becomes invalid this week ("our competitors launched X, stop our project"). Certainly the developers should not leave the project with the idea that they failed somehow.
– Jan Fabry
May 15 '14 at 19:43
I think we can debate whether this should be considered a "failure" or not, because failure implies (to some?) that somebody made a mistake, and this is not necessarily the case here. Business priorities can change based on new information, so it's possible that a valid decision last week ("continue with the project") becomes invalid this week ("our competitors launched X, stop our project"). Certainly the developers should not leave the project with the idea that they failed somehow.
– Jan Fabry
May 15 '14 at 19:43
@JanFabry good note, I adjusted the wording to account for that. Cancelled project doesn't necessarily mean failure
– gnat
May 15 '14 at 19:49
@JanFabry good note, I adjusted the wording to account for that. Cancelled project doesn't necessarily mean failure
– gnat
May 15 '14 at 19:49
@BrianS - I keep a fortune cookie fortune with that saying on my desk. It phrases it a bit more pithily, though:
Good judgement comes from experience. Experience comes from bad judgement.
– Bobson
May 15 '14 at 21:08
@BrianS - I keep a fortune cookie fortune with that saying on my desk. It phrases it a bit more pithily, though:
Good judgement comes from experience. Experience comes from bad judgement.
– Bobson
May 15 '14 at 21:08
add a comment |Â
up vote
14
down vote
I know that it's not the best for morale and motivation to throw out
six weeks of work, so how can a project be closed gracefully?
It would be far worse for morale and motivation to continue working on a project with no value, so end it cleanly and quickly.
Be honest with the team. Explain that they did great work, but the business reality has changed. People appreciate honesty, and this is the real world of business where this sort of thing happens.
The six weeks are a sunk cost. Unless those weeks produced something of value for some other project, the work is "thrown out" anyway. See if there's anything that can be salvaged for other projects. If not, do a retrospective to see what you have learned, have a project-completion lunch, put the project away, and get on to the next task.
1
The Bard said it best: "If it were done when 'tis done, then 'twere well It were done quickly".
– Spehro Pefhany
May 15 '14 at 12:49
add a comment |Â
up vote
14
down vote
I know that it's not the best for morale and motivation to throw out
six weeks of work, so how can a project be closed gracefully?
It would be far worse for morale and motivation to continue working on a project with no value, so end it cleanly and quickly.
Be honest with the team. Explain that they did great work, but the business reality has changed. People appreciate honesty, and this is the real world of business where this sort of thing happens.
The six weeks are a sunk cost. Unless those weeks produced something of value for some other project, the work is "thrown out" anyway. See if there's anything that can be salvaged for other projects. If not, do a retrospective to see what you have learned, have a project-completion lunch, put the project away, and get on to the next task.
1
The Bard said it best: "If it were done when 'tis done, then 'twere well It were done quickly".
– Spehro Pefhany
May 15 '14 at 12:49
add a comment |Â
up vote
14
down vote
up vote
14
down vote
I know that it's not the best for morale and motivation to throw out
six weeks of work, so how can a project be closed gracefully?
It would be far worse for morale and motivation to continue working on a project with no value, so end it cleanly and quickly.
Be honest with the team. Explain that they did great work, but the business reality has changed. People appreciate honesty, and this is the real world of business where this sort of thing happens.
The six weeks are a sunk cost. Unless those weeks produced something of value for some other project, the work is "thrown out" anyway. See if there's anything that can be salvaged for other projects. If not, do a retrospective to see what you have learned, have a project-completion lunch, put the project away, and get on to the next task.
I know that it's not the best for morale and motivation to throw out
six weeks of work, so how can a project be closed gracefully?
It would be far worse for morale and motivation to continue working on a project with no value, so end it cleanly and quickly.
Be honest with the team. Explain that they did great work, but the business reality has changed. People appreciate honesty, and this is the real world of business where this sort of thing happens.
The six weeks are a sunk cost. Unless those weeks produced something of value for some other project, the work is "thrown out" anyway. See if there's anything that can be salvaged for other projects. If not, do a retrospective to see what you have learned, have a project-completion lunch, put the project away, and get on to the next task.
edited Jun 2 '14 at 12:59
answered May 15 '14 at 10:57


Joe Strazzere
224k107658929
224k107658929
1
The Bard said it best: "If it were done when 'tis done, then 'twere well It were done quickly".
– Spehro Pefhany
May 15 '14 at 12:49
add a comment |Â
1
The Bard said it best: "If it were done when 'tis done, then 'twere well It were done quickly".
– Spehro Pefhany
May 15 '14 at 12:49
1
1
The Bard said it best: "If it were done when 'tis done, then 'twere well It were done quickly".
– Spehro Pefhany
May 15 '14 at 12:49
The Bard said it best: "If it were done when 'tis done, then 'twere well It were done quickly".
– Spehro Pefhany
May 15 '14 at 12:49
add a comment |Â
up vote
2
down vote
You would check with the people who decided to cancel the project what the chances are that the project might be revived. If the chance is zero, and any work invested has therefore zero value, you cancel immediately. If there is a possibility, you do the minimum work to make it possible to revive the project, say a day or two. Make backups of everything, document everything so things won't be lost.
And then you tell everyone involved that you are very sorry the project is cancelled, give everyone a chance to voice how annoyed they are with that decision and how stupid management is, and then you go on and switch to the next job.
add a comment |Â
up vote
2
down vote
You would check with the people who decided to cancel the project what the chances are that the project might be revived. If the chance is zero, and any work invested has therefore zero value, you cancel immediately. If there is a possibility, you do the minimum work to make it possible to revive the project, say a day or two. Make backups of everything, document everything so things won't be lost.
And then you tell everyone involved that you are very sorry the project is cancelled, give everyone a chance to voice how annoyed they are with that decision and how stupid management is, and then you go on and switch to the next job.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
You would check with the people who decided to cancel the project what the chances are that the project might be revived. If the chance is zero, and any work invested has therefore zero value, you cancel immediately. If there is a possibility, you do the minimum work to make it possible to revive the project, say a day or two. Make backups of everything, document everything so things won't be lost.
And then you tell everyone involved that you are very sorry the project is cancelled, give everyone a chance to voice how annoyed they are with that decision and how stupid management is, and then you go on and switch to the next job.
You would check with the people who decided to cancel the project what the chances are that the project might be revived. If the chance is zero, and any work invested has therefore zero value, you cancel immediately. If there is a possibility, you do the minimum work to make it possible to revive the project, say a day or two. Make backups of everything, document everything so things won't be lost.
And then you tell everyone involved that you are very sorry the project is cancelled, give everyone a chance to voice how annoyed they are with that decision and how stupid management is, and then you go on and switch to the next job.
answered Apr 23 '17 at 8:51
gnasher729
71.5k31131224
71.5k31131224
add a comment |Â
add a comment |Â
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%2f24117%2fcanceling-a-project-gracefully%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
9
Focus on helping get them assigned to their next task. Being left exposed without coverage is even worse then throwing away 6 weeks of work.
– mhoran_psprep
May 15 '14 at 11:48
1
possible duplicate of How do I survive a failed project?
– IDrinkandIKnowThings
May 21 '14 at 16:07