What Facebook teaches us about a social enterprise

A common concern I get from customers when discussing the use of social tools within organisations is something that goes along the lines of "Social enterprise.  You mean 'Facebook for the enterprise' - what a waste of time!"

Now for business managers tasked with driving organisational productivity, finding staff using Facebook when they should be working is definitely frustrating.   But using Facebook is not the same thing as using the latest social enterprise tools in an organisation.   More interesting, social enterprise utilise in a business context,  the great social benefits so brilliantly demonstrated by Facebook in the consumer domain.

I recently wrote an article for CMSWire which discusses the key features of Facebook which a business should seek to achieve using social enterprise tools.  You will also get to meet my niece, Grace, a mighty exploiter of Facebook's social capabilities and the person who introduced me to 'onesies'.

Andrew

What does the Microsoft buy out of Yammer mean to you

After a few days of whispers around the industry, it now seems clear that Microsoft will be acquiring Yammer for the princely sum of one billion dollars.

That's a lot of dosh, but represents a clear statement from Microsoft that (i) it considers the social enterprise market to hold significant upside; and (ii) it didn't feel that its (massive) development team could produce a home-grown alternative in timely and/or cost-effective manner.

For the social enterprise technology space, this move is a game-changer.  Disruptive new products like Yammer, as well as similar tools from the likes of Jive, Telligent and Newsgator, have been setting the industry pace, leaving the industry heavyweights (think: Microsoft, IBM, Cisco, Oracle) playing furious catch-up games.

Opinion so far has been mixed.  Have a look at this mixed bag of reviews by a variety of analysts and this bullish assessment by Eric M. Jackson , the CEO of CapLinked.

I believe this move will create a lot of uncertainty in the minds of Microsoft's customers, who have committed to SharePoint as their intranet/collaboration platform.   As it stands right now, SharePoint is the leader by a country mile in the portals space; however, out of the box, SharePoint is light-on for social capabilities. That has left SharePoint customers with only a few choices if they want to establish social functionality:

    (1) In house customisation of SharePoint - This is expensive and is likely to fall foul of Microsoft's inevitably rough treatment of customisations at upgrade time;

    (2) Stand-alone third party solutions, such as Yammer, etc. - This has had a lot of success, particularly for Yammer, with it's 'freemium', under-the-corporate IT-radar, model.  However, the problem with using Yammer is that it is a stand-alone solution, with limited integration with SharePoint, a separate user profile and  the YACC ("Yet Another Communication Channel") problem;

    (3) Use tightly integrated third party solutions - In the space, Newsgator has taken the early market lead , producing a product that plugs tightly into SharePoint, adding market-leading functionality while avoiding the issues associated with having social activities on separate platforms.

It is a fair bet that Microsoft will now seek to deepen the integration with between Yammer and SharePoint, creating a more unified experience,similar to that now available via Newsgator.   Moot is whether the effort will be skewed more to the Office365 cloud offering rather than the in-house solution.  In any event, this may take a year or so to achieve and in the meantime customers are left with some difficult choices:

 - For Yammer users, seeking better integration with SharePoint, should they wait for Microsoft's dev team to complete their work or should they jump immediately to a more mature platform, like Newsgator?  The issue here will be one of understanding the opportunity cost of not having a good SharePoint integration.  I suggest organisations in this camp do their due diligence on the alternatives;

 - For SharePoint users, seeking to add enterprise social capability, should they get started with Yammer , go with a Newsgator, or wait for the Yammer integration to settle?  Adding complexity to this one, customers have to bear in mind that - for the time being anyway -  they will have to pay license fees for Yammer where there are >100 users.  As with the previous group, this customers in this camp should take the time to evaluate the market alternatives.

 - For organisations not interested in using Sharepoint, the buy-out may make Yammer a less attractive option.  This is good news, perhaps for other vendors of stand-alone solutions, like Jive, Telligent, etc.  Similarly, organisations with commitments to other heavy weights (IBM, Oracle,etc) will naturally look to the social offerings coming from those vendors.

It going to be interesting seeing this one play out!

Creating a telepathic organisation

If, like me, you're scifi fan, you probably tend to live a bit in the future - after all, that's where all the cool stuff is going on, right?

I just published a post for my work in which I discuss how the new breed of social business tools can give your organisation telepathic powers right now! *

You can check it out here.

Andrew

* I may be exaggerating just a little

SharePoint and the art of fast food configuration

When I talk to new clients about SharePoint they are inevitably surprised and/or dismayed at the amount of planning that is required to implement it.    "But I just want a basic intranet - that can't be too hard!" they will cry or perhaps "While we're at it, let's just turn on team sites - it's no big deal - right?" (Wrong.)

It IS possible to do a somewhat vanilla implementation of SharePoint, but the fact is that very few organisations (actually none in my experience) are satisfied with the out of the box settings.

When you look at the SharePoint capabilities - team sites, portals, social tools, collaboration, document & record management,  search, workflow automation, business intelligence, and more - you find that there is a LOT of functionality to be understood and assessed, with various design decisions required.

For a simple analogy, customers would like the convenience of McDonald's, with their simple menu and lack of choices ("Will you have fries with that?), but if SharePoint were a fast food, it would be more like a Subway foot-long  ie. you need to make a gazillion design choices  - what bread, cheese, sauce, salad, etc,etc. - to get a meal that is customised to what you want.

Putting it another way customers make the mistake of thinking that SharePoint is a ready made, install shield application.  It's not - it's a platform.  A set of tools.  It is very powerful and flexible, but with that flexibility comes much planning.

To give you an idea of the breadth of areas to be considered, when I conduct SharePoint business planning, I find the following topics will generally have to be covered:

• User profiles
• Content profiling (types, metrics, life-cycle, user roles)
• Metadata
• Search
• Site structure
• Navigation
• Home page components and layout
• Layout of secondary pages
• Branding 
• My Sites/My Profiles
• Social features
• Audiences
• Permissions & security
• Mobile access
• Team sites
• Governance
• Change management
• Training
• Forms and workflow 
• (Less often) BI (Dashboards, Excel services)

There are also a bunch of technical and non functional topics that need to covered, but I will not go into these.

So there's a great deal of stuff to get through. How long it takes is directly relational to how much a customer wants to customise SharePoint.   For a client where I can be more prescriptive - providing best practice guidance on various design decisions - it will take less time.  Also, where the a larger stakeholder group will be involved (think: "Let's go ask the business what they want"), the planning phase is going to lengthen.   Money is a factor of course.   We all would like the idea of a bespoke suit, but will often settle for the 'near enough is good enough' comfort of off the rack due to budgetary constraints.

To give you some actual numbers, I find I can fit the above topics in 4-5 days where I am doing workshops with a small (3-6) stakeholder group, the approach is prescriptive and the capability (eg. Intranet) is somewhat narrow. This process can easily stretch out to weeks and even months where the consultation is wider and the planning more detailed.

For the business consultant charged with guiding a customer through all of these design areas, it can seem daunting.    However, you don't have be Robinson Crusoe - others have done this and there are 'maps' you can use to find your way through.  It is mostly about having and following a workable process.

From the above workshops come various design artifacts - site map, content profile, user profiles, wire-frames. These are used to aid the design process and can then be rolled up into a functional specification - the blueprint for the SharePoint information architecture (IA) and a great point of sign-off with the customer.

In a later blog I will discuss some of these artifacts and show you how to use these to guide the design of your IA.

Andrew

Zen and the art of running great client workshops - Part 1

As a SharePoint business consultant, facilitating client workshops is one of your primary activities and you need to get really good at it.    It's the core of the discovery phase, where you get to work directly with the key stakeholders to really nail the requirements.  Get the workshop right and you're half way home.  Get it wrong - and there's a ton of ways to do that - and you may find yourself with a half-baked or just plain wrong solution, or a client that is confused or uncooperative. 


Fortunately, getting a workshop right is not that hard. You just have to do some basic things well.  The funny thing is, as basic as most of the actions are, I know that lots of business consultants still omit some of these.   One thing I have observed is that many consultants have had no formal instruction on HOW to facilitate workshops.  Rather, it's been kind of an assumed knowledge.  That is certainly how it's been for me too.  However,  I have facilitated and participated in many client workshops in my time and have had the opportunity to work out what works and what doesn't.    In a series of posts I will share what I have found to be workable when it comes to running great client workshops.

So what do you mean by 'workshop'?

When I say 'workshop' I mean that special form of meeting where you and the clients 'work' together through various items, using a combination of discussions, white-boarding, product demonstration, PowerPoint slides as well as more specialised activities, such as card sorting and brainstorming.      You use a workshop to help with project scoping, requirements gathering and for the information architecture design.

I cannot emphasise enough how valuable workshops are. You get:

• To clarify the known requirements
• To surface the 'hidden'requirements
• Cultural insight ie. into how the people relate to one another, what they consider important, their lingo
• To position yourself in the minds of your clients - establish your expertise, competence and that they can trust you - vital steps towards ensuring your designs and recommendations are accepted
• To directly handle objections and to reach agreement on the various matters being addressed.  Those few hours when you have all the stakeholders in the same room is THE best opportunity you will get for gaining agreement.

Planning the workshop - Goals & purposes

The first action is work out the purpose of your workshop.

Why is this workshop being held?  What do you want to achieve?   What is the outcome you want?  Is there a specific deliverable to follow the workshop?


Workshops tend to be non-linear activities, moving if different directions, and it is easy to head off into uncharted waters.  With a clear goal and purpose, you can spot if the workshop is going too far off-topic and get it back on track.

Who should attend?

Next, you need to work out what sort of stakeholders should be attending.  The composition of attendees depends a lot on the purpose of the workshop.  ie. Knowing WHY you are having this workshop will guide you as to WHO should attend the workshop.

Are you consulting widely across the organisation, talking to different business units? Or are you working with a core group of stakeholders who will speak for the wider business?   Either way make sure you get the following types of folks in the room:

Get the right mix of attendees

• Decision makers (Hint: Someone who needs to defer to someone else is not a decision maker.)
• Subject matter experts
• Key influencers
• IT - they will ultimately be involved in the implementation so should be represented

Talk over the attendee mix with your key customer contact - they will be able to identify the right people with your coaching.  You may need to emphasise to them the importance this step.


Who should NOT attend?

Avoid nay-sayers

Ideally, you want all the attendees required to reach a consensus and no more.  Watch out for attendees that really have no business being in the workshop - those for whom the meeting purpose is not relevant or who will otherwise have no stake in the outcome.   Some organisations like to take a very 'inclusive' approach to meetings and workshops, inviting people who 'might' be interested in the topic.  The problem with this approach is that these attendees will just add 'noise' to the workshop; whereas we (and all the other attendees who are giving up their valuable time) need it to stay focused.

In particular, avoid inviting people who are openly opposed to the project/SharePoint/Anything Microsoft and who are not decision makers - they will just disrupt the workshop without adding much value.


Getting the numbers right

Assuming you have the right people attending, watch out that you don't have too many in the room.  A group of 6-12 people is about right for getting wide involvement from the group. Any larger than that and it becomes difficult to manage and to get agreement.

----------------------

So that's the end of the first part in this series on running client workshops.  In the next post I will cover workshop preparations, including invites, team readiness and more.

Foreword - What does it take to be a SharePoint Consultant

In one form or another I have been in the IT consulting game for around 15 years, working for a range of consulting firms, some large (global), some small (national).  In that time I have often found that when it comes to training staff, consultancies will put the bulk of their training spend into technical training ie. product knowledge.   Product knowledge is of course essential for an IT consultant.  After all, even the rawest, junior BA needs to have some awareness of the systems that are the end point for their swim lane diagrams and user stories; and it is certainly no less the case when it comes to my platform of choice, Microsoft SharePoint

SharePoint  - it's all about techie stuff, right?

SharePoint, as we all know, is a global phenomenon.  From its clunky beginnings in 2001, it has grown over the past 10 years and across 3 major releases, to have more features now than your average BDM can poke a red beam pointer at.  With so much stuff to learn, it is natural - and sensible - that a large amount of training time should go to learning what the features are and how to use them.   In fact, for a business analyst working in the SharePoint consulting game, your tools of trade include site collections, site, libraries, lists, content types, documents sets, workflows, site templates, managed metadata, search, master pages, etc - and you should know this stuff cold.     

My first purpose for this blog then is to share what I have learned about the components of SharePoint - how they work and how I go about planning for them.  I will tell you up front that I am a business consultant, not a technical consultant, so my blogs will be primarily for those who work in the business consulting area.

But what about your soft skills?

Even tough guys have to
work on their soft skills!

But technical know-how is only half of the equation when it comes to IT consulting and this is especially the case for SharePoint consulting.  SharePoint projects (at least the successful ones) will involve stakeholders from across a business - HR, marketing, communications, as well as IT - and from the bottom of the org chart right up to the top. A SharePoint intranet project is highly visible, so for the project team and particularly the project leadership, it can be a career boosting or limiting experience.  In these sorts of projects, technology alone will not be sufficient to get a great or even good enough result and it is here that the SharePoint Consultant needs to bring in his full arsenal of skills, not just the technical know-how.

To be able to do your job fully a SharePoint consultant needs to have an array of soft skills - like how to write good documentation, how to deal with clients in various situations, how to do information architecture planning, and so on.

So my second purpose for this blog is to share what I have learned about these soft skills.  Soft skills, unlike technical matters tend to be a little less black and white; that is to say subjective.   So it is pretty likely that what I will have to say can be done in other ways.   That said I will share with you what is MY best practice ie. it is what I have found WORKS.

If this sounds like your bag, make sure you follow the blog and/or my twitter account @andrewbish so I can let you know as soon as the next post is out (probably next week).

And lastly: if there is something you liked (or didn't like) about this post, or you just have some poignant observation you would like to share, make sure you leave a comment!   Don't be shy.

Andrew