Project Management

Little Blue Cloud - Brett Petersen (Technical Architect and Dev Team Lead)

Show Notes:

0:25 - How Brett got started working in the Salesforce ecosystem
1:17 - Transitioning from developer to consultant
3:19 - Moving from consulting to working for an end user
5:13 - Things to add to your toolbox (Lightning Web Components, Gearset third party dev ops tool)
12:03 - War story: When an email accidentally went out to thousands of community users
14:47 - Brett asks Spencer: What is your biggest pain point right now?
22:46 - Book club: Brett - Deep Work, Spencer - Rise of Superman
25:26 - What would you do if money were no consideration? Living with purpose and fulfillment.
29:10 - Connect with Brett: Upcoming developer presentation on LWC

Addressing critical project risks

“That's not going to work for us. We can't wait for the integration delay.”

In working with a client recently, we had cleared the integration delay and it's impact with most departments,

and this was the last department we needed sign off from. As we spoke to them, there was immediate concern about the impact of the delay to their process. If they didn't sign off on the integration, we would be confronted with delayed release dates, additional integration complexity, and a severe impact to other business units that we would need to circle back with to approve the modified solution. Hearing such a strong opposition certainly shook some members of the team and had people worried about the impact.

In moments like this, it is essential not to overreact. It is not uncommon to jump straight into a new solution, argumentative politics, or otherwise panic. We as humans have a tendency to get out of the uncomfortable feeling of conflict or tension, by proposing solutions. But if you sit in that tension and try to really understand it, the tension will ease and the solution will become clear. This means empathizing with the users so they understand that you care about their concern, and then asking questions that reveal the facts that are driving the strong generalizations they are giving you:

  • We don't want to move forward with a solution that is going to hurt your process. Can you help me understand the specific use cases that will be affected? Where would the delay cause an issue?

  • How often does that situation occur?

  • How many users will be affected?

  • If we went live with the solution as is, what would you have to do to overcome the problems presented?

With the answers to questions like this in hand, you can present options to the stakeholders, or potentially escalate to include the executives they report to so that a more global discussion can be had. What is the cost of changing the solution vs. moving forward? What is the real impact to those users? What workarounds or accomodations can be made?

Once the data is present and you are speaking in finite terms about who is impacted, how much, adn the cost involved, you can make a calm and rational decision about the best path forward. You will have deescalated the situation, and helped produce the best outcome given the constraints.

As to our client, it turned out there was only one use cases that was at risk, which occured 7-10 times per week, affecting 10 out of several hundred users. Not the show stopping risk that was initially perceived.

The illusion of multiple bugs

Every night I go running. I live in a pretty rural area so there are not a lot of streetlights, which allows me to see the starts and moon when the weather is clear. It is a beautiful scene. The stars shining, the moon reflecting off Utah lake, and the crisp cold air flowing into my lungs and throughout my veins. As I run I listen to audiobooks through my airpods. As my body gets stronger my mind gets sharper, and both get more resilient.

Barking cuts through the words of my audio book and I look around. So many of my neighbors have dogs - it comes with living in an area like this. Sometimes they are fenced, other times they are leashed, and still it is not uncommon that they are running freely at me. In my experience the best thing to do when a dog is barking and running at you is to square up to it and make sure it knows you are not intimidated. The only time I have been bitten by a dog was when I turned my back on it, so I make sure not to do that when I encounter them and I try to avoid being caught off guard by them.

On a run recently I saw a sudden movement that startled me. Assuming it was a dog I took out an airpod and looked around. Nothing was there. I kept running and it happened again. Still no dog. So I started paying closer attention to what was going on. I finally figured out what was happening in my peripheral vision. This section of the street had bright house lights on that were creating fleeting shadows of my own body that were duplicate and triplicate of my regular shadow. I thought I knew where my shadow was, and so these other shadows flashing in my peripheral were alarming.

As I thought about the experience, I though of how often this can happen in companies I have worked with. A bug or problem arises in the system and it causes critical failures in multiple areas. Quickly cases get created, calls and texts start occurring, and it can feel to a single admin like everything is in chaos, and that there are many problems when in fact there is just one. In addition, people might report an issue that has already been resolved but that they failed to report in a timely fashion. These types of situations can create many shadows that feel alarming, when really there is just a single person with many inputs that are creating the illusion.

The best way to quiet these voices and the sense of panic is through structured communication. Ensure users are all logging the issues in a uniform way so that you can gather the various inputs without getting overwhelmed. When users start calling or texting, you can use auto-responses to tell them you are working on a critical issue and their concern should be logged via a case or your standard process. That way you can ignore most of the noise coming in and get to the root cause quicker. You still need to quickly read those messages as they might have important clues as to the root cause of an issue, but an auto-response saves you the hassle of needing to explain what they should do, while also alleviating concern that you aren't addressing the problem. That buys you some airspace to tackle the most critical issue and get all the way to it's root cause. Once that is resolved, you should go through all the cases that have come in and look to see if they were also resolved by your fix. Likely, you can close out many of these and put people back at ease. This method helps you deescalate an issue quickly, and builds trust with your users that you have them covered.

While there are many techniques that can be used, I have seen that auto responses are a great tactic for saving time and quieting noise in a release hot-fix situation. Have your auto-responses ready to go in case an issue comes up, so that you can easily turn them on and quiet the noise that might otherwise slow you down and exacerbate the issue.

5 Tips to get started fast with Salesforce (or any project)

Salesforce Project Mobilization

The period after a budget decision has been made and before work starts is critical to a project, and I like to call that period mobilization. Here are 5 things you can do to nail mobilization, that will allow you to hit the ground running with your System Integrator (SI) or implementation partner.

1. Project Vision Statement

At a minimum, you need a project vision statement that says in no uncertain terms what you want to get done, when exactly it must be done by, and most importantly why you are doing it. If you can’t state this in 24 words or less (seriously, 24 words), then your vision isn’t clear enough yet, so spend a little time and get down to a statement that will serve as a northern star for your team as they trek through the details of the journey. This must come from the executive level, where the budget decision was made and the original objectives were clearly understood (or should have been).

Example: On Sept. 1, 2019 at 8 am, Salesforce will be our source of truth for Sales and Marketing, in order to increase customer retention.

If I am reading that as an employee, I can easily understand the executive expectations, how it might impact me, and can avoid asking the common speculative questions such as “Are they trying to eliminate my job?” because I can clearly see the why of the project as increasing customer retention. If you are actually hoping to cut costs as part of the why for your project, be transparent about it in your vision statement. But understand the implications of people getting fearful and potentially undermining the project - you will need to address this head-on, and explain a plan for how hiring will slow while growth continues, and over time the cost reduction will be achieved. Don’t leave any room for speculation about your intentions or the plans to achieve those intentions.

2. Team charter

Your project team should be 4-7 people that will represent all stakeholders of the project. Get them together now, before the project starts, and make sure that they all know the constituencies they represent. Ensure they have the time to dedicate to the project each week, so that they can do a good job. Then document the team with the Name of each team member, their role, and the constituencies they represent. This charter should be sent out internally to everyone even remotely touched by the project, so that they know who to go to if they have questions about the project, want to provide important feedback, or need to raise a concern. Ideally, on the team you have one project manager, that is not a member of a specific SI (either someone on your team or a third party) that will own the project. You also have an SI lead for the project on the team. This leaves 3-5 slots to be filled with whoever can best represent the various business units and their needs. The executive sponsor is not a member of this project team, but the project manager reports back to them for any decisions on scope/schedule/budget.

3. Scope Discovery

What do you mean no one planned an integration for us? Turns out marketing has been using a different system to manage leads than the rest of the company. Whoops. Does that need to be integrated? How did we miss this? The answer is no one asked. So how do you avoid this? Good mobilization. You have a project vision statement, so now your project manager needs to ensure all stakeholders hear that vision statement, understand it, and provide feedback on what they believe that means in terms of scope. For example, “On Sept. 1, 2019 at 8 am, Salesforce will be our source of truth for Sales and Marketing, in order to increase retention.” is a pretty clear vision statement. The project manager should ensure all stakeholders hear this, and provide their thoughts on scope. For example, customer service might want to highlight that they play a big role in customer retention and if customer data is in a new location, they will need to be in that system as well or have an integration to the customer support system. The clear vision allows stakeholders to talk about the future state and its implications with the PM, which means when the SI gets involved the PM already has questions to ask them in order to make key business decisions. What is the impact of integrating customer service vs moving them to the new platform? The project manager can then take multiple options back to the executive sponsor and they can decide if they want to increase the scope of the project to include customer service, tell customer service that they will have to live in a silo and ask them to start planning for that reality, etc. But the executive sponsor has the data to make a decision up front about the direction of the project and there will be no surprise later when that decision impacts the project. So many gotchas can be avoided with this simple exercise in good project management discipline, during mobilization.

4. Get your docs in a row

Most companies outside of very early startups have some form of documentation. Even many startups have something. You need to ask all the stakeholders if they have any documents that cover the processes that will be affected by your project, and/or any examples of how it is being done today. So much time is consumed by expensive consultants going around and collecting this information themselves, and if you can provide it up front, consultants can use their costly time to provide much greater value. What documents should you ask for? Process diagrams, schemas from any databases you are using today, training documents that explain how salespeople should work and update leads customer information, slide presentations from an executive retreat where a new commission structure was decided, google docs where a customer service manager has been taking notes on inefficiencies of the current support model, and so on. On most projects, I find these documents after hearing from various parties they don’t exist. Look harder. There is often far more already documented than you realize so ask clearly for any artifacts that will allow your partner to see into the current state of these processes and organize that info by process and stakeholder group. For example, your file should have a folder for “Sales Process” and inside that folder you would have folders for the different stakeholder groups that provided you documentation, with the documents in each group. This way, it is easy to get a picture of the various perspectives on a given process and understand where there are holes that need to be filled. Sales might have on view of the sales cycle, while sales ops might have a very different perspective on what it takes to close a deal. Your SI needs these perspectives, and the less legwork they do collecting that information up front, the more value they can provide.

5. System Access

When you purchase licenses from Salesforce you get a welcome email. You need to use that email to log into the system, and create a user for your partner to access your org. Alternatively, you can ask your partner to create a free trial org and start work there while you finish up the last negotiations with the AE and get everything signed (pro-tip, this can save you a month of subscription cost, just make sure the AE has the org ID for your trial org so they can activate it once you purchase). But not having access to the system will be an immediate roadblock for your team as you try to get the project up and running. Another thing to think about is getting your partner access to legacy systems so that they can see old processes and data structures. You might keep this to a limited permissions structure, but it’s another way to get things rolling fast.


If the above items sound like absolute basics of project management, it’s because they are. And yet through hundreds of implementations I have rarely seen a company execute on these items effectively, even after being asked to do so. Ideas are praised, but execution is worshipped. Companies that execute on the above items, and don’t disregard them as mere “good ideas” will see vast benefits throughout the rest of the project.