Several times in my career, I came across situations where my client wanted to take the driving seat of an implementation after a brief introduction to the basics of Salesforce configuration. Maybe they looked over the shoulder of a consultant creating a report or a page layout. “Oh yes, I get it it’s a bit like such and such language” I still hear them shouting…
One of my friends, was telling me about this Sales Cloud project originally meant to be declarative-only but the customer was feeling strongly about the implementation of a lookup field which should look like a picklist field enhanced with typeahead capability.
The team didn’t have the exact skills required, but under the customer’s pressure, one consultant was assigned the task to implement a typeahead picklist pulling its data from a custom object. The development was slow. The testing reported quite a few problems which in turn were slow to be fixed. The client was also squeezing in nice-to-have on top of bug-fixes. The project ended-up delayed and way over budget for a picklist which, quite frankly, could have been delivered as a standard lookup at no added cost. For my friend’s company the project was a total disaster.
When implementing Salesforce at a customer you need to make sure that users’ inputs won’t derail the project. It’s one thing to leave the door open to feedbacks and suggestions but it’s another thing to accept everything because it’s coming from the customer.
In consulting, it’s not the vendor working FOR the customer, it’s the vendor AND the customer working FOR the project.
The project is an entity in itself with a budget, a timeline and a scope.
##The Salesforce Police
The vendor and the customer must work together to keep the balance right. Because the vendor is the one bringing project expertise to the table, he is the one expected to agitate a red flag when the client’s changes in requirements are becoming a risk to the project. As a Salesforce expert, you need to make sure that best practices are followed, declarative comes before programmatic, you don’t reinvent the wheel, your solution is compatible with the next releases… You are the Salesforce police!
##Avoiding Scope Creep
To avoid your project to go pear shape as in the previous example, you may want to consider the following advices:
End of Sprint Demo
This is the place where most of the scope creep happens. Because there’s still, in theory, plenty of budget in this phase of the project there’s no feeling of financial pressure, and there’s tendency is to accept change requests with the hope that they will be absorbed during the remaining part of the build. Also, be conscious that you are pulling the curtain on unfinished software. The chances are that your audience can’t visualise the solution as you do and potentially ask for useless changes.
- Be budget conscious from start to finish. Your team has a fixed capacity: More effort will require more resources or more time and anyhow more budget.
- Avoid demoing half-baked features as this is going to waste everybody’s time and bring low-quality feedback.
User Acceptance Testing
This is another part of the project that can generate an important increase in scope. Key users may be change averse, they may want their brand new system to behave exactely like the old one. The idea of the UAT is to get a feel for adoption before go-live fixing bugs and addressing show-stoppers. It’s not about going back to the drawing board because Joe Blogg doesn’t like your solution.
- Always clearly state the goal and limits of UAT.
- Obviously, it’s down to the stakeholders to deal with people issues internally.
User Designed Solution
Some users will find interest in this refreshing new project and drop funky requirements as a way to enlighten their day. They may ask you features that exist in other web applications like Facebook or Instagram. Please remember that ultimately you will be the one with the neck on the table when your Facebook like typeahead doubles the cost of the build phase.
- Key users involvement in agile projects is about gathering business requirements then validating that the solution delivers the expected business outcome. It’s not about swapping seats.
- Listen to implementation preferences but make the final decision design based on your experience.
New Features Requests
Accepting new functionality requests up until UAT is totally fine. It’s one of the core benefits of agile methodologies. But this should not lead to scope creep.
*Always position a conversation on new feature requirement in the context of project success and ask what the trade-off is: increase in budget, delayed delivery or dropping another feature.
Never Ending Refinements
To be deployed to production in time your solution must first reach code-freeze. In the picklist story, the customer was asking for numerous non-functional refinements, pixel level cosmetics. Because the work started without a crystal clear description of the requirement, many iterations were required before a satisfactory result.
- Make sure that any piece of work is clearly described and understood by all parts. Associate each user story to acceptance criteria. Avoid subjective description like “The picklist must look great”. From the list of acceptance criteria, you should be able to write the project’s Definition Of Done. Get an early sign-off.
Hopefully these few advices will help you avoid getting into budget troubles while keeping your customer happy and your project successful.
I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.