8 Key Players in Your SharePoint Rollout
In my previous blog article, Is Your SharePoint Rollout Doomed to Fail?, I took a look at one of the main reasons many SharePoint installations struggle-the lack of user buy-in. Without complete buy-in on your SharePoint solution from everyone from the CEO on down, you might as well put your IT budget on Black-13, spin the roulette wheel and hope for the best. Assuming you're not the gambling type, just how do you tackle the training of your company in SharePoint? Who are the key players that require their own unique educational approach? In this post, we will begin to take a look at a typical SharePoint rollout, the roles involved, and what each role should know.
Unfortunately, many companies fail to include one of the key roles in any SharePoint rollout, upper management. Don't get me wrong, I'm not suggesting they are purposely kept in the dark. It is more about the level of engagement. Your CEO sets the tone for the company and everyone else tends to follow his or her lead. If the CEO doesn't completely understand the value, or the ROI, of their SharePoint solution, they will more than likely take a wait-and-see attitude towards the project...especially if the solution is sold and managed by the IT department.
This attitude will trickle down and soon you will find yourself with a SharePoint site that no one uses or even cares to use. Why bother? No one has any "skin in the game" as they say. Proper education of your executive team is important so they understand how their company will benefit by implementing SharePoint. Once they are on board, they will insist that each department be on board as well, and so on. So, does the CEO need to become a SharePoint developer? Of course not. But they need to see the big picture and understand the challenges that your SharePoint project will overcome. Ok, you have upper management's buy-in. Who's next?
There can be up to four architects required for a SharePoint implementation, depending on the size of your company. Smaller organizations might consolidate the architect roles into just one or two. The two most important architects are the:
- Business architect - This person is focused on the business needs of the company and the business problems that the SharePoint implementation is trying to solve.
- Technical architect - This person is focused on the technology requirements. The technical architect needs to work with the business architect to make sure the organization has the network infrastructure and resources necessary to support the SharePoint implementation.
The other two architects who should be involved are the process architect and the infrastructure architect. Once the business and technical architects iron out a plan, the process and infrastructure architects start working on how to implement it using the available resources.
- Process architect - This person develops the business logic to support the plan and may even get into where the business logic resides, such as workflows, custom applications, templates, etc.
- Infrastructure architect - This person works on the network and server requirements. Do we need more servers? Can we provide adequate security? How can we insure high availability?
Do these architects need to understand SharePoint? Absolutely! But here's the key. Most companies don't go far enough in getting the people in these roles sufficiently up to speed on all that SharePoint has to offer. Remember, SharePoint is a framework. This means it comes with an infinite amount of uses and many ways to implement. A common mistake is not thoroughly investigating the options available, and therefore going down a road that is misinterpreted as the only road available. It is common for a SharePoint implementation to be crippled right out of the chute due to poor architecture. The cure...training, of course. Architects that have gone through a detailed, structured training program are more likely to work better together and come up with solutions that lead to a successful implementation of SharePoint. And in the end, this will draw out the architects' buy-in which you needed all along.
Different companies label this role differently, but for the sake of this blog I'm going to refer to this particular role as champion. Most companies do not have, nor do they really need, an abundance of architects. But what you'll find is that once the solution is deployed, everyone wants access to the architects. SharePoint is not a trivial solution and once things roll out, there are few people that really understand the solution at a high level. And unless you have a cloning device tucked away in your back pocket, you're going to need more people to support the solution. Champions are the ones that understand SharePoint at a high level and are usually trusted with administrator rights on the servers.
They are then available to assist departments with site creation, security, major functional changes in business logic, and the like. It is also common for companies to assign the role of SharePoint Site Owner to these people as well, depending on the overall size of the company. These roles have a lot in common. Clearly this role also requires getting up to speed in SharePoint. Just like with the architects, the people in this role will need a detailed understanding of SharePoint so they can effectively build and configure sites that are aligned with the goals of the company. With champions on board, your chances of a successful SharePoint rollout are greatly increased.
These roles provide you with a solid foundation to begin building your SharePoint implementation. Education plays a critical role here because it allows efficient communication to occur between all your major departments. When everyone understands the power and wide range of features that SharePoint brings to the table, great ideas and great solutions have a chance to come forward. In my next blog, I will dig into five more roles that are critical to a successful SharePoint rollout: Administrator, Developer, Designer, Business/Power User, and SharePoint Site Owner. Stay tuned...