Time and time again the Salem strategists encounter a particular issue with client IT departments which is the overly-cautious approach to changes within the SharePoint environment. Clearly solid farm configuration and administration is essential, and fundamental changes to infrastructure and configuration 'on the fly' with little forethought are to be avoided at all cost. Hence change management protects the IT department and it's employees.
However, SharePoint, when designed, scaled and built properly is designed as a dynamic and agile platform for a wide range of business service opportunities hour-by-hour, day by day. Thus it is not a question of whether there are IT change management processes, but how they are used within the realm of SharePoint service delivery.
For SharePoint to be successful in most business scenarios, the ability of a business user to generate a temporary workspace or team site, for example, with no IT involvement is a very liberating and powerful experience, and one that sells SharePoint across the diverse business communities quickly. On the other hand, routing a business user through a long-winded process of justification for what may be only a temporary requirement is hugely frustrating and challenging and it won't take long for the business users to use something else.
An IT department is often an orderly, considered, diligent and deliberately process-driven environment. However few business users can really come to terms with why they can upgrade their desktop at home in less than 60 minutes but it takes an IT division 6 months or more to achieve the same result. Of course we know why but it is important for an IT department to be seen as a dynamic facilitator meeting business objectives rather than as the hurdle that prevents the business from adapting and succeeding in a challenging market.
SharePoint, when approached correctly is one of an IT department's greatest allies. Simply because devolved solution provision to the business community makes business users feel far more in control and also because IT is seen as the facilitator. Yet this is often not the case.
There are a couple of important reasons we regularly encounter. The first is that the IT department is treating SharePoint as if it is like all the other platforms and applies the same change control processes when they are in fact inappropriate to the nature of the platform. The second is that change control is used to deliberately control a slow release of services due to the fact that the IT department is worried about the in-house skill levels and also being found out as not being fully comfortable with devolution of service. Ownership is power !
The primary issue is one of embedded IT culture where we encounter IT teams stating that they have always worked this way and they always intend to, and that business administration of business services would quickly cause technical administration and management problems. This isn't entirely true and where each site collection has been properly designed and a quota applied then business devolution can indeed occur.
The advice that Salem offers is that to succeed with SharePoint it is essential from the outset that any IT department takes a completely fresh approach to SharePoint and how it will be used by the business community and which services can be exempt from change control and passed over as agile user-driven services. Once these services are freed from IT change management then the business users can be better informed and trained to create services as required and as their needs dictate. It is always interesting to watch the reaction to a very formal and heavily controlled environment when we show how Office and Outlook can provision user-driven temporary workspaces without any IT request. Similarly, should a business user customise their desktop icons, or aspects of Excel or Word, does anyone care, not usually. Therefore why should an IT department be overly concerned about the provisioning of a team site and what it is being used for ?
For those IT departments who rigidly apply entrenched change management processes to SharePoint, they are missing one of the most intrinsic and fundamental aspects of the platform which is the fast and agile ability to create something new and useful in seconds without a great amount of technical know-how. Put that back into the hands of a technologist and one has just stepped back a decade - it's really that simple.
This article was published without a change request.
