I am a project manager at my company. I usually work on projects where the customers are government offices, public administrations and company related to them. In September we will begin a project for a company whose board of directors is appointed to reflect the state of the public administration to which it refers: the party winning the elections appoints 70% of the directors. The term in office of the board of directors is fixed, so there are cases in which public administration is in the hands of party A and (for a period) directors are mainly connected to party B.

Now we are exactly in the last situation: party B won the recent elections, but the board of directors appointed by party A will hold office for a further six months. The project I will manage should last 18 months. We already know that when the new board will come to power, they will cancel the project.

This is not a possibility; it is a certainty: we already spoke with the soon-to-be new CEO and he confirmed it. For me this is not a problem at all (neither the first time nor the last) and for my company it is a win situation: we will be paid for the entire project even if it will not be completed, there will be no pressure to complete it, no timeline to respect, etc. Public funds waste is neither my problem nor my company one.

The only thing we are forced to do is to be able to demonstrate that we are working on it (so a team must work on the project and a codebase must exist) and a working demo must be produced at the end of the six months. So the strategy of getting the money and do nothing is not feasible (unfortunately).

My company does not want to hide the situation to the team (and I 100% agree), but telling someone “your six months work will be a total waste” is not easy. And I have nothing positive to say: the technology stack is well known to the team (so no new knowledge can be gained), and the project is extremely focused on a particular need (so there isn't any way to sell to other customers).

So, how do I tell the team that they will work for six months on a project that we already know will fail?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Aug 9, 2019 at 13:38
  • 5
    Can't you sell it or modify it into a marketable product when complete? Aug 9, 2019 at 17:34
  • 1
    Is there a possibility that Party A will come back into power and want to 'unshelve' the project later? (Also, if that happened, would you want to?)
    – Alex P
    Aug 11, 2019 at 15:34
  • I project a nonzero chance you will have to deal with the following from party B in six months: "The outgoing party A was corrupt and approved this to siphon off from the public treasury against the will of the people. We will not pay it."
    – Joshua
    Aug 11, 2019 at 19:32
  • @AbraCadaver the only other customers that can be interested are other PA, but the possibility to sell the project to them is infinitesimal
    – loMa
    Aug 19, 2019 at 7:27

16 Answers 16


telling someone “your 6 months work will be a total waste” is not easy

Don't think of it as a waste, try to look at it as an opportunity. Ultimately you won't be required to deliver (but I would absolutely plan to, just in case), but you still need to be delivering something, so to me this seems like a perfect opportunity to experiment with things you might otherwise not do.

If this is a software project, it's a great place to experiment with:

  • new languages
  • new frameworks
  • new approaches
  • new infrastructure

(amend the above to whatever industry you are in).

I'm almost jealous of the situation you're in! You get to work on something real with virtually no risk!

  • 32
    @LoMa Those are all just examples - the point is that you have the opportunity to experiment with something with almost zero-risk. It's an opportunity to expand your knowledgebase, on the clock, and not have to worry if your new idea doesn't work out.
    – David K
    Aug 8, 2019 at 13:17
  • 50
    @LoMa You could also try and explore some new ways of working (Scrum, Kanban, etc. being the obvious examples) or maybe even try out different roles, arrangement of meetings, etc. This is basically the ideal chance to experiment on every part of the workflow that the team feels might be inefficient. So long as you are still able to get something done for the demo.
    – Blub
    Aug 8, 2019 at 13:17
  • 37
    Can't upvote this answer enough. Go look through all the answers on here where people are complaining about high-pressure, high-risk programming work. Your team is being given a gift. A fully funded project with a degree of freedom and pretty much zero actual risk, zero chance that someone is going to try to dictate awkward scope change or additional requirements, and zero likelihood that you'll be forced into a stressful or overtime-inducing go-live or support mode after it's done.
    – dwizum
    Aug 8, 2019 at 13:24
  • 61
    Another "new" is new team roles. Give more junior members of the team more responsibility than they would normally be qualified for. The more experienced team members can mentor them, and maybe work on some side projects.
    – Phueal
    Aug 8, 2019 at 19:29
  • 13
    Start all your daily standups with a round of darts. Whomever is closest to the bullseye that day gets to lead the meeting, or make decisions, or assign issues, etc.
    – dwizum
    Aug 8, 2019 at 20:41

Stop calling it a failure

The project is going to end earlier than intended due to factors that have nothing to do with you or your company. That’s not a failure.

It’s also bizarre to think that getting paid 3x for the effort of x is a failure. That sounds like the kind of success a lot of people would like to have.

What the customer does with your demo isn’t your problem

Your problem is delivering what you are contractually required to deliver so you can get paid. Whether the customer actually uses it, or takes a year and a half before deploying it (a situation I run into frequently when the government is the customer) or even if they never use it at all is not your problem, and not something your staff needs to worry about (unless there is a maintenance agreement).

Tell your people that their 6 months of work will get them paid for 18 months of work.

It’s a no-brainer business decision anybody can get behind if you just state flatly that it’s about getting paid and nothing else. Everything else is secondary.

  • 119
    "will get them paid for 18" No. The company will get paid for 18 months of work.
    – FooTheBar
    Aug 8, 2019 at 13:05
  • 22
    I'm really not sure that "you're getting paid to do throw-away work" will motivate people. At least, not all people. Aug 8, 2019 at 13:09
  • 39
    @Joe You have to look from an employees perspective. A lot of people like to do work that is meaningful. It may be great for the company, but it's quite demoralizing for some people. Aug 8, 2019 at 15:19
  • 12
    @Joe what "other problems"? Its literally the exact situation OP is in, the "good for the company" choice of doing the work is basically a meaningless exercise in wasting public funds, unless some other kind of value can be shoehorned in.
    – mbrig
    Aug 8, 2019 at 21:01
  • 7
    @GregoryCurrie: Indeed, I got out of software with this being one of the big reasons. Existentially I couldn't deal with 6 or 12 months of my life and labor being thrown into the void. (Took a 2/3 pay cut and was happy to do so, got my health back, etc.) OP should maybe be on the lookout for employees in a similar frame of mind. Aug 9, 2019 at 2:59

What you are being asked to produce is a really impressive proof-of-concept demo.

You've been hired by Party A. They're hiring you, in effect, to produce something that makes them look good - that they can point to and say "look at this awesome thing we were building". That's the actual customer intent, and you have 6 months to produce something that will make that as credible an argument as you can (and, as best you can, undermine the ability of the other side to say that it was a terrible product that needs to be canned). It's distinctly style over substance, and the thing you've been hired for is not the thing that is written on the contract, but you have been hired (and will be overpaid) to make a thing that your customer actually wants.

So, if you can make a demo that really blows everyone away, that's not failure. Of course, you need to have the bones under it be strong enough that if it doesn't get canned for some freaky reason, you can still finish the job, but it's a real goal, and it's one that companies do sometimes get paid for legitimately. It also increases the chance that you'll be picked to create the same thing (or similar things) later once party A is back in power.

  • 2
    ...just be sure to communicate and present things in a way that Party B will not get pissed at you for creating a great demo... Neither during the next 6 months, nor after once the project is (possibly) canned but the demo remains.
    – hyde
    Aug 9, 2019 at 9:09
  • 5
    I think this is a really healthy way to look at it - you've got a hard deadline of 6 months to produce a demo that will make you look good to both sides. Aug 9, 2019 at 9:43
  • 1
    Definitely agree about using it to showcase what your team can do not just to Party A at location X but there may also be another set of Party A members at location Y - you want them to hear good things about your company and your team as well.
    – Dragonel
    Aug 9, 2019 at 19:28
  • Also, keep the staffing levels where they are needed to get the demo up, running, and bug-free in the soonest possible time. Then reduce staffing to one guy who does bug fixes for the remainder of the six months.
    – EvilSnack
    Aug 10, 2019 at 22:30
  • Even if the intended customer doesn't like it, it can be added to your company's product palette for the future. This may be the big break they always needed.
    – RedSonja
    Sep 25, 2019 at 6:31

There will be the possibility that some of your developers are working for you because they want to make a difference - but in reality, most people just want to be working hard on something they're good at and given a paycheck for it.

Nothing you do will really solve the problem for those who "actually care" about releasing the end product (i.e. work for you, to make a social difference). But for those that just care about "doing a good job"; this is an easy situation.

Explain to the developers; the scope has changed, and there's a new target to achieve in 6 months.

Note that this is not a failure. You are not on a death-march to make a product nobody wants - instead, the product scope has simply been changed and the deadline likewise.

Most importantly, you need to make sure the developers understand how this is a blessing for you as a company.

So long as they work hard, and can pull off this new deadline (the demo) to the needed quality - the company has an opportunity to make significantly more money, and move onto even more interesting projects.

If you can portray this as a challenge; getting the demo wrapped up fully and to a high standard, in a now shorter space of time - you shouldn't have any difficulties motivating your team to give it their all.

And again, for those that worked because they wanted to actually "make a difference" with their software; there's nothing you can do. They can take this as a learning exercise in party politics.

  • 12
    If the employer is going to have a windfall from the cancellation, it might be worth offering the employees a bonus for on-time completion of the new, reduced project. Aug 9, 2019 at 0:07

1) Try to identify re-usable components, or overlapping elements which could benefit your other projects. This could provide you with time to develop something which saves money, improves quality, or reduces technical debt.

2) Frame the project in phases. Phase 1 being the demo in 6 months, phase 2 being the complete product in 18 months. Focus purely in completing the phase 1, because that needs to happen. You don't need to underline the fact that phase 2 will get cancelled, everybody knows it. In daily routines don't mention the phase 2 at all, don't plan it, don't resource it. Once phase 1 is complete, the team will still get the satisfaction of delivery and job well done.

3) Offer a bonus. Your company is going to get paid well, so there should be little extra to give to the team. If monetary bonuses are out of question, it could be something nice, which benefits the team (new desks/chairs, coffee machine, sofa in lounge etc).

  • 2
    I like this "share the love" approach. It took some skill and effort to win the original contract. Recognizing that, along with sharing the proceeds, will take some of the sting out of "busy work".
    – DoubleD
    Aug 8, 2019 at 20:46
  • 1
    Re "identify re-usable components, or overlapping elements which could benefit your other projects.": This is not part of normal project thinking (every project is considered 100% independent) and may not be allowed. Aug 9, 2019 at 8:26

Adding onto @tddmonkey's answer, here are some things that could be worked on over the next six months.

Habits and tools

These are some things which initially take a time investment, but pay off long term. Given that the project will be scrapped, this is a great opportunity to make the time investment without worrying about negatively impact productivity:

  • Adjusting to an ergonomic keyboard and/or mouse
  • Establishing healthy programming habits such as stretching, exercising, re-focusing eyes at regular intervals
  • Learning new development tools including
    • New window managers
    • New editors or editor features. Good time to learn about Emacs/Vim the extra features of Visual Studio Code, Atom, Sublime Text, etc.
    • Shell commands (tmux, sed)
    • New shells (zsh, fsh)
    • The proper arguments to the tar command
  • New documentation tools
  • Project dashboards showing test coverage, open tickets, server uptime and resource usage

Development processes

Some things that would be good to have if they're not already set up

  • Automated tools for checking code changes. Can lint and validate against style guides. Can ensure TODOs are associated with a ticket in an issue tracking system
  • Automated linking of the ticket system to code commits
  • Add more test coverage for the existing platform
  • Improve test development and execution processes
  • Work on CI

In short, this is a good time to invest effort in removing as much friction as possible with the team's development processes. What can be done now so that in six months, when the real project needs to be worked on, the work can proceed as smoothly, healthily, efficiently, and enjoyably as possible?

  • 1
    This is my favorite answer. Just because the product is getting thrown away doesn't mean that it can't be practice. Also, who doesn't have the arguments to tar memorized? /s Hint: someone once showed me this way of remembering tar xvf - Xtract the Vucking Files - it's so hilarious it works! Aug 9, 2019 at 1:10

Companies and organizations cancel projects all of the time. That doesn't negate your work, the value of your work, the experience you gain from that work, nor the money you earn from that work.

The difference here is that you know beforehand that the project will be cancelled. I would fill the team in but I wouldn't present it as a failure, because it isn't. What the client chooses to do is their prerogative. It doesn't negate, or diminish, or devalue the work you and your team are doing.

Also, nothing is ever 100% certain. It may come to pass that the project doesn't get cancelled. Work on it as if it won't.

  • 3
    Agreed. Politicians change opinions about as often as they shake hands. A lot can happen in six months that might keep the project alive. At the end of the day, you want to be able to say that your company held up its end of the deal and was on target to complete on budget.
    – aleppke
    Aug 8, 2019 at 20:41
  • 2
    How does a guaranteed mid-project cancel not negate the work or value of the work? Work doesn't have value until it does something. That's the whole point of the sayings like "done is better than perfect." As for experience gained... apparently they already have experience with their "stack". Most of the experience gained will be "project experience" which, depending on the contents, could be completely nontransferable
    – Mars
    Aug 9, 2019 at 2:58
  • @Mars That's a subjective value. I know plenty of people that value the work more than what it's actually used for. I'm not saying it's a good approach do developing software, but it's definitely out there.
    – Luaan
    Aug 9, 2019 at 6:18
  • @Luaan What do they value? I'd argue that it's not the work they value, but the experience or learning opportunities, or at least the challenge. In this case, it sounds there will be none of the above.
    – Mars
    Aug 9, 2019 at 6:22
  • @Mars Nah, they value the money and work-life balance they get from the job. They're usually the kind of people who don't care much about things like learning opportunities or challenges - they just want their stable 9-8 job, and go back home to their families. Don't assume everyone in software development is a "craftsman" who cares much about the work they do. And even with the "craftsmen", they might be more interested in the cool things they did with the code than whether the code is actually useful (still a very common problem).
    – Luaan
    Aug 9, 2019 at 6:26

Give it to them straight.

Trying to soften this won't be doing them any favors. The facts are what they are - they're still expected to produce something functional. It doesn't matter that this might affect morale - if this is really "neither the first time nor the last", this is a reality they they need to face head on as soon as possible.

However, be careful.

100% canceled? Politics are what they are, and you have absolutely no guarantee that some external factor won't swoop in, and suddenly you're expected to actually finish this thing.

Take it seriously.

Anything you produce, anything you put your name on, will always reflect upon you - regardless if there are unfortunate circumstances surrounding the production. Remind them of this, if they need reminding.

Death and taxes

Again - I can't stress this enough - regardless of you certain you are, the only things certain in life are death and taxes, as the saying goes. If you half-ass this, or treat it as a playground or something, it can absolutely come back to bite you and your team. As the manager, it's your responsibility to make sure this doesn't happen.

  • 1
    "Public funds waste is neither my problem nor my company one." – OP. Anyone who knowingly works for someone with an attitude like that will have no problem with it. Either give it to 'em straight or don't give it to them at all. Considering that the question was even asked, it sounds like the latter is the better option.
    – Mazura
    Aug 9, 2019 at 2:59
  • A clarification regarding "neither the first time nor the last" means for me and for the company but this is the first time we know with so much notice.. This is the first time for this team
    – loMa
    Aug 9, 2019 at 6:29
  • 1
    I absolutely agree with the the "be careful" part. The farther you look into the future, the more the 100% certainty vanishes. Aug 11, 2019 at 9:55

Keeping it secret is not an option, people will find out. If they learn that you are keeping secrets from them, they will really be demotivated. So the question becomes how to tell them, rather than if.

You are obliged to deliver a "demo" in six months. Is there any reason that "demo" can't be a working, useful system?

It will obviously not have all the features the customer originally asked for, but it can still be useful.

So, what I suggest is changing the scope of the project. Identify the parts that cost a lot of effort without adding much benefit. Skip those parts. Make the rest and call it a demo.

The goal is to have the employees of the customer start using the system even if there is no official approval of it.

Then, when party A comes back in power, as they eventually will, you can talk about extending the "demo" into a better system.

Now, several other answers point of that politicians change their mind. This means you have to have a plan in case they don't cancel the project.


If the company is making a mark-up of 200%, one way to motivate your developers is to offer them some of that, surely? Say, an extra month's pay on acceptance of the sham product if (as expected) it gets cancelled after six months. You could even give them the option not to participate in the work, but I doubt that there would be many takers.

  • 1
    I seriously doubt this is OP's decision.
    – cag51
    Aug 10, 2019 at 11:37
  • @cag41: So do I, to be honest. It's the kind of thing that only an exceptional manager would do.
    – TonyK
    Aug 10, 2019 at 11:43
  • I meant, I don't think managers -- exceptional or not -- usually have the power to assign significant, off-schedule bonuses. Particularly in a large company with a lot of bureaucracy, which is pretty clearly the case here. And, to be fair, doing so would create questions about fairness -- why does OP get an extra paycheck when others working on high-stress projects that DON'T get cancelled do not?
    – cag51
    Aug 10, 2019 at 12:26

From a business perspective, this can be a good opportunity if you're not contractually bound to complete the project with the exact current team.

This would be the time to assign 90% of your seniors' time to a more valuable project for another customers, and hire a crew of junior developers to work on the government project.

Junior devs need experience and mostly produce code that won't last well, but that will be fine for a demo. Many junior devs work very quickly, so you can deliver the minimum requirements. They'll get to cut their teeth on a throwaway project, integrate with your existing team, show their worth.

At the end of the day, you'll have a second effective crew to handpick staff from to expand, replace seniors that will have left in the meantime, form a second team if desired.

If you're not in a position to make such decisions, consider discussing it with the decision-maker.

  • Change team members is not a problem and to some extent is a thing I can do without request any approval. Whereas contract prohibits outsourcing
    – loMa
    Aug 19, 2019 at 7:50

As a long-time developer, I've learned to assume that ANY given project might never make it to production. The solution is to view every project as a learning project. And the way to do that is to do the best possible job, using all the best coding practices and the most up-to-date technologies.

As a developer you are always learning and should always be improving, even if you're working with a familiar language and/or technology. If your team takes the time to make this project the best it can possibly be, this will be a great experience for everyone, and an extraordinary skill uplift opportunity for your team. On the other hand, if you give up on it now and twiddle your thumbs for six months --or even do just the minimum --everyone will be bored and miserable, and your team's skill level will drop, rather than improve.


Now we are exactly in the last situation: party B won the recent elections, but the board of directors appointed by party A will hold office for a further six months. The project I will manage should last 18 months. We already know that when the new board will come to power, they will cancel the project.

So? This is not the last election. This is not the last board. Your headline states the project will fail, your question states it will be canceled. You should view it as the project getting postponed. When party B's governing time is over (and not every government even serves out its time), the project might get continued, or it might get a new invitation for bids.

This is your chance to get paid royally for six months of doing an entry for this future invitation for bids. Don't waste that chance. In particular since this is also an option to prove to party B that even if they will cancel this project, it would be abysmally stupid to ignore your capacity for doing great work for their own projects.


First off, what you are describing is not a project failure at all and you are doing yourself and the team a disservice by claiming that it is. Intentionally or not you indirectly placing blame and responsibility on the team and their work; any professional will take your approach as a personal failure to some extent.

The situation is outside of your control and any professional on the team will understand that. You need to be direct and transparent with the team so they understand what is transpiring.

I find it a bit unusual that you can state it so clearly on Workplace but don't feel like the team is professional enough to get the same explanation.

  • 7
    We don't run the risk of getting demotivated. Aug 8, 2019 at 13:10
  • Do you think the question could be improved by describing that differently (e.g. working on an end product that we know will be scrapped) rather than failure of the "project"? If so you could suggest an edit to the question -- perhaps the OP has just described it as "project failure" as shorthand here. Aug 8, 2019 at 19:56
  • @GregoryCurrie If there's no risk to morale I don't see why OP asked the question.
    – HenryM
    Aug 9, 2019 at 2:34
  • 5
    @GregoryCurrie Unless you happen to be a taxpayer :p
    – Mars
    Aug 9, 2019 at 4:21
  • 1
    @HenryM Gregory was responding to the part about OP asking on workplace vs saying the same thing to OP's team.
    – Mars
    Aug 9, 2019 at 4:21

The concept of "a working demo" sounds wonderfully vague, especially in the Alice-in-Wonderland environment you are working in.

Just spend a couple of weeks throwing together any old junk that looks vaguely like a demo, then sit back and enjoy getting paid for doing nothing.

If you political masters are stupid enough to operate as you describe, they won't be able to tell the difference. If they do comment that the demo wasn't very good, tell them they are lucky the project will be cancelled before it overruns its budget by a huge margin, because it turned out to be far more complex than anticipated.


Try an iterative approach like scrum. Make shure that at the end of every iteration you have a "product" that has some business value. That way you have something that can be used and has value after the six months (Or at any time). And it may be not a waste at all.

  • 1
    I am not sure how scrum would help here with the fundamental problem, but it may be easier to get any output at all.
    – Sascha
    Aug 10, 2019 at 16:19
  • I doesn't have to be scrum, but an iterative approach to have a useful product after only a few iterations.
    – keuleJ
    Aug 10, 2019 at 16:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .