Trying to decide what to post about after a long hiatus…
What is SharePoint?
“SharePoint is increasingly an eclectic kit-bag of publication and collaborative tools, services and features that can be used somewhat like a Lego set to build technology solutions driven by business need. Receiving SharePoint for the uninitiated is rather like being given a toolkit as a gift. The first question would be: what do I do with this? Build something is the answer. Build what? Whatever you want or need to build. I’m not sure what I want, is there a blueprint or plan? No. Can we build what someone else has built? Sure. Can you help us build something the same as someone else has? Sure yes. How much will it cost? It depends what you want, we will need to discover what your specific needs are. Yes but how much will it cost as a ball-park figure? It depends on what you want. I want what everyone else has! Ah but everyone else is different so we cannot tell you how much it will cost and how long it will take until we have defined your exact requirements. And so it continues…
“In other words, the SharePoint toolkit is powerful but without a logical, progressive business plan, blueprint or roadmap alongside SharePoint is extremely difficult for a business audience to imagine in terms of a future, valuable whole. Business stakeholders have a requirement to describe SharePoint to their own internal audiences and this is frequently where initial problems occur. They call in a Partner to demonstrate the value of SharePoint in an hour. What is all too often described is a technical demonstration of a team site, or a workflow, or a form, or version control etc. SharePoint is being described both by some isolated features, and in isolation of a fuller business context.
“This issue regarding describing SharePoint is often anticipated by Partner Sales Managers prior to a client presentation by requesting some specific problems the business may be prioritizing and basing a pitch and demonstration regarding how SharePoint can solve these specific problems. Therefore SharePoint, as an enterprise platform, is all too often described in these situations primarily as a project-specific technological solution. What happens when that problem is solved – where does the client go then, what does the business do next, what else can they build? And so we come back to the same dialogue as before. What other problems do you have? What other priorities can we assist you with? How much budget do you have? It is because of this scenario, played out hundreds of thousands of times globally that a number of things have occurred that have assisted in defining SharePoint in a specific way. The first is the flexibility of solution design and delivery. This has led to SharePoint rather frequently being described as a ‘development platform’. ‘Tell us what you want and we will build it’. Ah, says the client, but we don’t know what we want. ‘It’s okay’ says the platform developer, SharePoint can be used to develop and provide you with anything and everything you want. Within a short space of time of the introduction of SharePoint solutions are being built without any form of business plan.”
IT departments must manage the entire SharePoint platform, ensuring long-term stability, security and integrity for the enterprise. The business just wants what they want! This can result in dissatisfaction on both sides. How does your company resolve this conflict?
Companies using SharePoint for end-user collaboration need someone who stands in the gap between IT and the business to broker that often tenuous relationship. This is usually assumed to be a business-side role. However, it’s much more appropriate for it to be a SharePoint role.
Before SharePoint, my background was in business process improvement and project management. I did not start out in IT at all. I was not a developer, programmer, engineer or system administrator. I took on SharePoint in the context of another initiative and quickly discovered its vast potential. I was fortunate to be able to make a career change and spent the next 5 years immersed in SharePoint, dramatically increasing my skill set.
Without the options of coding or development at my disposal, I learned how to get results by pushing the envelope and exploring the platform’s native options. Along the way, I also increased my knowledge of the IT side and built strong relationships with those responsible for the “care and feeding” of the platform. We quickly learned the value of what each side brought to the table. They appreciated the presence of someone skilled in speaking both languages. I interpreted “SharePoint-ese’ for the business; I also translated requirements and pain points into well-designed, quickly-deployed sites & solutions. These solutions delivered valuable return on a (sizable) SharePoint investment without spending a dime on development. I can also walk into any meeting and speak clearly and intelligently about SharePoint to stakeholders at all levels.
Do you have such a person on board? Don’t you wish you did?
From a technology standpoint, SharePoint is something of a latecomer. Those who currently make SharePoint their career have, by and large, come to it from somewhere else. Most were already in IT- usually developers/engineers/system administrators- who continue to focus on those areas as they extend into the SharePoint space. This tends to cause a “development approach” to solving SharePoint problems which is not always conducive to building a strong relationship with the business side. It can delay delivery of solutions and sometimes negatively impact upgrade paths. My strengths offset that risk.
By first exploring all “in-box” options to their fullest potential, companies can be assured of getting the most bang for their SharePoint buck. The vast scope of features built into the product practically demands such an approach to truly realize that investment. Before throwing development dollars at the problem, don’t you owe it to yourself to see what might be possible?
It’s amazing what SharePoint provides out-of-the-box! There are so many tools and functions are already there, just waiting to be leveraged. As previously mentioned, this approach also helps ensure future compatibility for upgrades, patches and service packs. Even more importantly, such methods are much easier to make transparent to end users. Handing over a “configured” solution often means that your users don’t need to come back to IT for enhancements down the road- with a little education, they can make many change or repairs themselves. It’s vital to take advantage of every opportunity at hand to strengthen the business partnership.
That’s MY SharePoint role. What’s yours?