Find a Microsoft partner you can actually work with

You may also be interested in: SharePoint-based solutions by B&R Business Solutions


Editor’s note: Contributor Chris Wright is the founder of the Scribble Agency. Follow him @scribbleagency

When looking to start a new software or IT project, many people look to team up with a specialist company or partner. The Microsoft partner network is the ideal place to start if your project involves Microsoft products of some sort. PartnerPulse is designed to let you find a partner quickly and easily, and you can search by products like SharePoint, Dynamics CRM, or Azure. But enough of the plug!

Once you have found a partner, how do you know the company in question are any good? Beyond the name, and where they are based, what do you really know about them? How do you know you can have a productive working relationship, one that results in a new system brought in on time and to budget?

You might have a favorite company you already know well, or have got a personal recommendation from a friend. If you are starting from scratch we would encourage you to post to their Pulse here on the site and ask them a few questions. We also have another good tip, one that we don’t see many people doing.. talk to the development team.

Meet the team itself

Once you find a Microsoft partner you will no doubt get in touch, meet the company, and be subjected to lots of sales meetings. Microsoft partners can differ in this area, but typically you will meet the company directors, the sales people, and be told a very impressive story about how great your project will turn out. This is all good, and serves a purpose (most of the time). But you really should, as part of your evaluation, meet the team that will actually be working on your project.

Above: Meet the actual folks who might work on your software project

Now at this this point we should state that we are aware scheduling issues might mean the people you meet during the sales process may change when it comes to kicking off your project. But the point stands – when you are evaluating a potential partner meet the people who actually work on the shop floor.

The developers and project managers, testers and designers – these are the people who will be putting in the hours on your project. It is their skill, goodwill, hard work, and attitude that will make your project a success. Not the sales guy, nor the company CEO, nor even your Account Manager. So ask to meet a project team, ask to simply say hello and see what you think. Do you get a good feeling? Do they inspire you with confidence? Do you feel you can work well with the project manager?

Your project will go wrong, it will cost more, it will be delivered late. These things are pretty much fact. But life will be so much better if you actually get on your project manager. If you start with the confidence and trust of the development team, then you are more likely to feel you can work through the inevitable issues.

Your gut feel or instinct about the team won’t guarantee a successful project. But when finding a good Microsoft partner, it will give you a good head start. Throw in some client case studies, and the odd employee Microsoft citification, and you are getting closer to making a well educated decision. Good luck!

SharePoint best practice: what roles in a SharePoint intranet dream team

You may also be interested in: SharePoint Hosting by


Editor’s note: Contributor Alex Manchester is an Intranet researcher, strategist and experience designer. Follow him @alex_manchester

A lot of thinking needs to go into developing a SharePoint intranet, whether it’s a new site or an upgrade of an existing intranet. The knowledge and skills required is too much for one person, making it critical to put in place a ‘SharePoint dream team’. But what roles are required?

Why build a dream team?

Building your SharePoint dream team is critical. The quality of the implementation team can make all the difference between a poor deployment and a solution with high business impact. Because of the idiosyncrasies of the product it’s important to have someone with extensive SharePoint experience on board.

Your SharePoint dream team should also involve external partners and it’s very unlikely to neatly fall to one person per role. For example most implementations have more than one development resource, while other people may be responsible for more than one area. Different skills are also needed or have more emphasis at different times during the project.

The dynamic in the team is important. It’s often the case that a focused and motivated group is the ingredient that delivers truly exceptional results. However they do need to have the skills, experience and levels of resourcing to empower them to deliver those results.

Here’s how the team roles can play out.


For the most successful results from your implementation you will need to ensure that the various roles detailed in the diagram above are covered to some degree.

Some of these roles are likely to be covered within your IT team, others from the wider business. In assembling resources and team members it’s worth looking at the skills that exist around your organisation.

It’s also advisable to get a committed and visible sponsor and champion in place early, as their involvement may help to attract other team members to the project.

The sponsor needs to be able to articulate the project’s vision, as well as be prepared to put the time in to give input and also ‘unblock road-blocks’. In larger organisations sometimes, the sponsor and a more active senior management champion might not be the same individual.

The vital project manager

The overall project manager is also vital. When many stakeholders are involved, it’s best that the project manager oversees all aspects of the project, and not just the more technical side.

In practice, the intranet manager often plays some sort of project management role due to their functional knowledge. Occasionally they are the official project manager for the whole project, although without backfill for their main role, this is particularly challenging and the intranet manager may find themselves stretched.

Change management, content champions

Change management is often an area where intranet teams can draw upon wider internal resources from internal communications, marketing or training functions. Even if they are not involved as team members, they may be able to produce materials and also give a view on best practices.

Involving content champions is an opportunity to engage with different parts of the business and receive invaluable feedback. Having an effective dialogue with these individuals will help to create a group who continue to support the intranet after the project has launched, and will champion it inside their own business division.

It also goes without saying that working relationships and good communication between the team members is key. The better you work together, the better the project.

SharePoint Online 2013 - Suggested Sites to Follow

You may also be interested in: O’Reilly - SharePoint 2010 at Work


Editor’s note: Contributor Jasper Oosterveld is a SharePoint Consultant at Wortell. Follow him @SharePTJasper

The new top navigation of SharePoint Online 2013 contains the Sites tab:


There is a section called Suggested sites to follow (in yellow). Unfortunately nothing is shown in my tenant. I asked Microsoft how this feed gets its suggestions. Here is the answer:

  • Sites that are being followed by your colleagues.
  • Sites that are being followed by people you’re following will tend to be recommended to you.
  • Sites that are being followed by a large number of people in your organization.
  • Sites that you have modified recently.

SharePoint 2013 Social is the Key Feature for End Users

You may also be interested in: SharePoint Hosting by


Editor’s note: Contributor Chris McNulty oversees SharePoint Solutions at Dell Software, formerly Quest Software. Follow him @cmcnulty2000

SharePoint 2013 is such a huge release, with so many new features, it’s hard to know where to focus. (App model! Shredded storage! Work management service!) Let’s assume the IT Pros and developers know what they’re getting already. What’s in it for end user? Simple. It’s hard to know where to focus when there are so many new things. So let’s pick one message. Social is the key new end user feature in SharePoint 2013.

You may think you’ve heard all this before. True, SharePoint introduced My Sites way back in 2003. We’ve added content, microblogs, tags and networks along the way. But remember two piece of pop wisdom:

Those who do not remember the past are condemned to repeat it. 1


Insanity is doing the same thing over and over again but expecting different results. 2

So pushing SharePoint social out the door with a My Site link, reminding people about it in email, is more than likely to get… more of the same.

At Quest Software, now part of Dell, we’ve surveyed users at a number of SharePoint events and conferences about their level of satisfaction with SharePoint’s capabilities. When we ask about the classic functions of document storage and collaboration, we see satisfaction around 57.7% of respondents. However, when we ask about SharePoint’s newer workloads, such as business intelligence or social, the satisfaction level drops to 20.5%. That’s a huge drop.

But there’s a lot to love in the SharePoint 2013 social network. You may have heard elsewhere about the what:

  • Integrated newsfeeds that let you follow sites, people, tags, and documents.
  • Mobile apps for SharePoint social
  • @username targeting and #hashtag integration with the Managed Metadata tagging service
  • Directly embedded views of shared documents, pictures, videos
  • Full integration of newsfeeds with Yammer streams (future functions)

How about why? Here are some real use cases, or missions, for SharePoint social:

Accelerated collaboration

In the real world, we work together in small groups of two or three as often as we convene formal meetings. We don’t need to align geographies or schedules. We also don’t need to force collaboration with big announcements, email distractions or active searching. Instead, we can generate and consume information about what we’re working on through the ordinary course of working in SharePoint.

Staff engagement

Every year, the workforce has more people who expect the kind of distributed collaboration and social tools pioneered in the consumer world (that’s you, Facebook. Hi, Twitter). Adopting enterprise social implicitly reminds our workforce that the enterprise is engaging them as they prefer and expect to be engaged.

Information control

SharePoint governance tells us that users need guidance on preferred usage patterns to keep them on track toward intended business outcomes. Left without guidance, users will move content into other channels. Some of it is inefficient, and leads to duplication or easily outdated documents (email.) Still worse is the tendency of users to move content to cloud offerings like Google, DropBox, Facebook, Twitter and the like. This moves data into uncontrolled environments, with no ability to manage and secure sensitive information. Keeping usage on SharePoint helps keep data inside the enterprise.

SharePoint social isn’t completely automatic. There are some key parts of infrastructure that are required (Distributed Cache and User Profile Service) and I’ll have more on those aspects posted in a few weeks. But the most important thing to adjust is the information architecture.

If you continue to build web sites that funnel everyone through an “enterprise portal”, and bury the social and personal elements elsewhere, you’re not adapting to social collaboration patterns. Watch for more on that topic, too, soon!

1 George Santayana (1905) Reason in Common Sense, volume 1 of The Life of Reason
2 Attributed variously to Albert Einstein, also Rita Mae Brown, Sudden Death (1983) p. 68

Sequential Workflow in SharePoint 2010 Using Visual Studio 2010

You may also be interested in: SharePoint Services with mindfiresolutions


Editor’s note: Contributor Venkatesh Kumar is a Senior Developer for Cognizant. Follow him @venkat_mru


In this article we will see how to create a sequential workflow in SharePoint 2010 using VS 2010.


Let’s make the scenario simple. We want to create a simple workflow and if the workflow status is not completed, we need to prevent the user from deleting the document.


First we need to create a "Status" column with a choice field type with various status options in our document library.

Once the "Status" column was created, the document library will be as shown below:


Open the VS2010 -> Select SharePoint 2010 -> Select the Sequential workflow project type and complete the wizard as shown below.


By default we have the following simple start page:


Just click the OnWorkFlowActivated step and create an event called OnWorkFlowActivated_Invoked:


Double-click the onWorkflowActivated step. It will redirect to the code behind file.


Drag a while loop step from the Tool Box, below the onWorkflowActivated step:



Select the while loop step and in the property window configure the "Condition" as "Code Condition" and create an event called "IsWorkFlowPending".




Place the following in the workflow:


Invoke the "IsWorkFlowPending" method in both the "onWorkflowActivated_Invoked" and the "onWorkflowItemChanged1_Invoked" methods.


Let’s deploy the solution and we will check whether or not the workflow is deployed in our document library.


Upload a document and start the workflow:

We will see the workflow status as "InProgress" in the document library.


Edit the task and change the status to Approved. Our workflow status will change to "Completed".


We can prevent the user from "Deleting" the document, if the "Status" is not completed. Just add an Event Receiver in the same workflow project.


In the code behind file, we will prevent the user from deleting a document if the status is "Pending".


Let’s check the code in the UI using a document which is in the InProgress Status and try to delete the document.


If we click ok the document is still in our repository.


Let’s make some changes in the code to display a user friendly message:


Now when we try to delete the document we will see the following message.



We created a simple workflow in VS 2010 which prevents the users from deleting a document, if it’s not approved.


Confessions of a (post) SharePoint Architect: The self-fulfilling governance prophecy

You may also be interested in: Critical Path Training


Editor’s note: Contributor Paul Culmsee is an IT and business consultant with 21 years experience. Follow him @paulculmsee

Confessions of a (post) SharePoint Architect Series:

Hi and welcome to another SharePoint (post) architect confessional post. In case you are here via the good grace of whatever Google’s search relevance algorithm feels like doing today, I need to give you a little context to this post and the larger series of which it is a part. These days, I spend a lot of time working on projects beyond the cloistered confines of SharePoint; in fact, beyond the confines of IT altogether. Apart from being a cathartic release from SharePoint work, I’ve had the privilege to work with various groups on solving some very complex problems in a collaborative fashion. As a result of these case studies, I’ve become a bit of a student of various collaborative problem solving approaches and recently released a business book on the subject called “The Heretics Guide to Best Practices” co-written with mild-mannered mega-genius Kailash Awati. Despite (or because of) the book having no absolutely SharePoint content whatsoever, it managed to win an Axiom Business Book award and I feel it’s indirectly a good SharePoint governance book in its own right.

Now, for the rest of you who have been following my epic rant thus far, you will now be familiar with the notion of Ackoff’s f-laws: “truths about organisations that we might wish to deny or ignore – simple and more reliable guides to everyday behaviour than the complex truths proposed by scientists, economists, sociologists, politicians and philosophers.” Via the f-law metaphor, you now also understand why midwives are more valuable than doctors, the word “governance” should not be defined if you actually want people to understand it and that people should not be penalised for their learning.

The next f-law that we will explore provides an explanation to why organisations so consistently and persistently apply the wrong approaches to SharePoint-type projects. IT departments have genetic predisposition to falling into this trap, as do other service delivery departments such as Finance and HR when they put in ERP systems. To explain my assertion, we are going to revisit the governance diagram that I used in the first f-law. You can see it below:


I used the above diagram to to explain f-law 1 which was “The more comprehensive the definition of governance is, the less it will be understood by all”. The above diagram serves to point out that governance is not the end in mind, but the means by which you achieve a desirable future state. Without any context to an end in mind, we have to accommodate many vague potential ends. To deal with this uncertainty, we inevitably look to definitions to provide clarity about what governance means. Unfortunately, this form of “definitionisation” tends to confuse more than clarify because it sneakily starts to drive the end, rather than be the means. This inevitably results in over-engineered, over-complicated and likely inappropriate governance approaches that do more harm than good.

It should be noted that “governance” is by no means the only word that falls into this trap. Words like quality, effective, “best practice” and even “SharePoint” should all be put in the green star above too because all of these words have no inherent meaning until they are applied to a given situation or context. This point is echoed by people like Andrew (“SharePoint by itself knows nothing”) Woodward, Dux (“SharePoint doesn’t suck – you suck.”) Sy and Ruven (“Can I use this diagram in my Information Architecture book?”) Gotz.

To that end, our next  f-law expands on this notion of means vs. ends and provides you with a practical way to assess the clarity of a SharePoint goal or outcome.

F-Law 3: The probability of SharePoint success is inversely proportional to the time taken to come up with a measurable KPI

Hmm… f-law 3 is a mouthful isn’t it. For a start I used the acronym of “KPI”, which in case you are not aware, stands for Key Performance Indicator – something that we can measure to visibly demonstrate that we have not sucked and actually achieved what we have set out to do. In essence, this f-law states that the longer it takes to determine a reasonable and measurable indicator that SharePoint has been a success, the less likely your SharePoint project is to succeed.

To demonstrate this, I am going to give you one of my patent pending techniques that is highly useful in client engagements to get people to think a little differently about their approach. Let’s reuse my “from here to there” diagram above to perform a basic experiment. Check out the project below and tell me … what project is this?


Hopefully, it did not take you long to work out that this project is the Apollo moon missions. Now, for the experimental bit. Grab a stopwatch, start the clock and answer this question:

“How do you know you have succeeded with this project?”

Once you have your answer, stop the clock and note the time. I’m willing to bet that you gave one or two answers:

  • You successfully landed a person on the moon
  • You got the person back to Earth again

I am also willing to bet that you worked out that answer within 2 to 15 seconds of pondering my diagram. Am I right?

Now, consider for a moment the sheer scale of of this project in terms of size, risk, innovation and level of expertise required to land a person on the moon and bring them back safely. Imagine the sheer number of projects within multiple programs of work that had to be aligned. Imagine the tens of thousands of people who directly and indirectly worked on this epic project. It is mind boggling when you think about it and it is little wonder that putting a man on the moon is regarded one of mankind’s greatest technical achievements.

And then we have SharePoint…

Now let’s contrast the moon project with another one likely to be very familiar with readers. So once again, tell me what project this is…


This one takes some people a bit longer to answer, but when I ask this in workshops and conferences I sometimes get people jokingly saying “my SharePoint project!” or “a nightmare.” So once again I want you to answer the following question:

“How do you know you have succeeded with this project?”

I bet this one has you a little more stumped and is much harder to answer than the moon example above. What is funny with this one is that, when you consider that in terms of scope and size, using SharePoint to improve collaboration is a mere pimple on the butt of sending a rocket to the moon. Yet, despite the moon example being much larger in scope, cost, degree of innovation and engineering, the success criteria is clear and unambiguous to all. People can identify what success looks like very quickly. No-one will point to Venus and say “I think that’s the moon.”  You either got there or you didn’t.

Yet, when I show a SharePoint project that is framed like the above example, people have a much (much) harder time describing what success would look like. In fact, I have asked this question many times around the world and most of the answers I am offered do not hold up to any serious form of scrutiny. Consider these common suggestions of SharePoint success and my response to them:

  • “People are using it.” My response: “Yeah, but people use email and the file system now, so why are you putting SharePoint in?”
  • “People are happy.” My response: “I bet if I replaced the crappy coffee with a top of the range espresso machine I could make people really happy and it’s a fraction of the cost of SharePoint.”

Sorry folks, but this isn’t good enough… in fact it’s a recipe for a situation where, in the name of “governance,” you deliver a bloated, over-engineered failure.

When problems are complicated…

My two project examples above highlight a particular characteristic of problems that is at the root of the difference between the moon and SharePoint example. Consider the following common IT projects:

  • Replacing your old email system with Microsoft Exchange
  • Consolidating Active Directory
  • Replacing your old phone system with Voice over IP system
  • Upgrading your storage area network  to new infrastructure

All of these are like the moon example. None of them are easy – in fact you need specialist expertise to get them successfully implemented. But when you put each of these in the green star of my “here to there” picture, criteria for success is fairly clear and unambiguous. For example, if email comes in and goes out of everyone’s inboxes, Exchange is a usually success. If you can pick up the phone, get a dial tone and make a call, then the VOIP upgrade has been a success.

These are all examples of complicated problems. With complicated problems, the criteria for success is clear and unambiguous and there is a strong relationship between cause and effect. You can be highly confident that doing X will lead to Y. In these sorts of problems, experts can come together and analyse the problem by breaking the problem down neatly into its parts to develop a high-confidence solution. Furthermore, there are likely to be many best practices that have emerged from years of collective wisdom of implementing solutions because of that relationship between cause and effect.

Wouldn’t it be nice if reality was always like this. Project Managers and tech people would actually get on with each other! But of course, reality paints a different picture…

When complicated approaches fail…

In a 2002 discussion paper about reform of the Canadian health system, authors Sholom Glouberman and Brenda Zimmerman make a statement that is completely applicable to how most organisations approach SharePoint:

- "In simple problems like cooking by following a recipe, the recipe is essential. It is often tested to assure easy replication without the need for any particular expertise. Recipes produce standardized products and the best recipes give good results every time. Complicated problems, like sending a rocket to the moon, are different. Formulae or recipes are critical and necessary to resolve them but are often not sufficient. High levels of expertise in a variety of fields are necessary for success. Sending one rocket increases assurance that the next mission will be a success. In some critical ways, rockets are similar to each other and because of this there can be a relatively high degree of certainty of outcome. Raising a child, on the other hand, is a complex problem. Here, formulae have a much more limited application. Raising one child provides experience but no assurance of success with the next. Although expertise can contribute to the process in valuable ways, it provides neither necessary nor sufficient conditions to assure success.[]

In this paper we argue that health care systems are complex, and that repairing them is a complex problem. Most attempts to intervene [] treat them as if they were merely complicated. [] We argue that many of these dilemmas can be dissolved if the system is viewed as complex."

The key point in the above quote is that the tools and approaches that work well with complicated problems actually cause a lot of trouble in complex problems, where certainty of an outcome is much less clear. My point is that while the notion of using SharePoint to get from “poor collaboration” to “improved collaboration” might seem logical on the surface, it is hard to come up with any sensible criteria for success. Therefore you are setting yourself up for a fail because you have made SharePoint take on the characteristics of complex problems. Without unpacking these implicit assumptions about “Improved Collaboration,” our aspirational future state will look like the diagram below. The reality is we have many aspirational future states, all hidden beneath the seductive veneer of “improved collaboration” that in reality tells us nothing.


What blows me away is that to this day most project governance material published consistently fail to realise this core issue while trying to treat the very symptoms caused by this issue!  They provide you with the tools, means and methods to chase goals which are little better than an illusion, with no means to measure progress and therefore guide the very decisions that are made in name of governance.

Without unpacking and aligning all of these different future states above, how can any SharePoint architect be sure that they are providing the right SharePoint-based enabler? If you cannot tell me the difference made by implementing a project, how can anyone else know the difference? Even if you can, how do you know that everybody else sees it the same way as you?

Is it little wonder then, that after more than a decade of trying, SharePoint projects (complex problems) continue to go haywire? While approaches to governance force a complicated lens on a complex problem and assume the goal as stated is understood by all, governance itself will be one of the root causes of poor outcomes. Why? Because governance will require people to focus in all the areas except the one that matters. When this gap in focus manifests visibly (for example SharePoint site sprawl), governance is seen as the means to address the gap. Thus governance becomes a self-fulfilling prophecy “We will get it right this time” is the mantra, all the while, we still chase those rainbows of “improved collaboration.”

Conclusion and coming next

I do not recall where I first heard the distinction between “Complicated” and “Complex” problems because I came across it some time after I discovered the term “wicked problem.” I suspect that it was the Cynefin model that first pushed my cognitive buttons on the idea, although I distinctly recall Russell Ackoff also making the distinction between complex and complicated. Irrespective of the source, I find this a hugely valuable frame of reference to examine problems and understand why SharePoint projects are routinely tackled in an inappropriate manner. With it, I have been able to give IT departments in particular, a frame of reference to understand why they have trouble with particular kinds of projects like SharePoint.

Many people in organisations do not discern the difference between a complicated and complex problem and use the tools of the “complicated problem toolkit” to address complex problems when they are inappropriate at best and will kill your project at worst. I will expand on why this happens in the next and subsequent posts. But my key takeaway is that addressing the issue of multiple interpretations of the future is not only the key SharePoint governance challenge, it is the key challenge for any complex project.

The sorts of tools and approaches that are part of the “complex problem” utility belt are numerous and are really starting to gain traction which is great. There is plenty to read on this topic elsewhere on this blog as well as people like Andrew Woodward and Ruven Gotz. The great irony is that if you do manage align people to a shared sense of what the end in mind will look like, things that might have been seen as complex will now become complicated and the traditional tools and approaches will have efficacy because outcomes are clear and the path to get there makes more sense.

In the next post and f-law, I am going to outline another chronic issue that further explains why we get suckered into chasing false goals…

Thanks for reading

Paul Culmsee

What can SharePoint analytics tell you about your intranet

You may also be interested in: SharePoint Smart Notifications by KWizCom


Editor’s note: Contributor Andrew Gilleran is a SharePoint Power User, based in Dublin Ireland. Follow him @agilleran

Ah metrics. Who looked at what and when. Not really why as such but you have to think about that.

In SharePoint, like any intranet or web site, seeing who looked at what is obviously essential to understanding whether your intranet works or not. Compared to, say, an ecommerce site, an intranet doesn’t have commercial or sales related goals as such. But it should have goals, you should be able to determine outcomes from your intranet. Otherwise what’s the point of having one? ROI is crucial of course and metrics can go some way in helping that.

In SharePoint 2010, the web analytics can be useful to provide some metrics for a site collection or team site. The most useful are page views to see what people are looking at and unique visitors. For a large intranet site with multiple site collections, it’s pretty useless as you can’t get a decent overview of activity.

There are a few detailed guides to SharePoint analytics and you can find the links at the end of this article.

One of the main aspects of the analytics is that you can only get them for a connected site collection or a team site. On our intranet, we have multiple site collections in our web content management (WCM) area of SharePoint so we don’t get a full analytics picture of our site. We use Google Analytics (GA) for that.

Good bits about SharePoint analytics

  • you can get access numbers (clicks) for non HTML pages such as Office files and PDFs
  • it’s far more accurate on unique users than GA as it is usually based on the logged in user via Active Directory and not JavaScript code (this depends on your set up though). Seeing who, by their log in name, is accessing a site is a bit Big Brother-ish alright but we don’t use that information internally.

Bad bits about SharePoint analytics

  • It will pick up every access to a page including those of publishers creating and editing content which is not what you want. But you can see these easily enough as the URLs have the editing ASPX code.
  • The example (Figure 1) below which just adds up figures in a column to give an inaccurate total.
  • The dashboard summary also makes little sense (see Figure 2 below). The two Value labels and trend tell me what exactly? I assume it means that we have more page views for this 30 day period than for the previous period and that it is up 37%.
  • Referrers. Again a total number which is useless. Only by going into the referrer’s section do I see anything useful because it shows me that many people clicked from links in emails to our intranet which is relevant.

Figure 1 - Number of unique visitors

Anyway, have a look at the image (Figure 2) for which the number of daily unique visitors over a period of time and a grand total of 5,292. Which is of course, completely useless and misleading. It’s just a total of the column, not actual visitors.

Figure 2 - Dashboard summary

So what do you do?

  1. Extract it out to Excel.
  2. Remove the weekend figures. Nice to know some sad people are looking at your site over the weekend but it distorts your averages.
  3. Get the average figure so you can report that the average number of unique users over a set period of time is about 200. That means something; not the 5,292 figure.
  4. Plot the daily visitors on a chart and see the trend over time which in this case is fairly constant except for a spike on April 19th.

That’s your simple report. The average number of visitors and the trend over time.

So overall the figures themselves aren’t too bad, it is the collation, presentation and the dashboards which are weak. There are many changes, of course, in SharePoint 2013 which will improve the metrics. Certainly being able to see popular documents in a document library is very useful.

Google Analytics is also used on our intranet and it’s pretty good expect for a few glaring exceptions. Visitor numbers, visitors and even visits are problematic as many people when using an intranet close the browser window and open it again each time they access the intranet. You will always get multiple visits from the same people. This of course shows multiple visits in GA and you have no idea whether these are different people.

So I don’t measure visits or visitors on an intranet. I stick to unique page views for our communications analytics which gives me a flavour of what people are looking at. Is it 100% accurate? Hell no, but it is as good an indicator as any as to the popularity of certain pages. And that is what stakeholders want.

Incidentally, Google Analytics real time view shows quite a fairly accurate view of current users based on cookies but you can’t build reports from that. But it is cool to look at. Especially when a company wide email newsletter goes out and you can see the traffic impact immediately.

From looking at SharePoint 2013 so far, Microsoft has certainly taken a good look at it. Opening it up to 3rd parties should also make a big difference in allowing others to provide tools and apps just as Google does.


The Intranet Benchmarking Forum (IBF) produced an excellent report for members called ‘Measuring intranets: A guide to intranet metrics and measurement’ which goes into much detail about intranet analytics. This is a member’s only report I’m afraid but if you have an large intranet you should be involved in the IBF anyway.


SharePoint 2013 analytics features
Google Analytics Real Time overview
Introducing Web Analytics in SharePoint 2010

Confessions of a (post) SharePoint Architect: Do not penalise people for learning

You may also be interested in: SharePoint-based solutions by B&R Business Solutions


Editor’s note: Contributor Paul Culmsee is an IT and business consultant with 21 years experience. Follow him @paulculmsee

Confessions of a (post) SharePoint Architect Series:

Hi all and welcome to another small piece of my SharePoint architect manifesto. In the previous post I introduced you to the notion of f-laws, which were first coined in a book co-authored by Russell Ackoff. In the process of developing a SharePoint governance and information architecture class, I was inspired to use the idea of an f-law because they appealed to my contrarian sense of humour and also contained some interesting nuggets of wisdom. I ended up coming up with a heap of f-Laws for SharePoint, and plan to write an article to cover each one.

In the last post, we learnt that f-Law 1 was all about the contention that the more you try and define what governance is, the less anyone will actually understand it. If you never read the first SharePoint Governance f-law then I suggest you do so, because these articles do tend to build on the foundation set from the previous. On that note, the focus of today’s f-law extends on one that Ackoff himself came up with. All I am doing is putting a SharePoint bent on it…

F-Law 2: There is no point in asking users, who don’t know what they want, to say what they want.

This f-law comes with an additional corollary: There is even less point in thinking that you already know what they want! (IT departments – I am looking at you here!)

The definitive way to explain this f-law is to leverage the work of one of my mentors – Jeff Conklin. In 2007 I read a paper of his that literally changed my career. It was titled “Wicked problems and social complexity” and despite me reading many papers since, to this day it is one of the best introductions to complex problem solving you could ever read.

In this paper, Jeff talks about the fact that many prevailing methodologies suggest that the best way to work on a problem is to follow an orderly and linear “top-down” process, working from the problem to the solution. You begin by understanding the problem, including gathering and analysing “requirements” from customers or users. Once you have the problem specified and the requirements analysed, you are ready to formulate a solution and eventually implement that solution. This is illustrated by the red line in the figure below.


Now many project managers, cheque signers and just about every program management office I have ever worked with try to operate this way because it promises order, certainty and control. This is understandable when ones performance is being judged on getting stuff done to an agreed time and cost. It is also understandable if you are a manager and will get your ass kicked if you blow your budget. There is only one teeny issue. For some scenarios, it simply does not work.

In Conklin’s paper, he detailed a 1980’s case study at the Microelectronics and Computer Technology Corporation (MCC) that looked into how people solve problems. A number of designers participated in an experiment where they were given a one page problem statement – not too different to many SharePoint business cases I have seen. Participants in the experiment had to design an elevator control system for an office building. Despite participants being experienced and expert integrated-circuit designers, none had ever worked on elevator systems before. Each participant was asked to think out loud while they worked on the problem. The sessions were videotaped and analysed in detail.

Below is what really happened. Check out the green line…

Clearly, the subjects in the elevator experiment did not follow a linear approach. They would start by trying to understand the problem, but they would immediately jump into formulating potential solutions. Then they would jump back up to refining their understanding of the problem. Rather than being orderly and staged like the red line, the line plotting the course of their thinking looked more like a seismograph for an earthquake. Now if you are looking at the green line and thinking “my god I better put a stop to that sort of shenanigans,” consider what Conklin had to say about it in his paper:

- "These designers are not being irrational. They are not poorly trained or inexperienced. Their thought process was something like: “Let’s see, idle elevators should return to the first floor, but then, you only need one elevator on the first floor, so the others could move to an even distribution among the floors. But the elevators need to be vacuumed regularly. I suppose we could add a switch that brought idle elevators down to the first floor. But then what happens in an emergency?” In other words, what is driving the flow of thought is some marvellous internal drive to make the most headway possible, regardless of where the headway happens, by making opportunity-driven leaps in the focus of attention. It is precisely because these expert designers are being creative and because they are learning rapidly that the trace of their thinking pattern is full of unpredictable leaps."

When I am speaking at conferences I like to mess with project managers in particular (who doesn’t eh?), because they are an easy target and already an insecure lot to begin with. I will ask the audience if anybody has an industry certification, such as a PMP or Prince II. Several hands usually go up. I then point to the phases of the above diagram and ask them if – when they were studying hard to obtain their certification – they actually followed the discrete phases that everybody else is supposed to follow. No single person has ever suggested that they did, instead all acknowledging that their process of learning looked more like the green line. I then point out that I’ve always found this perversely funny that people follow the green line to learn a process that tries to insist that everybody else must follow the red line. Ironic huh?

Knowing vs. learning problems

It should be stated at this point that you can use the red-line approach for certain types of problems so I am not outright dismissing it. In fact, within SharePoint projects there are indeed elements that can work quite well this way. The green line on the other hand, represents a phenomenon that Conklin called “Opportunity driven problem solving” and is the de-facto way we work on problems that are new or novel. For example, if you have ever experienced an “aha” moment, it was probably a leap of cognition that followed the jagged green line up or down, where you suddenly saw the problem in a different light. (Shhhh… don’t let your project manager know because you will have to fill in a form of some description!)

In these types of problems, we do not start by gathering and analysing data about the problem because the problem itself is moving target and varies depending on different stakeholders and their world views. Thus, there is no pure and concrete understanding of “the problem” because it is still forming as you think about solutions. In short, the jagged green line is a picture of learning. Quoting again from Conklin:

- "The more novel the problem, the more the problem solving process involves learning about the problem domain. In this sense the waterfall is a picture of already knowing – you already know about the problem and its domain, you know about the right process and tools to solve it, and you know what a solution will look like. As much as we might wish it were otherwise, most projects in the knowledge economy operate much more in the realm of learning than already knowing. You still have experts, but it’s no longer possible for them to guide the project down the linear waterfall process. In the current business environment, problem solving and learning are tightly intertwined, and the flow of this learning process is opportunity-driven"

I believe that many innovations stem from the opportunity driven, creative leap of faith of the green line. On that note, I’d say that one of the greatest opportunity driven learners had to be Einstein. An article by Mort Orman suggests that Einstein was intrigued by “holes” in prevailing theories and enjoyed posing “mind riddles” to himself, just to see if present theories could satisfactorily explain them. Unlike many others who might have given up when they got stuck, Einstein was persistent and kept at it for 10 years before he came up that little formula everyone knows. After explaining this story at conferences, I sometimes ask people “Do you think Einstein used waterfall when he came up with relativity?” No one has said yes yet…


The pattern of behaviour between the red and green lines represents the difference between a knowing problem and a learning problem. With a knowing problem, the problem is clear to all participants and even though it might require specialist expertise to solve, many of the variables are well understood. But for a problem that is novel or requires learning from participants Conklin’s case study illustrates that:

  1. People will examine potential solutions just to explain the problem.
  2. Each instance of examining the solution will impact the understanding of the problem.

Given that SharePoint is almost always starts out as a learning problem for the majority of participants, I do not see the point in trying to fight that green line. Instead, it is critical that you work with it rather than against it. The difficulty people have with this is that to do so conflicts with that promise of certainty, order and control that the red appears to offer. Why? Well among other things, you have to:

  1. Expect fluid requirements and scope changes
  2. Involve stakeholders from the start (they have to live with the result and their up-take is presumably a key KPI)
  3. Expect resistance and pullback from stakeholders (because people attribute more to what they perceive to lose compared to what they might gain)

Above all, you have to avoid penalising people for their learning. If you put barriers in front of people who are trying to improve their understanding of a multi-faceted problem they will eventually disengage from you. If you want to guarantee this sort of disengagement, go right on ahead and solve some problem before your stakeholders even realise there is a problem. Then when they do realise, smack them with the metaphorical baseball bat known as the scope variation form. One of two of those babies and those annoying stakeholders are guaranteed to go away. A pity your solution will go away with them but hey, it was in scope right?


I deal with this core issue of not penalising learning in a number of ways… some of which I have outlined in blog posts and many that I will cover in detail as we progress in this series and examine more f-laws. If you simply can’t wait for me and want “the answer” then I have news for you. If it were that easy there would be a “best practice” for it and someone would have created a certification by now!

So instead I will give you a couple of KPI’s to work to.

  • KPI 1: You get to a stage where your clients questions are “informed”. It is pretty easy to tell as a SharePoint professional where your stakeholders are at in their understanding of SharePoint. Over time there is a certain level of maturity in the questions asked of you and the way they are asked. This reflects both stakeholder learning as well as your ability to teach. If you get to this stage, you have increased your chances of SharePoint success significantly, which leads onto the next KPI…
  • KPI 2: You get to the stage where your clients are asking you well informed questions that you don’t know the answer to. Trust me that they will not mind that you don’t because their awareness of the product will no longer be naively simplistic anyways. You will also have developed a great collaborative partnership by then too. Also don’t forget my quote from Horst Rittel in the midwives post. There is a symmetry of ignorance with complex problems. The knowledge required to solve a complex problem never resides with a single person.

This leads me onto the final KPI:

  • KPI 3: Your clients should start telling you stuff about SharePoint that they have done that you have never done before or didn’t know you could do. In short, they will start teaching you stuff.

If you can create those conditions, be happy that they don’t need you that much anymore.

Thanks for reading

Paul Culmsee