Feeds:
Posts
Comments

Posts Tagged ‘Solution Design’

 Tunard Garden

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

 

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.

Advertisements

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 »