Andrew gave a great overview of the 21apps Organisational Shift Model recently in his post Rightshifting with 21apps Org Shift Model, but that was just a taster for an initial series of blog posts going into some depth around our model, how we implement it with real clients and the story’s behind its effectiveness for delivering true business value from SharePoint, Office 365 or any other platform.

The focus of this post is to give some more clarity about the Identity stage of our model. In our original whitepaper we stated the following:

Where are you with respect to 21apps SharePoint Organisational Shift Model?
Based upon the Marshall Model for Organisational Evolution (Rightshifting) we examine, assess and document your organisational and SharePoint implementation maturity.

Some may think that spending time working out how mature an organisation and its technology implementations are is a waste of time and has no value to a technology project, but for us this is the first crucial step in moving our client stakeholders from the default SharePoint project mentality of “local problem requires a local solution”  to looking holistically at how this project or programme will benefit the organisation as a whole.

One of the key tools we use in this stage is the Marshall Model for Organisational Evolution (Rightshifting). You can read about the model elsewhere, but the benefits for us are clear, picture this:

We have a client, we have a high-level understanding of their business, and that they feel their technology platform isn’t delivering value…

We have a workshop planned with a diverse mix of business and technology stakeholders and we need to elicit both the organisational and technological issues that need resolving as part of this engagement

There’s two options here that relate to opposing mind-sets in SharePoint projects; traditional Analysis and the much less prevalent Facilitation approach.

Taking a traditional Analyst approach to the project, what typically happens is that questions about what the users want of the project will be asked, discussions at both a pseudo-business and technical level will occur, notes get taken by various project team members (to be analysed and perhaps documented later) and a warm feeling will be had (by the project team at least) that they’re engaging with the business.

For some straightforward technology projects (think “Simple” domain in the Cynefin framework) this may be an effective approach. For most projects (especially for collaborative platforms like SharePoint) it is a wasted opportunity and results in poorly documented meeting minutes of little value. Perhaps a vague agreement of the way forward for the next stages of the project may be reached, but what does not occur is any demonstrable value from the meeting or a shared understanding of the problem space and certainly no shared commitment across technology, business and “provider” stakeholders.

That is the first and crucial failure of the typical analytical approach to delivering SharePoint projects. Some may say that the adoption of agile approaches to SharePoint delivery counteracts this approach, but in my experience analytical methods still get enforced, just in smaller chunks…

With our approach a different scenario emerges:

We visually and through the use of “business stories” explain to the client our model and the power of this approach to their situation.

We explain the purpose of the Marshall Model while we draw it on a whiteboard and invite the stakeholders (business and technology) to plot on the graph where they feel the IT (SharePoint if we want to be specific) and the organisations maturity lies.

We utilise other visual techniques to facilitate explanation of the problem scenario or complex situations.

We facilitate open conversations (whilst creating a live dialogue map of the session) and come to a shared understanding of the organisations overall maturity levels.

The visualisations don’t have to be awesome, they just need to be a focal point for discussion and participation.

However, the dialogue map (created live and on a shared display so attendees get a shared view of how the dialogue evolves) needs to accurately represent the conversations and decisions made as it forms the cornerstone of both our documentation and also future activities.

Over the course of just a couple of hours, armed with just a few photographs of whiteboard visualisations, the Marshall Model and a Dialogue Map, we find that we have achieved the secondary aims of this stage which are to engage the business, get a feel for the value we need to deliver and open them up to working in a collaborative and facilitative manner; we have also achieved our primary goal:

We have enough client momentum and shared understanding across the group to re-focus the SharePoint project to an organisational outcomes linked business project.

One of the most interesting outcomes for myself is understanding the dynamics between organisation and technology. With a shared understanding and commitment mapped on the whiteboard of technology and organisational maturity/effectiveness who is dragging who forward?

Is the  culture and organisational maturity crying out for better technology?

Is IT trailblazing “new ways of working” and trying to instil change in the organisation?

Think about your current project, which traits does it exhibit? Do you need to change the way you deliver this project? Don’t forget its the business that is investing in IT not the other way around.