Archive for the 'SharePoint' Tag

There’s this great article over at CIO about the real cost of SharePoint, a content management system by Microsoft.

A few quotes:

If an IT department is using SharePoint as a development platform for business applications, costs will increase because developers and quality assurance testers will be needed.

Time and effort needs to be put toward developing and maintaining a SharePoint governance plan that outlines the type of content that should be loaded into the system, records policies, standard processes and metadata constructs, and guidelines for approaching and supporting SharePoint projects. (Read: solid information architecture — hire an IA, dammit).

Even if your users are familiar with SharePoint, using it to solve a specific business problem (such as automating a contract management or accounts payable process) typically requires some training.

After deploying SharePoint, users will need to change their approaches to creating and managing information. Given people’s reluctance to change, a proactive change management program is recommended.

Most of the organizations out there just launch CMS systems without any thought to a lot of issues. It’s like any other software product, and should be treated as such.

There’s a few people that are more adamant than me about their dislike for Basecamp, but I finally decided to take a taste of the Basecamp Koolaid. It’s been a quick and dirty lifesaver, because it’s something I don’t have to maintain, and if something goes wrong, I would hope file recovery would by their responsibility.

It’s one of those tools that I wish did more, and while it’s simple, it’s too simple. By the time you figure that out, you’re kind of stuck, because migrating files is a pain in the neck.

It focuses way too much on Web 2.0

Look, you can drag and drop!

Look at the nifty hover-overs!

Look, wiki’s, but not really!

It’s cool for us web types that love that kind of stuff, but have you ever tried watching a corporate user use BaseCamp? It’s painful. They don’t get most of those little features and touches because 1) they aren’t Web 2.0 experts, and 2) the features aren’t documented in a way that any user would really know how to use them. It would be nicer if they spent some of that time on the next point…

It’s missing features — lots of features

This is a discussion that a friend of mine and I have about the product. We’re using it, and it’s a nice little file sharing tool, but there’s a lot of features we wish it had. Like…

• True prioritization that could be editable
• A better navigation structure
• A more sophisticated governance structure
• More consistent formatting tools (instead of me having to insert HTML)

…and the list goes on.

Seriously, a few of these features would be really, really easy to implement, and wouldn’t take a full feature release.

Simplicity is one thing. Limiting your feature set and telling the users it’s good for them is another.

The pricing isn’t really that competitive

I’m using Basecamp on a few projects, and am paying the $24.95 a month. That might not seem like much, but hosted, that’s roughly $300 a year. I can write that off (and I do) as part of running a business as a consultant, but still, that seems like a lot, and I’m using it on really small projects.

For example, here are some prices for SharePoint (which is the same pricing plans with more features as BaseCamp). Outside of some configuration issues, is a much superior product, and is gaining more acceptance in the corporate community. There’s some great templates to get you started, and quite frankly, I could set up a template in a week that replicates much of the functionality of BaseCamp. I’m lazy because I have more important things to do (like bill clients), and MOSS doesn’t have very good Apple support.

That said, if I were working in an environment that was mostly Microsoft, and had time to setup a SharePoint instance, I’d be all over it in a heartbeat.

They seem to be more about marketing

Sometimes marketing and a cult takes over. Good examples of this are Apple and eBay. Apple products are wonderful (I own enough of them), but they aren’t the most usable in the world. Same with eBay. eBay’s gotten much better over the years about user experience, but the reason it’s big is that they provided a marketplace, had that cult factor and marketed effectively, not because it ws the best product on the market.

The same goes here. If you tell the right people how good you are, and you have the right public relations professionals, you’ll get sales. It’s about the cult, sometimes, especially in the Web space.

They say they listen to their users, but do they?

This post is kind of old, but still, why did they publish this?

I’ve been a product manager, and laughing at your customer base was something that you did over a couple of beers with your customer service representives, not in a blog post. We all agree users in the end are stupid, but you aren’t supposed to make them feel that way.

I remember the days of the users doing something stupid, and then correcting the issue through a better feature development or more help text. This is like airing your dirty laundry, and what’s a bit more troubling about this is that it’s not like this is a free service — users are paying for this product.

They don’t hesitate to take shots at other sites — and yet seems reticient to deal with listening to their users. Let’s face it, the only person that can get away with that is Steve Jobs, and I don’t see him working anytime soon at 37signals.

Your IT person says Joomla. Your PHP person says Drupal. Your marketing person says SharePoint.

Let’s be frank: they are all buzzwords, and the person speaking to using that system usually has an ulterior motive outside of what’s best for the users. It’s like that Linux guy that likes Linux because it’s easy for him and no one else. Does that really serve the office?

If you have a Microsoft Gold Partner sitting in your office, he’s going to say SharePoint fits the needs for anything short of curing cancer even if MOSS is completely the wrong system. And frankly, all developers have their favorites, and sales people sell, regardless of what the product is. Mac vs. PC. Windows vs. Unix. Drupal vs. Joomla. They’re all religious wars, wars I’m especially tired of.

Every product has it’s merits, and should be judged on them alone, not on a salesperson’s preference. End of sentence.

What do you do? Read the rest of this entry »

If interested, send your resume to jobs@usabilitycounts.com.

An international specialty technology company is looking for an on-site full time Information Architect with at least two years of experience designing SharePoint (MOSS) Solutions to champion its SharePoint internet among the employees of the company. This position will ensure the proper governance structures are in place to define the administration, maintenance, and support of content through the information lifecycle. The Information Architect will work closely with business users and the Solutions Architect to develop business requirements for more complex team site applications.

Tasks

• Working within a cross-company team, define the organization, presentation, and navigation of content for the intranet site.
• Conduct one-on-one and group training for team sites. Working with individual departments to establish their team site. Work with business users and Solutions Architects to develop more complex solutions.
• Conduct group training for my sites. Develop workshops to help users establish their my sites.
• Develop and implement the governance and guidelines for how Sharepoint is utilized (content publishing, information security, archiving of content) along with the roles and responsibilities.
• Completes special projects and other duties as assigned.

Skills

• Two years experience as a Sharepoint Information Architect.
• Three years of experience managing projects with documented business benefits by leveraging collaboration technologies.

Background

• Four-year college degree, preferably in computer science or software engineering, or equivalent level of experience.
• Must be a self starter with good interpersonal and analytical skills.
• Must be able to work with both technical and non-technical employees.
• Must be detail oriented, creativity, experience working with multi-disiplinary teams.
• Ability to understand business requirements, analyze business processes and develop technical solutions to support the enterprise

I’m in the process of setting up a few content management systems for clients, and it’s been an eye-opening experience, not because the systems are crude, but because they actually work pretty well. SilverStripe and WordPress are two that I’m looking at using on a consistent basis, but there’s a few resources out there to help you select one:

• Six Revisions has a list of the 10 promising systems it has selected
• Open Source CMS is the mack daddy of CMS lists, and a lot of them have online demos
• CMS Watch is a bit more techie, and is a news portal covering the major systems
• Sometimes a blog engine is just what you need, and Smashing Magazine has reviewed 10 of them

In the coming weeks, I’ll go through some of the implementations I’ve been doing to make WordPress and SilverStripe sing. Stay tuned!

That’s a question I always ask when dealing with the clients: do they really care it’s a content management system?

The answer is no.

They’re looking for something that saves them time, backs up their data, makes it easier to share information with their co-workers, and that will work. They don’t necessarily care about the name of it, all they really want it to do is work, and for it to make their life easier.

That’s one of the points information technology departments miss in dealing with end users: the users at the end don’t really care what the name of the software is, because whatever they get, it’s imposed on them. From the email software they use to the word processing software they write up reports in, almost every piece of software is selected and standardized on across departments. Very few end users get to pick what their software is, and if they do get to pick, the information technology departments don’t support it.

So what’s my point?

To the information technology departments, specifically: whatever you do, make sure it doesn’t impose extra restrictions or demands on the end users. Whatever you build into SharePoint, take in consideration that the easier to use it is, the more users that will use it. Imposing extra governance and workflows to it doesn’t make sense.

For example, Groove is a great tool when paired with SharePoint, because you can have files on your local system sync with SharePoint document libraries automatically and seamlessly. What that meant for me is I lost a bunch of files in a system crash, but all of the files were backed up to SharePoint. I didn’t lose anything.

And it was so easy to use, I didn’t even know I was using it.

Can you say the same about your SharePoint implementation?

SharePoint is a platform with extensive functionality. There are some key questions you should ask before you select MOSS as your platform, and Ask A Good Product Manager has a great post about this. The summary is:

• What is the purpose for developing the application?
• What functionality does the platform provide?
• How is the platform received in the market?
• Can you justify the cost?

Read on…

One of the issues with SharePoint is that developing on it as a platform is quite a bit different than normal software development, because of the development is actually configuration of web parts and governance versus writing code.

So what do you do?

Microsoft to the rescue! They’ve released a new site called SharePoint Guidance. It’s a portal that covers all stages of development, from requirements gathering to unit testing and user acceptance. They also have a bunch of links to software that makes the job of developing for MOSS easier.

CleverWorkarounds has an insightful post are an South Australian goverment project that’s being scrapped after spending $5 million on IT development. What’s notiable about this is that this reflects how many SharePoint engagements go: projects failing because the approach taken was too complex for proper implementation, and many of the difficulties would have discovered early on with a proof of concept.

Projects fail for a number of reasons, but the main point here was the lack of high level systems thinking. Sometimes, it’s best to figure out ways to simplify the complexity, and that isn’t always an easyr thing to do.

There’s a post over at Knowledge Forward about how SharePoint is not a gap, it’s an ecosystem. It’s  true — there are gaps in the platform that allow third party vendors to build all sorts of nifty tools and web parts to fill those gaps. While it’s arguable that those gaps are intentional or not, what it does point it out is that SharePoint is incorrectly positioned as an out-of-the-box cure all for all your content management ills that can be implemented in two weeks exactly as you want.

(That may be part of the reason why there’s so many awful SharePoint implementations.)

MOSS is more of a framework of “Where do you want to go today” without needing to build the system from scratch and requiring money and time to do all that testing on what really should be out-of-the-box compnents.

SharePoint can do a lot of things, and sometimes almost anything, but SharePoint implemented incorrectly can equal months of pain and believe me, I’ve seen it. SharePoint however positions itself very well against the Documentums and Vignettes of the world in providing a solution that provides extensive control over workflow and document management but doesn’t break the bank.

It doesn’t mean it’s any easier to implement; it just means that you probably need three or four MOSS Architects when building a system with Vignette or Documentum might need 10 or more consultants who would cost twice as much per hour.

Here’s a few tips to make your life easier:

What Are You Trying To Do?

Figure it out — what’s the purpose of the SharePoint implementation? There’s a lot of things that it does well, and there’s also a lot of things that it doesn’t do well. SharePoint is excellent at document management, collaboration and other internal intranet needs. It’s blog and message board tools, however, aren’t as effective as they could be. The list might make SharePoint a deal maker or breaker.

List what you need out of any content management solution, and prioritize what’s more versus less important. This will help you evaluate how close SharePoint gets you to the final product.

What Does SharePoint Provide “Almost Out Of The Box”?

There’s a lot of functionality in SharePoint that gets you 90 percent of the way to where you want to be. Figure out what functionality you need out of SharePoint, and look for web parts and configurations that gets you almost all the way there.

If it’s not quite what you need, but close, either consider the time it takes to customize it, or consider changing your requirement so it fits the tool. This may seem like a backwards thing to do things, but if it saves

What Are The Gaps That Need To Be Filled, And How Do I Fill Them?

There are a ton of companies to provide tools that play well with SharePoint, and fill in some of the gaps where SharePoint falls short.

For example:

• Telligent has a product called Evolution, which fills in collaboration gaps where SharePoint isn’t as effective as it could be. Evolution is a complete social media package with blogging, message boards and social network components that includes web parts the integrate directly into SharePoint.
• Telerik provides a lot of smaller web parts like a totally configurable HTML editor that plugs directly into SharePoint. It comes with a bunch of other tools, but the editor is what sold one of our clients on how much control (or lack thereof) they could give end users editing SharePoint content.
• Infragistics also builds presentation layer controls that helps give end users a top notch User Experience in using SharePoint. Remember, some of those gaps aren’t just product-driven, they may be UI Driven.