Tag Archives: Design

Deft Design Delivers Dividends!

Part B of a two-parter that starts here at Part A.

Part B: To Brand or Not To Brand SharePoint? … Why is This The Question?

Read more…

Deft Design Delivers Dividends!

Yeah, about time we had a heading with some groan-worthy alliteration.

Read more…

Top 10 Tips for Success with SharePoint: #4

Play to Its Strengths

Play to SharePoint's Strengths

My next tip for success with SharePoint is a deceptively simple one.  While accepting that SharePoint has its weaknesses, success accrues from deliberately playing to the application’s many strengths.  Well d’uh, I hear some of you say. Bear with me – my point is acceptable I think, because many deployments I’ve seen simply don’t do this. They do the obvious – for example, “we’ve installed Team Sites for collaboration” or “we’ve rolled out SharePoint for document management” – but usually they haven’t moved far beyond this and found ways to leverage the platform’s strengths to truly make SharePoint a great fit for their environment.

So what are these strengths?  Well, they’ll differ from place to place: what’s a product strength to one SharePoint manager might leave the next indifferent.  My list of SharePoint’s best attributes may not be yours but, having got that qualification out of the way, here’s what I think are some of its greatest assets.

Lists

My absolute favourite feature of SharePoint has always been, might just always be, Lists. They are incredible.  IMHO, they can offer a great deal of value-add in many business information scenarios.

SharePoint Lists are…

List Views are

  • Highly effective for filtering and ‘explaining’ information by displaying data for specific audience groups (no development skills required!)
  • Underused in many deployments
    Just the other day, I had yet another conversation with a SharePoint business administrator who used folders in a List for good reason (Records Management) but was ignorant of her ability to display, filter and sort items independently of the folder. Having been shown the simple checkbox in the View configuration screen, “Best of both worlds!” she enthused.
    Views - folders

Since Lists are very similar to Excel, and most organisations I’ve worked with appear to just about run on Excel, I’m not sure why it can be so hard for SharePoint administrators to translate the List concept into business usage – and value – in practice.  I’ve always found that putting in a bit of up-front effort to resolve common business issues by building a simple List solution or two is an extremely powerful way of demonstrating SharePoint’s business value.   And of encouraging staff to think laterally about exploiting Lists for their own circumstances.  Here are some very simple examples that have worked well for clients in the past:

  • Enterprise Acronyms & Glossary – what organisation doesn’t have a plethora of arcane acronyms and terms that confound new starters, contractors and even long term staff who work across multiple business units?  This List solution is so easy it’s laughable, but it works. Create a custom List, rename the Title column to Term or Acronym, and add a text column for Definition.  Allow all staff to add to the List and encourage everyone to do so (optionally adjust the List settings so they can only edit their own entries and/or enable Content Approval by a List manager if you want to quality control entries, check for duplicates, etc).   I also usually add Categories – a ‘choice’ column – for business department or function. This way, terms can be sorted into groups such as HR or IT or Finance Acronyms. Create a view for each Category and you can link directly to that from the unit’s intranet site – IT Acronyms, Finance Acronyms, etc.  Every department contributes to an enterprise glossary while feeling like they’re maintaining and promoting their own.
    Acronyms and Glossary Lists
  • Frequently Asked Questions – A variation on the Acronyms list, with Question and Answer columns instead of Term and Definition.  I usually create a List template for FAQs and deploy it per SharePoint site as applicable, rather than building a single, enterprise-wide FAQs site.  Just find it works better that way from an ownership and maintenance perspective.  Depending on the organisational culture, I enable Ratings, so end users can rate the FAQs and hopefully encourage the content owners to continually improve the answers provided to end users.
    Why a List, not a content-rich page? Because in my experience, most business people find it easier to add or edit a single item in a List (once they’ve been shown how) rather than add content to a Wiki or a table or bulleted list on a Publishing page.  And because the power of Views make filtering of FAQs by topic or function so easy (see previous bullet point).
    FAQs Lists
  • Preferred Suppliers – For one client, I took multiple Word documents about the company’s many preferred suppliers, maintained by Procurement in a file store, and pulled the content into a single List.  Columns included the obvious, like: Supplier Description, Contact details, brief Terms of supply or use, Website URL, internal Relationship Manager, etc.  But to make it look and feel more like their Word documents and ease the transition from old to new, I also included a column for Picture so they could include a Supplier’s logo/image, and I made the default View Style = Preview Pane. As the user rolled over the list of Suppliers at left, a full page view of each supplier’s details appeared at the right. They loved it and, happily, found staff awareness and use of preferred suppliers improved greatly.  We did it all again a few weeks later for providers of their various Employee Benefits…
  • Staff / Office Phone Lists – For another client, a modicum of customisation was employed to pull data from the User Profiles into a SharePoint List.  I was then able to slice ’n’ dice the List with a number of useful Views, e.g. staff listed by Department, by Office – even by Role.   Employees could open the List in datasheet view and export it to Excel for further manipulation and printing. Various offices had required their Receptionists to laboriously construct and maintain Word directories of local staff.  So we created office Views which included staff photos, using the Boxed Style – it looked so similar to the Word booklet, they were happy to dispense with the manual overhead, and appreciated all the extra functionality – and currency – the online solution delivered.
  • Online Request ‘Form’ – Lists can even masquerade as Online Request Forms if you haven’t got InfoPath or your SharePoint Designer skills are rudimentary. It’s a very simple workaround for simple scenarios. I’ve used it on a number of jobs to capture user ‘requests’ to have a new Team Site provisioned. I’ve also employed this solution as an RSVP tool to capture responses to an internal event, and even as a form for ‘Staff Suggestions’ where anonymity was not required. Set up a List with columns to collect the data you need to capture in your request form. Configure permissions so that all users are able to add to the list, and adjust the List settings so each user can only edit (and view, optionally) his/her own entries.  Place a link to the ‘Request Form’ on the page, being a link to the List’s ‘add new item’ URL. When the end user clicks on the link, they’ll be taken directly to the empty form, ready for completion. Ensure whoever is managing the request sets up an Alert on the List to be notified of any new entries.
    Request Form List
  • Software / Applications Catalogue – A comprehensive List was created for one client’s IT department, to manage details of their myriad IT applications and authorized software.

Learn more about 2010 Lists on the Microsoft SharePoint Help & How To site: start with this great overview http://office.microsoft.com/en-us/sharepoint-server-help/introduction-to-lists-HA101782476.aspx and a number of introductory videos, commencing here: http://office.microsoft.com/en-us/sharepoint-server-help/sharepoint-lists-i-an-introduction-RZ101820091.aspx

Little tip – it can be hard for end users to orientate themselves quickly in different List views so, for every List and every View I create, I like to modify the web part’s appearance, in order to make a meaningful title visible on the page. Step by step instructions here…

My enthusiasm for the following out  of the box is a little more qualified, but still quite high:

Managed Metadata

As an information management  specialist who spends her working life thinking about content structure, usability, findability (what a word), etc, I really like this impressive new feature of the 2010 version for so many reasons.

As always, you can find extensive  detail from Microsoft, though I think Chris O’Brien’s overview is a great  introduction to the subject: http://www.sharepointnutsandbolts.com/2009/12/managed-metadata-in-sharepoint-2010-key.html See also: http://office.microsoft.com/en-us/sharepoint-server-help/introduction-to-managed-metadata-in-sharepoint-server-2010-HA101859256.aspx and don’t forget the Managed Metadata and Taxonomy Resource Center: http://technet.microsoft.com/en-au/sharepoint/ff924923.aspx

Sadly, there are a few gotchas with Managed Metadata in the context of some other SharePoint features. Thanks Paul Culmsee for such a good write-up there’s no point doing anything but cross-referencing his findings: http://www.cleverworkarounds.com/2010/10/28/un-managed-metadata-a-couple-of-gotchas/  Michal Pisarek has also collated several other issues to be mindful of in this great article: https://www.nothingbutsharepoint.com/sites/eusp/Pages/Managed-Metadata-Column-Limitations.aspx

At this point in time therefore, I think you need to carefully choose to exploit managed metadata or not, depending on the priority and value you attach to InfoPath forms and/or offline access in your SharePoint deployment, both now and in future.  If neither is on your radar now, or in the near to medium term, then I’d definitely advocate leveraging Managed Metadata to help classify and retrieve enterprise content (while hoping Microsoft addresses the underlying problem in future service packs or versions, or someone blogs on a brilliant workaround).

Process Automation – SharePoint Workflows

There are many proven examples of  basic processes automated in SharePoint that reduce handling time, streamline and simplify business workflows and create efficiencies.  The loquacious Bjørn Furuknap provides  a simple, accessible overview of SharePoint workflow creation options here: http://blog.furuknap.net/sharepoint-workflow-what-you-need-to-know

While the out of the box workflows in SharePoint Foundation or SharePoint Server may not be extraordinary, they’re perfectly useful in many basic business scenarios – like, for example, routing a document to your manager for authorisation. Start here: http://office.microsoft.com/en-us/sharepoint-server-help/CH010372671.aspx and here: http://office.microsoft.com/en-us/sharepoint-designer-help/understand-approval-workflows-in-sharepoint-2010-HA101857172.aspx?CTT=1   I also like this clearly presented, and very clearly enunciated, 11 minute video overview from lynda.com: http://www.youtube.com/watch?v=KzXtp996ciA

Using SharePoint Designer 2010 or Visual Studio, or even a third party workflow solution, you can extend SharePoint’s inbuilt workflows and create highly ‘custom’ automated processes that fit seamlessly into your organisation.

Some examples:

  • Financial Approvals – an InfoPath form collects requisite information from the requestor and routes the online form through the organisation’s authorization stage gates, optionally collecting additional information along the way, and capturing digital signatures.  It can be rejected and automatically  returned, with reasons, to the requestor if key information is missing, or if the business case doesn’t stack up. The same approach has also been used in the context of Travel and Leave Requests.
  • Performance Appraisals – an InfoPath form with an employee’s achievements and goals is routed between the employee and his/her manager to capture their comments and feedback and set new goals, in line with the organisation’s established appraisal process. Ultimately signatures of  agreement are captured and a record filed for reference next year.
  • Provisioning New SharePoint Sites – WonderLaura, aka Laura Rogers, shares her nifty solution for automating the approval and creation of a new SharePoint site here: http://sharepoint911.com/blogs/laura/Lists/Posts/Post.aspx?ID=126

Why yes, there’s a Resource Center!  Albeit not for the faint-hearted.

You can also make a good start with the SharePoint Designer 2010 Help & How To articles at http://office.microsoft.com/en-us/sharepoint-designer-help/CH010373544.aspx

Other Strengths

The Drop Off library and the Content Organiser, which I’m currently exploring with a technical colleague for a client, is great in the right context.

The 2010 enhanced Records Management feature set is a huge improvement over 2007.

I really like the Calendar Overlay – that is, the ability to ‘overlay’ one calendar with colour coded events from up to 10 others. It’s a great way to bring multiple business units’ calendars together in one master ‘enterprise calendar’.

I could go on and on, but you get the point I’m sure.

I’m keen to hear your views and, better still, examples of what comprises a SharePoint strength in your workplace …  Go on, add a comment…

Summing Up:

  • Straight out of the box, there are many features, functions and options to exploit in SharePoint, which can take many deployments from ordinary to useful.
  • Take the time to investigate these strengths, so you can build the ‘killer’ solution that will help your business understand the promise of its SharePoint investment early, and derive value quickly.

Top 10 Tips for Success with SharePoint: #1

Post #1 in the inevitable numbered series…
These will be just my opinions, of course but, for what it’s worth, they’re derived from years of observations on what’s worked and what hasn’t.  My lessons learned – sometimes bitterly – have come from working on or leading several real world SharePoint deployments. And also living with the results; I have done my time in an operational role as a Portal Manager on a SharePoint platform.
Not all my blogs will be like this, but this series will comprise quite long, discursive musings. You have been warned.   I’m a fan of cross-referencing, so if you persevere you’ll find links to other useful resources within.

 

It’s All in the Planning. Up To a Point.

Planning Makes Perfect

Don’t we all know the truism, or perhaps it’s a cliché:  if you fail to plan you plan to fail?  Ho hum you yawn, Project Management 101.  I’ll try to ensure the following isn’t wholly a variation on that well worn groove…

However, let’s begin at the beginning and focus on the importance of up-front planning before you embark on a SharePoint deployment, because it still needs reiterating.  I continue to advise and work with clients who want to “just get on with it”.  ‘It’ being implementing SharePoint to address [insert current problem here] or as the platform to replace [insert current broken application here] and fix all the company’s ills.  After all, it’s just a matter of installing the software, entering your licence key, doing a bit of configuration and away we go, right?  SharePoint pretty much runs itself.  How hard can it be!

Well unfortunately the answer is quite hard, quite often.  Also potentially quite expensive: even if your deployment is cheap and cheerful, the costs can mount downstream, when the brave new world of enterprise SharePoint turns out to be just as messy and difficult to manage as the problem it was originally going to fix.  

(I’m not going to open Pandora’s Box on the first and arguably most important task – determining whether SharePoint’s the right tool for the business need or problem. You can find plenty on that topic in the blogosphere, and this is a series on tips for achieving success with SharePoint after all, so we’re going to take proper evaluation and selection as a given.)

I advocate sound project planning for a SharePoint deployment; so far so obvious.  Next, please ensure the solution is designed for your organisation, not in accordance with some best practice ideal. You must understand and plan the implementation around your:

  • Priority requirements and pain points
    Are these the same thing?  Are you scoping the project to meet requirements but not addressing the real areas of pain in the business? Spotting ‘quick wins’ in the planning process and delivering on those on Day 1 will support user perceptions of success and help drive adoption.
  • Business practice
    Are organisational processes reasonably homogenous or are there many disparate units with differing needs and styles?  While SharePoint may be able to serve them all in theory, addressing widely different requirements and expectations can grow deployment cost and complexity. Scope will need to be carefully defined, or successful delivery could be compromised.
  • Organisation culture and user profile
    Are staff change ready or averse, and to what degree?  What’s the overall level of technical competence?  Is the organisation reasonably homogenous or are there many disparate units with differing needs and styles?  Be aware that SharePoint isn’t particularly intuitive for many people, and widely different needs and expectations can grow deployment cost and complexity. The answers to these questions can help inform decision making on change management planning and budgeting.
  • Technology landscape– e.g. current Office version, data storage capacity, complementary / competing systems, upgrade of a previous version or ‘greenfields’ deployment – and IT roadmap – e.g. on-premise or cloud hosting.
    How SharePoint is expected to fit into the bigger IT picture could rule some deployment scenarios in or out.
  • Software edition and core focus
    Are you deploying the SharePoint Foundation or SharePoint Server. If the latter, Standard or Enterprise editions?  Each will present you with certain planning and design choices.  (You can find a nifty editions comparison at http://sharepoint.microsoft.com/en-us/buy/pages/editions-comparison.aspx
    Is the core focus of your implementation internal (e.g. intranet or team collaboration environment), extranet or external (e.g. a website)?  Communication or collaboration orientated? If you answer “all of the above” be prepared for a huge project.
  • Deployment methodology
    Should you start with a pilot?  If so, how will you define and constrain that pilot? Will a staged rollout work best for you, or a big-bang deployment?
  • Budget
    Working within financial limits is a reality. But it’s important to be feasible – is the budget proposed really sufficient for an enterprise SharePoint project?  Just because you have an Enterprise EA does notmean SharePoint is free.
  • Environmental constraints
    Identify your specific risks and issues up front as far as possible. What factors might derail or compromise a SharePoint deployment and what can you do to mitigate these when planning the project?
  • And other specific circumstances – e.g. level of in-house technical and business skill available to the project, ongoing availability of administrative resources, etc.
    Do you need to engage external assistance or can you go it alone – for the whole or part of the project?

 

SharePoint Planning Resources

If you’re casting around for planning assistance…

Microsoft has done a laudable job in providing myriad Resource Centers to help with detailed planning of various aspects of the sprawling feature giant that is SharePoint 2010: http://technet.microsoft.com/en-us/sharepoint/ff465365  They’re pretty good, up to a point.

A cautionary note: be careful to interpret this material through your own filter and be aware that SharePoint best practice advice is sometimes an ideal and occasionally idealistic. It doesn’t always reflect SharePoint as just one part – however integral – of an organisation’s information ecosystem, or acknowledge that many companies struggle to maintain consistent, effective enterprise wide business processes.  For example, in the real world SharePoint users may simply not use Content Types (there’s a fascinating discussion on the promise and power versus dismal adoption of Content Types archived at http://www.endusersharepoint.com/2010/11/29/sharepoint-content-types-is-this-a-lost-cause/ to support this point).  They may not use My Site as predicted or the way you want them to.  And best laid plans may slowly go awry.

In my view, the Resource Centers can also sometimes become far too IT and product centric.  A small example: recommended governance roles & rules are synonymous with SharePoint roles & rules – very rarely meaningful to non-IT folk or senior stakeholders.

The SharePoint Help and How-To site within Microsoft Office’s vast online reference is also useful. While it won’t necessarily explicitly aid planning, it does offer more of a day-to-day SharePoint how and why that’s a worthwhile adjunct to the Resource Centers’ strategic / conceptual approach. See: http://office.microsoft.com/en-us/sharepoint-server-help/sharepoint-server-help-and-how-to-FX101834344.aspx

One of my favourite resources on SharePoint planning is provided by Paul Culmsee at http://www.cleverworkarounds.com/  – look for his Planning, Governance and Assurance series of posts.  (Also the Return on Investment series, if you’re still at business case stage – the multipart Learn to talk to your CFO in their language is pure gold: http://www.cleverworkarounds.com/2007/11/17/learn-to-talk-to-your-cfo-in-their-language-part-1/)

Up To A Point?

Right, onto that little caveat in the heading of this post. Having exhorted you to plan diligently and in detail, I’m now going to qualify that advice and hopefully not appear contradictory.

According to the principle of diminishing returns, eventually planning and yet more planning ceases to equate to project success and yet more project success. It becomes analysis paralysis, producing little or no return.

Having read some of the reference material out there you might think, for example, that you simply cannot move ahead with your SharePoint build and configuration until you have a detailed design document recording your enterprise’s entire suite of Content Types, Permission Levels, Term Sets, etc.  Or perhaps not until you’ve created use cases and identified actors for every dimension of a content approval process.  Not so.

On and Off the Page – Planning versus Reality

One of SharePoint’s strengths is, I think, its flexibility. You can quite easily move constituent parts around and tweak various elements on the fly.  Up to a point, again – sure, you need to be somewhat wary of burnt bridges, and once you’re a way down the implementation highway it can be time-consuming and costly to turn back and embark on a different route.

But I think we should leverage the application’s inherent flexibility much more during the planning and initial design process.  This is the point at which “just get on with it” has a valid place.  Let me explain…

I’ve learned from experience you can go through a user-centred design process by the book, for example, to arrive at an ‘evidence-based’ site structure and Information Architecture that everyone would agree, I’m sure, is empirically sound and exactly what is required.  Only to find the minute the IA moves off the page into a real world deployment it just doesn’t seem to work, and considerable adjustment to that carefully planned structure and hierarchy of sites and subsites, pages and document libraries is necessary.

I’ve observed analysts liaise tirelessly with a business team on their process for doing XYZ, produce exemplary flow charts and achieve sign off, then faithfully reproduce the workflow in SharePoint … only to find that it’s not really what the team imagined / wanted / can use after all.  Paul Culmsee blogs insightfully at much greater length on this at http://www.cleverworkarounds.com/2010/12/02/sharepoint-analystsstop-analysing/ if you’re inclined to explore this further.

Try to avoid making the mistake of too much planning. It wastes precious time and effort.  When planning falls short of reality it can make stakeholders nervous and can unfairly start to erode confidence in SharePoint or the project.

Prove It

I highly recommend building a rough and ready POC (Proof of Concept) environment, as early as possible in the planning process.  In a week or so, or less – depending on the number and complexity of concepts you want to prove with SharePoint – you can run up a server and build a very effective little demonstration and prototyping platform.

Recently, we built a fully-functional SharePoint 2010 POC for a client, in a standalone test environment, integrated with Active Directory, Office 2010, Lync, Exchange 2010 and Dynamics CRM.  I configured a couple of site collections and a handful of sites, libraries and lists, with a reasonably detailed enterprise term set provided by the client, plus a Search Centre and My Sites. This is allowing our client to thoroughly test many aspects of the SharePoint feature set.  They’ll have a much better understanding of the product’s strengths and weaknesses in the context of their actual business processes, and their implementation project should be better planned and more successfully delivered as a result.  At the very least, they will be making decisions with hands-on knowledge that no amount of reading – or even advice from yours truly – can match.

Summing up:

  • Planning a SharePoint project – thoroughly, carefully and in detail – is essential
  •  Design your solution for your specific circumstances.  Don’t get caught up chasing a best practice ideal (unless it really is best for your organisation).
  • Recognise when enough planning is enough, get ‘off the page’ and prototype live in SharePoint