The Great Dashboard Clean-Up: Roles, Data Owners and Key Result Areas

In the previous blog entry, I commented on the problem: the Salesforce Dashboards I had deployed were not driving change in the organization. At least not to my level of satisfaction. From my vantage point, everyone was looking at the data, talking about the data, admiring the data -- but I didn't feel we were learning anything from the data. I wanted our Salesforce Dashboards to do more -- to influence changes in our business practices.

None of this implies that we aren't already running a highly effective organization -- because we are. Our product (SAFARI C3, a VOIP Media Switching System) crushes the competition with incredible performance numbers -- 99.999% uptime last month, and 99.996% overall for 2008. Our Customer Response Team wildly exceeds our competitors in number of categories: response time, restore time, resolve time, and Customer satisfaction. Despite our success, we do have areas were we can improve -- all organizations do. And that's what I wanted our Dashboards to focus attention on.

Step One: Identify the Roles of Your Target Audience
Identify who is using Salesforce.com and Dashboards in your organization. Group them by role. At my company, Cedar Point Communications, we've embraced CRM fully, so I have users from many different roles in the tool every single day: the Executive Team, Sales, Marketing, Customer Support, Account Management, Partner Management, Field Services, Project Management, Manufacturing, Software Engineering, Hardware Engineering, Technical Documentation, and Product Training.

Phew! That's a lot of different user groups!

For each department, I assigned a Data Owner -- usually the department/division manager, or someone they specifically assigned to work with me. Next, I had a group meeting with all of the data owners to outline the project objectives. I then scheduled follow-up one-on-one meetings with each of them individually.


Step Two: Define Key Result Areas for each Role
At the 1:1 meetings, I asked each Data Owner what their Key Result Areas (KRA) were -- what were they hired to accomplish?

From Brian Tracy's Blog:

Each job can be broken down into about five to seven key result areas, seldom more. These are the results that you absolutely, positively have to get to fulfill your responsibilities and make your maximum contribution to your organization. Your failure to perform in a critical result area of your work can lead to failure at your job. There is essential knowledge and skill that you must have for your job. These demands are constantly changing. There are core competencies that you have developed that make it possible for you to do your job in the first place. But there are always key results that are central to your work and which determine your success or failure in your job.

A key result area is defined as something for which you are completely responsible. This means that if you don't do it, it doesn't get done. A key result area is an activity that is under your control. It is an output of your work that becomes an input or a contributing factor to the work of others.

With Dashboards focused around KRA, business unit managers would be able to see, at a glance, how their teams were performing. Each Role / Dashboard Owner would see where their team excelled and what areas needed more attention. The goal was to create Dashboards that influenced process changes within the organization.

Next blog post -- we'll start with the Customer Support team.

The Great Dashboard Clean-up Project

Ok, I’ll admit it: I created a monster. This post is my confessional, and also my pledge to atone.

Very early in our implementation of Salesforce.com, I wanted to show the power of Dashboards to my users. I downloaded the AppExchange Dashboard Pack 1.0. The application is free, and installs all of the many dashboards published by Salesforce Labs. The package had dashboards for every conceivable use: lead flow, marketing campaign metrics, sales forecasting, support KPI, sales / support rep performance tracking, document tab tracking, user adoption, data quality analytics … everything.

I downloaded the app, did a little tweaking (very little), and then published the dashboards to my users. When Summer’08 Release gave us the ability to email dashboards (as an HTML page) directly to users, I enabled that functionality for a few key managers and user groups, too.

Soon after, I saw copies of dashboards distributed at various meetings and screenshots of dashboard components included in PowerPoint presentations. Managers and executives looked forward to their daily, weekly and/or monthly Dashboard emails, and talked animatedly about them in the halls or at company meetings. I felt good.

Yet something was wrong. I couldn’t quite place my finger on what it was, but the monster was there, elusive. The users asked for more dashboards, more pretty graphs, charts, tables, and I appeased them. Today, we have more than 50 different dashboards and hundreds of reports feeding those dashboards. It's an absolute glut of information. And this monster I created now has a name: Data Admiration.

They come to the CRM tool, very excited about the volumes of data and information captured in our Salesforce Dashboards. They drink deep from the kool-aid. But none of these dashboards seem to drive any real change in the organization. Why not?

Reflecting on that question during my morning commute, I realized it's not the people, it's not the tool ... it's the dashboards. Those original dashboards that I pulled down from the AppExchange were developed as a proof-of-concept, a way of showing report and dashboard writers all of the graphical components and different techniques for using them. They were a learning tool, but I had implemented them as a business solution. And that’s the root of the problem. I have dashboards, but no real business intelligence architected behind them. The dashboards are colorful, they certainly detail a ton of information, but they aren’t oriented around the specific business intelligence needs of my user communities.

Understanding a problem is the first step in dealing with it! I chatted about the problem with the Big Cheese, and got the green light to focus on a complete overhaul of our existing dashboards. In the next few posts, I’ll walk through the process of this Great Dashboard Clean-up Project. Stay tuned!

How about you? How did you implement your Salesforce Dashboards? Are they telling you everything you need to know about your business / organization? We’d love to hear your comments!

No, Chicken Little, the (SaaS) sky is not falling

Yesterday there was a Salesforce.com outage that lasted somewhere between 30-40 minutes. In the 24-hours since that time, the blogosphere has been filled with various pundits spreading doom and gloom, saying this outage proves Cloud Computing is not a prudent business decision.

Sorry, Chicken Little, the SaaS sky is not falling. Cloud computing is here to stay. If anything, yesterday's outage is proof to me how much better off we are running our business in the clouds.

When the Salesforce.com outage started, dozens of IT engineers jumped into action, working to first isolate the problem and correct it. In the aftermath, today and for the rest of the week, dozens of technical teams will be working to understand what went wrong, how it went wrong, and what they can do to prevent it from happening again.

The best part? None of those people are on my company's payroll. It's a good thing -- I couldn't afford that many IT and support staff. Yet I am very thankful that they're on my "cloud", helping me run my business. I wouldn't be able to administer such an incredible CRM tool without their help.

When the outage started, I didn't call Salesforce.com; I saw that several folks on Twitter had already done so. I sent out an internal email telling colleagues "we are aware of the problem with Salesforce.com, and have people working on it right now." Yep, I had people working on it!

I switched our Support team over to our Salesforce Offline Viewer. It's a custom PHP application accessing a SQL server database that we designed several months ago. Through the Salesforce API, we update the SQL database every 24-hours with a complete copy of all transactions we've entered into Salesforce.com. The GUI isn't as pretty as Salesforce, but it contains all the data they need: Cases, Solutions, Contacts, Accounts, and various custom objects.

I then set up a "Salesforce" Twitter search on my TweetDeck, sat back, and watched for news that people were able to finally log in. I've never had to spend less resources and manpower managing a crisis.

This 40-minute service outage was a blip. Let me tell you about another recent outage at my company, this one not related to the services we have running in the Cloud.

A few weeks ago, we had a little ice storm here on the east coast. It knocked out phone lines and electrical power for hundreds of thousands of New England residents. Our company lost power for 4-days. The backup generator lasted for about 10 hours, and then it went offline, too. Everything was down: telephone service, electrical power, heat.

Employees couldn't communicate with each other over Blackberry or email, because the Outlook exchange server was down. Customers couldn't access our corporate website. All of our critical IT systems are redundant, with a co-lo on a completely separate power grid. Even that didn't help us, as this storm had knocked out both power grids (yes, we're moving the co-lo further away -- and let me tell you that is a huge project in itself!).

Every member of our IT and support staff began round the clock shifts, working to get our back-up generators back online, contacting utility vendors and facility managers, shutting down servers and equipment to protect from power spikes, etc. It was exhausting!

The one aspect of our business that was unaffected? Salesforce.com. We were able to communicate outwardly to customers via Salesforce. That allowed us to send a Mass Email to all Customers, providing them with alternate contact numbers for accessing our Customer Support staff. We modified the home page layout, to include status updates for all employees logging in to Salesforce from home.

The sales team, 90% of whom are remote, were able to conduct business as usual. After we altered the call routing for our main support phone #, the entire customer support team was able to work from home, too. They had full access to Cases, Solutions, and other information they use in Salesforce -- as if they were in the office.

The four-day service outage was seamless to our Customers, thanks to the Cloud. Thanks to Salesforce.com.

I compare these two outages -- especially the manpower and resources that went into restoring service fully and I know that Cloud Computing is the right model for our CRM service.

Perhaps all these blogging pundits have Cracker Jack IT teams, allowing all their in-house systems to operate with 99.999% up-time. If so, I hope they give special thanks to each and every member of their IT staff, and maybe a nice fat bonus at the end of the year.

Me? I work in a place called reality. And even though my company has the very best of IT folks, they are resource constrained. They do capacity planning, integration testing, and constant tuning of our many complex business systems. But Salesforce's IT team is bigger, and comparing the availability numbers between our in-house and cloud-based systems just wouldn't be fair.

So cheer up, Chicken Little, you've got people.