Table of Contents
Introduction
Solution architects play an important role in every Salesforce implementation. With deep technical expertise and strong knowledge of their organization’s IT infrastructure, architects may be called upon to assist in a variety of organizational initiatives. In smaller organizations, architects may find themselves leading projects as well.
The success of a project often depends on the level of planning that goes into it at the beginning. In some organizations you may find yourself given a detailed project plan, milestones to achieve, and all the resources you need to ensure a successful outcome. In others, you may simply be told that some new initiative needs to be launched in the next 90 days and sent back to your desk.
Regardless of the size of the project you are taking on, or your level in the organization, it can be useful to have a model or framework to guide your work. Checklists and guidelines ensure that you consider every angle of the project you are undertaking and ensure you have the resources, people and plans you need to be successful.
While there are certifications like the Project Management Professional (PMP) certification that you can earn, leading successful projects and initiatives are not the sole domain of the professional project manager. Every solution architect has a role to play in project management and all can learn the skills needed to do this well.
The FOGLAMP model comes from Professor Michael Watkins, and was originally developed to help new executives orient themselves after a promotion or job change by identifying opportunities for early wins and executing on them successfully. This model is equally applicable to Solution Architects of all levels of experience.
First, we will review the elements of the FOGLAMP model and then see how it can be applied to a project that a solution architect might find themselves assigned to.
FOGLAMP Model
The FOGLAMP Model is a simple mnemonic. Each letter indicates a different part of the project planning process. Your first pass at the FOGLAMP may be as simple as a single sentence. Eventually, you may extend this to a detailed set of questions, answers, and considerations.
The FOGLAMP elements:
Focus
The first part of the model is focus. You should understand the purpose of the project. This one shouldn’t be too hard – usually you’re being asked to do something for a reason. It might be helpful to understand if there are measurable outcomes that you can keep in mind throughout the project and guide your thinking.
Another important element of focus is deciding on what the project’s limits are. Scope creep is something that every Solution Architect has to deal with. By being clear about what the project’s outcomes and requirements are you can ensure a tight scope that you can deliver on successfully.
Oversight
Next is oversight. Oversight involves understanding who the team members will be supervising the project. This might be yourself, a project manager, or a business leader who has requested the project.
It’s also helpful to understand the concept of “buy in.” As a project gets underway, you will need things from people. Those people should understand the value of the project and be able to get you the things that you need. Of course, people are human and it’s not always the case that everyone you need to work with understands the value of what you’re doing. If you find yourself working with someone who hasn’t “bought in”, helping that person to understand what you need and the potential risks to the project and the whole team if you don’t get it can help bring them around.
Goals
Every project has goals. Whether you’re architecting a brand new Salesforce implementation at a complex organization or doing something as simple as adding a new custom object to meet an emerging data collection need, you need to understand what your goals are. This doesn’t just mean understanding the final goal, endpoint, or outcome. You should also understand the intermediate goals, milestones, and methods for measuring them as well as the timeline to achieve them.
For example, if you are onboarding a new program to Salesforce at your organization you might have six weeks to design and build the functionality needed. Inside of those six weeks may be a series of milestones:
- review and clarify the requirements
- understand any necessary integrations
- create your architecture diagrams
- spin up the environments you will need for configuration
- set up your CI/CD pipelines
And so on. Each of these has the goal of moving the project forward and specific deliverables that you can provide to stakeholders. By having a detailed plan, you increase the chances that you stay on track. Additionally, by understanding the outputs from each milestone you will be able to translate those into your final outcome, whether that’s a Salesforce launch, updated functionality or a set of configuration instructions for the individuals who will be completing the build.
Leadership
Leadership in a project involves not only being the person in charge or making the decisions that need to be made, but also being able to inspire others to follow those decisions. In many organizations and projects, your authority isn’t “positional”: the people you are working with may not directly report to you and you may have limited ability to direct their work.
Instead, the way that you get things done is by leadership and demonstrating personal authority. People believe in you and want to follow you because they understand that doing what’s asked of them will help the project move forward and make everyone’s life easier.
Abilities
Every project requires a specific set of skills. Do you have the skills that you need to undertake the task at hand? If not, it’s good to review what training, additional staff or other things you will need in order to complete the project.
Even Solution Architects with very strong technical skills will find themselves working with tools, techniques or integrations that they’re less familiar with. Upskilling is one way to help this, but so is leveraging the abilities of your team members who may already have the knowledge you need and just need to be brought in for that part of the project.
Additionally, it’s important to have representation on your project from your key stakeholders. If you’re building something new you want to get regular feedback from the people who will be using the product or affected by it.
Means
Means refers to what other resources you will need for your project to be completed successfully. If you are working with a new tool, do you have the licenses for that tool? If you’re scheduling meetings – does everyone have the time blocked out on their calendars and the commitment that they will have enough space in their schedule to do the work?
A team that lacks the means to execute on a vision will struggle even if everyone is strongly invested in getting it across the finish line.
Process
Finally, Process refers to any processes that the team will use. This can be a range of things, from the new functionality that someone will need to train end-users how to use, to the change management process for individuals to give feedback and prepare for what’s coming, or the even deployment processes used during configuration to ensure your architecture comes to life in the way that you anticipating it.
Case Study: How to use FOGLAMP
So we’ve learned a little bit more about the components of the FOGLAMP model. Are you wondering how you might apply this to a solution architecture project in your own work? Let’s take a look at an example and see how we can use these items to ensure success.
You are an internal solution architect at a financial institution that uses Salesforce. You report to the CIO and have an Administrator to handle day-to-day user needs and configuration, a Business Analyst to collect requirements, develop user stories and ensure user adoption, and a Developer who handles external integrations, data migrations and custom code. Your role is to oversee the system architecture, produce design deliverables and proofs of concept.
One day, you are asked to onboard a new financial planning team to Salesforce. This team used to use a third party platform but will now be completing their tasks inside Salesforce. Discovery sessions were held and requirements written up. Their existing system will be sunset in 3 months. You review the Financial Services Cloud ERD and begin to think about how you might add the functionality needed by this Financial Planning team to Salesforce.
What’s next? Perhaps you’d like to dive right into the design, creating your Level 1 and Level 2 diagrams (if you haven’t already), as you begin to figure out how to add these new elements to Salesforce in the most efficient, scalable way. Consider instead, you start with the FOGLAMP framework to help you understand the road ahead before you begin immersing yourself into the design.
Let’s look at what a few point-form notes from our vignette above might look like when applied to FOGLAMP.
FOGLAMP
Focus:
- What’s the purpose of the project? To build what the Financial Planning team needs to do their work in Salesforce, and onboard the team to it
- Limits: Minimum viable product needed by sunset in 3 months
Oversight:
- Who is involved? The CIO, the financial planning team, Salesforce team
- Who needs buy-in? Financial planners, they are nervous about transitioning to a new system
Goals:
- Build the functionality they need to use Salesforce
- Get the new team onboarded to Salesforce
- Migrate data from their old system
Leadership:
- Who is leading the project? Solution Architect, with CIO as backup
Abilities:
- What staff do we need? Financial Planning team manager, and end-users to view demos and provide feedback
- What learning do we need? The Salesforce team is unfamiliar with the financial planning software the users used before, so we will need regular meetings with that team as we build to make sure we are meeting their needs
- We believe we have the skills to manage the data migration. No integration with the old system is necessary.
Means:
- The financial planning team is busy. We need to carve out time for weekly meetings with that team and a monthly steering committee meeting. We also need access to their old system for data migration purposes
Process:
- New processes for the Financial Planning team will be in Salesforce; we need to make sure we are prepared to onboard and train them. Our Business Analyst will be closely involved in that work.
Conclusion
If you’re an architect who has had lots of opportunities to manage projects, FOGLAMP may be another feather in your cap. If you’re new to project management, hopefully it will help guide you on your next launch. Either way, you’re better prepared to ensure the success of your next initiative, no matter how big or small. Congratulations and good luck!