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.

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.

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.

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).

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?

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.

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.

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.

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.

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.

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.