Are you thinking about launching into a BI project soon?
Scope Management, Or…
Having made the decision to deploy (or maybe upgrade) SharePoint, done your due diligence and planned your project (see post #1 in this series), the next thing you need to do is scope your deployment and determine the functionality for implementation carefully, deliberately and preferably explicitly. If the planning phase was effective this should be easy enough. You’ll know what you’re trying to achieve and why – I’ll assume you have clarified the vision or objectives – and project scope should come reasonably naturally out of that.
However, project scope can be fertile ground for growing assumptions, like sprouting mushrooms in the dark. Being a little dogmatic up front, or at least very specific about what you’re delivering – and what you’re not – is usually a good policy, given an ounce of prevention is worth a pound of cure, as they say. Your key stakeholders or Steering Committee members may have their own assumptions about what this SharePoint project is and what it will mean for their business. Be as diplomatically pedantic as necessary to bring those assumptions to light and (also diplomatically) ring-fence any that are unachievable in the agreed timeframe and budget, or too great a tangent from core objectives.
- If you’re doing a document management flavoured SharePoint deployment, are file disposition and archiving or formal records management also in or out?
- Workflow is usually a big challenge in all sorts of ways that SharePoint may well expose but is unlikely to resolve on its own. Is SharePoint being implemented to support business process improvement by, say, replacing time-consuming manual offline processes with efficient online workflows? Then watch out for the implicit assumption that unclear or labyrinthine existing business processes, or lack of accountability, will somehow be resolved by the implementation (BPI/BPM is a different project, or at the very least a major workstream in itself). Or the other one – that SharePoint will make Business Analysts out of every staff member and they will quickly grasp this new system and leverage its plethora of tools to transform their way of working
- If you’re implementing an intranet on SharePoint, does your project scope also include sourcing / writing / reviewing / migrating content into intranet sites?
- Are team sites in or out? If in, what’s their core purpose and scope? Does your Steering Committee, for example, assume that a team sites implementation will include extranet-type capability so external partners and suppliers can collaborate online with employees, whereas the project plan assumes otherwise?
- If you’re upgrading from SharePoint 2007 to SharePoint 2010, is the objective a relatively straightforward version upgrade, or does the upgrade include re-assessment and restructure of the existing solution’s content, information architecture, etc.?
I raise these only to indicate that grey areas can proliferate, and unexamined assumptions can create plenty of room for scope creep or sometimes even all out scope wars down the track. To avoid budget and schedule overruns, arguments and tears, discuss, agree and then document as specifically as possible what’s in scope and also what’s out of scope. Stick to this throughout delivery – anything that wasn’t included was presumably excluded for good reason, and should therefore be parked as a candidate for a later phase.
… Don’t Try to Boil the Ocean
Speaking of phases, it’s a rare deployment that warrants or can afford serving up every piece of the SharePoint ‘pie’ (http://sharepoint.microsoft.com/en-us/product/capabilities/Pages/default.aspx) at first and at once. Even if you did have the budget and were able to tick off every segment against burning business priorities, arguably it wouldn’t be a good idea to try, when you consider the user impact and adoption issues, not to mention increased risk of failure. I imagine someone has come up with an equation that proves the likelihood of project success is inversely proportionate to its size and complexity. It certainly holds true for SharePoint. (For an excellent thesis on why SharePoint projects fail, see Paul Culmsee’s highly readable 8-parter that starts here: http://www.cleverworkarounds.com/2008/04/11/why-do-sharepoint-projects-fail-part-1/)
It’s also worth bearing in mind that rarely do people get as excited about a project that’s a highly qualified success, no matter how big or ambitious, as they do about a smaller project that’s an unalloyed triumph. Which one do you want yours to be?
Once your project is in flight, be sure to manage scope rigorously and stay focused on the end game. I admit this again sounds like basic Project Management and extremely obvious advice, but in the context of a SharePoint implementation scope management often seems to become particularly difficult. I think this could be due to SharePoint’s embarrassment of riches in the capabilities department. Despite (or possibly because of) that SharePoint ‘pie’, it can be difficult to explain to the uninitiated or a busy senior decision maker just what SharePoint is and can do. (And, more importantly, what it can do in their specific situation and for their budget.) And this can lead to misunderstandings about what “our SharePoint project” will deliver on Day 1.
But Don’t Just Boil the Kettle Either
- making the solution unappealing to or confusing for users
- introducing ‘hidden’ costs by de-activating / hiding core features
- locking yourself into a design (logical or physical) that won’t work for the business in future
You’re not just making a cup of tea here. Accept that SharePoint projects are usually fairly big the first time, and there are reasons for that (more of that in future posts). You need to do a certain amount of base level work to establish a good foundation, even if you do have a tight focus on just one or two aims or outcomes initially. And always think about future potential and the longer term roadmap when scoping a SharePoint deployment or upgrade project. Be mindful that you may be designing and delivering what will be an initial solution or just the first phase of several projects that will build on the application’s strengths.
SharePoint is relatively conducive to phased delivery in some respects – conceptual ‘chunking’ of purpose, if you like – but in other ways it really doesn’t lend itself to modularization, in my view. Take just one example of several, the user Profile and My Site. It’s easy enough to disable the private component of this SharePoint feature so that users are not equipped with a private document library and a workspace in which they can, amongst other things, manage web parts and create their own individual blog sites. And there are perfectly reasonable governance motives for choosing this approach. The private My Site is quite easily enabled by your IT administrator if/when the organization is ready at some future point to train users, and support and govern this feature. No consultants necessary. It’s not quite as simple a decision to disable the public Profile. If you insist on this, as more than one of my clients has in the past (in order to replace the SharePoint Profile with employee profile information derived from alternate sources), you are choosing to excise a core element of the product and that, I think, is a dubious choice. Profiles, for instance, augment information in SharePoint and enrich searches, and can add a great deal of contextual value to the user experience. Further, if circumstances change and you want to repeal the alternative in favour of enabling SharePoint Profiles downstream you may also find, as did one client, that this makes for an unconvincing business case on its own and approval can be hard to come by.
- Manage scope rigorously on SharePoint projects to help ensure success
- It’s better to deliver a smaller, initial solution extremely well and build on success from there, than do an ordinary job on much bigger project
- Start simple … but not too simple … and always think big picture