Almost 2 years of being here at the IMF, I have been directly and indirectly involved with numerous out-of-the-box solutions that were either immediate hits or nothing-to-write-home-about quick wins.  I do take pride in saying that they were all well-received.  The following are my general thoughts and steps on approaching solution development in SharePoint.  Note:  I am NOT a developer, I do not code.  When I speak of development, I am referring to the process of identifying out-of-the-box SharePoint features to compose the solution.

State your role.

In every kick-off meeting I always introduce myself, my title (it is ever-changing) and my role.

My name is Tom Pham. I am on the DAI team in TGSIK as a Business Analyst/SP Solutions Architect.  DAI’s role is to figure out how to meet your needs using out-of-the-box SharePoint features.

In stating this, you are indirectly setting expectations for the user on the extent of your involvement in the project.  Far too often, those lines of responsibility gets blurred – especially when this simple statement goes unspoken.  In cases where you’re working with a PM that you’ve worked with before on another project, they’ll assume you’ll pick up the reigns and start driving the entire project.  You think to yourself, “Whoa, I just got the meeting request 20 minutes ago and THAT was the first time I heard of this project!”  Clarifying these ambiguities even before requirements are discussed is half the battle.

Ask questions and zip it!

OK.  Tell me a little bit about what this initiative is about.

Do not assume a single thing!  Let the user speak and ask questions only to clarify.  Steer the meeting – don’t let users commandeer the meeting with side notes and tangents.  Identify what you will take ownership of and direct the user to who has ownership of XYZ system.

Who will be the audience?  Who will be maintaining the solution once we turn it over to you?

The first ‘who’ is self-explanatory.  The second ‘who’ is, again, one of those questions/statements that sets precedence on your involvement in the project.

When do you need this?

Unless it is absolutely clear that the timeline is unreasonable, there is no need to haggle over dates.  Quietly jot it down.  To talk about dates at this point is irresponsible because you haven’t begun to analyze the requirements.

Declare your intentions.

Great!  Lets talk about next steps.  I have enough information here to get us started.  I am going to have a discussion with my teammates to assure I’m using the best possible approach.  I am also going to research A, B and C and give you an answer.  After my research, I will shoot out, in an email, my recommendation.  In the meantime, please provide D.  Ed will provide E.  And Frank will provide F.  And so on and so forth.

We can set up our next meeting now or if you prefer, set up our next meeting after you’ve gone over my recommendation.

Look at what you’ve done.  You’ve committed to researching the unresolved.  You’ve let the user know that you will immediately start analyzing the requirements and will recommend a solution (your recommendation might be several recommendations based on the time and resources).  You’ve identified and assigned action items for the other members involved.  Everyone leaving the meeting should have a clear idea, not of what SharePoint can do, but of how this project will move along.  They feel confident that a previously stagnant project is finally gaining some traction.

Communicate your ideas through rapid prototypes or diagrams.

The majority of the projects I’ve undertaken were treated as an opportunity to let SharePoint shine.  How could we use this project to springboard SharePoint’s popularity throughout the organization?  Having an evangelist mindset was something that came natural.

You’ve already committed to providing the user with your brilliant recommendation.  This can be done in 2 ways.  One, rapid prototypes using the SharePoint staging environment or two, diagrams.

Rapid Prototype:  When the solution is as simple as creating a document library and adding a look-up column, of course, just create a proof-of-concept!  Don’t waste your time and Visio’s time.  Send the user the link to your prototype in staging and go grab a cup of coffee while you await their feedback.

Diagram:  Even when the solution is a simple one, I still spend the extra time to create the diagram.  I do this when there are more parties involved.  I can highlight, in the diagram, the various responsibilities of the respective parties.  I also do this for the novice SharePoint user.  Simply put, the visualization of the information flow reduces questions I would have otherwise have to answer.

Here is an example of a quickie diagram:

• STA-RES GFS data solution diagram

I use this opportunity to illustrate the manual process that will have to remain and illustrate the areas where SharePoint will automate.  This is also a good time to silence the skeptics and show your brilliance.

Know the limits – understand the Realization Model for SharePoint Out-of-the-Box Solutions.

Below is the SharePoint Solution Realization Model.  Here is a quick explanation:

As a SharePoint Evangelist, you preach that SharePoint is the Alpha and Omega.  The truth of the matter is that it will not solve everything, but then again, what does?  Outside of the quick wins, SharePoint remains a strong alternative for automating the inefficient processes that are in place.  The dangers of this is that client grow to assume that SharePointcan do simply what it was not meant to do.  Your challenge is to provide a solution whereby SharePoint’s out-of-the-box features can accommodate for 70% of the functionality – you can use your creativity to push it to more than that.  But for the sake of this example, I have set it to roughly about 70% in the diagram below.  The other 20% can be achieved through, policies, guidelines and manual processes that occur before it reaches the SharePoint solution.

Click to Enlarge

With SharePoint and the human factor, the user has reached 90%.  In the diagram, I’ve labeled it as the Acceptance Moment.  It is also known as the “Coming to Jesus (or Buhda or any diety)” moment.  At this point, the user simply accepts that SharePoint cannot reach 100% solution realization or continue to press forward and customize the solution through code development.

Do you want to lose 5 features so that you can gain 1?

The choice will always be up to the users.  As the Analyst, you are to advise them on the pitfalls of going down this path.  You do not want to customize something so much that it becomes unrecognizable and impossible for future upgrades.

Intangibles

Smile often.  Show enthusiasm for the project and the optimism in knowing that you’re going to blow their socks off with what you’ll come up with.  At all times, be the consummate professional – you owe it to the client and you owe it yourself.