Join us and learn about. The governance dilemma for Salesforce projects, what makes Salesforce special compared to other platforms. Why has many Salesforce projects struggled with quality despite governance. The CTA role in defining and implementing a Salesforce governance model and Governance at scale.
Throughout my career, I have seen many examples of how software governance or lack of it can negatively impact a project success.
The impact can range from poor user adoption to sub-optimal solution performance. And could lead to more unfortunate events such as data leaks or complete meltdown.
Examples
- You might have heard clients complaining about ending up with 80% of their functionalities custom developed instead of the promised 20%.
- In some occasions, that lead to a hyper allergy from anything related to custom-developed features. Even when it is actually unavoidable. Extremely difficult feature request processes might be introduced to deter teams from custom-developed solutions
- You might have come across the situation where your team proudly developed the same feature twice. Or thrice. Or built something that was rendered obsolete in the next Salesforce release.
- Or you might had the experience of inheriting an under-performing solution that has no available documentation anywhere that can describe how they were developed (or even why)
- Governor limits anyone?
- Have you heard this statement before: we are unable to introduce any new features because every time we introduce and test a thing, something else falls apart
Market confusion
Salesforce has promoted the concept of a Center of Excellence (CoE) for years as part of the overall governance body. However, different interpretations can lead to different implementations and expectations
- The terms used can vary. Some companies call it “Center of Excellence“, “C4E“, “Center of Expertise”, “Network of Experts”.
- The terms “Design Authority“ or “Platform Authority“ are also used sometimes. This creates more confusion.
- This is common particularly when there is uncertainty about the purpose of the entity. Is it there to drive transformation or a is it a best practice center?
- The CoE is not a new term. And it can be mistakenly associated with legacy thinking and a slow pace for business and technical change. This could lead to the usage of other terms such as “Network of Excellence”, “Center of Innovation” … etc
- The different interpretations can lead to different implementations and expectations. Which would usually lead to frustration when their targets are not met
The importance of introducing a process to validate the design of key user stories should not be underestimated. This is actually where most things can go wrong
Difference between a Salesforce CoE and a Design Authority(DA)
What does a Design Authority look like
For a Design authority to be effective it requires;
- Executive sponsorship
- Both technical and business expertise
- Members to hold accountability for their respective organisations
- Credibility and influence within the enterprise
An illustrative structure of a Design Authority
What does the Design Authority do at the different touchpoints?
The Design Authority’s expected responsibilities
What it does
- Meet with regular cadence (e.g. weekly)
- Single point of contact to have the full overview of all application changes
- Advise on and review solution blueprints / high level designs, and provide appropriate feedback to improve designs if necessary
- Sanity check of effort as needed for more complex designs
- Establish targets for re-use of components and design patterns
- Support resolution of architectural issues raised by implementation projects
What it does NOT do
- Provide a guarantee that what was designed is what gets delivered
- Re-write solutions or design specifications
- Review every single line of a document for spelling or grammar corrections
- Perform detailed reviews on all code written
- Estimation oversight of all work entering the pipe
Design Authority Benefits
- A good level of standardization in the design process. If you worked for an enterprise that deals with multiple external consultancies you will notice that they usually follow different approaches. Focused more on the delivery of a particular project rather than the overall vision of the bigger program. This is particularly relevant considering the high level of attrition in the Salesforce market. A Design Authority could look across the design work and make sensible join-up suggestions and/or recommend a consistent design process/taxonomy.
- The DA provides a community/forum that enables team alignment on a deeper level. The people who knows exactly how each part of the solution is working will be setting around the same table. Sharing thoughts, challenging each other, and reaching up to conclusions without the need for further alignments. This is a much deeper level of team alignment than what you could ever get in activities such as release/PI planning.
- It provides a perfect process to continuously develop, monitor, and track the design of the overall solution throughout the project. Not just in a short blueprinting/design/pre-game phase which could eventually run out of date and fail to respond to context changes. n effective Design Authority could keep tabs on progress and intervene as needed.
- The DA activities eventually creates a very valuable artefact. The design decision log. Which contains all the “why” and “how” relevant to all key decisions taken in this project and who participated taking them.
- A perfect ground to develop talents. Allowing them to get involved in creating, challenging, and defending a solution. This is a daily practice for what architects are expected to do as CTAs. All parties would learn more by engaging in this activities.
The best way to prepare for the CTA review board is by practicing a mini-review-board every week. The DA in a win-win process for everyone. The enterprise (who gets a better quality deliverable), the delivery team (by avoiding challenges and issues while delivering the project), and potential CTAs (as they practice a part of the CTA review board in their day-to-day job)
How to implement a Design Authority (DA)?
- Start with an executive sponsor or champion. A structure such as the DA needs a senior executive sponsor who can provide support to the DA members and coach them on how to be effective within the enterprise.
- Ensure that all stakeholders are aligned with the definition of an “effective DA”
- Create and document the process. The DA should have a level of formalism and you should have materials that can explain to people new to the DA how it works and how they can engage with it successfully.
- Start small (e.g., an “Acorn”). Then allow the entity to grow and mature with time (e.g., an Oak Tree). Evolve the DA as it gains credibility and influence. During the evolution, keep updating and adjusting the process and rules.
- Avoid the negative assumption that the DA would turn into a bottleneck. People tend to think that they will get hundreds of user stories to review and approve every week. On one side, this is very exaggerated. On the other, you can always control the criteria defining what is a DA-relevant user story.
- Socialize the concept that these invested hours will prevent many more wasted hours spent on fixing things that could have been spotted at the beginning
- Keep the number of participants in the core team small (workable number). But ensure you can extend the team whenever needed to cover complex and wider organization challenges.
Recording
Please note that we have limit of 100 attendees that can join the online sessions. However, recording will be posted on our YouTube channel. Please subscribe our YouTube channel to get notification for video upload.
