SharePoint shares a common dilemma most software projects tend to have: How can I showcase the finalized outcome of this project with the look and feel, when we haven’t actually started implementing anything yet?

Some companies tend to prefer the approach where you build conceptualized SharePoint sites both for demoing and selling as products (or components). It’s a solid business-minded approach and seems to work great in the SharePoint realm. The downside however becomes apparent when the delivery is abrupt for any of the following reasons:

• Changes to requirements for your readily-available building blocks – thus, you are diving heavily into custom deployment. Take a deep breath, it’s going to take a while
• Your version 1.0 application/building block overpromises and under delivers
• A SharePoint update unearths new functionality or changes to existing features you hadn’t accumulated into the equation
• Dividing your lead architects’ time between in-house development and customer-focused deliveries. It’s hard to do both under time constraints and pressure
• Your frame agreement reads like an EULA for Apple, and you run into supportability and delivery scope issues

Putting these aside, it’s still important to establish a common ground for understanding what features and functionality will be designed together with the teams on both sides (the customer and the company delivering the solution) and how you plan on materializing the end-result from pure will.

The first plateau: Education

To me choosing a career in IT is all about education. Not the formal kind but the intuitive one. You never stop learning since essentially everything you comprehend today is worthless tomorrow, to put it harshly. On top of this you have experience, skills, stamina and spirited effort. Sometimes alcohol helps too. In modest amounts.

Educate your users, customers and business decision makers. Translate the obscure hieroglyphs at sharepoint.microsoft.com to common sense. Keep asking those dumb questions without being demeaning and help others reach the first plateau, just one of many on the rocky SharePoint terrain.

My preferred way of sharing knowledge and insights is a classroom- or meeting-room based workshop. A simple training is fine and good but it often stifles true innovation and sometimes becomes a chore of labs, powerpoints and whatnot.

You shouldn’t start with the uber-techies. Start with HR, marketing and management. Go through the easy but essential stuff:

• What’s the philosophy of SharePoint?
• What are the products called?
• What can you do with SharePoint?
• What is document management?
• What’s a portal, a team site and a my site?

This should be really low-key and basic. Always aim to find a new angle to learn while teaching (not preaching) and leave enough time for information to sink in. Do demos. Lots of demos. If the demo-gods are not smiling upon you, all the better – you learn while you do, and this shows the attendees not everything is perfect. That’s why you need to design what you will be building. Otherwise they’d be out buying SharePoint like milk – “it just works”.

It’s not about impressing the audience with your two thousand memorized tidbits of SharePoint, but incubating and sharing a holistic and non-technical view of SharePoint for anyone who cares to listen. Even the janitor might get invited and they ask tough questions.

I’ve sometimes been opportunistic in the sense that my workshops contain only a single slide: A quick introduction of myself and agenda for the day. Rest of the day is all improvisation, ad hoc prototyping and trying out new things without a safety net. The challenge is to keep explaining what you’re doing while simultaneously thinking ahead how things will pan out. For men, this is often a challenge, myself included. With practice it gets easier but always is a bit horrible.

Avoid doing a philosophy of SharePoint/SharePoint 101 –type general session just before your critical workshops (those that require real outcome and eat your precious billable hours). People need time to reflect what they’ve learned and for the majority of us, 15 minutes is not enough. We are not machines, you know. Some people are.

So to summarize – keep it simple, keep evolving and make sure this is the best workshop and presentation of your life. Especially for this project. They care and you should, too.

Tools of the trade: Mind maps

I wouldn’t be telling the truth if I’d say I’m a master of mind maps. No, sir. I’m a simple man trying to concoct every important thing said to a piece of paper.

Mind maps are best utilized for

• Metadata and taxonomy: Content Types, Site Columns, managed metadata-mappings and hierarchies
• Traditional site navigation planning: Global navigation, portal and site hierarchies, site collection visualizations, organizational structures

I’ve often employed mind maps for other things like to do-lists, instructing developers on the relationships between different entities and domains, blow-up models and for visualizing all key pieces to a given problem. It really works wonders.

I wish I had the audacity to buy and use a MacBook Pro – it would thus justify the purchase of MindNode. Having seen this OSX-only piece of mind mapping software in action I have to say it’s elegant, simple and usable.

On the Microsoft side of things, there’s not too much to choose from: there’s the Mindjet Mindmanager, which is not that bad but tends to be a bit too technical for viewers. It lacks the visual aspects of MindNode but mostly delivers the same end result.

That’s where bubbl.us is a fresh approach. It’s browser-based, so probably not the ultimate solution for the road warrior with lackluster 3G connectivity. It’s free though!

Give me something more advanced: Sketchflow

Sketchflow is part of the Microsoft Expression Studio Ultimate suite. My personal feelings against Sketchflow are mixed at best: While it aims to provide a superior prototyping tool/designer platform it fails on so many levels it’s mindboggling. I’ll spare you the oddities and just point my malice on licensing, availability and lack of support for tablets.

You can download a 60-day trial here.

Then again, Sketchflow is a viable option for sketching prototypes: You get to build stuff on the fly and show the results in real time. I just wish they’d incorporate true Tablet PC support for this and I could finally justify purchasing a HP EliteBook 2760p. For now I’m using white boards and occasionally and accidentally permanent markers. Sorry about that.

I’m not a clever man: Excel is alright

I’ve always kind of liked Excel. Not really fancied using it but embraced the fact that it’s been there since 1987 or so, everybody accepts the use of Excel hands down, it’s cheap and reliable and you don’t really have to invest a lot of time to learn new versions of Excel. When was the last time Excel crashed on you? I can’t remember either, although most of my spreadsheets are below average in terms of complexity or amount of rows. But it suits me.

There’s been times when I’ve come across the need to have a more templatized approach to my work. It works nicely with Word and PowerPoint but often thwarts my efforts in Excel. I’ve come to the realization that almost always the requirements are so specific that it’s easier to start from scratch and work your way up from there. It’s more rewarding too, in a twisted kind of way.

Excel is essentially great for

• Organizing a site collection structure or multiple site collections
• Emphasizing the inheritance of Content Types
• Listing Site Columns and their types and settings
• Mapping built-in functionality against a requirement list

Summary

Tools are great. Great tools are even greater! Still, a successful project and good prototyping with SharePoint boils down to the following factors:

• Be genuine
• Ask a lot of questions
• You don’t have to know everything. But be prepared to find the answers on your own time. Don’t be the clueless consultant
• Be nice – it’s nice to work with nice people