Large SharePoint implementation and upgrade projects are the nightmare of many corporate boardrooms. Decisions regarding goals for the organization concerning how SharePoint should be used, internal misunderstanding about the need for a business process overhaul and entrenched resistance to change all create friction among the CEO, CFO, CIO, vendors, consultants and users. Costs escalate as scope creep takes over and the capabilities of the new system are modified to accommodate current rather than optimal procedures. The result is that another project runs into red ink and IT gets another black eye. Industries reports show that cost overruns of 1 million, 10 million, even 100 million, are the reality of attempting to change mission critical SharePoint and systems.

It doesn’t have to be this way. Here are some observations that keep a SharePoint implementation project on track.

Many people believe that a new shiny SharePoint platform is a “magic potion” that will fix whatever glitches there are in the way people work in the organization. They assume that after installation, profits will be up, down time will be decreased and productivity will have gone through the roof. That is not the case. If the current process for tracking an invoice or managing customer relations is inefficient, then simply putting in SharePoint will merely speed up a bad process. Customers wind up getting duplicate mailings in two days rather than three! The first step in any SharePoint implementation must be to find out how things are really being done in a department and not what the training manual describes as the process. This is called ‘Making sure SharePoint meets User Requirements’. Then, changes can be made to design the optimal process to achieve success using the new technology.

SharePoint adoption requires that users alter the way they have always done it. This means leaving their comfort zone and people don’t like change. They tend to resist, complain and often, leave the company. Unless the users are involved from the beginning, a new acquisition is something done to them and they feel powerless. The people doing the work are invaluable assets in the task of trying to make their job more efficient. Make sure that you define SharePoint Governance, engage with your users both business and technical looking critically at user requirements from both camps.

The best and the brightest from each department make good working partners with senior management when choosing new systems. That way, no one gets surprised by the costs in terms of money or effort when implementation time comes around. Creating a cooperative atmosphere, of course, is key to making this work. Buy–in doesn’t happen automatically. Often, the attitude of line operators is that their presence is merely window dressing and that the senior managers will make the final decision regardless of their input. A skilled facilitator is necessary to get past this distrust. You need an evangelistic Project (or depending on the scale of the technology release – if SharePoint and other new technologies are involved, a Programme) Manager to enhance client understanding and create a vision using ‘SharePoint Project Mantra’.

It’s easy for the user or client to be overwhelmed by slick SharePoint presentations, particularly when the presenter is talking about things that most people don’t completely understand. Showmanship gets in the way of real capabilities. Unless the review team is judging each vendor against the same list of needs, with the same understanding of the significance of each rating, “likeability” can win over capability. Make sure you use people who can get interactive with the users – Business Analysts are very important in making sure that as well as demonstrations being provided that they can illicit responses from the client and users. The purpose of interviewing is learning on both ends – the client / users learn about the platform, the interviewers learn about what the client / users do and what they need from SharePoint.

Generating a list of requirements is hard work. If the team hasn’t bonded before these discussions, a power struggle ensues, with each faction holding out for its own “essential” specifications. An outsider with no ties to any internal group is usually better able to bring about consensus than someone from the inside. The overarching goal is to produce a list of standards that support the mission of the enterprise. The more immediate goal is to create a unity that transcends the narrowness of each participant’s vision of that mission. The team meeting that follows each presentation must reinforce the common purpose while giving everyone a chance to voice their understanding or lack of it as well as their concerns.

Creating SharePoint requirements means multi-solutions to multi–criteria problems. Every business wants high quality, easy–to–use SharePoint that gets implemented instantly and costs next to nothing! Of course, that doesn’t exist. It’s the actual frontline users who will be responsible for making the new system add value to the enterprise. Even if management do not provide their requirements, the project will proceed faster, more efficiently and with a better result if the frontline people have a real voice in the selection. Getting their buy-in at the start seems like a delay, but it results in a shorter, better project in the long run.

Getting agreement on system and user requirements is an art as well as a science. It involves communication between people who have many obstacles to clarity of meaning. It is a frustrating process, but when done right, it is the foundation for success. When the people who will be most affected by the change are motivated to have project success and see the value to them as well as the company, then the requirements will be an exciting design adventure, not a boring, confusing chore. The key is training the parties in communication and team effort. With both knowledge and practical exercise, you can build the team that will succeed.

Success means everyone succeeds. The users, company management, implementation partners and the SharePoint / hardware vendors must all achieve common success – or all fail. When the entire company team agrees on vendors and implementation partners, the road is much smoother. When the vendors, implementation partners and company team are adversaries, the road leads to disaster. Everyone must believe that success requires everyone to succeed.

Change management is a process, not an event. It should occur continuously throughout the course of the procurement and implementation. Management should not assume that everyone is going to accept the new system without a great deal of preparation. The selection and implementation teams have been consumed for significant time with bringing their project to completion. However, it hasn’t even appeared on the mental radar screen of most users unless there is a deliberate effort to raise awareness of the coming change. Because people don’t like change in general, it’s hard to introduce a particular one without having changed their initial attitude about the concept. This is the first and most essential level of change management. After that has been addressed, then people are more apt to be open to the detailed changes that will be required. Use SharePoint Governance and create Training and Education strategies to ensure that users will continually engage with SharePoint – SharePoint grows and becomes more an Enterprise platform the more users feel comfortable, become more productive, and feel that they have a stake in the future of SharePoint in the organization.