Recently I passed through a series of interviews for almost every of the top 10 Sitecore Platinum partners in the US. That was a wonderful experience, I learned lots about all these companies and their way of doing business. Moreover, I can definitely say now that organizations in their culture and temper are like humans - some are pro-active extroverts, while others are very pedantic process-oriented nerds.
One of the companies made me a set of a few ~1.5 hours-long interviews with a vice president baking me with lots of challenging but interesting questions, mostly management and business-related. As it usually happens, I keep thinking about it well beyond the time in the background, and my thoughts resulted in this post. I compiled that into a single solid dump of my experience, so here we go.
Presales
Take it as the rule of thumb: you have to spend resources on presale! The evaluation should be well detailed, not to receive a "negative profit" later. I remember a project when the assessment was done by the architect, who did not allocate enough time to study the Customer's processes in detail. He conducted most of the work "according to the standard", using the "best practices". As a result of poor quality assessment, the project received "negative margin".
At the stage of pre-sales evaluation of the project, it is necessary to provide a list of possible additional works (volume, cost, time). For example, a change in some indicators entails a restructuring of the entire model, which can take a significant amount of time, require the involvement of significant resources and cost decent money.
Integrations
Integration evaluation also refers to the pre-sales evaluation of an upcoming project, but I emphasized this point intentionally.
First and most, you need to make sure that the systems do integrate with each other. Moreover, at the presale stage, it is crucial to find out as many details about the upcoming integration as possible: what systems, what protocols, buses, etc.
In another projects I took part in, the incompatibility of the external systems was discovered only at the stage of integration after work started. That resulted in the customer being unhappy with and additional labor costs for developing and configuring the alternative. Don't underestimate that!
Agreement
Probably the most important stage with all the parties to be involved. Mistakes in the agreement may cost a lot!
1. It is crucial to ensure that the terms in the Agreement do match your resource plan. Why? It often happens that even at the presale stage of negotiating with a potential Customer, some additional clauses get added to the Agreement, and these changes get forgotten to be reflected into the resource plan. This is what happened in our project. The PM did not take part in the process of signing up the Agreement, and different participants in the process added each from themselves, but no one checked the compliance of the Agreement with the actual resource plan. As a result, a misalignment between the Agreement and Resource Plan led to time and labor losses that were not taken previously into account. Just doing an extra check would eliminate that loss and could save time and retain customer satisfaction!
2. When it comes to client training it makes sense to describe the learning process well in details in the Agreement. You may include a number of hours, topics, number, and type of users - also specifying business and/or technical users, as well as the list of attached instructions (including number, titles, etc.). No need to be ultra precise here, but the scope should be agreed upon and signed. Once in a time, our contract stated that we would provide instructions and provide training. But it ended up that the list of instructions and the amount of training planned by an Architect (why him, BTW?), mismatched the Client's expectations, and they demanded much more. This case is in fact a subset of the following point.
3. Try to avoid wording that could be interpreted differently. The presence of inaccurate wording may lead to ambiguity when the Customer insists on his understanding of the Agreement inaccuracies. According to the Agreement, during the data collection phase, the team supposed to hold an introductory workshop. However it turned out that no one knew what exactly should be shown. The customer expected that workshop to demonstrate the system in action with their actual data, so that potential users would understand how the system would work. Therefore preparation took a lot of extra time, not included in the initial project estimation. The lesson learned: when there is some uncertain clause in your contract with an unclear meaning or unknown implementation, it is better to immediately clarify what exactly this clause implies.
4. One more point relates to customer data or content. It is wise to specify that the Customer provides data in the required templates and formats in your Agreement. If that is not the case, then formatting/conversion work must be paid additionally. Once ago we had to load a large amount of data into the system. The Customer provided the data in the non-classified loose raw format. As a result, a large amount of labour spent on cleansing the provided data. That wasn't originally included in the estimate calculations and resulted with extra time and cost.
5. This clause is likely be found in the most of contract templates, however few people pay attention to it, sometimes delaying the deadlines. It pays to specify the deadlines or the amount of iterations for the approval. Any approval delays cause by the Customer should be recorded. By fixing these delays, you can win some extra time to adjust the deadlines if needed.
6. When it comes to change requests it helps to cap your maximum efforts in the Agreement. For example, stating that changes that require adjusting the architecture say more than 10% are provided for an additional fee. Most of the Agreement templates have this clause stated out in this or that way, though.
7. It goes without saying, however I spell it just in case. You must keep all communiaction with the Customer until the project completion and beyond a warranty period. Always note and take a record of any additional work outside of Agreement terms to be done to complete the project - at least time spent, reason, resources taken, etc.
Testing and Acceptance
1. All the acceptance criteria should be clear and known well in advance.
2. When it comes to testing, the amount of effort should also be defined and signed well in advance. At least, types of tests, their order, and required resources from both sides.
3. It is often a case, when testing is due to start however the required access is missing or the testing environment is not ready, or not even provided (I am now writing about things to be provided by a Client) - this is to be recorder as mentioned before.
4. There might be more unpredicted cases like once the Client demanded most of their staff to take part in the delivery testing and the Agreement did not cover that case. The issue for us was that Client employees were in totally different time zones, which made us to adjust. Would that be predicted in the Agreement - there'd be a possible solution negotiated rather than getting this unpredicted at a cost of overtime for our Dev and Ops teams.
The above is just few of project issues I remembered but was still good to share.