I’d like to think that I’m a pretty good SharePoint Developer. I can jump back and forth from SharePoint Designer to Visual Studio. I can talk to you about the pros and cons of sandboxed solutions. I can even talk your ear off about the advantages of using Silverlight and the Client Object Model in SharePoint 2010.
But, as I reflect over the last 2 years, and the SharePoint projects on which I’ve worked with several clients, I realize that I’ve spent an overwhelming portion of my time being a Business Analyst in addition to a SharePoint Developer.
I also realized that’s exactly what each of my clients really needed - a Business-Analyst-Developer consultant. They needed a BAD consultant.
Whether you’re on a large project with an individual person for each team role, or whether you’re on a small project where people have to wear multiple hats, it always good to have a BAD consultant on-board. This is the consultant who is technically proficient and able to implement the necessary solution design, but who is also able to speak the language of the business, and translate between technical needs and user needs. For instance, a BAD consultant can take the User statement “We need to be able to automate our data entry processes in such a way that workers can input information remotely…” and go off to design some InfoPath smart forms with workflow, and deploy them with Forms Services via the extranet.
Have you ever been given a complete list of development tasks for a SharePoint project, where an attempt was made on each task to prioritize it, but ultimately 90% of the tasks end up being marked as High Priority? Sometimes the client doesn’t really know which tasks are the most important to a particular solution, or which tasks should go in the first iteration of the project in order to facilitate the most useful feedback. Some developers might start with the task marked #1, and go right down the line. But a BAD consultant is sensitive to the goal of providing value. And being able to communicate to the users that a splash screen with the company logo isn’t as important in Sprint #1 as the login control is an important part of helping to give maximum value to the client as soon as possible.
For Goodness’ Sake
A really good developer can develop some really awesome solutions, and still have a customer who is unhappy with the final result. Does it do everything the requirements demand? Yes. But it’s important for a consultant to make the customer feel good along each step of the development journey about the final product they’re getting. A BAD consultant achieves this thru regular and open communication at each iteration. The customer may need to understand, for instance, how certain design decisions improve the overall stability and performance of the solution, even though they may diminish certain aesthetic qualities that the customer was expecting (for example, creating a global navigation solution that leverages the native navigation structures versus a customized fly-out multi-level animated navigation). And many times they need this expressed not so much in technical terms, but in terms that are aligned with the goals of the business. Good documentation, like diagrams and functional specifications, are also an effective way to develop confidence and trust in your users about the solution you’re delivering.
So the next time you’re interviewing a potential SharePoint consultant, be sure to ask them… “Who’s BAD?” (yeah, you knew it was coming) : )