Addressing the SharePoint skills shortage, Part II: The SharePoint BA

The New Software Era

I know this is a generalization, but I think that the world of software is finally changing. For years now, we’ve heard about systems that provide enough abstraction, enough of a “toolkit” user interface so that end users could configure their own specific application functionality. Truth is, these systems were always regarded as marginal by the mainstream IT industry, for a variety of reasons: reliability, scalability, performance, universality, lack of standards etc. All valid points, of course, but none of them could detract from the fundamental demand from users to provide them with highly configurable software and get out of the way.

At the risk of over-simplifying things a little to develop my point, let’s take a look at this back-of-the-napkin comparison table between the old and new software eras:

Old software era

New software era

Applications custom-built by development team Formal process of requirements/business analysis, meant to minimize cost (because it’s cheaper to adjust documentation than code Each application has a unique user interface End users cannot build applications IT department is the gatekeeper between users and applications (or users and services) Long times to launch, relatively high costs (PM/BA/risk management effort per application is more or less always the same)

Users can build their own applications Prototype, prototype, prototype (perpetual beta) IT only provides scalable infrastructure and security Shot times to launch Low cost

There are obvious and evident benefits to the “new era.”

The challenge, as discussed in my last post, is now that end users don’t really ‘take up arms’ and suddenly start developing their own applications. They quite like having experts at the table to guide them through the process of constructing (or configuring) a business application.

IT departments, as they are today, are poorly equipped to provide these services. The increasingly siloed approach to delivering software in the enterprise has left us with a complete lack of generalists.

• Business analysts know how to elicit business and functional requirements for a world of software where ‘anything is possible’ (no, or very few technical or UI constraints), but they don’t know how to work under the constraint of using a product as the primary vehicle of implementation
• Solution architects and developers are platform experts and have focused on developing their skills at quickly building complete applications, from scratch, by using pattern-based approaches (scaffolding, etc.), but don’t know how to work under the constraints of a product, either (as noted before, their instinct is to custom-build everything, often without being aware that it’s already there).

What ensues in an enterprise that’s committed to Microsoft SharePoint is a mix of confusion and frustration. I’ve seen any number of companies that, 2 years into the MOSS 2007 journey, still have only deployed a disorganized smorgasbord of proofs-of-concept and departmental WSS servers, realizing none of the enterprise benefits of the platform.

This is a significant challenge, both for Microsoft (who, as always, will struggle to make an argument for the 2009 enterprise agreements to customers who are not even realizing the full benefits of the previous version) and for those ‘visionary’ CIOs themselves who were SharePoint-friendly because they could see the potential of an end-user focused information management platform.

Enter the SharePoint BA

So what’s a SharePoint BA? Well, he’s a Business Analyst who works primarily with the SharePoint platform. This is someone who comes equipped with the hard and soft skills of a software business analyst and the product knowledge of an expert user/product manager. The SharePoint BA operates, at all times, under the basic assumption that everything should be implemented using SharePoint. More importantly, he works on the principle that most users’ requirements can be met with out-of-the-box SharePoint functionality. He thinks of his job as that of a guide, a marketer, a consensus builder and a hands-on implementor.

Here’s the approximate profile of a SharePoint BA:

Skill Category	Required Skills
Hard skills	Detailed SharePoint knowledge from an end user and administrator perspective. This should include truly every aspect of the functionality, from collaboration to document management, search to KPIs, My Sites to Records Management A solid understanding of how to translate business requirements into what SharePoint offers – I think of this as a “constraint parser,” allowing the SharePoint BA to quickly run through the options in his head (“Can I do it in a list?” – “Can I create a view for this?” – “Do I need workflow?” – “Can I use SharePoint Designer to do this?” – “Do I need an external data connection?” Etc.) Good core business analysis skills (the whole gamut of BA skills is still required, everything from diagramming to wireframing to use case writing) Good core Windows/Office power user skills (it’s important to really be able to find your way around a computer, also in the sense that frequently, the SharePoint BA will have to figure out minor problems or “fake something up”) Good documentation skills (the ability to structure and write a document; the ability to evolve a document template
Soft skills	Great consulting skills (excellent verbal and written communications, ability to present, ability to listen and summarize, ability to put forward an opinion Ability to learn rapidly and effectively Interest in playing with SharePoint (or other) application functionality to ‘figure things out’ (this person cannot be theoretically oriented) Ability and willingness to be involved with practically building something Ability to manage own time, work on multiple things at the same time, etc.

This is very different from a classic BA who’s involved in specifying and designing custom applications.

From a process perspective, the SharePoint BA interfaces with the business to gather business requirements. In so doing, he continually proposes specific ways of implementing the requirements using SharePoint. Unlike typical business analysts, the SharePoint BA has an opinion about implementation and expresses it. Often, he may choose to prototype something on the fly to show the users how it could be done: “Is this what you were thinking?” – “Would this work for you?”

I iamgine SharePoint BAs will spend much of their time providing information to users about SharePoint. This could take the form of use support or training. This may end up being frustratingto SharePoint BAs – supporting end users is not every IT professional’s idea of a good time (or, for that matter, a good job). The person who’ll do best in this profile is an evangelist of sorts, a believer: SharePoint BAs should believe passionately in their madium’s ability to deliver cost-effective applications to business users.

The nature of the work, therefore, is also less transactional than a typical BA’s activities on old-style software development projects. Before, BAs used to be a specific part of the overall software development lifecycle. They elicited requirements and wrote them up at the beginning of the project. These requirements were ‘consumed’ during the rest of the project.

For SharePoint projects,  the BA’s activities are more fluid and longer-term. From education to requirements, from requirements to implementation (configuration, that is) – the SharePoint BA follows projects practically end-to-end.

In my next post, I’ll try to imagine some programmatic ways to address the SharePoint skills shortage by methodically building technologies like SharePoint into college curricula and IT professional training programs.