SharePoint Analysts–Stop analysing!

Michal Pisarek wrote a nice write-up of what makes a good SharePoint Analyst. I feel I have something to offer here, given that I…

  1. am a cynical old bastard
  2. am an opinionated old bastard
  3. have had some opportunities that not too many SharePoint people have had
  4. wrote this post on a plane while suffering jetlag 🙂

I am going to argue that as a SharePoint ”analyst”, the worst thing you can do is act like an analyst.

I previously wrote about the identity crisis that Business Analysts have which became apparent to me when I spoke at a BA World Conference last year. The gist of my point in that post came from my observations of a panel discussion on role of a BA within Agile development. I noted that the whole discussion seemed based on an underlying presumption that the role of the BA was to translate between IT and “the business". Agile by its very nature, shifts the ground out from under this assumption which caused a bit of consternation on the part of the panel. My takeaway from this, was that a role does not define the person. The body of knowledge of your discipline (in this case BABOK) is not the one truth. When you think about it, the body of knowledge by definition, consists of the lowest common denominators of a discipline of knowledge – a starting point. This is because the skills that you have built are your skills. Sure, you can write about them, but that only conveys a small dimension of what your skills entail.

Essentially, if everybody followed the BOK as the source of the truth then all consultancies would look the same. (Thinking about it, now you know why all large and expensive management consulting firms tend to sound the same…hehehe 🙂 )

image

The point is that it is the knowledge that you have earned that makes you what you are and what customers want. Knowledge comes from making mistakes, not by confirming your rightness. Therefore, people who practise constant learning by trying things out, challenging their models of reality, always build a hugely valuable corpus of tacit knowledge that is locked up in their brain where knowledge is connected and related in ways that form insight. It is because of this unique insight, that customers rarely want a “Business Analyst”.  They want Joe or Bob because of what Joe or Bob, as individuals, bring to the table. (Kailash writes about this in more detail if I am leaving you scratching your head at this point. I am going to quote him in a reply to Richard Harbridge).

The point I would like to emphasise, however, is that best practices cannot capture tacit knowledge. Codified best practices (or standards) are therefore necessarily incomplete. One of the things standards don’t tell you is how you should “practice the practice”. Practices have to be customised or adapted to specific organisational contexts before they can be practiced. The process of customisation invariably involves the creation of tacit knowledge to fill in the missing bits. This is why I used the word “rediscover” to describe this process, rather than “customise” (or “adapt”) : the former gives a better sense for the magnitude and type of effort involved whereas the latter suggests that minor tinkering will do the job (which it won’t).

So, here is a tip. Don’t define your own wellbeing by a role title or adherence to a body of knowledge because, if you do, you will inevitable have an identity crisis. The world simply moves on and with it, the problems that people are trying to solve tend to wriggle out of the domain of any single BOK. Any attempts to resist this will eventually become dogma and then we have “memetic smackdowns” as I describe in this EUSP Post.

image

Okay, so now that I have finished a mini rant, I’d like to address the whole “analyst” thing. Don’t get me wrong – it’s not the title of the role I am going to talk about here, but the analyst paradigm itself. That is, the notion that my purpose in life is to take some requirements, go to a back room, spend time “processing” and “synthesising” those requirements, translating away between "IT and “the business”, before formulating a solution for the customer.

This does not work well with most SharePoint projects! Especially ones that seek to “improve collaboration”.

Many people fail to see why this is the case, yet given the huge gap between the SharePoint that Microsoft shows you versus what you see on the ground, you would think that it would be kind of obvious. For what it’s worth, understanding why the analyst paradigm is dangerous also neatly explains why IT is generically predisposed to struggling with SharePoint.

Consider the following projects:

  • Implementing Microsoft Exchange for a global organisation
  • Implementing Active Directory for unified and policy based user and resource management
  • Replacing PBX with a Voice over IP system
  • Upgrading your wide area network from site to site VPN’s to MPLS managed WAN
  • Determining support and escalation procedures for a SharePoint deployment
  • Replacing a Windows XP/Office 2003 desktop environment with Windows 7/Office 2010

In the above list, if you ask the question “Will users accept and adopt this?” the answer is a fairly clear yes. At the end of the day, no matter what version of Exchange is in, Microsoft Outlook is still Microsoft Outlook. What the user sees is an Inbox and so long as mail comes in and goes out – they are happy. All Active Directory is to a user is a username and password to get to their computer. Irrespective of how clever the routing is in a Voice over IP system or a WAN network, a phone is just a phone. You can plan for support and escalation procedures for SharePoint, but at the end of the day, people will use the SharePoint system because it is the right solution for them. Sure they might get pissed if they have bad technical support, but if the solution is crap then no amount of awesome support structure is going to change this.

This, my friends, is the realm of the analyst paradigm!

You see, if you ask me to deploy Active Directory or Exchange, I will ask you a bunch of questions about your number of sites, number of users, communications infrastructure and the like, and I know that users will use it. I actually don’t need to talk to them. Oh sure, someone might do some communications planning, but I don’t need to address user adoption because adoption is already there! People adapted to email, telephone and Microsoft Windows years ago.

Instead, I can go into a back room, read a bunch of whitepapers and design/deployment guides and blammo. Here is your solution and here is how much I think it will cost. Better still, I can use waterfall style of project methodology because as a specialist, I have done this before and have expertise. I can tell you what needs to be done in considerable detail and break it down into a plan.

What it all boils down to is that there is a clear relationship between cause and effect, characterised by answering YES to the “If I do this, will users accept and adopt this” test. But most IT departments (and most IT integrators) are going to default to the analyst paradigm because many of their other projects tend to be in the above category. This analysis based mode of project delivery is very much ingrained into the reptile brain of a lot of IT professionals through years of repetition of implementing these types of projects. After all, it’s just IT, right?

Also, note that many of these type of projects are characterised by being very technically complicated. Some are insanely so and require specialist technical expertise. This is the realm of the supremely skilled person who performs an analyst function with a body of knowledge behind them. The whole industry certification process is built on this fundamental underpinning and works really well with things like Cisco and Microsoft in areas like Exchange, Active Directory and the like.

Now, consider the following projects or initiatives (I am deliberately picking things where people may disagree with me so go with me, ok).

  • Coming up with an navigational structure for a SharePoint collaborative portal
  • Installing SharePoint to improve collaboration
  • Replacing a folder based file share with a metadata based document repository
  • Designing a new road layout for a local suburb
  • Putting in a new intranet
  • Putting in a records management system
  • Installing a new time tracking system

In all of these problems, it is difficult to answer yes to the “Will users accept and adopt this” question. Sure, you can go all big stick and say “We will force them to” but that fails the “accept” part of the test. Therein lies the danger for the analyst paradigm. You can go off to the “back room” and use your body of knowledge, read best practices and “analyse” until the cows come home. Until you deliver the solution, you will not know if it will be accepted.  The cause and effect relationship is not clear until after an action has been taken!

image

The reason you can’t confidently answer yes is that all of these projects above require adaption on the part of the target audience. Adaption leading to adoption is a hit and miss affair. While we might like to think that we are all rational, clearly we are not. If you want rational, think Dr Spock from Star Trek – and even he got mad sometimes! Office politics and organisational inertia stems from the irrational world. Butt covering by positioning for “blame avoidance” for decisions made by fear and anxiety are commonplace. If you work in a large organisation and listen carefully to a typical meeting, the logic and facts that are spoken out loud are rarely what matters compared to the complex non spoken interplays that go on underneath the words.

For what it’s worth, I added a non IT example of designing a new road layout for a suburb. A rational analyst might think that residents have to accept the solution by definition because, after all, once a road is in, that’s it. But what typically happens is that residents of that neighbourhood see the plan, petition, form lobby groups and harass the hell out of their local political representatives. If this is enough to make the politician edgy then they will vote the plan down before it ever happens. Sure it might have been a good plan, but it’s gone now and the chances of further buy-in are greatly reduced.

The pure analyst is often taking a rational approach to an irrational problem space. Sorry folks – this is simply asking for trouble. Like the politician who does what they think will keep them in power versus what is logical shows the rational world does not always get a good look in. A good example in SharePoint land, is the “metadata is good and folders are bad” thing. Any metadata fanboy with this mantra often find the hidden organisation will beg to differ 🙂

So, what do we do then?

image

The facilitator paradigm instead aims to elicit resolution of problems using dialogue between stakeholders by achieving a greater degree of shared perception of the problem situation. Unlike the analyst paradigm, there is no back-room approach as such. By definition, we need to collaborate to do this. (Fancy that, eh? Collaborating to deliver a collaborative platform – who would have thought!)

Now, I am not talking about facilitation in the classic sense with everybody sitting in a room in a circle and plays team building games. Some of the best project managers and business analysts I have met are facilitators without necessarily knowing it. What I mean by facilitation is that our starting point is to leverage the wisdom of the crowd, by creating an environment conducive to participants being able to surface the irrational as well as the rational. Only in this way, can we come to a shared understanding of a problem and what should be done about it.

I previously termed this the holding environment, and it really is. A great business analyst or project manager knows this instinctively, and uses many tools (as well as some coercion and sometimes their own ego surrendering) to bring it about.

If you take anything away from this post, remember this. Anytime you cannot confidently answer the “Will users accept and adopt this” question, it is highly likely that not all users see that there is even a problem yet. Therefore, expecting people to magically buy-in and adapt when they don’t recognise the problem is never going to fly. Like trying to get a Darwinist to accept that intelligent design should be taught in schools, someone who does not believe in it to begin with, is not going to easily buy into a solution that requires them to change their beliefs and therefore behaviour. 

Conclusion

When you think about it (rationally!) we usually look at SharePoint as an enabling technology that can address a legacy of poor collaboration and information management. Yet, how can the world of the analyst work out if their solution will create the very same legacy without all stakeholders being on the same page?

So remember, in a project where the cause and effect relationship is not clear, use the facilitator paradigm and stop being such a bloody analyst!

Thanks for reading. Comments most welcomed Smile.

Paul Culmsee

www.sevensigma.com.au

 

In 2011, I will be posting sections of my Governance and Information Master Class here. Much of the content consists of mental models, alternative frames of reference, pattern and practices as well as other tools and methods, specifically for the facilitator paradigm. This is my interest area and feel the analyst paradigm is already well represented in the SharePoint space.

14 Comments on “SharePoint Analysts–Stop analysing!

  1. Hello Paul,

    Great post with some very clear and poignant observations.

    What I agree with most:
    1. Effective facilitation (theory, techniques, and experience) is a requirement for an effective analyst skill set.
    2. A waterfall/inflexible methodology or plan (that is non agile by nature) will be challenged by chaotic or very complex problems where not enough information is known and realistically action must be taken and results must be assessed to actually determine what the underlying problem(s) are.

    Some things that made me ‘perk up’.
    1. Analysis by it’s very nature is never complete. You can always go deeper and explore a problem further.
    2. A poor analyst is one who makes an assessment, observations, or discoveries and does not confirm (over time and by measurable results) whether those assessments, observations, or discoveries remain true.
    3. An Analyst is still a person. Just as a Project Manager is. To describe the point I want to make let me use this quote (which I completely agree with) “It must be remembered that project management is first and foremost a philosophy of management, not an elaborate set of tools and techniques. It will only be as effective as the people who use it.” – Bryce’s Law – So in this same way I do believe “Analysis is first and foremost a philosophy of diagnosing and solving problems, not an elaborate set of tools and techniques. It will only be as effective as the people who use it.”

    Fundamentally if you can’t determine what the problem is (or don’t have sufficient understanding/shared understanding) then you CAN apply many analysis techniques to help determine the problem(s). Yes facilitation techniques can help, as can requirements elicitation techniques, root cause analysis techniques and others, but the reality is that these kinds of situations depend on the availability of information and skill of the individual.

    I guess all I am saying on point 3 is that while I agree with you I do 100% believe it is the domain of the Business Analyst (or an adequate role variation) to determine and provide solutions to the problem which in my mind includes all the things that almost seemed to be indicated as a seperate skill set/set of requirements.

    Hope this adds further value and context to the conversation,
    Richard Harbridge

  2. Paul, Bloody brilliant! Of course! Why couldn’t I see it before? I study Sigma Six, I’m passionate about Lean, I filter down to only value added process all the time, but I never saw it as facilitating. Love your writing and theory, thanks for sharing. I read your blog often and am generally left so inarticulate in comparison that I’m ashamed to comment. Tonight I had to say ‘Thanks!’

  3. Kerri, thanks for the feedback. Richard.. I will post the particulr experience that was in my head when I wrote this article. Its one for the book but I can give an abridged version. Just bear in mind that my own corpus of insight comes from working on non IT problems more than IT. So I am probably a bit more right wing facilitation approach than you 🙂

    You mention verification of analysis by measurable results. The realm of determining those measures and making sure they are the right measures should be the realm of facilitation via and shared understing. Notice how when you call helpdesk they are desperate to close your call to ensure their KPI’s are met. All this does is piss off users, so while one small part of the organisational system is optimised, overall the metric does damage. This is an excellent example of a “metric by analysis”.

    I actually do not disagree with you because i often perform “classic” analysis, but it always is within the facilitation umbrella.

    regards

    paul

  4. Paul – Great post. I especially liked the examples, they clarify the difference between the two paradigms very nicely.

    Richard – It is useful to see the two paradigms as complementary approaches to problem solving: analysis (or breaking down) and synthesis (or combining). Facilitation is a means of synthesising ideas drawn from individuals within a group. Note that facilitation typically involves specific techniques (of synthesis) – we discuss some of these in detail in the book.

    Unfortunately, most standards, BOKs etc. focus on analytical methods rather than synthetic ones. Hence we have analysts of all kinds – financial, system, business – you name it. I’m yet to see a business-related job title that uses the other word (synthetic chemist does’t count :-))

    Regards,

    K.

  5. Thank you Kailash. That makes more sense to me now.

    I especially liked the ‘combining’ concept. I never thought of facilitation as a direct focus on combining, but instead with an analytical focus of effective information gathering – I suppose either would help make a decision, solve a problem, or exchange ideas/information effectively.

    Paul:
    A better way in my mind of wording that scenario based on our discussion would be: “Notice how when you call helpdesk they are desperate to – determine the cause of the issue and the appropriate resolution – in order to close the call and ensure their KPI’s are met.”

    In that rewording both the act of facilitation and analysis are performed which highlights how they both work well together. Failing to facilitate the call well could result in ‘pissing off the user’. So could failure to facilitate the analysis well (if the issue isn’t resolved correctly it also may result in ‘pissing off the user’. So either way I think they are equal in importance.

    Both are strong disciplines and I agree facilitation should recieve more focus/attention especially in the IT space (due to the fact it doesn’t have as much right now). 🙂

  6. Quoting you Richard ‘A better way in my mind of wording that scenario based on our discussion would be: “Notice how when you call helpdesk they are desperate to – determine the cause of the issue and the appropriate resolution – in order to close the call and ensure their KPI’s are met.”’

    It all comes back to the KPI. If the KPI is the time taken to close a call where quickest is best, then “determine the cause of the issue and the appropriate resolution” will be superficial at best.

    Therefore that KPI must have been dreamed up by an analyst, not a facilitator 🙂

    By the way, I use that example because with this logic I was able to convince Microsoft support to keep a call open when they wanted me to close it and re-open another 🙂

  7. I noted that the whole discussion seemed based on an underlying presumption that the role of the BA was to translate between IT and “the business”. Agile by its very nature, shifts the ground out from under this assumption which caused a bit of consternation on the part of the panel.

    This is a common feeling among business analysts, but it’s not the position of IIBA or the BABOK Guide. At best, translators are necessary when people don’t speak the same language, but the reality is that people are usually better off communicating directly. A good business analyst should be a problem solver, and problem solvers never have to worry about not having a role anymore.

  8. Hi Kevin

    I own BABOK 2.0 and it has a lot of good stuff in it. PMBOK essentially makes similar points, particularly about avoding command-and-control “Robot projects”, yet it doesn’t always seem to get carried down to the coalface. That gap is what Kailash Awati and I found interesting and have just completed a book about….

    regards

    Paul

  9. Hi Paul,

    Great Post!

    Some thoughts…

    Context 1 –

    The ‘Analyst Paradigm’ to me as a practicing Business Analyst is ‘There is a solution to a defined problem or perhaps lots of solution but still one that is optimal and it is a BAs role to find it out’. The following tasks are therefore more detailed and microscopic in nature. Being able to model business process well and being able to conduct good workshops etc. are great skills within the fore stated context.

    Context 2 –

    Now let’s turn it upside-down. There is a problem but no one person can articulate it or completely understand it. There are many solutions but no one knows about the effectiveness or even the measure of effectiveness of those solutions. There isn’t an optimal solution. In this situation skills such as relationship building, judgement (foresee and act in time), well rounded perspective (viewing the situation with different frames of reference), selling etc. are more handy tools to have.

    I often come across Business Analysts who have or are developing towards the skillset to be effective in context 1.
    I also come across people who have the skillsets for context 2. These are generally managers, Account Managers, ‘successful’ (by way of outcomes) project managers …but not many BAs

    SharePoint Context –

    SharePoint Business Analyst: The name itself suggests (to me) a BA who specialises in SharePoint i.e. a BA who is also technically proficient in a specific Microsoft Offering.

    CONCLUSION

    On a skills continuum it looks like

    What I have gathered so far is that we need to view it like so…

    Thanks for the post Paul C and thank you for your comments Richard H.

    Kind Regards,

    Leo

  10. Somehow my continuum got eroded in my post

    Soft Skills ————– to ————— Hard Skills
    Context 2 Professional to ————- ————- BA to —————– Share Point BA

    How it should look like
    Soft Skills ————– to ————— Hard Skills
    SharePoint ———-BA —— well ——– across ———– both

  11. (Thinking about it, now you know why all large and expensive management consulting firms tend to sound the same…

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.