This section explains some typical follow-up questions you may have once you start to think about your first SharePoint project.
A: Your SharePoint project team won't break any of your old familiar patterns. The typical team consists of the following roles:
- Project manager: Manages the team to the schedule.
- Business analyst: Works closely with end users to obtain business requirements. Works with the technical team during implementation to answer business questions and provide quality control as the business solution is built.
- SharePoint architect: Ensures that the solution follows best practices for SharePoint. This includes infrastructure and security, coding and efficiency.
- SharePoint developer(s): Implement the solution in code.
- Quality assurance: Test the solution.
In many cases, the first project's scope is small enough that you would have a team like this:
- One part-time Project Manager.
- One part-time Business Analyst. Sometimes, the PM serves both as PM and analyst.
- One full-time SharePoint Architect. The architect often does some coding.
- One or two SharePoint Developers.
- One QA person. Sometimes, the QA role is filled by the BA person, the PM person, or any combination of the three.
Or if this is really a small project then this may sufficient:
- Business Analyst/Project Manager, and Frontend Developer also known as a SharePoint Solution Architect.
The most appropriate team members may not be your "best" .NET coders, particularly if there is not custom development work. As we discussed in the planning phase, one of the key goals of a project is to build up the team's knowledge base. Your best architect and developer may not be the ideal candidate for sharing knowledge. You know your team, so be sure to staff the project with a knowledge sharing environment in mind and balance that need against the need for technical skills.
A: This simple question begs another question, "Why do I need to leverage success?" or more to the point "How is leveraging success with this first SharePoint project any different from leveraging success in other projects?". If you want SharePoint to be truly transformational rather than merely a collection of one-off business solutions, you need to find a way to parley your first project's success into something bigger. After all, if you follow the advice this chapter offers, your first project hasn't exactly boiled the ocean. That's not to say that it's low value, but you've deliberately crafted a solution that is relatively narrow in scope in order to reduce the significant risks that the first SharePoint project entails.
The solution is a joint road show with your end user business partner. After your customer has gone live with the solution and is living with the benefits of the project, create a presentation that touches upon the following points:
- What did you do? Emphasize the business problem and the solution.
- What benefit did the company realize from this effort?
- How long did it take and what did it cost? Don't forget to include costs to your end user partner, especially in terms of hours spent.
- Most importantly, how does this real-life in-production solution represent unexploited potential elsewhere in the company?
The objective of the road show is to motivate other business units to step up to the plate and request their own business solutions. You'll know you've been successful when the queue is 10 city blocks long. Of course, that presents a new set of challenges but that's a topic for a different book altogether.
You can reduce these risks and use this first project as a launching pad to SharePoint transformational nirvana by working closely with end users in a highly iterative manner. Show them intermediate work product to stay on track and make opportunistic enhancements to the solution in midstream. Build these intermediate reviews into your project schedule as well as intra-team technical "show and tells" designed to build up your internal SharePoint expertise and comfort levels.
When you finish, close it out with a joint road show with your end user business partner. Nothing sells like success in having a joint presentation with your satisfied customer and happy end users.