Why Agile is a Must for Salesforce Implementations
We are hearty evangelists of agile project management at Idealist Consulting. We find ourselves in casual conversations about how key it is to minimizing risk in Salesforce implementation projects so often that we thought it was time to share some of our reasons. This guest post comes from our CRM Admin Consultant Ashley Bochiechio.
As a Salesforce consultant, I have done projects which use agile project management as well as projects which strictly adhere to a traditional waterfall approach. Remember the difference? Agile project management follows a project structure of design, tweak, repeat, launch, improve. Waterfall, on the other hand, is a style of project management which focuses almost half the scoped time on the creation of a highly detailed design document (an all-inclusive document listing what will be implemented for a given project). Based on my experiences, I have developed a strong preference for agile. In the great race to implement Salesforce, time is always of the essence, but not only that, your project risks will be much better managed through an agile approach.
Here is why should you insist on seeking out an agile consulting firm as your partner.
Waterfall leads to higher risk
Before I sing the praises of agile further, let’s look a little closer at the design documents involved in waterfall-style implementations. Design documents are great for detailing unwavering and predictable things. A typical design document will include business process, lead and opportunity lifecycle, email templates, any custom fields with respective values, role hierarchy, and custom profiles, and many more. Sounds great, right? The only problem is, they just don’t work for Salesforce implementations.
Salesforce has had 37 product releases in 12 years, which is normal in the technology industry - in fact, the ever-changing nature of Salesforce and the elasticity of its capabilities is a major selling point. Since every company has a unique set of business processes, it only makes sense to have a custom-fit CRM solution, which is what Salesforce delivers.
The real use for a design document is to provide an insurance policy for the consulting company, disguised as a security blanket for the customer. No customer will ever be able to develop a lucid picture of the proposed system by reading a design document. So when the project derails the consultant can pull out the design document like its a get out of jail free card. The result is the customer pays big money to design their own system prison. At Idealist Consulting, we believe there’s a better way.
Agile gives you wings!
I feel much more confident with my agile projects because the agile approach allows for the freedom to make changes as necessary, without the shackles of an outdated document. I can get to work doing what I do best today, not sometime next year. This keeps the momentum of the project fresh and alive. If I have 10 projects going, I know from day 1 when I will need to budget my time. With waterfall, I have no real idea when the design document will be approved, which makes it difficult to allocate project resources and ensure a client’s schedule is maintained. It’s a roller coaster from hell and makes for a highly stressful and risk-prone experience for both the client and consultant.
With my agile projects, the very first phone call with the customer starts with requirements gathering. This allows me to hit the ground running. On the next phone call, we are looking at their Salesforce system together with some freshly implemented customization. This allows the customer to start getting familiar with the system from the very beginning. After more phone calls and modifications (quick iteration and early prototypes being one of the keystones of agile), we start on report creation. Since the customer is already intimately familiar with the system, reports make more sense. When it is time to launch, there is already a well-trained superuser to assist the adoption process. Here’s a deeper look into how each of these stages reduces risk.
Requirements Gathering and Implementation from the start
Agile allows to skip the pomp and circumstance and get to what really matters - the work. With waterfall, there are many long-winded review sessions focused on making the customer comfortable, the who’s who conversation, the business process review, overall analysis of existing systems, and of course many discussions about the big design document. None of these things show concrete results in Salesforce or provide valuable results, and much of this can happen very quickly in the project kick-off call. Every waterfall project I have had also involves explaining why half the hours and budget have been used up and nothing is in the system. The customers feel like the wheels are spinning but we are going nowhere. This simply never happens with agile because real work happens from the very start.
Review within Salesforce from the start
Agile lets me take the customer’s hand and show them everything going on in Salesforce from day one. This is much like getting a backstage pass: at first, the props and ropes and pulleys may be a lot to take in, but over time it becomes more familiar. One of my best agile projects ended with my customer becoming so involved with the system that she went ahead and became a certified Salesforce Administrator! The waterfall approach is more like sitting in the audience with an info booklet, becoming mesmerized and distracted because you can’t see the whole picture.
Report creation after getting to know the system
One of my very favorite thing about agile is that we evaluate together what kind of reports need to happen at the perfect time: after the initial object configuration. So what does that mean? It means that once the whole puzzle has been put together (the Opportunity Account and Contact Objects plus any custom objects are completely ironed out) we can look at reports.
This is the best way to do things because the way reports work in Salesforce are very object- specific. Each Object is its own report, but some objects work together so that you can report on two objects like Opportunity and Account. Others are not related and reports are not possible, such as Opportunity, Account, Custom Object, Quotes and Contracts. In fact, it is impossible to have more than four objects in a report. So for the person with a backstage pass, this makes a great deal of sense and it is digestible. For the person in the audience, this is very confusing. The worst part is that for the person in the audience, their reports were already picked out before the system was created, and now those reports could be worthless.
Go live with a knowledgeable superuser
When it’s time to go live with the system, there is an in-house system expert that has been involved from the start. This is extremely important in managing the entire migration process because many questions will be able to be answered directly by this superuser, such as:
- Why should we use this system?
- Can we have this show up over here?
- I want to see this on the homepage, can you change this?
- Can we get the total amount on this report?
- How do we hide [X] from [X] users?
These kinds of concerns have usually been addressed already, and the superuser is key to explaining these answers. So during the overall process, there is someone on your team to answer questions, and as the consultant, I can provide backup. This also means there is someone post-launch to manage the system. But of course, less post-launch support is required because a much higher level of self-sufficiency is fostered by the agile process.
Summary
Let’s review the reasons an agile approach is the only way to go to reduce risk and improve outcomes in your Salesforce implementation project. Agile will:
- Save you time and money
- Lead to faster results and a faster final product
- Allow for greater customer self-sufficiency and autonomy
- Give your team more relevant reports
- Result in a higher degree of customer system comprehension
- Grant you greater peace of mind
So you can see, agile makes happier consultants and happier customers - and who doesn’t want that? The next time you’re talking with your consulting firm, ask what agile methods they’re applying to your project, and how you can help. It’ll be a win for everyone.
What experiences do you have with agile or waterfall methodology? We’re interested in your take - please leave comments below.
For more information on preparing for a big technology project, check out our whitepaper for the best strategies.
