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.
Please note, I am not a lawyer, nor have I played one on TV (though I really liked Boston Legal). I’m also not a privacy expert, but I really value mine. Like, really value it. I mean it.
Earlier this week, March 27th to be precise, the Supreme Court of Canada ruled that authorities need a wiretap warrant to “intercept” text messages, the same as they need for listening in on phone conversations. You can read the full ruling here and you can check out CTV’s take on it here. For you non-Canadians, CTV is one of our national broadcasters.
In essence, the court opined that text messages are equivalent to an electronic conversation and should be afforded the same level of privacy. So far so good, but what I want to know is what makes communication a conversation? To my mind, a conversation occurs when one or more parties are interactively using their words and their ears. Whether the conversation occurs on the phone, in person, over computers … whatever, makes absolutely no difference. At the same time, what excludes electronic communication from being a conversation?
Is a chat via instant messaging not an electronic conversation much like text messaging? True, the devices may be different, but it was the court that stated that the technology should not matter. Are private/direct messages via social networking sites not private conversations? Is an email thread between specific individuals not sometimes a private, electronic conversation?
My point is this …
If we’re going to hold the authorities to a higher standard when they want to “listen in” on our conversations, we need to be very clear about what a “conversation” is. If text messages require a wiretap warrant (btw, what about texts stored on the device?), then so too should instant messages, private/direct messages, and some emails.
I’m in favour of providing the authorities with the tools they need to effectively deal with crime and criminals, but not at the expense of my privacy.
Let’s pretend you’re working on a major project that has multiple stakeholder groups, each with agendas, priorities, philosophies, etc. Now let’s also pretend that the project (it’s actually a program) has been envisioned by the CEO or some such all powerful being. Let’s agree that all the stakeholder groups, in order to keep their jobs, have bought into the CEO’s vision of the future. Why, then, is it that no two groups can actually agree on how to move forward? Why, in some cases, does one group actually try to diminish the value of another (it’s not a .net vs Java thing)? It’s because they don’t communicate effectively.
Communication is not about the loudest voice winning. Communication is about articulating your points in a manner that can be understood by your audience. Communication is also about LISTENING. The communication issues on this entirely fictitious project are really due to nothing more than a bunch of alpha dogs peeing on the same spot to mark their turf.
The reality is that they are going to have to find a way to communicate effectively; because this project is not going to be scrapped (someone would lose face – another communications gaffe). Coming in hard with an iron fist in a velvet glove isn’t going to work because there would be a massive backlash from the user community, resulting in really bad things happening to a lot of people.
One of my roles as a consultant is to facilitate communication between stakeholder groups. It’s my job to take everything in and send it back out in a way that offends no one (or offends everyone equally). The toughest thing to accomplish is to convince everyone that all the good ideas are theirs (fosters buy-in and ownership).
My point is this: if your project is being hit by internecine warfare, you need to do something about it. It’s all well and good to have a communication plan that includes posters, coffee mugs, cult-like rallies and all that blather, but if the people that have to define and build the solution can’t come to some sort of agreement the whole thing’s a waste of time.
If you don’t have the resources internally to fill the facilitation and liaison roles, engage a consultant.
The totally fictitious project is an ECM project, but poor communication will kill any type of project.