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