What I learned in the last project

At Bending Spoons, we are approaching the end of a long project. The focus of the project was to develop a single library that grouped together several minor libs we had developed in these years. The project started in November 2019 and we are about to release the first apps with it inside.

We did several mistakes on this journey, but these taught us a lot: not only about technical topics but also about team cooperation and people management.

The goal of this post is to share what I learned in the 3 major phases of this project: preparation, execution, conclusion. I hope these pills can help other people in managing their projects.

Preparation

During this phase, the team is studying the problem, understanding the scope of the project, which tasks must be carried out, and what resources are needed. This is a planning phase and it is considered finished when the team has a clear idea about what to do.

Write ahead what’s your plan.

The first thing I learned is to jot down a plan for the project. The plan should be divided into phases that will be split again by the team. The goal of the plan is to identify the main steps that the team has to tackle to complete the project successfully.

It has another benefit: people interested in the project can follow it easily. Whenever they need more information, you can link them to the plan and use it to explain in which phase the team is and on what it is working on.

It can be used also as a guide to define estimates on when each phase should be finished.

Set timelines to manage expectations.

Your team is not the only part invested in the project. There are several other people in the company that shares an interest in the project. Setting up a timeline of when every phase of the plan would be finished and, ultimately, when the project could be considered done, helps to provide all the information these third parties could be interested in. It can also start discussions about why the timeline is so long (or so short) and it should improve the estimates extracted from the plan.

Always keep in mind that there could be unforeseeable events that could delay the timeline. Plan for them by increasing those estimates: it’s always better to finish the project sooner than expected than to deliver it with a big delay.

Deliver small documents before starting…

When you start working on a project, you have to design one or more components, the architecture of the project, and take several other decisions.

Write them down in their own small document: collect all the reasoning performed, all the alternatives considered, the pros and cons of each of them, the final choice, and why that has been chosen.

This will not only become part of the documentation for the project itself, but it should make it easier for other people to jump into the project.

I want to stress that the documents must be small. People are submerged with other things to do: a single document of 40 pages can be frightening! Having several smaller documents allows other people to read them when they have time.

…And ask feedback as soon as you can.

Once the document is created, ask for feedback. If they are small, people should be able to look at them, understand what is their purpose and your choices and then you can discuss them. The feedback loop should be quicker and it would help you adjusting the trajectory of the project.

It should also prevent big changes while people are implementing the project and should prevent some big wastes of time.

If you are redoing something, write down how much it took the first time.

If your job is to reimplement from scratch something that was already there, take some time to understand how long it took to create it the first time. Not only it will be a great guideline to craft a good estimate of how long will take to finish the project, but it will also help in managing the expectation.

If you need help from other teams, communicate the need as soon as possible.

It can happen that your team requires support from other teams. As soon as you discover that, notify the other team and organize a meeting with them to plan the work. Unpredicted coordination among teams can be disruptive because all teams have their own goals and agenda and those are rarely aligned and can lead to great delays.

Execution

During this phase, the team is focused on implementing the project. It’s the phase characterized by the practical work.

Keep track of all the decisions your team takes.

Take notes about every decision your team makes and why it has been taken. Save them into a document. Those decisions usually come out from meetings and informal discussions, but don’t let them slip away. After some time, you could end up wondering why you took some decision, and reconstructing the reasoning could be really hard without this document.

Keep track of all the decisions other teams take.

If you are collaborating with another team or if you need the help of other teams, it is your duty to record how the discussion goes, the decisions taken, and why. Not theirs.

Write those down on a dedicated document, maybe a document for each involved team. As soon as a new person joins or the other team asks what or why something has to be done, you can recollect the document, reconstruct the discussion, and provide the required information.

Notice that some decisions can be reverted if new facts are unveiled.

Keep track of all the time spent in meetings and the topic discussed.

As much as it’s your duty to keep track of all the reasoning about some decision, it’s also your duty to ensure that not too much time is wasted on meetings and it’s your job to keep track of how that time is invested.

Involve people.

Involve people in the project. Let them take ownership and discuss everything together. The most they become attached to the project, the more they will care and the best output they will produce.

This does not mean that they have to participate in all the meetings and in all the discussions: this will be disruptive and highly inefficient. Remember, a 1-hour meeting with 5 people costs 5 hours, not 1. However, prepare follow-up messages and summaries and share them with your team. Ask for their opinion and adjust the design and the goals accordingly.

Let people try.

Trust people and assign them complex tasks: they will surprise you. When tasked with a difficult job, smart people go the extra mile to show them worthy. Yes, maybe you have to iterate on their solutions more times but, in the end, it will pay off:

1. they will be more satisfied with their work.
2. they will grow, becoming able to tackle more difficult tasks. And this is good for the company too.
3. they may become very knowledgeable on some topics, even more than you.

Never Assume, Always Ask.

When reviewing something (a piece of code, a document, anything) never assume why something has been done as it is. Always asks. If you are surrounded by smart people, they had thought about the problem much harder than you did, before producing the solution. So they are more often right than wrong about what they did.

If there is something that looks wrong or that is not fully convincing, ask why it has been done like that and what were the underlying assumptions. When all the cards are on the table, if the solution is still unconvincing, elicit the doubts and try to work out a different solution.

Project Conclusion

The project is now close to an end. The team is about to put it in production or actively start using it.

Summarize all the above information in a retrospective document.

At this point, the team should have gathered a big amount of information on how the project is evolved.

Creating a retrospective document can help you understand what has gone well and what has gone wrong. The team should dig deep into the “wrong” elements, trying to understand why those happened and how can be avoided in the future.

Plan for potential next steps

In every project, pragmatism kicks in, sooner or later. There are improvements and nice-to-haves that your team would like to implement but those were not planned or would require too much time.

Do not desperate: write them down and, once again, create a plan for them. This plan would be evaluated weighting in other company’s priorities and it could end up not being performed at all. However, in the case it is, you should be able to start again from the first bullet of this list!

Every project is an occasion to grow. I’m confident that following the above suggestions could improve the output of the next project and also gather enough data to learn from the mistakes that would inevitably happen. Embrace it and don’t stop learning.