How to Build Successful Salesforce Apps Like the Experts

As with any application development project, our team follows best practices and guidelines we’ve fine-tuned over the years to guide our process, mitigate risk, and ensure our clients’ success.

The methodology our Salesforce team uses takes the evolving ecosystem into account. We focus on leveraging new platform features to keep functionality on the platform while allowing for scalability for the client’s business.

Overall Philosophy

In the very early stages of a project, we focus on developing a roadmap and within the confines of that a minimum viable solution. Budget, scope, and timeline create an iron triangle of constraints that help drive our consultative approach to client engagements. We have concrete outcomes at every stage to ensure clients have granular control over budget and timeline throughout the entirety of the project.

And, of course, suitable adjustments can be made at any time. As trusted advisors, we focus on educating and empowering our clients’ stakeholders to understand existing vs. new scope to make informed decisions about budget and timeline.

Foundation

First Half of Foundation

The foundation phase helps us strategically plan out our development process by outlining a minimum viable solution and prioritizing its features and workflows. During the first half of this phase, we work to get a good understanding of the breadth and depth of functionality desired. We develop a detailed matrix-style story map calling out epics and the story titles underneath each epic to get an idea of the depth of functionality desired for each. We do this via a series of meetings with key stakeholders.

On multi-year engagements, we develop a roadmap projecting large buckets of work over the desired period of execution time before getting into the minimum viable solution. From that, we evolve the minimum viable solution for the first set of the most valuable work.

Typically, additional details emerge at this point through purposeful analysis of every requirement. We want to uncover just enough hidden complexity and/or risks to provide a mid-foundation estimate. This serves as a great checkpoint for our clients and allows them to weigh costs versus benefits and make informed trade-off choices if necessary.

This first half of the foundation phase often narrows the range of our project estimate and adds a level of confidence. At the end, we focus on agreeing with the client on a story map and locking down the scope for the minimum viable solution.

Second Half of Foundation

During the second half of the foundation phase, we focus on breaking down and documenting the stories down to a very detailed level, including acceptance criteria. We have many detailed level meetings with key stakeholders and subject matter experts (SMEs) responsible for any given functional requirement. At the end of this stage, our team aims to document a set of user stories ready for subsequent agile execution. We outline details on how a given function breaks down into incremental and valuable parts that our development team can develop and test quickly. When necessary, we also create UI mockups and wireframes to help clients visualize the evolving user interface.

We then walk through each story to confirm these plans with our client’s key stakeholders and SMEs. Often, the number of stories can be quite high, especially in a complex engagement. In those cases, we deliver high-level summaries conducive to periodic review by stakeholders.

Collaboration Tools

Our team uses two powerful tools from Atlassian Software, Confluence, and Jira, as our project collaboration and tracking spaces. Confluence (known as “Whiteboard” at Soliant) is an extremely powerful, collaborative “wiki”-style space where we evolve our deliverables and store our project artifacts, such as the user stories described above. We utilize this space most heavily during this stage and welcome client participation alongside us in this space as the project evolves. The space remains accessible to clients even after the completion of our work. Jira (known as “Workbench” at Soliant) provides powerful issue and project tracking capabilities, and clients also have access to this space.

Once stakeholders confirm user stories, we convert them into JIRA tickets. Each ticket links back to a corresponding user story in confluence for requirements traceability. In the agile spirit of incremental and iterative development, we bucket tickets into multiple versions in JIRA. These versions target meaningful chunks of functionality that can be released to a UAT environment and, if independent enough, to production as well. Each such version also serves as an additional checkpoint from a project tracking and control standpoint.

Our team uses these versions and tickets in JIRA for backlog grooming sessions in which our project team story-points the tickets. We then convert the story-point estimate into an hours-based end-of-foundation estimate for the client. At this point, we have an important client check-in meeting to ensure everyone feels good about the refined minimal viable solution, schedule, and budget. Our team uses this documentation as a basis for project tracking and control, so client buy-in is crucial at this stage.

Key Outcomes of the Foundation Stage

1. Project Goals
2. Roadmap, if a large engagement
3. Story Map
4. Mid-Foundation Estimate
5. Detailed User Stories in Confluence
6. Corresponding JIRA tickets
7. Versions in JIRA with planned start and end dates
8. End-of-Foundation Estimate

Development

We start with all tickets and versions prepared in JIRA and execute versions in increments of two-week sprints with short daily internal scrum meetings.

We employ the following project control mechanisms during this stage:

1. Sprint burndown chart to identify if the team is stalling on a given sprint
2. Control Chart for the preceding two weeks to assess the general trend of development process flow – increasing or decreasing – and identify tickets skewing the averages. We use such tickets to understand the root cause for anomalies and devise fixes for process issues.
3. Velocity chart for planning future sprints
4. Version Report to keep the projected completion date of a given version under control
5. Proprietary forecasting tool to assess various project metrics
6. Risk review meetings by Soliant’s internal PMO to identify and mitigate project risks

We report these metrics and progress via weekly status calls and/or emails with clients.

Key Outcomes of the Development Stage

1. Architecture & Design Diagrams as needed
2. UX mocks and related comps
3. Finished increment of functionality every two weeks
4. Sprint Retrospective every two weeks
5. Project Control Metrics
6. Project Status Reports
7. Finished version(s) of functionality that can be deployed to UAT environment

UAT – User Acceptance Testing

In agile, users often engage in UAT at the end of every sprint. However, our experience suggests that end users can rarely keep up with the pace of development. They do have a day job after all! There is also overhead associated with deploying to a formal environment such as UAT from a development team’s effort perspective.

We, therefore, target UAT during specific intervals, often post-completion of development of a very specific version. This process, in our experience, has yielded better overall results in consulting engagements. Each version has a planned end date as well as a projected end date, and we use these to proactively plan UAT dates. We typically prefer a period of two weeks for focused UAT and support this stage with suitable test scripts and/or feature walkthroughs/ demos. Our clients’ staff test based on well-documented test scenarios and test cases. Any defects and/or enhancements found roll into the next version after suitable triage in consultation with the client. Any major enhancements that fundamentally affect the design are prioritized with the utmost due diligence, likely as a separate enhancement.

Key Outcomes of the UAT Stage

1. UAT Deployment Plan and Dates
2. Test Scripts and feature walkthroughs/ demos
3. Testing by End Users
4. Defects/ Enhancements and Triage thereof
5. Execution Plan & Costs for Accepted Defects/ Enhancements

Deployment & Rollout

Following successful UAT of all versions, our development team prepares to deploy accepted features and functions into the production environment. Salesforce deployments tend to be a multi-step process with steps before, during, and after deployment. Thus, we deliver a formal deployment plan documenting all necessary steps, including a rollback plan as necessary.

Depending on how independent a given feature set is, we can deploy to production after a given version is complete rather than waiting for the completion of all versions. We would highly recommend this approach, given the much higher risk of a big-bang deployment.

Once the system starts getting used in production and additional versions need to be deployed, we initiate formal change management and notification plan built in collaboration with our client. This plan includes major changes going in, when they are going in, outage period when users will need to be out of the system, which user groups are impacted, etc.

Key Outcomes of the Deployment and Rollout Stage

1. Accepted version(s) deployed to production and ready for use
2. Notification and Rollout Plan
3. Change Management Plan

Data Migration

We rarely encounter an implementation that does not require any data migration. The extent of the process varies, and we typically define & evolve it during development, when we get a detailed understanding of the minimal viable solution’s architecture and design.

Key Outcomes of the Data Migration Stage

1. Plan for data migration effort, if needed

Training

Our team can provide “train the trainer” training, and additionally, we recommend that those designated for this role participate throughout the development process to obtain their buy-in and complete understanding of the developed features. These users should play a critical role in User Acceptance Testing of the beta solution before they receive the “train the trainer” portion of their training. A subset of these users should then attend the end-user training to serve as internal Subject Matter Experts (SMEs) among the other users.

We recommend conducting training onsite at locations, if possible. We find training attention and retention are far higher if users cannot multitask during their training (all too easy over web training). Depending upon the geographic distribution of your team, we can travel to various locations to work with groups of trainees, or we can gather at one of our regional offices to provide training.

Of course, users who cannot travel may attend via web share, and we will certainly record the audio and video portion of the training for re-use among your staff. We further recommend that you potentially consider offering separate training for those who may need a slower-paced approach to accommodate more time for technical practice.

Finally, we suggest that post-launch, perhaps by an interval of once per month for three months, we hold follow up, optional “clinics” via web and conference call to which users can bring their “real-life scenario” questions. Of course, we also provide support as needed, but these clinics serve as an opportunity to reinforce learning.

Key Outcomes of the Training Stage

1. Trained personnel ready to use the new system in Salesforce

Support

As a full-service Salesforce Partner, we work with individual clients to determine support policies and plans in alignment with their resources, business needs, and desires for support.

After an initial project deployment, we often work with clients on an ongoing basis to accomplish “continuous improvement” changes and assist in supporting the new application.

We have extensive experience transitioning applications from our team to our clients’ teams for ongoing maintenance and administrative purposes.

Key Outcomes of the Support Stage

1. Agreed upon support contract

Project Tracking, Control & Risk Management

We cannot overemphasize how important project tracking and risk control mechanisms are in client engagements. Multiple checkpoints at which we assess everything relevant to the project and keep surfacing and/or mitigating any risks are crucial to a project’s success.

Key Checkpoints

1. An initial ballpark and/or schedule estimate as an initial guide
2. A mid-foundation estimate, typically within weeks of starting, to allow assessing convergence or divergence from the initial ballpark and take corrective measures as necessary
3. An end-of-foundation estimate, to continue assessing convergence or divergence from the mid-foundation estimate, allowing us to take corrective measures as necessary
4. Daily sprint metrics, such as burn down and control charts, to assess and correct development flow, if necessary
5. Real-time version metrics, such as projected completion dates assessed weekly to alleviate schedule risk
6. Versions moving to UAT environment to assess targets to actuals
7. Proprietary forecasting tool to gain detailed insights into projected completion dates, velocity, etc., assessed bi-weekly to visualize and alleviate scope and/or schedule risk
8. Weekly Status calls and/or emails to summarize any or all of the above

Given this number of checkpoints, we offer our clients plenty of opportunities to assess project health frequently and alleviate any concerns about the project getting out of control.

We produce some sample charts for your reference.

Sample Charts

Proprietary Forecasting Tool Charts

Case 1: How we managed scope down and completed the project ahead of schedule

Case 2: How we managed additional scope and were able to forecast the new completion date

Beyond these practices, we continuously and formally manage all potential risks using a proprietary risk management tool. Most risks are directly associated with the iron triangle constraints of scope, budget, and schedule. However, we often track risks that indirectly impact these constraints to keep an even closer eye on our projects.

Examples of Risk

1. Budget – Trending Over Target
2. Client – Business Strategy Change
3. Client – Low Familiarity with Software Development
4. Client – Low Availability of SMEs
5. Data – Hygiene/ Governance
6. Requirements – Lack of change management discipline from the client or non-converging/ overlapping requirements
7. Schedule – Aggressive/Fixed
8. Size – Large minimal viable solution
9. Criticality – Mission Critical System

We track these weekly informal risk scrums and focus on relevant risks for internal and/or client review. Our team makes formal mitigation plans, also tracked in our proprietary tool, to ensure we continuously assess the risk against the plan until it gets mitigated. We also formally share any major risks under the client’s control along with their respective impact and invite the client into this process of mitigation.

Partner with an Experienced Salesforce Team

Our team has developed this process from over a decade of experience and expertise built on dozens of projects and delivered solutions. We find that through thorough planning and consistent client communication, we can build truly innovative applications that empower organizations to grow. If you’re looking for a partner for your next Salesforce project, we are happy to give you more details on how we could work with you. Contact us to learn more.