One of my mentees reflected with me recently on a long project that she was leading. One of the things that didn’t work was the team’s motivation throughout the project. It wasn’t too high when the project started, and as the project dragged longer it disappeared almost completely. My mentee found herself carrying the load on her own, constantly needing to push the team forward.

I’m sure you all know the feeling. Every now and then there are things that simply need to be done, even if they are not that exciting. And some of them are longer than others, which makes it really hard to maintain the excitement, or even the willingness to simply do the work needed to get the project done.

These projects are usually a necessary evil (more on that below). But within this situation, there are things you can do to make them successful and less painful for everyone. 

Convince Yourself First

If you want to get people excited about something, you need to make sure you are excited about it yourself. Remind yourself why this project is important and what you are hoping to get out of it. Focus on the impact – once the project is over, what would become possible for your customers, your product, your team, or the entire company?

Make it as tangible as possible. What would success look like? Where would it lead you? Describe the flow of events and tell the full story. Add the details and make it a reality.

Your goal here is to make sure you truly believe that this project is key and that now is the time to do it. You should feel motivated and excited to get started. But what if you don’t?

If you can’t convince yourself that this project is what your product or company absolutely needs right now, it’s time to raise flags. If you simply don’t understand why this is important, or why it is important now, go and ask around. Ask your manager or the person who initiated the project for their point of view (for example, the development lead if this is a technical debt project). Understand why they think it should be done at all, and why now. Ask questions and explain things to yourself until you can truly feel that this is the most important thing to work on right now. If you can’t convince yourself (and only you know if you are a true believer), you will have a hard time convincing others, and the likelihood of this project succeeding is very low.

A note about “disagree and commit”: I’m a big believer that sometimes this is a must-have for an organization to function properly. You can’t always challenge every decision, and you should definitely pick your fights. However, disagree and commit works much better when the risk is low. For a long or resource-intensive project, if you are not 100% into it, the risk in doing it anyway could become too high in terms of its costs and your ability to lead it to success. Reflect that to your manager and discuss alternatives before you move on.

Over-Communicate the Why

At this point, once you are fully convinced that this project is important and would make a great impact, you should be eager to get going. If you are not – go back to the previous step, but if you are – now it’s time to get the team into the same state of mind.

As with any requirements you are writing or defining, the context makes the difference. When the project isn’t exciting in and of itself (think updating to a more modern design, scaling the infrastructure, adding a complex integration to a customer’s ERP system) it is even more important to connect all the dots for people. You should go end-to-end and into the details. Explain exactly why this project was prioritized over everything else you could have been working on, what impact are you expecting it to make, and the future potential that it opens. Paint the detailed picture of what success looks like, so that the team can feel it, not only understand it.

You should make a deliberate effort to over-communicate the context. That is, challenge yourself to get people to tell you “yes, yes, we know exactly what the context is, you told us time and again”. I’m guessing that you will fail. The reason is that this communication is never too much. Whenever you repeat it, even if they already got it, it emphasizes other aspects that they might have overlooked previously and helps them get clarity on decisions that they need to make, that they didn’t need to make the last time they heard it. So there is usually an enormous value in communicating the why time and again.

Make sure they get it. Make sure they feel it. Make sure they want it.

Deliver Value Regularly and Frequently

Congratulations! By now you should have a motivated team to work on the project. However, maintaining that enthusiasm over time is hard. And the longer the project, the harder it is. One of the top motivation killers is slow pace, and longer projects usually move slower than others – if not by actual pace than by the feeling, since with the same amount of work you accomplish a smaller part of the outcome compared to shorter projects. 

This means that with longer projects you as a product leader must work harder to overcome this, and the best way to do this is to make sure you deliver value regularly and frequently. This is generally a good advice, with anything you work on, but here it is absolutely crucial for your success.

Alas, it’s not easy to do. Breaking large working blocks so smaller ones so that they still deliver value is challenging. I’m sure you experience that when a user story is too big to fit into the sprint, and you need to break it into smaller pieces so that it still fits in. Or when you think about the definition of your MVP. Simply breaking the work down into pieces is not a problem, you can always decide to work on the infrastructure or UX separately. But that defeats the purpose – since they don’t have much value as a standalone deliverable. When you break it down, you should aspire to have a piece of the product ready at any point in time, not a piece of the code.

As challenging as it is, it is also important for your success, for a variety of reasons. When talking about motivation – the delivery of a valuable feature feels like an accomplishment, while the delivery of pieces of code that don’t add up feels less so. On top of that, you might be able to actually release it to your customers, let them enjoy the benefits of it sooner rather than later, and also provide you with relevant feedback early on. This magic circle continues to work for you in another way, as it prevents over-engineering and would sometimes allow you to stop when 80% of the value has been delivered with just 20% of the work. And that is something you can’t do if you build 100% of the infrastructure first.

As I said, being truly agile in the sense that you should always have a working product at hand is a good idea for any project. But for longer ones, it is a must. Not only will it increase your chances of success, and help boost the team’s motivation, it can actually make your longer project shorter (and I’ve seen this happening time and again when done right). 

Sometimes, longer projects just need to be done. But with the right approach, they can be fun, engaging, and making an impact that is worth their effort. It’s up to you.