Tag Archives: Business Analysis

BrightStarr US Looking for SharePoint Analyst

Leave a reply

My company, BrightStarr, is looking for a SharePoint business analyst.  Our goal is to work with someone who:

  • Understands the platform very well
  • Has a good idea of what’s a smart SharePoint solution versus a cobbled together house of cards
  • Enjoys working directly clients, some of whom understand what SharePoint is all about and some who have just a vague notion that SharePoint could help them but not sure exactly how
  • Can write very well
  • Can communicate really well with a small team
  • Is good at and enjoys multi-tasking.  This is not a heavily process-driven environment (we have enough process to do things in an organized way, but we’re extremely fast on our feet, nimble and all that good stuff).

This is not a developer position although if you’re a consultant-developer looking to focus more or consulting and less on development, this could be a good step for you.

If you’re interested, ping me on twitter or email me!

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

“Can Do” versus “Should Do” in SharePoint Projects

8 Replies

I think that many of us are occasionally presented with, for lack of a better phrase, young-child requirements.  The end user really, very badly wants a certain specific look and feel, or a very specific sorting structure or a to cut out one click or menu option to ease navigation or [insert passionately held belief that happens to be wrong].  As SharePoint pro’s, we can generally meet almost any kind of requirement with the platform, but for some of them, we know in our hearts that:

  • They are going to take a disproportionate amount of time to implement (and therefore cost more)
  • They are going to be highly custom and therefore difficult to maintain and troubleshoot
  • There is is some easy SharePoint approach that meets 80% or more of the requirement (i.e. meets the sprit of the requirement, but not the letter of the requirement)

Bottom line, we know that the “requirement” is really just a nice to have or even legitimate in some sense, but something that people should live with rather than spend a lot of time trying to “solve.”

I think of these as “young child” requirements because I’ve seen this pattern many times before.  Kids will pine away and nag you for some new toy for weeks at a time.  You get them the toy, they play with it for a few hours or days and then put it down, never to pick it up ever again.  Or, you don’t get the toy, the nagging stops and the kid moves on to become President of the free world.   I’ve seen this happen in SharePoint projects.  Decision makers either get what they want and it becomes an unused or underused function or they don’t get what they want and the project still succeeds anyway.

I was reminded of that today in a forum post and I liked how Clayton Cobb tried to get the forum poster to push back on one of these kinds of requirements: http://social.msdn.microsoft.com/Forums/en-US/sharepointinfopath/thread/af8a1941-92ad-4f1a-b1bf-875e28ea79b7/

I’m really curious how people view this topic and how you deal with it.  Am I missing the point?  Do you have strategies to steer decisions makers away from overinvesting in trivial requirements?  Please leave a comment.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin