Inheriting a Project Behind Schedule
19 May, 2021
null at InVision
I joined a company that was in the midst of changing its financial billing model. The project of rewriting the whole system had been in development for a year and a half and had been passed around to different teams. However, no significant progress was made, and I was hired to take up where everyone had left off.
When I joined the Monetization team, I was told that the project would be completed within three months, an unrealistic assessment made on past estimations. Even a cursory glance at figures assured me that this was not possible. Project objectives were not clear, no tracking was set up (not even in Jira), dates seemed randomly picked, and PMs could not come to a consensus on how the UI/UX would look like in the end . Moreover, the whole project was looked at from an isolated perspective of building code without thinking about the larger business impact.
For starters, we had a week-long onsite with the original product and engineering team and all key stakeholders to reevaluate what has been done so far. The intensive communication also helped us familiarize ourselves with the problem, gain domain knowledge and identify the most critical gaps.
After I did some digging, I realized that problems were not of technical nature. The code itself was quite decent. But as we started to map out the project and learn more about business cases, we realized that the code could not satisfy all of our business requirements. It had nothing to do with the code being buggy or alike but with gaps in product ownership. In lengthy conversations I had with the former PM, I realized how everything was wrapped in assumptions, and as a new person on the team, I was rather critical towards assumptions.
Soon I learned that the project was not tracked in any other way than spreadsheets. I collected all available plans and created a centralized repository of all the documents. I studied all of the existing documents and did some back of the napkin math because we had no data to base our estimations. I was reluctant to make any commitments with insufficient data, particularly not to dates set by past team leads. Being transparent about that was critical because the leadership was led to believe that the project was further along than what it was.
To be able to provide some crudest estimation, we had to make a formal delivery plan of what we were going to build. The PM and I worked hard to put everything in Jira and then formalize the plan. We invited all stakeholders to take a look and give their feedback.
We laid all of the feature gaps in the plan. Once we wrote stories for the features, we committed not to work on anything until we knew what the definition of Done was. The definition of Done should also include who -- other than a developer working on a feature -- should define that. That was assigned to different stakeholders, and we slowly started to rope them into the decision-making process. That was a precondition to do the gap analysis -- what we didn’t have and what we should have.
The next thing I did was formulate a timeline that was not anything but easy with insufficient data at my disposal. I was cautious about setting up the final date and instead decided to go with small, incremental wins. I broke down everything into incremental deliverables and milestones. Some stories I inherited were too broad and too vague, for example, “write trial system,” and I had to reframe them first to be able to break them down.
We also sped up our regular two-week sprint cadence into a weekly sprint which enabled us to receive feedback faster. Our goals were based on that weekly cadence, and every week we were able to demo working software in production. We were lucky to have a great infrastructure that would allow us to deploy in production anytime we wanted. As we were pushing out more and more features, we started to work more intensively with internal stakeholders. They could give us fast feedback on which we could iterate even faster. By iterating quickly, using things like feature flags that we could easily toggle on and off, people could develop code safely while playing with the software.
Finally, gaining trust as a newcomer who took over a project other people worked on before was often taxing. I had never intended to diminish their efforts, but I had to provide an explanation about the obvious disconnect between our different approaches. Being open and transparent at all times helped me to earn trust even as a newcomer. The leadership appreciated my efforts to provide them with accurate data, and while they had more domain knowledge, they were willing to listen to my ideas.
- The importance of having a plan that breaks down deliverables into something that will bring incremental value to customers is critical. Including your customers and end-users in the development process as soon as possible will help you gain trust and correct mistakes quickly.
- A great benefit of agile methodology and fast deployment is that you can receive fast feedback and reiterate rather quickly. In the end, the project that was planned to be completed within three to four months took about a year and a half. However, we were shipping bits and pieces all along the way and were open to feedback from customers and end-users.
- Though I was new to the company, I worked on similar projects before and was able to identify complexities from the business perspective. I understood that the entire rewrite would heavily impact different stakeholders and, from the very start, made sure to have them on board.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Tommy Morgan, VP Engineering at Crystal Knows, recalls a time in his career when his values didn’t align with his superiors and shares his insights on preventing this outcome when taking on a new role.
VP Engineering at Crystal Knows
Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.
Engineering Manager - Patient Experience at Curative
David Kormushoff, Director at Koho, recalls how he galvanized his team to tackle a time-sensitive problem, sharing his tips on how to shift chaos into calm.
Director at Koho
Suryakant Mutnal, Engineering Manager at PayPal, discusses the importance of time management and the necessary structures in order to create internal consistency.
Engineering manager at PayPal
Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.
Head of Frontend at Doist