This post is for you clients who have already selected Sitecore as your new website platform and is starting up a new Sitecore project.
Here are a couple of my thoughts on how you can get your Sitecore project on the right track from the beginning, by setting the stage for a good collaboration with your implementation partner.
The website you a building today should also be the website for tomorrow and hence the website you are building should be extendable, flexible and scalable. It is absolutely possible to build a Sitecore web platform which will last many iterations – considering that you take this into account early in the process.
Select your implementation partner carefully
Your implementation partner is the single most important collaboration partner in your project. They bind everything together; requirement specifications, user experience design, hardware, software, domain knowledge and more, and is therefore crucial for the project’s success. Therefore your primary focus initially in your project should without doubt be to find the right implementation partner.
In my opinion, what you should focus on is:
Human chemistry: A website is not primarily a technological project, but a communication project. Therefore select a partner with whom you can communicate openly and freely. If you sense that they are listening, factors as for example domain knowledge is less important.
Experience: Sitecore is not a difficult tool to learn – but is takes time to master. Therefore, try to find a partner which has multiple large scale projects under its belt, and preferably with projects which has undergone a number of iterations.
Technology based: In my experience, companies which are technology based, i.e. which focuses primarily on the integration and platform parts of the solutions compared to the user experience driven companies, e.g. design agencies, makes more future proof Sitecore solutions. Therefore if you are looking for someone to build your future webplatform as opposed to just your next website, opt for a company with vast knowledge of Microsoft .NET and surrounding technologies.
References: Most implementation partners can most likely show an impressing list of references – but please do not stop there. Call their references and enquire about support, quality etc. Hearing whether their existing customers have gotten value for money is very useful.
Don’t be too specific in your requirement specifications
My suggestion is that you use your implementation partner as a sparring partner on requirements. Remember that these guys have built other solutions before yours and might bring experience, skills and functionality which will benefit you. Also, allowing multiple implementation partners to suggest different solutions to your website’s objective – as opposed to a RFP checklist – will allow you to better evaluate their creativity.
Therefore, in the specifications, try to explain the objectives you have for your company, users or editors, instead of the precise functionality. In Pentia we have had multiple requests for debate forum functionality in solutions – which in our experience is a prime example of a specific functionality which is often never used by users. By explaining which objective the clients wanted to achieve on the website, instead of the specific functionality, we could have advised better, earlier in the process and given more value to the client. By the way; in most cases we managed to dissuade the clients to actually implement the debate forum, and used the precious development time for something much more valuable.
In short: Requirements change. Therefore, being too specific and detailed about functionality already in the RFP process will most likely get you a whole lot of expensive, unused functionality.
Be open about your development budget
This is in my book a no-brainer. The only reasons for not being open about the budget are if you adopt the “they-are-all-thieves-and-robbers” attitude or if you hope to haggle your way to a cheaper website. In both cases, you are doing yourself and your website a whole lot of damage.
First of all, you have to trust your implementation partner, as they hold an immense power to make your project a success or failure. If you don’t, find another partner. Secondly, this is not a standard product you are buying. If you push your implementation partner on time or money, they have but one place to push back: quality. This basically means that your solution will be in a worse state, bringing lower reliability or higher support cost.
Therefore, a selection process is not about getting the lowest price or best solution description. It’s all about finding the implementation partner which you trust the most. And if you found that implementation partner, why not be open about mostly everything, including budget?
Bring your partners on board early
There is a lot of benefit in bringing in all your partners as early in the process as possible – this means both strategy and design partners and well as implementation and hosting partners. Each domain has something to bring to the process and can potentially save you a lot of money and hassle. Getting the implementation partner and hosting partner to talk together as early as possible can save a lot of time in the deployment process, and in my experience, by getting the implementation partner involved in the strategy and graphical design process a lot of hours can be saved in communication afterwards. Furthermore implementation partners often have prebuilt functionality which – if it fits the project – can save you a lot of time and money. The earlier this is brought forward, the easier it is to fit into any graphical design or information architecture.