Posts Tagged ‘SharePoint’

 Tunard Garden

To plant is but a part of landscape composition; to co-ordinate is all.
Christopher Tunnard


My youngest sister is a freelance landscape architect in London, and so I know a little about this area.

As such, I have heard of Christopher Tunnard, a Canadian-born architect and academic, who in the early part of his career practised as a landscape architect. In 1938 he published Gardens in the Modern Landscape which married the influential modernist ideas then current within architecture with the discipline of landscaping.

Working in Britain at the time, the effect of Tunnard’s writings were short lived in Europe as the coming of the Second World War fostered a move towards more socially responsible design. Yet in 1939 he moved to Harvard where his theories later became the catalyst for what can be termed as the Anglo-American modernist movement in landscape architecture.

And in viewing a garden in the United States that showed his ideas in practice – sadly, the only surviving example of his landscaping work in America – I was struck by how similar planning in landscape architecture is to the visual processes that we employ within web development. 

Tunnard Garden - design

Tunnard's Garden: design plan










Site Mapping and Concept Modelling for Information Architecture

While anyone working in web development knows about the composition, usage and value of site maps, by contrast the related use of concept modelling is a relatively new and unexplored discipline (as applied to IA).

Basically, concept modelling is about conceiving and presenting an abstract representation of the informational ideas and their relationships found at any level within a site. [1]

As Dan Brown in his excellent book, Communicating Design (Peachpit Press, 2007), explains: concept models illustrate how different ideas relate to one another, representing the building blocks of the idea as nodes and their relationships as lines between them.

The diagram below from the book shows a concept model for a website selling musical instruments.

Concept Map - Muical Instruments

© Dan Brown, Communicating Design (2007)














As Brown says:

While this concept model doesn’t show any more of less detail than the others, it does deal with a specific concept. Instead of representing a broad view of the website, it shows all the different kinds of data on the site and how they relate to each other. This concept model illustrates the different ways of categorizing an instrument (the categories of categories) and associated metadata for each instrument. This concept model represents the relative importance of each concept by varying the size of the circles.

And the principal value of such concept models lies in their flexibility as a planning tool to tease out the underlying relationships between nodes.

Essentially they enable people to visualise (and then discuss) the multiple and complex relationships found between users, nodes (as areas, content types, and metadata, etc.) and the contextual links found in a complex system. 

Thus, they can be used in formulating an approach to designing a site structure, and should be used early within an information architecture process.

By contrast, a site map is more focused on defining the eventual structure of the information found in a website, and illustrate a part-whole relationship where an item lower in the map belongs to a higher level item.

And although they can be very different in presentation the traditional site map often looks very much like an org chart: a system of boxes representing pages, connected by lines representing links with their placement and linkages representing the hierarchy. 

Site Map

© Dan Brown, Communicating Design (2007)

Thus, a site map more often tends to the presentation of the end result of an information architecture (often expressed as a single A4 page in a hierarchy represented by uniform squares and links in tiered structure).

By contrast, concept models offer a flexible and dynamic approach to site map planning and may be used as a tool to assist in the construction of an information architecture, which will probably be turned into a site map for the final solution design.

Therefore, in effect, site maps represent the visual specification of a site, and are often used as part of a solution design document. While concepts maps are a tool that assist in the generation of such an information architecture specification.


Visual Mapping in Practice

Just recently at Storm we have started to use concept modelling in our own SharePoint projects.

Their value is of especial importance when one is having to consider the migration and re-design of an existing site structure in an attempt to improve the user journey.

Now this sort of “migration” scenario is a very common one in a SharePoint Intranet project, where an organisation might be considering one of two possible solution paths:

  • Version migration: A site migration from one version of SharePoint to another; or
  • Improving site structure within the same version: Examining and then improving a site structure – possibly badly conceived in the first place – within the same SharePoint version.

At Storm we are working on two such projects at the moment.

And the one that I have chosen to demonstrate the application of concept mapping is one that deals with version migration.

The project setting is a Scottish public body that has a large number of external stakeholders, for whom we are working on migrating (and improving) the design of an existing SharePoint Intranet while simultaneously planning the migration from SPS 2003 to SharePoint 2010.

Here the aim is to transition from a “file share” SharePoint approach that was adopted in SPS 2003 to delivering a higher-level Communications & Information Portal in SharePoint 2010, while simultaneously looking to use the features of 2010 to support and enhance the overall functions of the site.

As such, we are taking a large and relatively chaotic information domain (where all staff members may contribute) and seeking both to rationalise and re-organise it so that it becomes a more centralised and managed tool for information management for the organisation in question.


Project Process

Following James Robertson’s Enterprise IA methodology we started the design process for this particular project through generating an Intranet Development Roadmap (note: a 2 page word document – nothing more) and conducting Needs Analysis via a user survey (based on the Intranet Review Toolkit).

The objectives for the Intranet concept that emerged were presented as follows:

Intranet Development Roadmap


Next Steps  

With a clear and manageable objective in place and some early needs analysis of features to support, we are currently in the process of identifying user tasks/goals and starting an initial IA review.

And because there is already a SharePoint Intranet in existence, our early IA review is focused on the mapping this existing site (both structure and content), and generating an understanding of current logic behind the information organisation (with a view to revising this treatment).

For this we are using both site mapping and concept modelling (see high-level examples below).

Site Mapping

A site map of the top-level site structure for the existing Intranet reveals a fairly large information structure:

Intranet - Site Map

Intranet - Site Map

Concept Model

By contrast, the early concept model reveals something of the relationships we must explore further:

Intranet - Concept Model

Intranet - Concept Model

Well, what’s the outcome so far?

What is interesting is that by using this approach within the project team – rather than merely an interview-based methodology – we are beginning to understand how a potential IA restructuring might be of value across the Intranet.

Take, for example, the Corporate Reference Library – which for the purposes of this study we will call the “Knowledge Centre”. [2]

As currently conceived, this Intranet area is intended as a central informational repository for all staff to access key documents and external resources.  

As such, it has two main internal user audiences:

  • Staff Members in general
  • “HelpLine” Advisors: These represent a sub-section of staff who are dedicated to providing an advisory service to the organisation key external users (i.e. young adults).

As originally conceived, the Knowledge Centre was focused on catering for both user groups, aiming to deploy both key organisational documents and links to external key policy and informational resources organised by a generic sub-site hierarchy of “Subject Focus”.

See, for example, the sub-site structure for “Arts & Culture” below (which has the generic sub-site structural treatment presented below):

Knowledge Centre - Arts & Culture Site Map

Knowledge Centre - Arts & Culture Site Map

However, it appears from our initial reviews that there are a number of issues with the Knowledge Centre in its current treatment:

  1. It is trying to cater for two user groups – who have different goals and tasks. In supporting two user groups is actually trying to support two functions in one place: (a) a centralised informational resource for all staff and (b) a helpline resource for information advisors. As such, it does neither well.
  2. The role of the Centre within the Intranet is not clearly defined. As such, because all staff may contribute to the Intranet, the Knowledge Centre is not the only place where staff may add relevant information resources within the site. Other high-level areas such as Projects, Support Services and Products and Services also contain key information resources of a topical nature.
  3. The Centre does not support a poly hierarchical view of content. The Knowledge Centre’s current sub-site structure means that a document that has content relevant to a number of Subject Topics appears in only one Subject Focus in the hierarchy. And without content tagging by Subject Focus and access to a scoped search at the Knowledge Centre-level this results in staff not finding relevant content unless they already know it exists and where it resides in the sub-site hierarchy.
  4. The “HelpLine Advisory Service” is not well catered for in the existing treatment. In fact, it appears that the Advisory Service’s information resources are scattered in a number of places throughout the existing Intranet site (e.g. Support Services > Enquiry Answering; Knowledge Centre > All Subject Topics; Projects > Information Advisory Service; Products & Services > Various.).
  5. Key Content Types are not defined for users. Again in relation to the HelpLine Advisory Service, specialist content types such as Factsheets on subject areas are not immediately visible to Advisors and instead are scattered across a fairly large “Subject” sub-site structure. As such, given the nature of their job, Advisors find it difficult to trace relevant information quickly and rapidly whilst on the phone, and instead resort to individualised information strategies to answer enquiries.  

Early Conclusions

It appears from our initial mapping work – to be confirmed by actually interviewing the HelpLine Advisors – is that there is a distinct case to separate out the current treatment of the Knowledge Centre into two new and separate high-level site areas for the Intranet:

  • A HelpLine Advisory Service for Advisors
  • A Corporate Reference Library for Staff

As such, this treatment has been presented in an early concept model as follows:

HelpLine & Reference Library - Concept Map

HelpLine & Reference Library - Concept Map

And while we have not yet discussed:

  • The Content Types needed to support the (a) HelpLine Advisory Service and (b) the Reference Library areas; and
  • The logical organisation and structuring of each area – whether by sub-site structure and/or by metadata and scoped search.

Nevertheless, we have gained an important understanding at an early stage of what is deemed a key support area for the organisation through the use of visual mapping of an existing Intranet structure.

And Finally ….

I think there is much to be gained by adopting a visual mapping approach to the design of SharePoint sites; especially so with Intranets – which can be very large information structures that, by definition, often present complex information architectures to their users.

As is the nature of an Intranet solution, very often such a site goes through a series of site architecture revisions as it evolves in relation to the organisation in question. And arguably this applies as much to a SharePoint Intranet as any other solution; perhaps more so, because early information architectures for SharePoint have, more often than not, been badly conceived simply because the world over we are learning “best practices” with this product as we go.

In addition, the task of site migration from one SharePoint version to another is a key issue facing organisations in the decision to upgrade. As such, it is rare that an organisation will not want to take the chance to review its current SharePoint site treatment in an effort to improve information management support for its staff.

And clearly while information architecture is only one consideration in site migration within SharePoint, it is nevertheless a critical one and as a result we need to improve our conceptualisation of such architectures and our project approach to conducting this task.

I think that adopting a visual mapping approach to information architecture is of great value in SharePoint solution design. And, in particular, concept modelling is an important means whereby we can qualify and discuss our understanding of Intranet site maps within project teams in such a way that it improves our overall approach to information architecture.

Alongside more traditional tools such as Site Maps and Content Inventories it is yet another tool to assist in our ambition to design improved Intranets for our users.


[1] In Communicating Design Dan Brown summarises Concept Models as follows:

Concept Models - Dan Brown























[2] Note: in the interest of preserving client confidentiality, the references in this Case Study have been deliberately anonymised throughout this post.


Read Full Post »

Seal Of The President Of The United States Of America

Today I say to you that the challenges we face are real. They are serious and they are many. They will not be met easily or in a short span of time.

But know this, America – they will be met.

On this day, we gather because we have chosen hope over fear, unity of purpose over conflict and discord.

On this day, we come to proclaim an end to the petty grievances and false promises, the recriminations and worn out dogmas, that for far too long have strangled our politics.

President Barack Obama
Inaugural Speech, Tuesday 20 January 2009


I like to read the inaugural addresses of the American Presidents.

For me, they can sometimes signify a time of change and renewal, not just for the United States but for the world in general.

And while the historian Niall Ferguson in his book Colossus identifies the tradition of the State of the Union address as being evocative of Imperial Rome (and all that implies), nevertheless I still have a strong sympathy in the ideals of the founding fathers, and in the constitution of the American political system.

As such, more than a few Presidential speeches go down in history as some of the greatest of our times. And the acceptance speech in January 2009 by Barack Obama, America’s 44th President, was no different, and from a purely personal perspective it made me genuinely hopeful of the advent of a more inclusive form of politics from America.


The State of the Union – SharePoint style

Anyway, the past week or so – in the absence of being able to pay for one of those lofty SharePoint reports issued by the analysts for X amount of dollars – I have been looking at the web trying to find how the “State of the Union” is with SharePoint as of 2009.

Basically, I was looking for some hard evidence of how widely MOSS 2007 is being used and, more importantly, how it is being used by customers.

I wanted to take a look at this because after 2¾ years I wanted to see how MOSS 2007 had been received by the people who actually use it out there.

And there was a practical reason for this.

With SharePoint 2010 on the way I wanted see what had been the relative successes and failures of MOSS 2007, and to be able to assess whether in 2010 there are potentially some genuine improvements on the cards from Seattle.

That, and because I often get asked how SharePoint is being used, and I simply don’t know the answer to this question to any degree of certainty beyond my own personal – limited – experience.

As such, I wanted to find out (if at all possible):

  • How SharePoint is being used.
  • Whether it is better suited for particular tasks or whether it is capable of addressing an enterprise’s content management needs more widely.
  • Its particular functional strengths and weaknesses.

And in doing this, as usual, I came across articles with the seemingly obligatory negative stance on SharePoint.

So what’s the real answer beyond the partisanship and the anecdotes? What is the status of SharePoint usage as of 2009? 


State of the Market: Microsoft SharePoint

On the web I came across a survey of AIIM organisational members, and conducted by Carl Frappaolo of Information Architected. [1]

This survey – commissioned by Oracle, I suspect, because the findings actually demonstrate that SharePointis not being widely used at a deep business process level – is actually rather good and indicates that while MOSS 2007 has been tremendously successful in uptake nevertheless it has some distinct gaps and failures in usage which will come as no surprise to thoseworking directly with this platform.

For those interested in the full report you can access it here, but what follows is a summary of the key findings that I found especially useful.

1. SharePoint is rapidly becoming pervasive in the Enterprise

This we know already.

Of 511 responses amongst AIIM’s membership, some 69% (or 353) responded that they were currently using Sharepoint. And of the 31% (or 158) who were not, a further 71 respondents (45% of the negatives) said they will be likely to use the platform in the future.

SharePoint - Enterprise Usage

Thus, 83% of all respondents either currently use or are likely to use SharePoint.

And while the numbers clearly do not tell the full story this is an impressive level of market penetration (and as the survey suggests elsewhere this is primarily for MOSS 2007 rather than SPS 2003).


2. Why Don’t You Use SharePoint?

The 158 responses who said they didn’t use the platform were asked the above question, and here there were some surprising results:
 Why Enterprises don't Use SharePoint

In truth, I’d expected a more negative response than this finding, rather than almost half of respondents saying that they planned to use the system some time in the future!

And other than this, the negatives were what broadly what one might expect around MOSS 2007:

  • Customisation/integration figures relatively highly
  • There are some scalability and security concerns
  • And the usual Microsoft platform issues

And what’s noticeable is that weaknesses in the platform’s feature set was relatively down the scale in terms of non usage. Clearly the platform is not  perceived as being functionally that weak by non-users (although see Section 3 below for some further interesting results from actual users). 


3. Use of SharePoint functionality

I found this section quite fascinating.

Basically, the overall finding is that while SharePoint is broadly adopted, the survey suggests that currently SharePoint is predominantly used in a somewhat limited fashion within Enterprises, and has not yet achieved the status of a universal ECM.

In terms of where SharePoint (i.e. MOSS 2007) is most broadly used then this seems most focused on:

  • Portal Platform
  • File Sharing
  • Search

With more limited usage and lesser satisfaction in each of the following areas:

  • Collaboration & Social Networking
  • Web Content Management
  • Document Management
  • Simple Process Automation
  • Business Forms

While the functional areas that appear as outright relative failures in MOSS 2007 are as follows:

  • Complex Workflow/BPM
  • Records Management

 Taking each of the functional areas in turn one gets the following results.

3a. The Good

(a)  Portal Platform

As might be expected – i.e. the Portal being one its foundational goals from SPS 2003 – SharePoint is quite widely used as a portal platform for employees, and what’s more in its current iteration it receives a fairly broad vote of confidence from users (although clearly it could do better).  

 Portal Platform - Usage

Usage (Partner Portal)





 Partner Portal - User Satisfaction

User satisfaction (Partner Portal)

(b)  File Sharing

With its tight focus on Office integration, the use of SharePoint for file sharing is the one area where the platform has gained significant traction.

From a functional perspective, its ratings are the best that it scores in the survey although even here it stills fails to achieve a high level of satisfaction amongst the user base.

This ties in with my own feeling that, while good in this area, MOSS 2007 still lacks in usability from a document share perspective. (And one hopes that the advent of the ribbon in SharePoint 2010 will go some way to address this.)

File Sharing - Usage

File Sharing (Usage)






File Sharing - User Satisfaction

File Sharing (User Satisfaction)








(c)  Search 

While positive, the results for SharePoint search surprised me as there is little doubt that MS Search in MOSS 2007 is a well conceived function and yet it only rates as “good” in this survey.  

However, on further reflection its quite possible that SharePoint Search suffers from the fact that often little or no attention is paid to search configuration in implementations and even less to ongoing search management and tuning.

Without this attention most search engines tend to perform under par compared to their true ability, and yet arguably they are one of the key functions to support a coherent information architecture.

Search - Usage

Search (Usage)







Search - User Satisfaction

Search (User Satisfaction)








3b. The (Relatively) Indifferent

(d)  Collaboration & Social Networking

From a marketing standpoint collaboration is one of SharePoint’s major sales points, but here rates little more than good and relatively low in enterprise adoption.

And while personally I feel that the collaboration tools in MOSS 2007 justify this overall rating, the less said about the current support for social networking tools the better.

In general, I feel that support for collaboration is a tough nut to crack in the Enterprise space. Clearly there is some room for improvement in SharePoint 2010, and it is simply a case of watching and waiting to see what’s to come in this area.

Collaboration - Usage

Collabor-ation (Usage)






Collaboration - User Satisfaction

Collabor-ation (User Satisfaction)







(e)  Web Content Management

As is well known, WCM in MOSS 2007 was a new addition to the platform (supplanting MCMS 2002 as a standalone product), and as such it performs creditably but with some notable issues (e.g. browser & accessibility support and design integration).

What’s interesting from the survey is that SharePoint usage for WCM is relatively limited in the organisation’s surveyed here and it receives a predominantly “good to fair” rating. 

Currently, I feel this is a fair judgement and it certainly ties in with Gartner’s latest magic quadrant assessment of WCM, which places Microsoft as one of the “challengers” in this space rather than a market leader.

And while I feel that while the WCM model underlying MOSS is, in fact, quite elegant and easy to use for (non-technical) end users, there are nevertheless significant customisation challenges in WCM implementation.

WCM - Usage

WCM (Usage) 






WCM - User SatisfactionWCM (User 









(f)  Document Management 

Document Management has featured in SharePoint since SPS 2001, and while I think the model is fairly good (and certainly better in MOSS 2007 than SPS 2003), it nevertheless tends to get a rough ride from the analysts. 

In terms of the results here both its usage and satisfaction rating is slightly above that of WCM, but nevertheless in this survey Document Management still lags the relatively good functional areas.

One can’t help but feel that with ownership of the (Office desktop) SharePoint should  really rate better in this area, but equally I wonder whether this says as much about the state of Electronic Document Management (EDM) in general as it does about SharePoint. From my – admittedly limited – experience, I think many organisations are some way from adopting the true discipline required to practice effective EDM, and instead are still generally reliant on the more chaotic file share as a means of “managing” electronic information more widely throughout the Enterprise. Thus, it’s a fair cultural shift and a significant governance leap to embrace this change in practice successfully.

But equally I think there are some valid usability issues in interacting with SharePoint lists (such as Document Libraries) in the browser, and one hopes that SharePoint 2010 will address this positively.

Document Management - Usage

Document Management  (Usage) 





Document Management - User Satisfaction

Document Management  (User Satisfaction) 








(g)  Simple Process Automation 

Here SharePoint does seem to have some potential strengths as the platform offers some of the plumbing to automate simple business process tasks.

And yet the feature gets a reasonable but not outstanding rating, I suspect because of the related requirement for customisation and integration (of which it is suggested in the survey elsewhere is relatively difficult to do in MOSS 2007; or leastways it requires a certain level of developer skill to be present).

Hence I suspect this rating is not so much a failure of SharePoint per se, but simply a reflection of the effort and energy taken to achieve such initiatives within any Enterprise using a platform approach. 

And in case it is possible to argue that “simple” is an oxymoron when it comes to such things, and so we get the following results:

Simple Business Process Automation - Usage

Simple Business Process Automation  (Usage) 





Simple Business Process Automation - User SatisfactionSimple Business Process Automation  (User Satisfaction) 









(h)  Business Forms 

I’d be the first to admit that I am no expert on business forms using Infopath 2007 within SharePoint, but we have a lead developer at Storm that has used Infopath extensively and he says that it is difficult to implement. His ability on SharePoint is such that I trust his judgement implicitly when he steers us clear of using it within MOSS 2007 implementations.

But what’s interesting from this survey is that while SharePoint usage in this area scores relatively low within the Enterprise, the satisfaction ratings are no worse in implementation than the other middle range features.

Thus, while SharePoint clearly doesn’t (as yet) compete with the point solution offerings out in this particular space it is quite possible that it will do so in SharePoint in what is arguably a critical functional area to support.

Business Forms - Usage

Business Forms   (Usage) 


Business Forms - User Satisfaction

Business Forms (User Satisfaction)








3c. And the Ugly 

(i)  Complex Workflow/BPM  

Again I have no claims to any great expertise here, and so I’ll simply state that in this survey SharePoint currently receives a relatively poor rating in this area both for usage and for satisfaction, and having relatively limited experience of either the market area or implementations of this nature I have no real opinion on why.

Complex Workflow & BPM - Usage

Complex Workflow & BPM (Usage)





 Complex Workflow & BPM - User Satisfaction

Complex Workflow & BPM (User Satisfaction)






(j)  Records Management 

This area has received much criticism in MOSS 2007, and yet arguably this sort of standards compliance in information management has undergone something of a renaissance in recent years due to Sarbannes Oxley in the US and the Freedom of Information Act in the UK (and probably other similar governmental initiatives elsewhere).

Originally when MOSS 2007 was first released it was reputedly going to be the subject of a major point release upgrade in this area, but somehow it never happened. And, as far as I know, the functionality found in SharePoint is not well regarded by experts in the records management field.

And this survey seems to support this opinion, as SharePoint scores low in usage and fair in satisfaction.

Thus, it seems possible to say that Records Management has a long way to go in SharePoint to become a viable and widely used feature.

Records Management - Usage

Records  Management  (Usage)




Records Management - User SatisfactionRecords  Management  (User Satisfaction)








And Finally …

From the findings in this survey that are given here, I feel that in general the State of the Union with SharePoint is nothing like as negative as the platform’s many detractors would have you believe. But equally they do not present a universally positive picture, and it does indeed seem to be a case of “good, but could do better” in quite a few areas.

Thus, while on a generic level there are signs that SharePoint (aka MOSS 2007) struggles within the Enterprise in places, there are also distinct positives from this survey that one can take away and reflect on for future implementations.

On balance, therefore, I feel these are important findings as we head towards a SharePoint 2010 release.

At the very least they provide some hard statistics – courtesy of the AIIM survey and Information Architected – to benchmark the relative functional improvements that we will hopefully see within the next version.

Read Full Post »


Once in a Lifetime - Talking HeadsAnd you may find yourself living in a shotgun shack
And you may find yourself in another part of the world
And you may find yourself behind the wheel of a large automobile
And you may find yourself in a beautiful house, with a beautiful wife
And you may ask yourself – well … how did I get here?

Once in a Lifetime
Talking Heads (from the album, Remain in Light, October 1980)

How Did They Get There?

I have always liked the music of Talking Heads.

From the late 1970s onwards, and after years of little or no recognition, the ex-art students from the Rhode Island School of Design made famous a unique fusion of rock, groove and world beat.

This was music that people could relate to.

Likewise, I have always had a lot of time for Heads frontman, David Bryne, for his seeming humility (and obvious brilliance). Speaking of their success years later, in all modesty, he said: “A little bit of chance, a little bit of fate … which I guess is quite incredible”.

And the reason why I love the song Once in a Lifetime is not only for its haunting existential quality but because of the film Stop Making Sense.

On this footage Byrne doesn’t so much sing as speak this song.

And throughout, he performs rather like a puppet; making sudden flings of his arm, tapping his head, and raising his arms skywards in tune to the rhythm of the lyrics. It’s all quite unique, and yet his routine – physical spasms, unfocused eye movements, and sharp intakes of breath – was apparently inspired by watching footage of epilepsy sufferers.

MoMA at New YorkAnyway, Lifetime was deemed so good that it was subsequently named as one of the 100 most important American songs of the 20th Century, and the Museum of Modern Art in New York now features the SMS video as one of its exhibits.

What a journey … music made art in the creators’ own lifetime!


The More Things Change …

Whenever I sit there reading this or that judgement on SharePoint, I think many people very quickly forget just how far Microsoft have come in what has been a remarkably short period of time.

The diagram below (courtesy of Sharon Richardson of Joining Dots in the States) illustrates something of the SharePoint Story up until MOSS 2007. [1]

And what follows is a personal view of that journey. 

SharePoint History 1999-2006 © Joining Dots

SharePoint History 1999-2006 © Joining Dots

SPS 2001

In professional terms, I am old enough to remember the point when Microsoft announced “Tahoe” (aka SharePoint Portal Server 2001) to the world.

At the time I was working as a PM/business analyst on dynamic web-based corporate information management using metadata – think MOSS “Content Types” and you’ll get the idea – and so I was genuinely excited by the idea of Microsoft entering this field.

After all, the Microsoft solutions team at Computacenter were struggling to make this work – first on Microsoft’s Site Server 3.0 and then our own bespoke Microsoft solution (both efforts, sadly, being very forgettable).

And arguably SPS 2001 was itself equally forgettable as a release; it was basically a team-based “product” cobbled out of a loose collection of, then current, Microsoft technologies, and whose scaling performance was, quite frankly, abysmal.

I’ve no idea how many organisations adopted SPS 2001 in practice; but it must have been very small in contrast to the public interest it generated.

SPS 2003

Nevertheless, SPS 2001 got Microsoft going in this area and that – and the fact that they dominated the desktop with Office – meant that the SharePoint team’s next effort was a much more creditable departmental-level portal: SPS 2003 (including what has subsequently become known as WSS 2.0).

However, SPS 2003 still felt like flawed technology.

As a product, it was a limited platform and suffered from numerous shortcomings in the way it provided a Portal view to its users (not least in usability, web styling and content management, and the search/navigational relationship between portal and team spaces).

And what’s more, without extensive guidance issued from Microsoft, it seems as often as not to have been badly implemented within organisations.

Nevertheless, it was fairly widely adopted. And equally it did introduce the idea of SharePoint as a potentially viable Portal; thereby laying the foundations for a Microsoft take on web-based information management at an organisational level, with close integration to the Office desktop.

MOSS 2007

Microsoft Office SharePoint Server 2007 was released to market on 30 October 2006, following an estimated £120 million product development investment by Microsoft.

In both its scope and product architecture, MOSS was radically different from SharePoint Portal Server 2003 (i.e. it was fundamentally much more coherent as a platform).

And it differed from previous versions of SharePoint in that it wrapped Web CMS features with (significantly enhanced) Portal features of the earlier iterations. As such, it was re-branded as an Enterprise Content Management platform capable of delivering websites, extranets and intranet portal alike.

As such, MOSS is a much broader and solid product release, wrapping up genuine website and intranet portal functionality within a single platform (built on WSS 3.0), whilst incorporating Enterprise Content Management (ECM) features such as collaboration, EDM, ERM, business intelligence, electronic forms processing, etc. to varying degrees of success.

However, while very good in places, for people working at a solution level MOSS 2007 still feels like a slightly immature product release by Microsoft.

Yet, nevertheless, from 2007 onwards it has sold extensively, and demonstrates very convincingly that information management is part of the agenda of many organisations.

Albeit, I’m sure, with varying degrees of success….

SharePoint 2010

From the perspective that I am qualified to give (i.e. as a non-developer on SharePoint), I have written previously about my personal view of the Microsoft’s recent public announcement about SharePoint 2010.

And, without wanting repeat myself too much here it seems that at least from what they have chosen to tell us the latest version of SharePoint has undergone a highly significant evolutionary shift in its features and capabilities as compared to MOSS.

And what’s more there also seem to be signs of a highly welcome shift in emphasis towards usability from the perspective of the end users. With an equal effort to make some of the relative failures in MOSS at a broad functional level – BDC, web content management, styling integration – more enterprise capable.

My hope, therefore, is that finally in SharePoint 2010 we will see a truly mature release of what is now one of the leading ECM products in the world.

And Finally …

Out there on the web it is obvious that Microsoft, in relation to SharePoint at least, still gets a fairly rough ride from many – mainly non-technical – commentators. [2]

And clearly there is some justification in this critique; it is obvious, for instance, that MOSS 2007 suffers from weaknesses and shortcomings.

But equally, to be fair to Microsoft, this is not an easy area in which to design a highly-capable Enterprise-level product overnight.

Arguably, therefore, it is only by taking a longer historical perspective that we get a more balanced view of the journey that Microsoft themselves have been on with SharePoint. And we can also start to see more clearly how the product is now potentially reaching a level of maturity in corporate terms; a situation which one could have only of dreamed of in 2001.

Such is the extent of change in SharePoint Products & Technologies in the course of a single decade of development.

… The More They Stay The Same

So what hasn’t changed?

Well, just recently, I have been re-reading The Social Life of Information by John Seely Brown and Paul Duguid (Harvard Business School Press, 2000).The Social Life of Information

It’s quite rare that I bother to re-read something – after all, every single day there is so much more stuff out there – but this is, quite simply, a classic of its kind.

And what’s more it’s a useful corrective to the idea that technological progress solves all; in particular, the thorny problem of corporate information management within organisations.

As one reviewer states:

In this important and finely argued volume, Brown and Duguid point out that technology occurs in a social context that is often overlooked: that things like habit, work environments, and human judgement play a major role in how, when, and even whether technology gets adopted. A refreshing and timely counter to the infoenthusiasts who think that Moore’s Law solves every problem.

In relation to corporate information management the basic premise of the book is subtle, but can be relayed as follows (and here I must apologise if, like the man standing in the cinema queue in Woody Allen’s Annie Hall, I completely misrepresent the authors’ actual ideas):

  • People learn primarily by doing and experiencing in settings that include other people (e.g. within social institutions such as organisations) rather than by information itself. As such, we are not merely information “consumers”, but are also an integral part of that process.
  • Most useful information that is potentially transferable to others is socially situated and constructed, and is therefore very difficult to separate from its social context and package it into easily transferrable “units”.

Therefore, any attempts to standardise information for use by people is a very difficult pursuit (and impossible without considering very carefully the social context).

This argument, if you believe Brown and Duguid, has major implications for both the viability of information systems (e.g. Intranets, Portals, EDM, ERM systems, etc.) and for formal attempts to manage information in a particular organisational setting.

Now I happen to think that there is some truth in their argument.

And that as “info-enthusiasts” we remain largely oblivious to the idea that much useful information remains highly contextualised and is therefore very difficult to standardise into packages that retain a clear and unambiguous meaning for the recipient.

As such, it seems that effective information management is incredibly difficult to achieve to even a moderate degree of success – regardless of the technology used.

And that equally such attempts require a sustained intensity of effort that most implementations simply don’t even get close to.

The Information Management Landscape – What’s Changed?

“Same as it ever was, Same as it ever was….” goes the refrain in Once in a Lifetime.

Fundamentally, in the field of corporate information management at least, I essentially agree with this. In fact, it’s remarkable just how little the fundamentals in information management have altered after a decade of great change in web capabilities.

As of mid 2009, therefore, I still think that we barely scratch the surface in our understanding of how to make information management work well in the vast majority of organisational settings. [3]

And that – if we accept the essential message of Brown and Duguid – we need to recognise that information management in a corporate setting is messy, difficult and highly contextualised work, and that quite apart from the technology there are often a whole range of softer issues as to why this or that solution fails – or succeeds – in getting adopted.

As such, it is the organisational and human factors that seem matter as much, if not more, as the purely technical; and it is the former that are far more difficult to assess and account for than the latter.

But equally, working as I do as a semi-technologist from a technology perspective, I’d like to think that, when contrasted with turn of the century, there have been extraordinary changes in our technical ability to conduct information management within organisations.

Now with SharePoint 2010 on the way I am no longer quite so sure that Microsoft’s portal technology isn’t finally starting to catch up in meeting the basic technical requirements of the institutional settings in which it is placed. [4] 

But nevertheless I still believe that the essential constant in the field of information management remains valid; that we still need to attend more closely to the institutional and personal settings in which such technologies are used. And that equally we must attempt to understand the problems posed by managing the life-cycle of information (in its context) far better that we actually do. [5]

And if one accepts that this is true, then isn’t it the task of the information workers and solution professionals to work that much harder on the softer aspects – the planning, management and governance tasks – of making such technological systems stick in organisations?

Thus, we shouldn’t over-focus on just one aspect of what is a highly complex domain at the expense of all the others; and claim that or that technology is flawed in this or that way. That is too easy an answer, and in any case I don’t believe that it is solely technological progress – or the lack of it – that is the fundamental reason for our relative lack of progress. [6]

It is perhaps our institutions that are resistant to change, and by extension it is our understanding of the relationship between people, processes and systems in a context that greatly needs to be improved.

So it really is a case of the more things change, the more things stay the same. Yet equally, I think it’s also possible to argue that the more we do this sort of work, the more we understand, and the more we get better.

After all, we can only get better, can’t we …?

[1] If you are at all interested in SharePoint then this person’s blog is well worth a look. See http://sharepointsharon.com.

[2] As of mid-2009, there is a very active global developer community following and supporting SharePoint; many of whom are very good at what they do. And being naturally smart people in their own right I often feel that their judgements appear, on the whole, far more balanced than their non-technical counterparts (despite what one hears otherwise).

[3] For me, much of what passed as “knowledge management” in the earlier part of this century merely confirms that view. After all, can one really manage knowledge? And personally I think that the recent rise of social networking tools represent a form of knowledge “sharing” or “facilitation”, but arguably they do nothing to “manage” knowledge as such. Of course, this is all word games, but I still think we are a long way off actively being able manage knowledge per se. And, finally, for an interesting post on this see Patrick Walsh’s recent effort. I like this guy’s stuff as he really thinks things out.

[4] Note in saying this I don’t believe for one minute that the 2010 release will be perfect. I do think, however, that we have come on a quite incredible journey with this system in what has been – in historical terms at least – a very short period of time.

[5] Equally I have had my fair share of failures in this field; and for most of them the reasons were contextually based, or, leastways, the contextual interfacing with the technology. See The SharePoint Myth for an interesting take on this in relation to SharePoint itself.

[6] And finally my apologies for the rather narrow focus of this post on SharePoint. I feel that this can equally apply to any other system, but it’s what I know about as a technology in this setting.

Read Full Post »

Perestroika (Russian: Literal meaning: "restructuring"; now indelibly linked with attempts to restructure the Soviet economy in the late 1980s)

Perestroika (Russian: Literal meaning: "restructuring"; now indelibly linked with attempts to restructure the Soviet economy in the late 1980s)

Perestroika means overcoming the stagnation process, breaking down the braking mechanism, creating a dependable and effective mechanism for acceleration of social and economic progress and giving it greater dynamism.

I stress once again: perestroika is not some kind of illumination or revelation.

To restructure our life means to understand the objective necessity for renovation and acceleration. And that necessity emerged in the heart of our society.

The essence of perestroika lies in the fact that it unites socialism with democracy and revives the Leninist concept of socialist construction both in theory and in practice. Such is the essence of perestroika, which accounts for its genuine revolutionary spirit and its all-embracing scope.

Mikhail Gorbachev, 1987
General Secretary of the Communist Party of the Soviet Union


A Silent Revolution

As a postgrad student in the late 1980s, like so many students in Soviet Studies at the time, I was fascinated with Mikhail Gorbachev and his far reaching programme of political and economic reform in the Soviet Union.

We all knew that perestroika was a brave and radical programme of internal reform coming at a time of maximal stress in the Soviet system; what we didn’t know – and what no-one could have possibly predicted at the time – were its consequences for the CPSU (Communist Party of the Soviet Union) and its political counterparts throughout Eastern Europe.

In late 1989, in a few short months, a remarkable “Velvet Revolution” swept throughout the Eastern European satellite states, and then in August 1991, and almost unbelievably to Western observers, the Soviet Union itself suddenly ceased to exist.

And while perestroika – and its complementary political programme of glasnost or “openness” – were merely symptomatic of the fundamental political and economic problems facing the Soviet Union; there is little doubt that, once started, the process led indirectly to the dissolution of the Soviet state, the end of the Cold War, and a radical shift in the geo-political landscape.

Such is the force and power of an idea ….


Restructuring SharePoint

Switch to mid 2009, and while the rather unflattering analogy is probably unwelcome in Seattle, we find Microsoft now actively preparing for a “restructuring” of a different kind as they gear up for forthcoming release of “SharePoint 2010” – the latest version of its SharePoint Products & Technologies family.

On 13 July 2009 Microsoft publicly announced that SharePoint 2010 had reached the technical preview engineering milestone for the product, and simultaneously they issued a public website detailing some of the features of the new software release in the form of a “sneak preview”.

SharePoint 2010 - Sneak Preview Site

SharePoint 2010 - Sneak Preview Site

And, make no mistake, this is very significant news indeed from Redmond.

Arguably, Microsoft Office SharePoint Server 2007, was the first release of the SharePoint Products and Technologies family that could be called anything like “mature”.

In both its scope and product architecture, MOSS was radically different from its immediate predecessor: SharePoint Portal Server 2003, which to be totally frank was a constrained and limited product, best used for enabling Departmental-level information portals and little else.

(By the way, the less said about SPS 2001 the better ….)

By contrast, MOSS was a much broader and solid product release, wrapping up genuine website and intranet portal functionality within a single platform (built on WSS 3.0), whilst incorporating Enterprise Content Management (ECM) features such as collaboration, EDM, ERM, business intelligence, electronic forms processing, etc. to varying degrees of success.

And these days, at reputedly $1+ billion of sales per year, MOSS 2007 is big corporate business – not just for Microsoft, but also for the many thousands of clients and partners that use and specialise in it.

Thus, from its humble beginnings in 2001, SharePoint is now transformed to the status of a flagship product for Microsoft, akin to both Vista and Office in the Enterprise space.

And it’s no exaggeration to say that SharePoint 2010 is a fundamental product release for the company.

And what’s more SharePoint 2010 comes at a point where many analysts might be tempted to say (again) that Microsoft is struggling to re-invent itself in the face of bitter competition for primacy on the Internet (if not yet for the desktop) from companies like Google.

(Although to be equally fair to Microsoft, the analysts who study these things for a living have been telling us this for years ….)


Transitions …

Working extensively as I do with MOSS 2007, I have always had a nagging feeling that, while good, this version of SharePoint was a slightly immature product release by Microsoft.

And, as such, it papered over some fundamental solution problems – from both an implementation and deployment perspective.

This, in itself, is old news.

Ever since MOSS 2007 was released to market in late 2006 many analysts and experts have written balanced – and not so balanced – judgements of its capabilities and shortcomings.

See, for instance, that respected US web consultancy Prescient Digital Media’s judgement on the matter.

But as a strong and positive supporter of the platform, my absolute hope is that now (and finally) in SharePoint 2010 we will see a truly mature release of what is now – by sales, at least – one of the leading ECM products in the world.

Microsoft’s product restructuring, therefore, is of great interest to me.



Although clearly a marketing gear up, I was intensely interested in this “sneak peak” of SharePoint 2010 and this is what I gleaned from it.

(Note: in the interests of brevity – i.e. this will get way too long if I am not careful – and for the personal reasons explained at the end of this post, I am limiting my comments to merely the Overview section of the website.)


Generally, I found this interesting in that the 2010 marketing “value chain” is much more focused on end users, rather than workflow functions (as in MOSS). And while one could cynically argue that this is just marketing spin; equally, it could indicate a genuine and welcome change in emphasis on user experience and interaction with the product.

Key points:

  • Support for websites: They state they have not forgotten that SharePoint is used for websites, not just the enterprise. Well done guys; I am looking forward to seeing how.
  • Enhanced community and social networking support: A critical point as in MOSS 2007 these tools are poor (especially the latter), and yet arguably are of massively increased importance for both web and enterprise. 
  • Support for connectivity whatever the device (i.e. desktop, browser, or mobile): Depending on what’s been done here this again is critical going forwards, and the product now needs great  flexibility across all devices.
  • Search: Integration of FAST search technologies into MS Search, with an emphasis on improving search results (both content & people) and support for improved federated search. There is obviously a lot more detail to come here, and it should be interesting.
  • Enhanced support for customisation via browser, SharePoint Designer and Visual Studio 2010: This is one of MOSS’s pain points, and when it comes to implementation it will be interesting to separate fact from fiction. 
  • Enhanced business data integration: Depending on reality and the SharePoint usage scenario this could be truly significant.
  • Support for migration between 2007 and 2010: Very interesting – I wonder how?

Feature Highlights:

  • Improved user experience and support for Content Management life cycle: The page editing functions of MOSS have been given a significant makeover; introducing the concept of a Ribbon (first seen in Office 2007) used in a contextual way supporting web editing and list interaction in the browser. From both usability and content management life-cycle perspectives this is to be highly welcomed, and could be revolutionary in scope. I know from experience, for instance, that many ordinary users find MOSS a frustrating experience in interacting with lists and content items; thus enhanced support for users in this area is critical.
  • Silverlight: A Silverlight web part has been introduced. This is a natural evolutionary path in terms of Microsoft technology integration, making it easier to expose this rich and dynamic media for users actually within the interface. And while according to our technical experts at Storm, in relation to SharePoint at least Silverlight is currently mostly being used for limited gloss at the moment, there is undoubtedly rich potential here as long as SharePoint 2010’s performance scales. See, for instance, the power of this technology in one or two of our recent websites that use Silverlight as the basis of the delivery medium: The Scottish Government: 2009 Summer Cabinet and The Drinking Water Quality Regulator for Scotland (you will need the Silverlight plug-in installed by the way).
  • Site Theming Control in the Browser: At Storm we tend not to use themes as the basis of our SharePoint 2007 sites, finding them too limited and constraining. But nevertheless in the hands of a good designer (and depending on how it has been implemented) this may well be a useful addition, as the form (i.e. look & feel) of a SharePoint site has been the source of critique in MOSS 2007.  
  • Cross browser support: Depending on how well this is supported going forwards (i.e. MOSS 2007 was relatively poor on cross-browser support), this is to be welcomed, but nevertheless in dealing with dynamic medium like the Internet this should be a minimum supported standard rather than being seen as an additional feature. Thus, I will be very interested in seeing the reality of this. (And no mention, as yet, of support for accessibility … one of MOSS 2007’s black holes.)
  • Visio Services: This is a natural evolution of Microsoft product integration, and could be a very useful addition to some types of enterprises, as long as it truly de-couples SharePoint from needing Visio 2010 on the desktop.
  • SharePoint Designer 2010: Also gets a makeover, with a ribbon interface. And depending on what they done under the bonnet this is could be highly significant in terms of ease of customising SharePoint, as both our designers (primary development interface) and developers (secondary) use SharePoint Designer 2007 extensively with MOSS.
  • Business Connectivity Services: An evolution of the BDC, which according to one of Senior Developers at Storm (who took a close look at this for a project in MOSS 2007) was poor in implementation.  Depending on reality this could be a truly significant extension. It suggests a viable means for ordinary users (via browser and Office) to surface, share and manage structured data from databases and web services. As such, it could be of extraordinary benefit in certain settings.
  • SharePoint Workspace (aka Groove): Looks promising as an individual user’s way interacting with SharePoint as a personal file store (from experience, a problem area with MOSS in some usage scenarios). However, not knowing Groove, at this point I am simply not qualified to comment further.
  • Rich Media Support: Extensions within SharePoint in this area are highly welcomed, as both on the web and in the enterprise space the integration and consumption of rich media is becoming of central importance (and is now present in limited fashion in most implementations that I work on). (In fact, I was recently talking to one of my colleagues at Storm about this very point in relation to MOSS 2007; he said that he felt that Microsoft had missed a trick in “ignoring” this – especially in Internet usage scaenarios. If so, then it seems that Microsoft have been catching the zeitgeist.)


Microsoft’s SharePoint Perestroika

Gorbachev got it wrong.

In bravely setting in motion the changes necessary for the economic and political renewal of the Soviet system, he underestimated the power of an idea enshrined in a process, and the great political forces it unleashed.

Clearly Microsoft do not have this sort of problem. But nevertheless SharePoint 2010 is a highly significant product transition for the company.

In an attempt at a summary, my feelings are generally strongly positive at the user experience changes that this sneak preview of SharePoint 2010 indicates. From what we have been told here, and at least at the non-developer level, there seems enough to indicate a highly significant evolutionary shift in the product’s features and capabilities.

And, while this is not the end of the story in terms of MOSS 2007’s current weaknesses and foibles, unlike the many professional analysts out there that follow Microsoft I have deliberately chosen to remain silent on the more technical aspects of the changes to the platform indicated within this preview. Because of the importance of such comments to a product that I know well, and generally support and like, I would rather leave that task to people much better qualified technically than myself to comment.

What is obvious, however, that SharePoint’s perestroika has been underway for quite some time within Microsoft, and now that we are entering a period of greater glasnost with the product it will be truly fascinating to see what emerges from the 2010 SharePoint Products & Technologies stack and how this translates into practical solutions and to a market repositioning over the next 18-24 months.[1]


[1] Note: This will be my first and last post on SharePoint 2010 for some time. As a Microsoft Gold Partner, Storm ID have been fortunate to have been nominated and accepted as a participating organisation within the SharePoint 2010 technical preview. And while I have not yet seen the product working in action – hence this post just before I do – I now have to respect the Non Disclosure Agreement from Microsoft that comes with this nomination. Therefore, any subsequent posts that I make on SharePoint 2010 will be limited solely to comments on public announcements.

Read Full Post »

Henry Ford“The best we can do is size up the chances, calculate the risks involved, estimate our ability to deal with them, and then make our plans with confidence.”

Henry Ford (1863-1947)
American industrialist, pioneer of the assembly line and prolific inventor



Words of wisdom from one of America’s great 20th Century industrialists, and the other day I listened to a talk on The 10 Deadly Sins of Software Estimation by a true innovator in our own industry, Steve McConnell – the CEO of Construx Software in the States. [1]

And as anyone that works in this field knows all too well, the subject of estimation comes up time and again, from client or supplier, at the start of every web project.

Fundamentally – for a whole range of perfectly valid reasons – stakeholders need to have the answers to such basic questions as:

  • How long will a project take?
  • What the margin of error on either timeline or budget?
  • What effect will making this trade-off have on project length and/or cost?

And sometimes, on the odd occasion where the whole process starts getting really surreal, it even descends into: “I’m not quite sure what we want, but are you really sure you can’t deliver it more cheaply, quickly, etc., etc.?”

And nowhere does this hold more true than at the very beginning of a project; the point at which we are suddenly asked to produce “THE ESTIMATE….”


Problems of Software Estimation[2]

In his talk on The 10 Deadly Sins, McConnell claimed:

The average project overruns its planned budget and schedule by 50%-80%. In practice, little work is done that could truly be called ‘estimation’. Many projects are scheduled using a combination of legitimate business targets and liberal doses of wishful thinking.

Now, rightly or wrongly, I happen to believe implicitly in this statement.

And one estimation problem that makes it to No.3 in his all time charts is one that McConnell refers to it as “making commitments too early in the cone of uncertainty”.

The basic premise of this is that: Uncertainty in a software estimate results from uncertainty in how project decisions will be resolved.

This situation is neatly summarised in the diagram below, which shows that time/cost estimates created very early in a project are subject to a very high degree of error (i.e. something of the order of -75% to +300%).

The Cone of Uncertainty

The Cone of Uncertainty (© Section 4.2, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006)

And what this diagram also shows is that estimation inaccuracy drops dramatically as you progress through a project.

So by the time requirements definition is complete – on the average about one third the way through a typical project – the margin of error has dropped to between -33% and +50%.  


What This Suggests in Practice

With software estimation we are caught in a Catch-22. The more one understands a project, the more accurate the estimate, but the only way to reduce inaccuracy is to actually do the project.

The message, therefore, is that an estimate will become more accurate as a project progresses, and it will be very inaccurate at the start.


Levels of Solution Uncertainty in SharePoint Projects

To be honest, the cone of uncertainty within SharePoint projects can be very broad indeed.

The reason is fundamentally to do with the nature of dealing with a product-based solution that is very extensive, functionally in places constrained, and yet in others highly capable. 

And it does not help that SharePoint also has the following characteristics:

  • It is undoubtedly a hard platform to master: from planning and requirements analysis to configuration, development and design and deployment.
  • It is idiosyncratic in implementation: thus just when you think you have it under control then it turns up another particularly difficult aspect that requires more effort and energy to overcome.

All told, therefore, we have found it hard to estimate upfront the true effort involved in a SharePoint project, and there is little doubt that this can have very significant consequences for your solution planning – leading to overruns in terms of resource effort and elapsed time.

Nevertheless, as with any product, genuine experience pays, and the more you work with SharePoint then the more one gradually gains “rule of thumb” metrics of what it takes to enable this or that feature.

Arguably, however, such rule of thumb estimation isn’t enough.

The platform’s capabilities and features are extensive and within each core functional area there are so many unexpected wrinkles, that it is advisable – even mandatory – to plan a solution in detail very early on in order to manage a SharePoint project effectively.

And this effort, in turn, helps with project estimation….


Solution Estimation with SharePoint

Although we have in the past, we now no longer adopt rule of thumb estimation when it comes to quoting for a project using SharePoint. Instead, we analyse early on and in detail (a) how a solution’s feature set could be enabled within SharePoint and (b) what the base level of effort is involved.

The method we have arrived at is worth looking at in some detail:


Step 1: Project Assessment

First, we jointly assess whether a project fits the “shape” of SharePoint itself – this type of assessment being undoubtedly more art than science.  

The Starting Point

Essentially, this step relies on making a judgement call between what SharePoint can do as a product and what it must do in the context of a particular project.

And for it to pass the assessment this relationship must, on the whole, be strongly positive.

And make no mistake, this upfront assessment is a critically important decision; essentially it sets the outline and constraints of a solution throughout its entire project life-cycle, and yet is a technology choice that must usually be made from the outset of a project.

(Note: This is where that indefinable quality of “knowing” SharePoint comes in handy. I liken it to the difference between having knowledge and experience of something rather than merely reading information about it).


Step 2: Project Requirements Mapping

Next, we conduct a detailed assessment of the solution requirements from a SharePoint perspective.

This entails looking at each and every project requirement and asking “how can this actually be done within the confines of SharePoint Products and Technologies”.

And depending on the uncertainty inherent within the solution domain, this process can vary in granularity ranging from relatively low fidelity diagramming with notes (where you are more certain) to quite exhaustive and detailed requirements mapping (where you are less certain).

See, for instance, the extract below which shows this process applied to a recent Storm ID solution tender to a Website project using MOSS 2007 – where the solution uncertainty was relatively low.

(To come, sorry reader: file is at work!)  


Step 3: Work Breakdown Structure (WBS) Planning

Once we are clear on the probable development approach, only then do we create a WBS (i.e. a project plan).

This WBS does not need to be exhaustively granular at this stage (see, for example, my previous rant about Gantt charts in a separate post), but it does need to have the right level of detail against which to map estimates comfortably.

Too high-level it becomes a farce; too detailed, and it’s counter-productive.

See the WBS below for our example:  

WBS for MOSS 2007 Website

WBS for MOSS 2007 Website











Step 4: Map Estimates Against the WBS

This is a key step in the process, and squares the circle between solution evaluation using MOSS, an outline WBS as a project plan, and the actual effort required to deliver the project.

In effect, this is where the estimates are born.

And to further allow for solution uncertainty we apply “modifiers” against each estimate that allow for essential parameters of:

  • Complexity: A multiplier that accounts for the base complexity of implementing the requirement within SharePoint, ranging from “A = Low” through to “C = High” to “D = Can’t do”
  • Risk: A multiplier that accounts for how well understood we feel the requirement to be, and how likely it is to change within the course of the project 
  • Effort: An overall effort multiplier for high/medium/low sensitivity analysis – measured in either days or hours to implement a feature

 Again, see the Estimate Map below for our example: 

Estimates mapped against WBS for MOSS 2007 Website

Estimates mapped against WBS for MOSS 2007 Website

Of course, adopting this overall approach means that solution clarity is everything. And where lacking then we seek the detail with the sponsors of the project, only stopping until we are satisfied that the actual scope of the project is relatively clear – probably with a few remaining grey areas.

This way we can build a relatively accurate picture of the effort within a solution, but equally in our estimate modifiers we also allow for the unknowns. 


Less Rocket Science Than a Process …

All this, of course, is hardly rocket science, and happens the world over in solution design.

But the point we are trying to make here is that this approach is not really optional with SharePoint – it is essential.

For reasons that are well documented in the project management literature, a failure to do this sort of solution assessment can have highly negative consequences for all involved for the management and delivery of a project throughout its life-cycle. [3]

We believe, therefore, that to give your SharePoint project half a chance requires an active approach to planning.

And equally you must also accept the need for the following:

  • Do your homework upfront: plan your solution design early, and do it in detail. Detailed product-based requirements analysis will lead to both more balanced solution estimates and more realistic projects.
  • Rely on genuine experience: excellence in business and technical understanding of the platform pays. Don’t believe that SharePoint is either a simple or purely out the box product, and instead use experienced people with this platform. Again, this will lead to more realistic solution assessments and better delivery.

And Finally …

It is virtually a truism that getting your solution estimates wrong with SharePoint matters a great deal – whether you are the project sponsor, a stakeholder, or a project team member.

Paradoxically, at Storm ID we now attempt to deal with the cone of uncertainty problem in relation to SharePoint by planning our solution designs as early as possible, and in so doing we devote care and attention to defining the project solution at almost pseudo-developer level using our experience of what does and doesn’t work (wherever humanly possible).

This approach helps mitigate – though clearly doesn’t remove – the level of solution uncertainty that is inherent in dealing with SharePoint, and is one that repays itself many times over.

Maybe Henry Ford had it just about right all those years ago: do a little spadework, play the numbers in the guessing game, and then make our plans with greater confidence….  



[1] On McConnell: For the 10 Deadly Sins of Software Estimation, see http://blogs.construx.com/blogs/stevemcc/archive/2009/06/22/free-webinar-10-deadly-sins-of-software-estimation.aspx. As an ex-Microsoft project manager, Steve McConnell is acknowledged as one of the finest writers on software project management in the world. He is the author of classics such as Code Complete, Rapid Development and the Software Estimation, all of which have the extraordinary ability to turn your preconceived beliefs on software project management completely on their head.

[2] This and the next section follows Chapter 4 of Steve McConnell’s book, Software Estimation: Demystifying the Black Art (Microsoft Press, 2006). If you are at all interested in this pervasive problem in software project management, buy this book.

[3] For reasons that are well documented ….  I feel that this is so important in relation to SharePoint solutions that I intend to write another post on this in the future. And while this is a broad subject, and in a single post one is limited to what one can do, for me it is worth the attempt.

Read Full Post »

As a kid growing up in Wales, in the absence of having a TV at home, I used to play chess against my younger brother.

As a result we both got pretty good.

And while these days I hardly ever bother with the game (and was never that strong anyway), I still occasionally read through some of the games of Bobby Fischer. For me, many of his games are a form of poetry in motion and are completely fascinating; not because I still habour any Walter Mitty ambitions to be a decent player, but because they represent a near perfect union of form and function.

Consider, for instance, the following position: 

Fischer-Petrosian (7th Match Game, World Championship Candidates Final, Buenos Aires, 1971)

Fischer-Petrosian (7th Match Game, World Championship Candidates Final, Buenos Aires, 1971)

It’s White to move, and Fischer plays:

22. Nxd7+!! …

In this setting, this move looks completely unnatural.

White totally dominates this position, and it exhibits all the hallmarks of a classic Fischer game with its clear-cut advantage in both space and key square control in the middle-game. (And, believe me, once this guy gets an edge he never lets go.)

Instead of Knight takes Bishop, Fischer could play 22. a4 … disallowing the reply 22. … Bb5, with 22. … a5? clearly being impossible due to 23. b5! … which is winning. And 22. Kf2 … is also worth consideration (although incomparably weaker, once you know the answer), anticipating an endgame with the White King at d4.

And yet Fischer chooses at this point to exchange his beautifully placed Knight on c5 for a “bad” Bishop on d7.

Superficially, at least, 22. Nxd7+ … looks like a very “ugly” move and, for us mortals, shouldn’t even be considered (i.e. its doubtful that any other strong player in the world would have played this way “on principle”). Yet according to people watching the game Fischer played this move “instantly”, and that against an ex-World Champion! And what’s more during the game itself he was heavily criticized for his decision by watching Grandmasters (i.e. hindsight is truly a wonderful thing).

Yet Fischer’s logic is unshakable. By trading Knight for Bishop in this position White removes the only Black piece that holds his position together. After its exchange the two White Rooks enter the game on c7 and e7, and there is absolutely nothing that Black can do to prevent this.

The game continued for just 12 more moves. A beautiful sequence of play saw Black reduced to total helplessness and he resigned on the 34th move with White threatening mate.

As one of the most beautiful games in all of chess literature, this is hugely impressive in two respects:

  • First, the game is completely direct and to the point – there is little, if anything, that is fanciful about it. (FUNCTION)
  • Second, in chess terms, it is entrancingly beautiful, and is literally perfect in conception and execution from beginning to end. (FORM)

 This got me thinking ….

The Point

Well, just recently, Storm made a bid for a SharePoint project that included the delivery of an Intranet.

As part of the pitch presentation we had to demonstrate an Intranet design applied over MOSS 2007. And in Intranet design with MOSS 2007 one thinks automatically – because that is what we are taught – about a “Collaboration Portal”.

 Consider, for instance, the default of a Collaboration Portal.

MOSS 2007 - Collaboration Portal Home

MOSS 2007 - default Collaboration Portal - Home

Whilst very functional, with a classic “Inverted-L” navigation design to support a “broad and deep” information architecture (very important for Intranets), one can hardly claim this is beautiful. (And at the pure browser interface, configuring any of the out of the box Microsoft “themes” makes little or no difference to handling this presentation issue.)

At Storm, we have implemented a number of Intranets based on this structural presentation, variously applying themes (with modified core.CSS) or a skin over the top of a base Collaboration Portal, adding both imagery and colour to provide the veneer of a better look and feel.

See, for instance, this treatment over WSS 3.0:


Ethos Community - WSS 3.0

Ethos Community - WSS 3.0

And this, over a full MOSS portal:

Scottish Refugee Council Intranet in MOSS 2007

Scottish Refugee Council Intranet in MOSS 2007

Ok, both admittedly much better, but still not great (and believe it, our designers are very good).

The fact of it is, is that MOSS 2007 running in Collaboration Portal mode is inherently resistant to design styling (i.e. it is something of a CSS nightmare). It comes back to the tried and trusted adage that SharePoint will do what it wants to do very well indeed; but it’s not so good when you want to do something different. 

The latter scenario, a radical suggestion, I know, but it happens.

Anyway, in July 2008 Ben Curry and Bill English of Mindsharp fame in the US released a very good book entitled Microsoft® Office SharePoint® Server 2007 Best Practices (this is better for non-techies BTW). In one small paragraph of an 800 page title they recommended using MOSS 2007 in Publishing mode to enable an Intranet. And while I instinctively don’t like the term “best practice” – after all, who really knows? – I could immediately see they had a point.

One project later, with the Royal of Bank of Scotland, and I was completely sold.

It transpires that by stripping out some of the rubbish that comes with a MOSS Publishing site (courtesy of Tom Travers in our dev team), we discovered that it is actually possible to style a decent Intranet view (courtesy of Jason Kennedy). And while we had project constraints on look and feel as a result of this particular client’s design standards, the relationship between design and other considerations within this solution felt in far better balance overall.

So coming full circle, we revisit that pitch for an Intranet project that I mentioned at the beginning of this section. After doing some very cursory needs analysis and a basic IA – it was a pitch, remember – it was over to the design team for a flat visual for an Intranet Home in MOSS.

After a few iterations, we arrived at this for a top-level unified comms portal:

Intranet design - using MOSS Publishing site

Intranet design - using MOSS Publishing site


Does it Matter?

Does it really matter if aspects of the “form” of an Intranet site are relatively weak, if the myriad of other considerations that contribute to the successful creation of an Intranet are present?

Well, these days, I happen to think it does.

Arguably in a mid-to-large corporate setting an Intranet reflects how an organisation perceives itself and values its staff, and a badly presented garden leaves a bad impression on the visitor as they come up to the front door. 

And while design is so much more than a user’s perceptions of (mere) presentation, nevertheless the visual aspects of an Intranet arguably matter as much as they do for a Website. 

Like chess, however, it’s all about finding that elusive balance between form and function for a “typology” of site that, by definition, should exhibit strong functional and usability characteristics.  

And Finally … A Parting Shot

At the chessboard, at least, Fischer was a genius….

His play has that airy quality of perfection – think of the American poet Robert Frost and you’ll know what I mean – that makes everything seem so simple and obvious. And yet is all but impossible to attain in practice.

At its best, his playing style represents form and function in near perfect balance, and in chess it takes incredible flexibility of mind to achieve this without falling prey to either preconception or dogma.

It is as though Fischer looked at every move in the course of a single game with the eyes of a child.  

Switch to web design, and I think we know very little about the value, importance and application of design in relation to Intranets. And, sadly, out of the box the user interface presentation and styling of the Collaboration Portal platform in MOSS 2007 does very little to challenge this view, with its stark over-emphasis of function over form.

Alongside other key factors such as information architecture and (site &  content) governance, this pronounced imbalance greatly affects users perceptions, usability and interactions with the platform.

As of mid 2009, therefore, I feel our understanding of what is the correct balance between function and form in Intranet user interface design may not have even got out of the starting blocks!

It looks like – after maybe some 12-15 years in this field (and the eighth year of SharePoint)  – we are still searching for Bobby Fischer.

Bobby Fischer (1943-2008), aged 14, IQ 187

Bobby Fischer (1943-2008), aged 14, IQ 187

The message:

If you have an Intranet project on MOSS 2007 don’t even think about using a Collaboration Portal as the start point.

Think Publishing site, as at least this gives you half a chance in the debate about Form vs Function.

You can always add – and try to style! – the Web Parts later….

Read Full Post »

As one of the softer web disciplines that lies at the heart of Microsoft SharePoint as a software product and its central importance in the implementation of countless solutions, I have read a lot of articles and book chapters about SharePoint that stress the importance of “getting your information architecture right”.

The quality of this thinking is not always quite what it might be. The analysts at Forrester, for instance, tell us (seemingly with great authority):

SharePoint buyers expect intuitive navigation, contextual search, and easy administration out of the box. But such benefits depend on how content is structured, labeled, and categorized, and they require a nuanced understanding of how different audiences will navigate and search for information.

The information architecture (IA) behind a SharePoint deployment has lasting consequences for the end user experience and for Web site management. Information and knowledge management (I&KM) professionals should use their SharePoint implementations as an opportunity to set solid information architecture in place that turns today’s information overload into tomorrow’s valuable information assets.

The upshot?

Information workers will finally be able to find the critical information they need to do their jobs.

(See Forrester: The Critical Role of SharePoint Information Architecture, http://blogs.msdn.com/architectsrule/archive/2009/02/26/forrester-the-critical-role-of-sharepoint-information-architecture.aspx)

Ok … so far, so good, but where exactly does this get us?

Town Planning… 

Town planning

Town Planning (© things magazine)

In early 1998 Louis Rosenthal and Peter Morville made their name in publishing a bestselling book entitled Information Architecture for the World Wide Web (now in its Third Edition!).

As a newly appointed e-business consultant working for The iGroup at Computercenter in London, I remember avidly reading their – essentially very simple – book and thinking “Wow, these guy’s have got it right!”

Switch to mid 2009 and inevitably the practice of building websites is far more sophisticated, and hopefully I am little less naïve than I used to be.

Superficially, at least, it seems that those professionals who devote their lives to working on the web are now much more qualified to provide a sophisticated response to the question of what makes a “perfect” information architecture. One that takes into account so-called “best practice” in emergent web disciplines as diverse as needs analysis, stakeholder and user audience profiling, content analysis, information science and classification, usability and accessibility, wire-framing, web and user interface design.   

Yet growing sophistication in the field comes with a price.

Quite simply, it is very hard for a busy web professional – and I include myself in this category – to have a genuine appreciation of all these burgeoning web disciplines to allow true mastery over the undoubted “art” of information architecture. 

In my personal view, therefore, the vast majority of those who construct information architectures for a living are informed not by a deep understanding (of a myriad of web sub-disciplines), but rather by a mix of unvalidated opinions, their personal preferences, and a partial understanding of their trade.


In the City of Organised Thought

What of the subject matter of the information architects – the  websites, extranets and intranets?

Essentially, all these forms of “web patterns” reflect human activity in all of its diversity. This relationship is undoubtedly an organic thing that both evolves overtime and exhibits great complexity.

Think, for instance, of an Intranet that must by necessity reflect an organisation’s ever changing social, political and informational life, and you realise that this is indeed a complex undertaking. Likewise, a website that marries a particular content focus with this or that user audience – the latter always demanding, whoever they are.  

As such, these generic “web patterns” are capable of order and structure – indeed in many ways they exhibit and need such order – but the kinds of order that are possible vary enormously even within the same general setting.

Sure, these different kinds of order may be related as “patterns”, but equally they cannot be mutually reduced except by gross simplification.

Recognition of this awkward fact – i.e. a singular lack of neatly tended streets in our metaphor – also tends to be fiercely resisted by professionals who are engaged in theoretical system building both to justify their profession and the need to prove that they “know their stuff”.

And because they have succeeded in introducing an impressive kind of order they are always tempted to extend it more widely than they should. In effect, they have formulated a neat and tidy “theory” and as such want to place that above all others.

MEL Generated Cityscape by CGZool

Cityscape (© CGZool)

It is as though they have the ambition of knocking down the irregular and awkward city streets that disrupt their thinking, and rebuilding them to their vision – with a strong preference for unfailing regularity in both architectural design and pathways. 


Beware the Despotic Pattern with SharePoint

What then are some general pitfalls in town planning with SharePoint Products and Technologies?

First, there is the ever present tension of dealing with a software product in solution design. It is obvious that the very fact that SharePoint is a product both structures and constrains your thinking in relation to the practice of information architecture.

And while there is little doubt that MOSS 2007 as a CMS has an elegant hierarchical model enshrined in its Content Database structure:   

  • Site Collection
    • Sites
      • Content Types
        • Page Layouts
          • Controls  
          • Site Columns
            • Content
            • Metadata

Yet MOSS is known to be hard to customise….

As a consequence this model tends to impart a strong solution preference in formulating an IA within SharePoint. Effectively, out of the box MOSS 2007 – in either its Publishing or Collaboration Portal mode –  will do what it wants to do very well indeed; but it is not quite so good when your architectural design does not conform to SharePoint’s particular blueprint.

There is, therefore, no doubt that it is very easy to lose honesty very quickly in the overwhelming desire to avoid the pain of customising SharePoint to meet a requirement for implementing even a moderately awkward neighbourhood.

Try, however, to resist the lure of this particular siren!

As we have discovered at Storm just recently there are some very real benefits in remaining honest. This being due in the main to the technical brilliance of my colleagues – in particular Tom Travers – who have succeeded in opening up MOSS 2007 to customisation in a number of different areas. Town planning being one of them.

Second, beware Greeks that bear false gifts… and retain a healthy skepticism towards the town planners of this particular product (i.e. the SharePoint analysts that solemnly tell you how to formulate that perfect IA). Telling is one thing; doing is quite another. Thus, treat with caution – though clearly don’t dismiss – their formulas and pronouncements as they relate to the complex and difficult task of town planning.

And, finally, never lose sight of the fact that in constructing an IA – regardless of whether it is for SharePoint or not – there is no substitute for deep understanding, imagination, and, yes, a lot of hard work.

Note: This post is the first of an occasional series that attempts to explore the discipline of information architecture in relation to SharePoint. And my advance apologies if this first post mentions relatively little about SharePoint! I am simply trying to explain how I see the landscape of the discipline before turning my attention to SharePoint proper.

Read Full Post »