But how do you go about defining, documenting and communicating those business objectives? Then – how do you tie them to the features that SharePoint offers? In short, how do you make it more likely that SharePoint will line up with and support your business objectives?
Here are six simple rules of thumb.
Rule 1 – Insist on documentation. Colleagues may tell you that a Project Initiation Document isn’t needed. That the bureaucracy is unwarranted. That everyone knows what the business objectives are – so why waste time stating the obvious? That it would be impossible to get something like that approved. None of these objectives are valid. Particularly the last. If disagreements are waiting in the wings, much better to get them out in the open at the start and resolve them. Otherwise they will hit you mid-development, and that will spell trouble.
Rule 2 – Keep the big picture in view. Information guru Ben Schneiderman has a great mantra: “Big picture first, then zoom in and focus.” If your objective is to improve customer retention, make sure everyone knows it. All too often, objectives are described at a very narrow and detailed level, and the description focuses on the short term outputs rather than the longer term outcomes.
Rule 3 – At the same time, include enough detail. If the art of strategy rests on knowing the current position, the desired goal, and the route between the two, make sure all three elements are included. Often only one (“where we want to be”) is included – leaving stakeholders to guess at how the desired outcome will be achieved.
Rule 4 – Think of the *contribution* SharePoint will make. If you know of a corporate or business unit strategy, describe it here, then express clearly how SharePoint will contribute to it. If the key aim of the customer service team is to resolve complaints more quickly, think about how SharePoint can help. If the aim, on the other hand, is to reach larger numbers of new customers, think again about SharePoint’s contribution – it could be radically different. Make sure that the link is explicitly made in your documentation.
Rule 5 – Know the target audience. In a past life, I wrote many advertising and marketing briefs, and the target audience section was always one of the most important. Marketing briefs might include not only who the target audience is, but something about how they think and act. The briefs might go further, and specify what the desired response is – to try the product? Get back in touch? Renew a subscription? It may seem unfamiliar to apply these consumer marketing techniques to enterprise audiences, but they can be highly effective. At any rate, developers need to understand target audiences; their needs, objectives and qualities. In our SharePoint consultant approach, a description of target audience often graduates to a set of personas, which in turn leads to a set of tasks. Personas and tasks link business to data architectures. If you prefer, use the more established metaphors of users and use cases.
Rule 6 – Know what success looks like. This one ties in to Rule 4, and is at the heart of SharePoint planning and Design. Success doesn’t simply mean the completion of workflow steps, or the creation of new sites without error messages. You should force yourself to define and commit to some targets. What might be important to your organisation? Content uploaded? Networks built? Downloads? Blog entries written? Or do you have bigger business targets in mind? You might find a framework like the Program Logic Model useful in measuring the success of your project and establishing early on what the leading indicators and KPIs relating to that success might be.
