Business Requirement or Business Value?

In Business Intelligence by IRM UK0 Comments

Print Friendly

One of the key issues I see with any project based upon the Microsoft SharePoint Platform is the significant lack of business value they actually ever deliver despite the promises of a “collaboration nirvana” or a “strategic business platform”.

Introduction

So what is business value?

Wikipedia defines business value as:

“…an informal term that includes all forms of value that determine the health and well-being of the firm in the long-run… Business value often embraces intangible assets not necessarily attributable to any stakeholder group. Examples include intellectual capital and a firm’s business model…”

My definition varies subtly, not because I think the wisdom of the crowds on Wikipedia is wrong, more because the statement above highlights the potential weakness of the term “business value” i.e. “intangible”, whereas I am of the opinion that if you cannot measure or directly correlate an action to value, then it is not “business value”, it becomes more of a positive action with no definable value.

My definition of “business value” has therefore become:

“…all forms of quantifiable value that can be directly attributed to the positive well-being of a firm…”

My experience of working with businesses delivering SharePoint projects over the last 5 years has led me to believe that pretty much all IT service providers and client IT departments really just don’t get it, technology project after technology project gets delivered based upon:

  • A set of “formal requirements”, and these vary from a detailed weighty tome to the informal output of a meeting
  • The IT implementers technical experience
  • Functional limitations of the platform
  • What the client IT function think the business need.

These common drivers have led me to develop a few simple f-laws (truths about organisations that we might wish to deny or ignore) regarding IT project business value that you may wish to wield in times of need:

f-1. IT project stakeholders, who don’t know how to measure what they want, settle for wanting what they can measure.

f-2. The less important the requirement, the more time clients (and IT) spend discussing it.

f-3. The more technical experience your supplier or IT department has, the less they understand your business needs.

f-4. The amount of business value a project can deliver is inversely proportional to the technical complexity that actually gets delivered.

Considering these f-laws, there is no wonder that IT projects deliver to poorly defined requirements and tend to miss the point with respect to business value. To articulate this further, here is a real world example that I have witnessed.

Let me tell you a story:

I came across a UK financial services organisation that had their roots deep in financial tradition and were not particularly technology savvy. They had signed an EA agreement with Microsoft and were looking to leverage the tools and platforms they had at their command to deliver business benefits to the company [sounds a positive idea?]. The IT department had implemented SharePoint on a test server and started to use it as their team and project portals for collaboration and document management, with some basic level of success and positive feedback.

They were migrating from Lotus Notes to the Microsoft platform as part of a strategic technology re-platform programme [strategic for the IT department maybe, but does the business really care?], and therefore wanted to share the value and the opportunities with the rest of the company. An ideal lighthouse project was the re-development of their intranet onto SharePoint [a familiar story]. So a project was created:

  • Led by the IT Department
  • Implemented jointly between IT and an IT services provider
  • With minor business sponsorship though Internal Communication department.

The “requirements” as they were, were for a like-for-like replacement intranet articulated by IT through a list of SharePoint features, the original Lotus Notes-based intranet had a number of “custom features”, branding was minimal and functionality was typical for a basic intranet solution.

The implementation went as you would expect with no major implementation issues and the new intranet platform went live [with the typical fun announcement of “name your intranet”!]. Despite this positive technology project implementation, this is how the project was perceived by the business community:

  • “What’s different?”
  • “Why doesn’t it do this, I’d expect a new intranet to let me…”
  • “Why can’t I…?”
  • “What was wrong with the old one?”

In addition to those comments:

  • There were also usability issues within the non-technology savvy organisation.
  • The IT Department were questioned about cost versus value
  • Other IT-led projects, with much greater value potential became significantly more difficult to justify.

Obviously not a lighthouse project, and as always the “build and they will come” was not the right approach!

The problem

So hopefully that story should resonate with you and articulate that we all do indeed have a business requirement versus business value problem?

So what’s the real deal here? Well in my experience projects delivered solely on business requirements (either sourced from IT or the business stakeholders) just don’t deliver value to the business community and the issues those projects create are clear and damaging; here’s a few of them and I know that you will have more:

  • Project only delivers SharePoint functionality – The project focuses on technical functions with no consideration of business value, end-user requirements and “ways of working”
  • Requirements fatigue – “…we explain what we want to IT but they don’t deliver, so what’s the point anymore…”
  • Perception is Reality – The perception that the SharePoint project has not delivered anything of value, even though it has delivered all the stated business requirements, will not help anyone
  • Lack of any meaningful Return on Investment – Attempting to identify and measure value from SharePoint function-based business requirements at the end of the project is like shutting the gate after the horse has bolted
  • IT doesn’t become a strategic business service – If IT projects can’t deliver towards the business strategy then IT will very soon become marginalised and a revert back to an expensive cost-centre.

So these issues seem to create 2 clear chasms in the organisation between business and IT:

  1. Business know they have challenges and issues but don’t understand how technology can support them
  2. IT departments know they have technology that can deliver value but don’t know what the business really need.

The reality is I am sure, significantly more subtle than this black and white picture I am painting, but it is a reality that we need to seek to address in order to be successful with our SharePoint implementations.

The two points of view articulated above are very indicative of the behaviours typical of an organisation who has SharePoint installed but does not know what to do with it.

Rightshifting

Bob Marshall published a paper on “The Marshall Model of Organisational Evolution”, which neatly demonstrates through the concepts of the “four mindsets of rightshifting” the evolution and chasms that occur within organisations implementing SharePoint, or any other large-scale, functionally rich application platform:

The simple chart you will see the four basic mindsets which prevail within organisations at given levels of effectiveness, along with the three “transition zones” (shown in orange) where each of these mindsets overlap. The basic premise of Rightshifting is that organisations can improve their effectiveness incrementally (and with little turbulence / disruption), until such time as they approach a transition zone. At these transition zones, major upheaval – in the form of a shift of mindset – is required to proceed further to the right i.e. to continue to improve the effectiveness of the organisation…”

Taking a purely SharePoint perspective on the first two stages of the graph above:

Ad-hoc – A typical entry position whereby the client has SharePoint deployed and sporadic teams of early adopters (such as IT) are using the platform for discrete activities

Analytic – This second stage is normally reminiscent of an organisation that has implemented SharePoint as an Intranet and is starting to deliver small, discrete business services such as room booking and document management with sporadic organisational adoption.

The chasms (orange) are the discrete touch points whereby an organisation needs a significant shift in mind-set from both IT and business perspectives and understand more clearly the need and the synergy between delivering business value and the technology platform.

Looking at this challenge in another way, the f-laws I stated in the introduction are absolutely key demonstrators of the challenge faced, when implementers are trying to deliver SharePoint into organisations crossing the “Ad-hoc” or “Analytic” chasms:

f-1. IT project stakeholders, who don’t know how to measure what they want, settle for wanting what they can measure.

f-2. The less important the requirement, the more time clients (and IT) spend discussing it.

f-3. The more technical experience your supplier or IT department has, the less they understand your business needs.

f-4. The amount of business value a project can deliver is inversely proportional to the technical complexity that actually gets delivered.

To cross those chasms, you have to radically change your thinking to focus on business value.

Some clues:

Here is a hand-full of examples of real-world client business requirements for SharePoint Intranet projects I have been involved with:

  • We require WYSIWYG editing for create and edit of pages and content
  • Document approvals process
  • “Ask Jeeves” type of automated FAQ
  • Room booking
  • Colleague Directory
  • Secure groups
  • Discussion forum

As you can see these requirements (I appreciate they are on the extreme end) are mind-blowingly dull and for the most part offer little or no demonstrable and measurable business value, but this is what we are faced with and is what clients and IT departments are requesting for as their “business requirements!

I had an interesting look back over a raft of SharePoint projects I’ve seen, reviewed or been involved with and analysed the percentage of projects that had potential to deliver business value based upon the requirements the client had stated. Based on analysis of their requirements, had the potential of only between 25% and 50% or less of those requirements delivering any real business value.

The solution

The answer isn’t to go and through yourself metaphorically across the chasm and hope you can jump that far, and we have seen clearly that it’s not about just deploying the technology and praying…

The solution is I think relatively straightforward to understand in concept, but not necessarily easy to execute and does take a significant effort and organisational buy-in from both parties (business and IT) to “shift to the right” in thinking and culture.

In simplistic terms, some key recommendations I would make for moving from Business Requirement to Business Value are:

STOP DOING SHAREPOINT PROJECTS!

Name and frame your SharePoint projects with a business audience and value in mind

Ensure you are engaging with the right business and IT stakeholders and that you are asking them the right questions: 

  • Ask “What Business values are you trying to achieve?” Not “What are your business requirements?”
  • Extract and articulate a clear vision for the project from the business stakeholders
  • Make sure you facilitate a shared understanding between yourselves and the stakeholders of what you are trying to achieve
  • Drive out Business Value Requirements from the user requirements and use those to govern the project.
Wrap-Up

So I hope this has been a valuable explanation of why “business value” in SharePoint based projects matters so damn much? I think it is appropriate at this point to recognise that there are challengers to this viewpoint that believe that only measuring economic value, economic profit, or shareholder value is an appropriate aim for business value. I absolutely endorse these as fantastic “pure” measures of business value, but for me as I am often engaged as I am sure you are, as the kind of linchpin between business and IT,

I feel that my definition of business value is more appropriate:

“…all forms of quantifiable value that can be directly attributed to the positive well-being of a firm…”

And I think in reality there will always be a healthy and pragmatic mix of business value (primary) and business requirements (secondary) in our SharePoint projects.  This blended approach can be difficult to achieve when a project is faced with organisational, process and technology changes, I hope what I have articulated today will help you start to change your approach to SharePoint  projects, feel free to call on us at Soulsailor Consulting Ltd to help guide you across those chasms between business requirement and business value.

“However beautiful the strategy, you should occasionally look at the results…”
– Sir Winston Churchill

Leave a Comment