In my blog post, "The Nine Keys to SharePoint Success" I called out Business Connection as the number two key to success. In this blog post we'll delve into what makes a business connection – and how to create it.
How hard could it be to solve a business problem? A walk through the break room will provide snippets of the latest frustrations of your coworkers. Getting into your car of an evening will reveal more challenges as someone is on their cell phone desperately trying to get home – and address some urgent business problem at the same time. It seems like business problems wash over us without any effort to try to find them.
The challenge is that these problems may not be the most pressing problems that the business has, so how do you find the business problems that matter? There are a few key ways to sniff them out – and to solve them with SharePoint.
If your organization is very large you'll have a team of software developers – or several teams – working diligently against a never ending list of applications that the business wants. The pressure to complete their work is managed through the application backlog. That is the list of applications that the business wants but there aren't resources to get them done – yet.
The application backlog is very formal in some organizations, having to be pruned, tweaked, and reconfigured every quarter, every year, or for each reorganization. In other organizations the application backlog is written on the development manager's whiteboard. Whatever the process to keep the backlog, it's a gold mine for key business problems. These are the visible problems that the organization believes are the most important. Cherry picking a few items off the backlog that might be able to be solved – or mostly solved – with SharePoint can help to ensure that you've got a real business connection to what you're doing.
Help Me Help Desk
If you can't cherry pick from the application backlog – or you can't figure out how it's managed in your organization – you aren't out of options. Another key source for business problems – in this case undiscovered ones – is the help desk. The help desk answers calls when systems are having problems and also when internal customers need help knowing how to solve problems.
Systems with disproportionally high numbers of calls or calls with long resolution times might be candidates for retirement. In fact, these solutions are often on their "last legs" just waiting for things to break completely so that someone will try to find a solution for the problem that they solve. So, why not preempt the process and try to find a SharePoint solution to the problem before the old system fails completely?
Requests for help are useful to as they tend to indicate areas of solutions where the business is exceeding the design criteria. Sure you can use Excel to close the financials for a global organization – but that may not be the best approach. Searching through the service requests can often expose key needs for the organization that aren't being addressed in the best way.
Ask for Directions
Perhaps asking for directions from management is too obvious, however, often I find that folks are timid when approaching a business person to ask what challenges they're facing. Sure you can infer the business problem by looking at the application backlog or the help desk call report – but wouldn't it be easier to ask about the business challenges?
The Business Doesn't Know What They Want
Occasionally I hear an objection from a well-meaning CIO or IT director who admonishes their staff for wanting to – gasp – talk to the users about what they need. The argument is that IT knows better what the business needs than they do. This is positively dangerous thinking.
On the one hand, I can agree that the business doesn't know the solution that they need – that's not their world. On the other hand, they know the business problems, challenges, and opportunities they are facing better than anyone in IT will ever be able to know. It takes both the intimate knowledge of the problem that the business brings and the technical skills of the IT team to propose and explore solutions which may fit the problem.
The best solutions come from listening to the problems that the business is struggling with and proposing solutions which may solve those problems – or at least part of the problems. One of the reasons that the classic waterfall model of solution development doesn't work and why agile approaches are so in vogue right now is because waterfall doesn't encourage the same single-team mentality that agile approaches do.
Six Degrees of Kevin Bacon
One of the challenges that SharePoint projects often face is that the problem that the solution solves isn't directly a problem that the business is having – at least not tangibly. One of my favorite conversations is "Why are you using SharePoint?" The answers are often "To collaborate" or "To share" -- which is fine, but it doesn't really tell me much about the real business need that SharePoint is solving.
Usually when I press on this point I hear "we have to collaborate better." Of course, no business needs to collaborate better just to collaborate better. There's an implied with collaborating better. It could be improved efficiency, reduced cycle times, or fewer mistakes. The problem is that we need to get to the real reasons for the SharePoint platform. If we can't get to the real reasons for SharePoint – beyond the platitudes of efficiency and better service – then we don't really know what problem we're solving.
The further we are away from the real tangible problem we're solving for the business the harder it will be to get resources, to get users engaged, and to make the platform successful. It's difficult to take a platform and really connect it to business problems – unless you recognize that you deploy the platform and then engage the business with the specific examples of how you've improved processing by leveraging the platform
Throughout this process struggle to get to the real answers on how the business is benefitting. Maybe it's a reduced response time to a RFP by a day. Maybe it's improving the closure rate of proposals through better quality deliverables. Maybe it's something else. Whatever it is try to get your numbers as close to the actual business impact as possible. You may have heard of SMARTer as a framework for getting things done. It's a way to make things concrete so they can be effectively measured.
You don't want the business problems you're solving to be six degrees of Kevin Bacon away from the problems the business wants to solve.
Return on Investment
In most cases a request for an ROI is a barrier because the person asking for it doesn't "see" the benefits of the solution. At some level this will be the case at higher levels of the organization – but often the ROI is a smokescreen barrier that's inserted to force folks to clarify their thinking around the real value to the organization.
As I said in the SharePoint UnROI, the real goal of an ROI isn't the bottom line numbers. The goal is the clarification of the plan for how the business will be successful with the solution. In the case of selling SharePoint's ROI, it might be that you have to bundle a few solutions that you intend to deploy immediately and compare the cost to deliver on SharePoint as compared with the cost to deploy a solution without SharePoint.
ROIs are notoriously bad at showing the impact to the organization for platforms and tooling like SharePoint. It's difficult to get valid assumptions about how much time is wasted each day because of poor information, the number of sales lost due to late, incomplete, or unprofessional responses, or how improved communication would help to transform the organization's productivity. Because the assumptions are hard to make, the problem turns into the Drake Equation. It's an interesting exercise but the confidence in the answer is pretty low.
If you approach the ROI as an opportunity to clarify your thinking and to reduce the uncertainty of the outcome – then it's a good process. The ultimate output of the ROI may not be anything like the real return on investment but at least you've improved your understanding of the business impact.
Rational or Emotional Decision
The final point to consider when delivering a business connection is to realize that as much as we really want to believe we make rational decisions, we actually make emotional decisions and then rationalize them. If you don't believe me, try to cost-justify the purchase of a hybrid vehicle. For most of us it can't be done. I took list prices for a Toyota Highlander and a Highlander hybrid and then planned a fictional 6,000 miles of highway driving and 6,000 miles of city driving and gas at $4 per gallon to determine that the hybrid would pay for itself in 23 years. The life of the vehicle isn't even that long. And yet folks buy hybrid vehicles and flaunt their gas savings.
We've discovered that the lowest cost bid for contracts isn't always the best deal. The intangibles are often weighted such that a higher priced big can win – for good but emotional reasons.
If you're looking at creating a business connection and believe that it's as simple as an ROI, you might need to take a step back and remember that the root of politics in your organization is emotion.
If you're looking to better understand the nine keys to success or how to deliver a business connection, take a look at our DVD.