Back to resources

Inheriting a Project Behind Schedule

Deadlines
Productivity

19 May, 2021

null null

null null

null at InVision

Shawn Hartsell, Lead Software Engineer at InVision, recalls his early days at a new company as he took over a project that was falling behind schedule.

Problem

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.

Actions taken

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.

Lessons learned

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

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

"You don't care about quality" A story of single metric bias

3 February

This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.

Product Team
Productivity
Team Reaction
Alex Shaw

Alex Shaw

Chief Technology and Product Officer at Hive Learning

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Productivity
Prioritization
Performance
Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies

Mindsets of High Performance team

14 October

Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.

Innovation / Experiment
Mission / Vision / Charter
Building A Team
Productivity
Feedback
Motivation
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Checking For Values Alignment When Considering a New Role

20 June

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.

Changing A Company
Goal Setting
Managing Expectations
Company Culture
Leadership
Productivity
Convincing
Motivation
Psychological Safety
Toxic Atmospheres
Health / Stress / Burn-Out
Performance
Tommy Morgan

Tommy Morgan

Head of Software Engineering at Tidelift