This is another in my 8 things series. And another anonymous posting to protect the innocent (and the guilty). I can vouch for the credibility of the author, but am sworn to protect his identity. This article focuses on the obstacles encountered by external consultants as they work to implement a SharePoint project -- and how they can avoid these pitfalls.
The posting was inspired by a previous popular one by an anonymous end user (Mona Lisa), 8 Ways to Kill Your ECM Project.
Before consulting on any SharePoint project, a little detective work on the IT department can really pay off. One reason for this is that SharePoint has the reputation for being a "disruptive" technology. Let's deconstruct what this term means with respect to IT office politics before getting to the wrecking strategy detailed below.
First, we must acknowledge that SharePoint doesn't really fit any of the standard categories used to manage IT applications. It's not an ECM system in the sense of being exclusively focused on that function alone, though it can be used to manage content. It's not a search engine, though it can search across many types of content. It manages web content, but it manages lots of other content too. And finally, the straw that we always grasp at, it's a "collaboration" platform which is fuzziness itself when bean counters try to measure its ROI.
The ability of SharePoint to break IT boundaries is often at the root of the fear and loathing it inspires. For many, SharePoint challenges the inherent constraints that give IT processes whatever security and predictability they currently have. SharePoint lays bare these constraints, or, more diplomatically, standardized controls, in a way that often causes IT pros to deploy passive-aggressive strategies that sabotage their own ship. These strategies resemble those carried out by those disgruntled French railway workers who brought the whole train system to its knees simply by following a few neglected bureaucratic rules, like carrying out thorough bridge inspections before any bridge could be crossed.
It's a form of organizational jui-jitsu designed to stall projects that threaten the IT comfort zone. So, what are the key practices that foster such disasters? First, couple of definitions. The "infrastructure team" means the permanent enterprise operations staff. The support team signifies the permanently staffed technical personnel that supported and maintained enterprise applications, as well as developed new functionality during on-going projects as assigned by management.
So what are the most likely mistakes that are made in dealing with internal IT staff?
8 Ways IT Politics Can Wreck a SharePoint Project
1 -- Use a non-technical term to describe your server when conversing with the system administrator.
It takes only one mistake like this to land you in the same bin as project managers and sales people -- those who have to be heard but never listened to. If you find that your emails no longer get responses, even when you request specific operations, this may be the reason. Once you are marked in this way, it will take much more effort than is available in a high-pressure SharePoint project to get you out of the bin.
2 -- Imply that network issues may be the root of SharePoint performance problems.
Performance and stability issues always move the project team into the bulls-eye of suspicion.
Who knows what can happen once untested code leaks out. And aren't you the same goof-ball that already confirmed your lack of systems knowledge? What an interesting idea you have. We'll discuss it among ourselves at the next Change Board meeting and get back with you.
The solution to this dead-end is to find a procedure that allows you to identify the network bottleneck. Unfortunately, this means troubleshooting a network that you played no part in setting up and whose documentation is safe from your prying eyes. Fortunately, the system administrators will usually realize at some point that the network really is the issue and come up with a fix, usually right after you have lost 5 days of project time searching for nonexistent object disposal errors.
3 -- Explain to IT that SharePoint is a single application rather than a collection of separately maintained applications.
Because of the way application boundaries are drawn, it is often impossible for IT to comprehend that SharePoint sites are not separate applications. They are polite, but they plainly don't believe you when you say that separate sites all share the same database, security, components, and configuration files and really don't require completely separate sets of architectural documentation.
Such documentation, you say, would merely repeat the same descriptions over and over again for each separate "application." They nod their heads, smiling that smile that says, "We understand how lazy you developers are, and we sympathize, but we can't make an exception for you just because this will result in a monumental waste of time and eat into the functionality you are required to create for your customer."
4 -- Involve the support team in the detailed design of your SharePoint solution.
Though infrastructure and support people may have no SharePoint experience, they often insist on being included in the detailed design of your solution. During these discussions, they will ask penetrating questions such as "Have you thought about what will happen if documents are added to the system?" or "What will happen if users don't use the system the way you trained them to?" This latter question is always asked with a menacing glare that suggests that you have failed to devise a sufficiently severe method for punishing disobedient users.
5 -- Form a governance committee by getting your developers to convince end users to join.
Professional .NET developers tend to have the social skills of Vlad the Impaler. However, if the project managers don't accept the responsibility to form a governance committee and the business owner doesn't have time to do it and it's not the IT department's responsibility to help (in any way), then it's up to Vlad or Vladessa to add this vital ingredient for any successful SharePoint project. Vlad's RESTful web services are likely to be much more effective than the results of this assignment.
6 -- Make sure that high-level team managers never communicate with each other.
If managers don't communicate about what their teams are doing, then everyone feels less threatened and can carry out their jobs with lots more "Cheers" at the ends of their emails. So be sure to identify the most-overworked developer on your team, the one who does most of the actual work of creating solutions, and assign him or her lots of extra communication tasks. Use any means necessary to keep his or her attention off improving the quality of the code so that they are not such narrow and dull bar companions. By pushing communication duties down the chain, you ensure that those with the least overall sense of company dynamics have the most influence. And in a double win, you ensure that no synergies between teams can be leveraged.
7 -- Make sure no one on the support team has time to read project documentation.
The less they know about your project, the easier it will be to criticize. Therefore, since the goal of the support team is duplicate as much existing functionality as possible, keep them so busy on competing projects that they can never learn the project's applications. That way, when they're asked to support it, they'll have the ironclad excuse that they are too busy on another project that meets the same requirements already implemented by the SharePoint project team. Customers love to hear that the expensive project they just paid for needs to be redone correctly.
8 -- As soon as the support team sees that SharePoint is gaining acceptance, set up as many competing projects as possible.
Nothing succeeds like success. If users like the functionality SharePoint provides, then they'll like it even more if it's provided on an obscure, unfriendly platform that only the support team can maintain. Therefore, do development the right way by dividing up the previously delivered SharePoint functionality into parts that fit neatly into your pre-determined IT application types and make each new application into a six month's project. That way you'll prove to those cowboys on the project team the value of proper controls.
So what are the lessons derived from this disaster?
- Get buy-in early from the infrastructure team by anticipating their questions and concerns and making sure that they hear your questions in their language.
- Clearly communicate the infrastructure requirements, expectations for operational support, and other project issues. Get the necessary feedback about key project enablers such as network support. The time to identify network issues is at the beginning of the project, not the morning after the first release to production.
- Demonstrate how SharePoint works by giving the support team a virtual image that they can study to attain the necessary comfort level with what your team is producing. Once they begin to buy into to the SharePoint model, whole categories of bureaucratic meddling can be eliminated.
- No matter how busy you might be on project work, communicate and over-communicate with the support team, but do it in a way that maximizes both of your strengths. Your strength is your detailed knowledge of the team product. Their strength is their knowledge of the organization and the history of previous projects and what it takes to support them.
- Governance is not only crucial to a successful SharePoint implementation, but it can be a major enabler of user commitment to the platform. Having said that, the politics involved in gathering together a worthwhile working committee are often beyond the influence of anyone on the project team. The lack of commitment of organizations to governance best practices is one of those issues inherent to the way modern corporations are structured. In most cases, the best hope is that one of your team is persuasive enough to make someone at the C-level support the initiative. Governance is something they understand and service on the governance committee can be rewarded in many ways.
- Lack of communication between team leaders is very difficult to remedy at the lower levels. Someone needs to coordinate across teams to ensure that they are not competing with each other in a destructive way.
- Rather than creating voluminous documentation, find ways to demonstrate the product through demonstrations. In the modern IT environment, the chances of anyone reading project documentation other than in an emergency are close to nil.
- Make sure that the support team understands that your project will add to existing applications - not replace them. Your team's very existence may be interpreted as a sign of inadequacy. A persuasive case must be made that your team has been brought in to add new functionality that can best be provided by the SharePoint platform - and that the support team can use this as an opportunity to expand their skill set. Any planner worth his or her salt will make sure they thoroughly appreciate this.
Some other posts that may be of interest...
- 8 things you need to know about SharePoint governance
- 8 things SharePoint 2010 needs to be a true ECM system
- 8 more things you need to know about SharePoint
- 8 things to consider when implementing SharePoint with another ECM engine
- 8 ways to use SharePoint for social computing
- 8 things you need to know about automatic classification and metadata tagging in SharePoint
- 8 things to do to make content more findable in SharePoint
- 8 ways SharePoint help in Enterprise Governance, Risk and Compliance
- 8 things to consider when selecting an application to scan or capture into SharePoint
-
8 Ways SharePoint 2010 Moves Toward "ECM for the Masses"
-
8 Things You Should Know About Transactional Processing in SharePoint
- 8 Ways To Benchmark Your Collaboration Strategy
Recent Comments