Even though you know the methodology and master the Salesforce technology, you always tend to face the same project recurring debates with your clients. Here are 5 key points that that could help you to keep in mind what are the best practices to avoid them.
1 – Agile or Waterfall, that is not the question
When you deal with User experience features, you may want to iterate often with your Customer since UX modifications are easy and fast to implement. Then you may choose an Agile methodology for your Project.
However, if your project requires complex backend calculations implemented through heavy development, you may want to secure the architecture once for all. That is why you would rather have strong validations early in the project.
Anyway, whatever the methodology you choose, it all gets to be conscious of what you are trying to achieve: being in a “Waterfall spirit” will spare you painful and useless rework but when you feel confident about your ability to change things along the way, then think agile!
2 – Rationalize the Workload Estimation
You don’t want your team to work all night long during weeks because you have underestimated the complexity of the app that you are building. On the other hand, your Customer will not let you charge him dozens of consultants for building one simple custom object.
This is why you need to know exactly how much working time will be needed to deliver your Project. The business requirements should describe one need and not several needs, so that the associated build assumptions could be precise enough. Then, abacuses will help you to know how much time you are supposed to spend on each item, according to your experience.
To build those abacuses, you need to measure the time spent on the different types of components (reports, custom objects, page layouts) from the start to the delivery in production of a project chosen as a reference. You will therefore be able to make statistics about the working time associated to each category of task and reuse them in your future projects.
3 – It is all about prioritization
Your project is now estimated. During the second workshop, your Customer wants to add a custom reporting system for managers, and you know that you cannot deliver it during the allotted time. As usual, your customer considers everything as a high priority.
that new Business Requirement and estimate it later. Once it is estimated, you confront your customer to the workload associated to that requirement. Then, your Customer understand that implementing this requirement would require removing many low-charged useful features from the app. He finally decides by himself that this requirement has a low priority and then should not be implemented in the first release of your application.
4 – Keep your End Users in mind
You are now working on your second release. You have been struggling with a Custom Quoting system for two months and you finally have something that is quite presentable. By chance, you meet John Smith at the coffee machine. As a Salesperson, he will be one of the users of your application. You propose to show him the custom quoting system in the sandbox environment. John doesn’t understand why he now needs 3 minutes to do what was done in 30 seconds in the previous standard system.
If the solution doesn’t fit the true needs that business units experience every day on the field, the solution will not be used, and it will cost more time and money to rework it and make it fit to the real needs of the business users. Your part of the job is to convince your customer that you need some of your end users to be involved in the very beginning of the project, when key design decisions are taken.
5 – Stand by the Standard Solution
Later in the development process, you face this business requirement that makes you build a custom reporting system. It is gratifying for you and your team to show your customer all your best programmatic development abilities. At this point of the project, everyone is happy.
Six months later, the same customer gets back to you because he wants to add in the report a field that is critical for the business. As it requires customizations, this cannot be done before the next release in one month. Your Customer is quite unhappy now and says that he was really badly advised on this point. As a consequence, you are forced to get back to a standard report to satisfy his urgent.
That is why you should avoid over-customizing your solution with programmatic development unless the requirement cannot be fulfilled within the standard solution or in declarative development.
Whether you consider iterations, avoiding rework effort, prioritizing the tasks or gathering the Business Requirements, all those points developed here have a goal which is anticipation. If your Salesforce project is managed with the permanent care of anticipating all potential issues during and after the project, in the run mode, your Customer will be thankful for developing a long-term vision and caring about the consequences of your actions after the project. In the end, he will be also thankful for not answering to all his day-to-day desires. This is how trustful relationships can be built with your Customers.