Inheriting Projects

From a Design & Front-end Perspective

At Switch we have been lucky enough (or unlucky enough) to inherit several projects over the years. In this article we have a quick look at some of the things we have learnt from our experiences. There’s always a risk taking on someone elses project due to the increased learning curve, so it’s always best to ask the right questions at the beginning before kicking off on design and development.

Our talented Project Management team handle the bulk of the project transition, to ensure this is a smooth experience into the team, they step through a bunch of workshops and checks before introducing the project to us. We’re fortunate being on the design & development team as it’s quite hard trying to get a sinking ship upright again, particularly if the project has been live for a while and has gone through several phases of development.

The article below comes from a Design and Front-end perspective, we’ll leave the management side of the transition for one of our Project Managers to handle as it’s definitely worthy of its own article.

Project Evaluation

To help the project management team, we’ve come up with several questions that give us a general idea of the project. The best case scenario is if we are able to meet or chat with the existing development team and have them walk us through the history of the codebase together.

  • How old is the codebase?
  • How many parties has this project passed through?
  • Is there any documentation?
  • What operating systems and browsers does the website need to support? Where else is the website being used - kiosks, tv screens, mobile applications etc.
  • What are the next technical targets they need to hit? and when do they need to to go live with them?
  • Are there any other parties directly involved with the project? such as an SEO agency
  • Are there any issues that have been raised by the client? What can we do on the technical team to help salvage customer confidence and satisfaction

Depending on the answers to the above, we usually recommend rewriting the front-end code to match our in-house standards that we have setup over our many years of Sitecore experience. As developers, it’s never fun having to work around someone elses code and hacks, as it always incurs additional time. The project will also become ’that’ project that none of the team want to work on - which is never good for the projects success nor the teams morale.

The Visuals

The design handover is usually much simpler compared to code. The design team can usually ascertain the brand based off the original creative brief or other brand documentation. There are a few questions to consider though

  • Current status on the design - was it causing any issues for the technical team or was the design not on-brand?
  • What works and what doesn’t - they do or don’t they like about the existing design? and why?
  • What can we improve on - how close do we have to follow the supplied design concepts? is there any leeway and budget for us push the designs to improve on them?
  • Other design requirements - such as accessibility
  • Are all design assets available - such as PSD’s, logos, brand guidelines, fonts

Don’t Be Afraid of Spaghetti Code

Inheriting someone elses code is one of the most challenging parts of being a developer. The dream for every developer is to be able to rewrite the project but this rarely occurs as the client usually doesn’t want all of the money they’ve spent so far go to waste (plus someones head will usually be on the line).

In the beginning it is always best to always expect the worst spaghetti code you’ve ever seen... there are always some nice surprises and unknowns in the code that you cannot discover until you actually get stuck into the code.

Where the existing code is to be maintained, we have found that following the guidelines below help us maintain focus and productivity.

  • Check your surroundings - don’t just dive straight into the code, get a better understanding of the code and make sure you’ve got all your bases covered. See what’s been done already so you aren’t rewriting something that may have already been done or can reuse.
  • Change as little as necessary - except for the parts that need changing. It’s also helpful to work and commit more regularly and in smaller chunks. There’s no need to get frustrated about existing code, you didn’t know the circumstances behind their decisions.
  • Leave comments in your wake - a few lines of documentation will help future developers save tremendous amounts of time for future efficiency and maintainability.
  • Test more than usual - another downside of inheriting a project is that you never know how your changes may affect other areas of the website. There is nothing worse than deploying the website with bug for a new client who has just gone through a bad experience with their previous provider.
  • Note down improvements - whilst working through the project be sure to jot down improvements that will give the client more bang for their buck. Project managers will value your opinions and any advice we can provide, whether for performance, scalability or general efficiency will build trust and success for the project and client.

Prepare for Kickoff

Once the project is ready to begin, the team have found a project-kickoff meeting is always great to get the team into the swing of things. When inheriting a failing project, this is particularly important so the team can get a good background of the project and avoid the same pitfalls. Some points we cover in our kickoff meetings are:

  • History & background of the project.
  • Understanding of the product or service provided.
  • Overview of the project team and stakeholders.
  • Pitfalls of previous project owners - how should we avoid them.
  • What the customers satisfaction level is at this point, what are the outstanding issues and where we can quickly add value.
  • Setting goals for success.

Communication is Key

All in all, there is a common binding factor for all the above - communication. Communication within the team and with the project stakeholders is key, the success of knowledge transfer between all parties is essential in assuring a successful and smooth transition. Having the appropriate information will save everyone many hours of pain.

As a designer or developer, being transparent and upfront about the additional time & costs of an inherited project is appreciated. We shouldn’t be arguing with our project manager or our project stakeholders on any restraints, as we’re all looking for the same thing - the project’s success.

Here at Switch, we are always striving to evolve and improve our processes, there is no one-size-fits-all, every project is different. If you have any other ideas or thoughts, that have worked in the past, we’re always open to suggestions. Hopefully this article gives you some ideas on making the project inheritance process as painless and productive as possible.


Want more?

Back to the Blog