It’s a chilling phrase that I’m betting your clients mutter all too often.
They’re dragged into a meeting to discuss the requirements of the new SharePoint Project, they don’t know the context, they don’t understand why there’s more change, they don’t know the underlying strategy, all they know is their own individual business challenges.
You ask them what they want and then you get both-barrels of their emotive, locally-focussed, technology driven business requirements shotgun!
The previous post in this series about our 21shift model, focussed on how we run our “Vision” stage. Today I will look at what we think is a pivotal stage in our approach to ensuring your organisation delivers business value from your SharePoint or Office 365 (or any other technology!) project and that is the “Outcomes” stage:
Outcomes – We facilitate the definition of value, outcomes and requirements you need to deliver for your organisation, business, customers, citizens or stakeholders.
The traditional practice of articulating project requirements is typically driven by functional capabilities of the platform. I’m sure you’ve all either said these things or heard this from your clients:
“We want SharePoint MySite’s so we can be more social”
“We need a document library to store our contracts in”
“Can we have a list of events on the home page”
“Can we have News and Audience Targeting”
The words highlighted in the bullet points above are all SharePoint functional features, is this really what you users are asking for deep down? What do they really need? Do you dare ask the question WHY?
So at 21apps we have stopped talking about ‘business requirements’ and changed the focus to ‘business outcomes’ because its the value of those outcomes that’s important, not the technology features used to implement it.
So what’s with this change of terminology?
Quite simply it’s because we feel that for projects based on technology platforms such as SharePoint or Office 365, tradition Business Analyst techniques and approaches aren’t sufficient or appropriate and we now need to look outside of IT for more appropriate approaches that take a more facilitative approach.
There’s some great rationale behind this point that discusses the ‘baggage of requirements analysis’ from Andrew in his recent blog post Requirements–we don’t need them! and also a light-hearted view on the world of requirements that is painfully accurate on the Dilbert website.
To add some context to this, here are my top 10 fundamental issues with business analysis and so called ‘requirements gathering’:
- Analysis makes significant assumptions based on the individuals experience – Results are very much influenced by the individual analyst, their experience, domain knowledge and ability.
- Analysis translates business requirements to technology features – But not all requirements have a clear associated technology meaning.
- What the business needs from a technology solution is constantly evolving – Business, economy, culture, people, our understanding and technology capabilities are also continually changing, who really still thinks that delivering a solution based upon requirements captured 3 months ago is going to be effective?
- Business problems are quite often ‘wicked problems’ – No point trying to assume you know what the one and only answer is to the businesses problem.
- The act of ‘Requirements gathering’ pulls together disparate local requirements and then tries to ascertain and align the business value – Wrong way round!
- Analysis focusses on local problems and local optimisation – Local-based projects can quite often be detrimental to overall organisation effectiveness.
- Analysis doesn’t focus it’s efforts on business-technology alignment – It’s driven by individuals, ego’s, hidden agendas, organisational hierarchy and who shouts loudest.
- Analysis (and especially MOSCOW ranking) puts the emphasis on what business users and/or stakeholders want and not what is best for the organisation – It’s my opportunity to influence, what can I gain from this project?
- Analysis asks ‘What’ and doesn’t pay any attention to the ‘Why’ – If there’s no good business reason then don’t do it!
- Analysis rarely delivers a shared understanding and shared commitment in both the business and IT functions about what the project is going to achieve – Without a shared understanding of what’s being delivered, how can we hope to be successful?
Let’s unpack why facilitation is more appropriate. Fundamentally, SharePoint projects are ‘People Projects’ and that means that they are influenced by a diverse set of factors including:
- Pace of Change
- Problem Wickedness
- Technical Complexity
- Social Complexity
Stakeholders and business users ‘don’t know what they don’t know’… If you ask them what ‘SharePoint’ should do they will tell you so called ‘requirements’ that will make their life easier, not what will improve organisational effectiveness, delight customers and help achieve their businesses vision.
Technology projects need to move away from aspiring to fulfill individual and local ‘wants’ and focus on delivering technology that helps meet organisational goals (Big Hairy Audacious Goals) and business outcomes not just local improvements and petty feature driven wish-lists.
That’s why our approach focusses on using facilitation tools and techniques to ask both ‘What?’ and ‘Why?’ and elicits the business needs and measurable value, linked to the organisational strategy and outcomes and because we use facilitation, we gain a shared understanding and shared commitment across all the business and IT stakeholders to deliver a strategic business project no just another technology upgrade.
In our on-site consulting engagements and our ‘Governance as a Service’ (GaaS) offering we use inclusive, activity-based, collaborative and facilitative tools and techniques that are academicaly and industry proven. In most client meetings you’ll find us and the client standing by a whiteboard, writing, drawing, playing and sticking up post-it notes!
Some examples of what we use to facilitate business outcomes (what you call business requirements) include:
- Innovation Games – Yes we play games with our clients, both on-line and face-to-face, they’re a great way to improve user and business stakeholder engagement in the envisoning, scoping and business outcomes phases of a SharePoint project.
- Dialogue and Issue mapping – Another great tool, pioneered in the SharePoint world by Paul Culmsee. It’s an inclusive facilitation process that creates a visual ‘map’ that captures and connects participants’ comments and associated rational as a meeting conversation unfolds.
- Affinity Mapping – This technique, predominantly using whiteboards and post-it notes, allows the capture of large numbers of ideas stemming from brainstorming activities to then be sorted into groups for review and action.
- SharePoint Project Canvas – Based on the work done by Alex Osterwalder in the book ‘Business Model Generation’, 21apps have modified the ‘canvas’ to allow us to visually map a SharePoint projects business model, including facets such as costs, revenue, value proposition, customers, partners, high-level activities etc
- De Bono’s “Six Thinking Hats” – A technique that is extremely effective at focussing a workshop and meeting to achieve specific objectives or focus on particular facets of a topic and removing all ‘ego’ from the discussion. The different coloured hats are used individually and represent different ways of discussing a topic or focussing on a problem for example when ‘wearing’ a ‘white hat’ you focus on facts, ‘green hat’ concentrates on innovation and ‘black hat’ is cautious, careful and critical.
Because in these inclusive, visual, facilitative processes we are asking the ‘What?’ and the ‘Why?’ we can distance ourselves from the constraints of the technology platform and the existing legacy assets and look to innovate the business rather than defaulting to technology solutions. Sometime that means that the right answer to an engagement is not a technology project but a change in process, culture, roles or business model! Either way as long as the business or technology change project improves organisational effectiveness, delights its customers and helps our clients achieve their businesses vision, then we are happy and the project is a success.
A great example of where using facilitative techniques in-the-field has really added value, can be seen in the Legal Ombudsman Case Study.
If you think this approach will fit well with your business or customers, consider getting 21apps on your team for a small subscription cost, delivering this approach through our innovative ‘Governance as a Service’ (GaaS) offering. Find out more in the GaaS Service Description or get in touch.