How To Reduce Your Application Backlog with SharePoint

There’s always more CIOs can do to help the business succeed.

Regardless of what company you work for, there seems to be an unending parade of requests to integrate some new application, or develop some application for a part of the business where you can’t find a commercial off-the-shelf (COTS) product to solve.

Like many CIOs today, despite the unending list of tasks you have been assigned, you may also be faced with a flat or shrinking budget. If you’re in that enviable position, having the limited budget finding the right people is always a challenge. This begs the question: How do you improve your internal satisfaction and reduce the backlog of applications to build?

Defining the Problem

The first thing you need to realize is that your application backlog is an iceberg. What you see are only the projects that are big enough and valuable enough that they’ve officially made the list. Behind your official list are the applications which smaller and less significant parts of the organization need but can’t get on the list because they don’t meet the minimum bar. Whether you have an official minimum bar or not, most organizations have learned that some projects just aren’t worth putting on the list. Consider the age of some of the requests on your backlog. In many organizations application backlogs are measured in years not months or weeks.

How Did We Get Here?

Applications make the list because the current costs represent something significant to the organization. The other reason the applications make the list is because the business can’t solve the solution themselves. What would be optimal would be if the business had the tools and skills to create their own solutions.

Historically there have been tools like Microsoft Access which created problems when the business was allowed to create their own solutions. The problem wasn’t that they were necessarily creating their own solutions, but rather that they chose a technology with issues and there wasn’t enough communication for you to understand where the business was building their own. Picking a better platform to allow users to build their solutions on, and also improving the communications with the business, can effectively remove the negatives surrounding users built solutions and allow the organization to reap the benefits.

Where’s Here?

Nearly every survey indicates that the market penetration for Microsoft SharePoint is huge. Microsoft research indicates that 78% of the Fortune 500 companies use SharePoint. Effectively SharePoint is available in most organizations, even if it’s not an officially supported platform. So here’s a platform that the organization owns but one which is also typically underutilized.

In many organizations, SharePoint is underutilized because it was propped up with the purpose of facilitating collaboration. In the history of business a more ill-defined target was never known. It may be successful in helping some users work together but many others aren’t quite sure how to use it. Perhaps in some companies SharePoint was implemented as a small document management system and it’s now become little more than a more expensive way to store files.

In most cases business users don’t yet see the value of creating their own solutions, and you haven’t had the ability to create the awareness or desire on the part of the business to leverage the platform for all it can do.

Adoption and Engagement

Let’s say the infrastructure team stood up SharePoint and technically it’s working well but the adoption rate has never been what you had hoped. Then the infrastructure team asks “Why aren’t they using it? We did the same things that we did when we installed Exchange and they’re just not coming.”The answer lies in the fact that Exchange – or more precisely email – is a mature service. I remember in the early 1990s when I was driving email adoption in organizations because it was new, unintuitive, and yet immensely powerful. The infrastructure team just expects that if they build it people will come – which doesn’t work for a set of tools that aren’t entrenched in the way people work.

Fundamental to the SharePoint adoption problem is it’s comparison to email. The comparison is wrong because email is its own solution. It’s not, at its core, a platform for building solutions, it’s a tool for message delivery and communication. You don’t need to build anything on email for it to be useful. SharePoint can be useful without building on it, but it’s most valuable to the organization when solutions are being built on it.

Users don’t need to just use SharePoint to add value or to just adopt it. Instead, some fraction of users needs to be fully engaged in creating solutions on the platform that others can use. It’s this engagement, this solution creation, that’s critical to pull adoption along, and more importantly to drive business value.

At What Cost

The real costs to creating engagement, and thereby reducing the application backlog, aren’t in dollars. It’s in changing the way that you’re looking at the investments you’ve already made and getting more impactful in the training and reference investments you’re making. A little bit of planning on an adult-centric approach to learning can lead to more engaged users creating their own solutions, and a reduced need for your application development teams to get involved. By taking an involved approach to helping the business solve their own needs you can increase communication and minimize the number of business critical applications that they are building without your knowledge, and strengthen the relationship with the business in the process.

About Robert Bogue

Robert Bogue is an 8 time Microsoft MVP currently awarded for SharePoint server who has written 22 books including The SharePoint Shepherd’s Guide for End Users which is also available as a corporate license to help drive engagement. Robert is also a Microsoft Patterns and Practices Champion and internationally renowned speaker who consults with Fortune 500 companies on how to better leverage their investments in SharePoint.

Robert’s blog is at http://www.thorprojects.com/blog. Robert can be reached via email at Rob.Bogue@ThorProjects.com.