A few weeks ago I was approached about working with an organization to help them put together a new SharePoint 2013 site to replace the one they currently have (SP2010). The business unit that approached me is responsible for engaging with stakeholders when the company wants to build infrastructure in their operating region; let’s call the unit EE (external engagement) for the sake of discussion.
Now, before I get all ranty and critical, you should know that EE wasn’t getting much love and attention from IT; this post is not about assigning blame to EE or their Business Analyst, with whom I’ll be working pretty closely. The fact is that there are problems in how IT engages with the business that are way beyond the scope of this post. As you read this post, keep in mind that a business case has been prepared and approved by IT (a VP) and EE (a Director and an SVP).
“To enable [EE] to capture the benefits of SharePoint in our department, we need to revisit our existing 2010 [EE] Team site.” That quote is the first sentence of the main body of the approved business case for the project. The case goes on, in excruciating detail, to describe in non-quantifiable terms how implementing various features and functions available in SharePoint 2013 will benefit the department. What the case doesn’t contain is any sort of goal or objective from the business indicating why the project is necessary and what the measurable business outcomes ought to be. Nor does the case contain any criteria upon which project success will be based.
If I were to summarize the business case as it’s currently written, it would be something like “There’s a bunch of cool SP2013 stuff that isn’t being used and we think we can use it to make our site look pretty and show people what we’re doing and we’ve started a Proof of Concept (PoC) that we’re going to finish soon to show you just how pretty those SP2013 things will look on our site and we’re going to do whatever we want whether it’s standard or not even if it’s stuff that other projects and departments are really responsible for. Okay?”
In addition to containing a shopping list of SP2013 features to be deployed, the business case also makes assumptions about the way in which many of the features will be deployed. Now, having some insight into the organization, I can tell you unequivocally that many of those assumptions are incorrect because they don’t comply with standards and guidelines that the organization has adopted. To be fair, had IT paid more attention, these deviations would have been caught and much time and money would have been saved.
I, and others, have advocated for trying to get the most out of the technology organizations have on hand. However, that doesn’t mean that organizations should invent requirements that provide no discernable business benefits simply to make use of some feature that’s currently sitting on a shelf. What it means is that, once real business needs and benefits have been identified, organizations should look at the tools they have on hand before going out to acquire something else. Of course, this should all be bound by an organization’s standards and guidelines.
Fortunately, the business case has been approved only to get the business requirements done. The organization uses a pure waterfall, gated SDLC so I’m going to use that to our advantage and try to get things back on the right track. I’m also going to try and get the PoC descoped or killed altogether. Things aren’t so far down the path that they can’t be corrected, but it will take a fair bit of cajoling and coaching of the BA. We’ll also have to get IT more engaged but I have a pretty decent PM to help with that bit.
Things to take away from this story:
- Only deploy technology based on identified and accepted business needs;
- Have measurable outcomes defined so you can actually determine whether or not you’re succeeding;
- Business and IT are partners and must work together;
- If your BA isn’t that strong, make sure they are properly coached and supported;
- Don’t sign off on a business case that doesn’t contain business objectives, business drivers, or success criteria;
- If you’re not going to comply with corporate standards and guidelines, cool, but have solid justification for not complying;
- If the first sentence in your business case is something like “To enable [EE] to capture the benefits of SharePoint in our department, we need to revisit our existing 2010 [EE] Team site.”, you don’t actually have one;
- Shiny Object Disease is both preventable and curable.
 Many years ago I had a contract gig with a major airline. My sole responsibility was to evaluate non-standard IT requests to determine whether or not the provided justification was sufficient enough to warrant approving the request. I.e.: Standards and guidelines can occasionally be broken if there is valid justification.