Introduction

I normally talk about SharePoint project success in terms of “SharePoint Celery”, where I see the negative calorific value of eating a stick of celery analogous to the lack of positive ROI in most SharePoint projects. For one day (blog post) only I want to switch analogies if I may.

Let us think of a SharePoint implementation in terms of a relationship and these four key stages:

·         Flirting

·         The Proposal

·         Wedding Planning

·         The Big Day

·         Happily Ever After.

What I hope to reveal within this blog post is that in traditional SharePoint implementations (and probably a lot of weddings and relationships) we are not focussing enough time and attention on the right phases, which is why we don’t always get the outcomes we would wish for.

Flirting (Vision & the Why)

There may be days, weeks, months or even years to get to the point of being ready to “propose” marriage or in fact the use of SharePoint to solve a business problem. But in both life and SharePoint contexts, this period is important, really important in fact! It’s this “phase” where you decide the “Why?”, the reason for proceeding with the relationship and where we should be assessing the difference this project or marriage is going to make and whether it is really worth it.

Some marriages happen for no really good (long term) reason at all (no clear “Why?” or benefit); most SharePoint projects unfortunately fit into the same category. I am sure most of us have at some time said of friends, celebrities or work colleagues “why are they getting married? They have nothing in common, what will they get from it?”

I see this as clearly analogous to not identifying a clear “Why?” and not identifying the difference your project is going to make to those involved (the business or marriage stakeholders). There needs to be a very clear shared understanding and shared commitment required for a SharePoint project or a marriage to really work long term.

We often see organisations implementing SharePoint “just because” someone senior thinks it’s the right thing to do, or driven by the IT team because they have the technology so why not, and it is these scenarios that more often than not end in failure, disappointed users and worst of all, wasted resource (time, money and opportunity). Rather than deciding on a whim to deliver SharePoint (or get hitched), we should consider carefully the longer term and not rush. We should ensure we have a clear vision and understand the difference this is going to make to our business or lives.

A great way of achieving this is to use workshop techniques such as “Remember the Future” or “Cover Story”, which we at Soulsailor Consulting Ltd can help facilitate.

The Proposal (Business Case and Approval)

Marriage and relationships (we hope) are for the long haul, just like our SharePoint projects; but there are still a couple of pivotal points in time that we need to consider to make things work.

The first of these is the “proposal” that point in time when you get down on bended knee in front of the board and ask for approval and funding of your project.

Let’s face it, no matter how clear and confident and sure of a future together we are (SharePoint or your partner), sometimes the planets don’t align and they say “NO!” – it may be because they don’t have the same shared understanding and commitment as you, it may be the timings not right, or it may be just that you (or your project) is just not attractive enough and the board (your partner) never really fancied you anyway!

Whatever the reason, the cause and effect is the same… there is no project or relationship to work on... This is a very sad place to be.

I hope it goes without saying that doing a project without approval is never going to end well, or even start at all; but it amazes me how many projects and specifically SharePoint ones start without “consent”, without a thought of Return on Investment (ROI) and without a business case and approval. If the organisation doesn’t share your passion, your understanding and commitment to the delivery of this “value”, then how will you deliver it?

It’s also worth considering at this point “tradition” – certainly in the UK we typically ask for permission from our future long term partners “father” before “popping the question”; in the SharePoint context however, we shouldn’t just rely on the permission of one stakeholder, for organisational change (and in my opinion all SharePoint projects have some change element) or our relationships having the support of senior stakeholders/parent/friends is a significant aid to the process and delivery of long-term value and happiness.

Wedding Planning (SharePoint Project)

So we have approval for our project or to get married to the person of our dreams, we’ve probably set a date for the go-live launch / wedding day, so now what happens?

·         In SharePoint you create a project team with a project plan

·         In marriage you may appoint an external wedding planner, or perhaps the “brides” family will do the organising?

Either way what we have is a project of some kind and a project manager (mother of the bride, wedding planner, bride’s best friend etc.) who is going to run around and control the show for the next few months or even a year in order to make the preparations for the big day and the wedding/launch go smoothly…

This feels in most cases as the time in the relationship or SharePoint project where most emphasis, time and effort are spent.

Are you with me so far?

Does this sound like where we spend most of our time implementing SharePoint?

Great, so what happens next? You spend lots of time and money and have lots of stress and challenges dealing with developers, infrastructure, seating plans, flowers, stakeholders and family all to make the big wedding day or SharePoint solution launch awesome and perfect.

But think about this situation carefully and ask yourself this:

Is the wedding planning really that important?

Special yes; required yes; but critical to the long term success of the relationship?

Absolutely not!

Likewise, is the SharePoint project plan really that important?

Expected yes; required yes; but critical to the long term success and delivery of value through the SharePoint platform?

Absolutely not!

So why on earth do we focus so much time and effort and attribute so many success factors to everything leading up to the big day?

A little crazy perhaps, but let’s face it that’s what “we do”?

The Big Day (Launch)

Launch day arrives, yay the project is completed, the plan has been completed and deemed a success, business users have given the solution the OK (user acceptance testing etc.), maybe there’s been some end-user training, basically everyone is happy and the solution is purring in the background. Job done…

Back in the wedding, the Bride and Groom got to the church OK, no one raised any objections, the speeches went down a storm and the party is in full flow. What a lovely day...

Then what happens…

Over in the Big Corp the branded mugs and mouse-mats have a spelling mistake, a server goes down and some people are complaining that the functionality isn’t what they expected…

Over at the wedding party the best man just had an argument with the bride’s brother, your Aunty has had a far too much sherry and is dancing on the tables and DJ is playing some really bad tracks...

Do any of these problems that may seem huge and devastating at the time really affect the marriage or the value of the SharePoint solution long term… absolutely not!

Happily Ever After (Continuous Improvement)

I’m hoping that the discussion so far has highlighted that despite approaching SharePoint projects in what seems like a logical fashion, we are still not really being as effective as we could be.

The most important aspect of SharePoint projects is not that project plan that we were led to believe, no it’s the SharePoint Flirting (Vision and Why?) and the Long Term SharePoint Relationship (On-going  Change Management) that really makes the difference.

So how do we simulate two partners working together to create a wonderful long term relationship in the context of your SharePoint project?

My view is that they are both pretty similar; in the context of “life” you have the two partners and their support network of friends, relations and colleagues. In the SharePoint context there are still two main parties that need to be involved

·         The business users

·         SharePoint Tummelers.

The support network (for the Tummelers) is provided by the SharePoint Centre of Excellence (C of E) or some other business centric, SharePoint aligned team. A close relationship should be developed and exist between users and Tummelers (who are in effect just a special type of user).

The other aspect that is often missing from SharePoint projects is both any consideration as mentioned before for on-going change management and also continuous improvement.

In the context of a relationship we as humans are constantly evolving, our tastes change, we mature our perspectives change and this is exactly the same as “SharePoint business users”. So solutions (and people in relationships) need to change and adapt regularly. SharePoint solutions are people solutions, they live in the Complex domain of the Cynefin framework and as such they exhibit emergent behaviours.

We have to continually stay focussed, evolve, test, probe and adapt to the emerging needs of our relationships and also the business problem that our SharePoint solution was implemented to try to solve.

Conclusion

Shot-gun weddings for the most part fail.

Relationships without on-going hard work usually go bad.

IT led SharePoint projects with no business alignment or vision pretty much always fail.

SharePoint projects with no active on-going change management “wither on the vine” and fail to deliver their business outcomes

You need to treat your SharePoint implementations like a marriage or long-term relationship:

·         It should be seen as a commitment for the long haul

·         There’s needs to be a shared understanding and commitment

·         You have to have equal doses of give and take

·         It’s hard work, but the benefits are significant

·         Business and SharePoint projects should never stop evolving.

If this post resonates with you and you need help and support in focussing on the right things, the long term benefits then please feel free to contact me.