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) : )
Don't forget the BADASS Consultant.ReplyDelete
Business Analist Developer Architect SharePoint SuperHero Consultant.
Thats kinda the role I have in my current project.
Besides that, great post! Always nice to find quality sources to add to my feed reader :)
Also it might be nice to add disqus for commenting on your blog? I like to auth with twitter when commenting
At first glance this really confused me, why one would require a BAD consultant, I thought BAD refers to real meaning of bad. To deal with any SharePoint projects I think BAD will be always a good choice as he is more knowledgeable from both the sides and will be more helpful to get the desired results.ReplyDelete
IEEE Project Domain management in software engineering is distinct from traditional project deveopment in that software projects have a unique lifecycle process that requires multiple rounds of testing, updating, and faculty feedback. A IEEE Domain project Final Year Projects for CSE system development life cycle is essentially a phased project model that defines the organizational constraints of a large-scale systems project. The methods used in a IEEE DOmain Project systems development life cycle strategy Project Centers in Chennai For CSE provide clearly defined phases of work to plan, design, test, deploy, and maintain information systems.ReplyDelete
Đặt vé máy bay tại Aivivu, tham khảoReplyDelete
ve may bay di my gia re
bán vé máy bay từ mỹ về việt nam
thời gian bay từ Việt nam sang Los Angeles
giá vé máy bay từ Toronto đến việt nam
awesome post https://judahwrmn763.exposure.co/what-not-to-do-in-the-website-development-tampa-industry?source=share-judahwrmn763ReplyDelete