Mess to Masterpiece — How to Turn Around Inherited Projects

One of the ways that I cut my teeth on innovative tech projects was to take on a project that was already going South. After working on a few projects, and applying my newly minted Agile knowledge, I was thrown into the deep end. I took on a project that was already in full swing. Discovery was done a few months prior to me starting and the team was already set. There was a lead developer, a couple of front-end guys, a backend dev and a designer. There was also a quality assurance (QA) engineer on the project. The client was already working towards the release of their flagship product and had set expectations. And it was horrible. Truly horrible.

The “work packages” were whatever the client had most recently thought of, the developers worked at their own pace, and designs were often done to retrofit whatever had already been developed… and then it was developed again with the new designs. And DevOps? Forget about it. The continuous integration, continuous delivery pipeline (CI/CD pipeline) was a bombsite. The QA was testing on his local device, development environment and production. They were all different. Sometimes the most up-to-date version was on production. Sometimes it wasn’t. Bugs were often irreproducible and certainly weren’t logged in any systematic way. And the least surprising news of the day: the project was behind time, over budget, and no closer to achieving anything (I can’t say “what it set out to achieve” because it wasn’t really clear).

So what do you do when you inherit a project that is a complete mess?

Photo by Tim Mossholder on Unsplash

Starting Over without Starting Over

The temptation is to scrap everything done and start from scratch. But of course, you probably can’t do that. Unless you have inherited a flagship product moments into implementation, the project will have a significant budget already committed and will be working towards a timeline. Even if the scope isn’t clearly defined or strategically aligned with specific business outcomes, the team will have put significant effort into what they have built so it would be terrible for morale, not to mention a waste of resources to wipe the slate clean. Furthermore, it is highly unlikely that no value was created before you joined the team so best not to disregard everything.

In reality, you need to quickly assimilate with the existing team, whilst leading the project and maintaining a good relationship with the senior stakeholder on the client side. You need to find a way to stop the rot, keep whatever good work exists and clear out the deadwood.

An apparently quick and easy fix is to change the project team. Bring in new developers and designers and get them to take over. Anyone who is familiar with my work will know the Project Success Pyramid (PSP) attributes successful outcomes to four critical success factors, with personnel being the least impactful of the four. So when approaching a messy project in the implementation stage, changing team members is the last port of call. New developers with the same poor processes will give broadly the same results.

How should you approach it then?

Each project will be unique in almost every key area so you will need to apply those nuances to your approach. However, there are some fundamental actions you can take that will significantly improve your chances of effective course correction.

1. Stabilise processes — Whatever is going on in the project when you start, you need to be able to track activity. These aren’t so much metrics as you aren’t necessarily using this to measure productivity or any other output. But you need to be able to understand what is being done, by whom and what the result looks like. There will be processes in place (albeit not the ones you want or being implemented properly) so find out what should be happening and get the team to stick to those processes… for now.
2. Run a mini discovery — Once you have stabilised the outputs through encouraging the team to execute the existing processes effectively, you want to get to the heart of the matter. At this point, the project should be able to continue as it was, but in a more predictable manner because of the work you’ve done in point #1. You have the opportunity to spend some time with the client and senior project team members to reestablish what the desired outcome should be. Confirm the problem statement, user persona, solution hypothesis and success criteria. Run a quick tech stack audit, examine the CI/CD pipeline and overall deployment process. Decide on a new workflow. And crucially, create a prioritised, estimated backlog of testable user stories.
3. Align existing planned work with new outcomes — Now that you have the outputs from your discovery, you need to go back to the live project and go through the old backlog. Work top-down from desired outcomes to establish if any old work needs to be completed. If it aligns with the newly minted objectives from discovery then add the right detail to match the new stories. Remove anything that doesn’t directly move the needle for the new success criteria.
4. Implement new processes — You now need to make sure that the workflow and communication meet the necessary level for you to lead this project to success. If you need to add environments to the CI/CD pipeline, get the DevOps engineer to do so. If you don’t have one, hire one, or get a back-end developer to add it to their tasks (if they are capable). Document all tools being used, from Figma to GitHub and make sure everyone is aware of what should happen, when and with whom. Also set out a communication schedule. When should there be a showcase? What about mid-point calls with the client? And business analysis sessions? Who needs to be informed with merely an email update? And how will the internal team work together? Get the processes in place that you need to be able to be successful.
5. Train the team, Get Stakeholder Buy-in — Everything is now in place. You just need to work on the “personnel” part of the project. Spend time with each of the team members individually and as a group to get them up to speed with the new ways of working. This should always be a dialogue. If there are things about the process that they don’t like then take time to understand their reservations and agree to revisit it after they have given it a chance. Stand firm on your process but be willing to listen, and if you aren’t getting the desired outcomes after a short period, consider taking on their suggestions. Make sure that everyone is comfortable in knowing who will do what, and the conditions under which they should receive and give work.
   Educate the client and other senior stakeholders, on what they should expect under your leadership. Set your own review criteria and get them to buy into your commitment.

Conclusion

Although challenging, taking over a project that has been a bit of a mess is an opportunity to turn things around and bolster your reputation. Consider everything that has been done as part of the road that has led you to where you are, good and bad. Don’t assume anything and only make changes once you have steadied the ship. Then slowly, correct the course with clearly defined criteria and robust processes, giving the client and the team an objective yardstick by which to measure your progress.