Posts tagged ‘governance’

Something that has been truly bothering me lately is recruiters or project managers or executives not knowing how to staff SharePoint Deployment projects or staff their Operations teams that support SharePoint. Too often I receive calls from recruiters looking for SharePoint “Technical Resources”. Rarely are they looking for people who know how to analyze business processes or manage enterprise information management platforms like SharePoint. It seems recruiters want hands-on resources who write code and do everything else including administration and configuration. Unfortunately looking for a jack of all technical trades is just not the best way to minimize risk when it comes to your enterprise application deployment. I’ve seen too many implementations that have gone wrong or ended up simply re-creating the information mess that already existed in the organization.

So let me outline the resources required for ensuring success of your SharePoint implementation. It is important to note that these resources do not simply go away once you have completed phase I of your global deployment. Each one will be required for ongoing governance of operations and continued solutions development and support of business needs:

Program/Project Manager – an individual who not only knows how to manage IT projects, but also understand ECM, information architecture, software and solutions development, IT infrastructure, etc… They don’t have to know how to write code or know SharePoint administration hands on. They do need to have some “technical acumen” but they also need to evangelize the solutions to both end users and senior executives. They need to know how manage and govern an application like SharePoint and have discussions about backups,restores, failover, disaster recovery, taxonomies, etc. They also need to understand communications, collaboration, knowledge management, business process improvements, ECM, web 2.0 — all the capabilities that an organization might leverage with SharePoint.

Systems Analyst – Having the word “SharePoint” on this resource’s resume is just not required. There are sooooo many GREAT system analyst resources that I have met who seem be stuck in their current role between IT and the Business. Perhaps they’re in a Big 4 Consulting firm doing QA work on some legacy or ERP application or custom web development for some large Fortune 500 client, drafting business requirements documents, or working late nights with offshore development teams. All of these individuals I’ve talked to seem disenchanted with their current role, see little career growth, are tired of their current technology focus, and are looking for the chance to work with an application that the sex-appeal of SharePoint. It really doesn’t matter if these individuals know SharePoint or have seen it. Let me repeat that: It really doesn’t matter if these individuals know SharePoint or have seen it. If they are experienced with any enterprise application, the skills are all transferable. This role is so critical in SharePoint’s success because someone needs to work with the end users and business to understand their needs, map out the requirements and workflows, wireframe site designs, get hands with SharePoint Designer and do light customization and design of sites, and provide QA. However, there is no reason why this resource needs to know how to write code. They just need to interact with the business and developers ensure what is delivered to users has some level of quality and actually matches the requirements identified upfront in the project. Lastly, a systems analyst is not someone who simply leaves once the initial deployment is completed. This person will be needed for ongoing requests by the business to develop solutions on top of SharePoint. So many companies have way too many internal processes that are paper based, inefficient, or handled over email….that a systems analyst resource will be busy for at least the next decade.

Solutions Architect and Jr Developers – Okay, so here are the resource who knows how to write code… .Net, visual studio, etc. Maybe you offshore development and if you do, that’s fine. However, you better have really really good system analysts and project managers to manage that development and provide the interface and QA to the business — especially if there are language barriers to manage. Don’t expect these resources to know how to configure SharePoint, install it, or do any administration whatsoever. However, it definitely helps if they do and can guide your organization in their deeper taxonomy planning, security, and high-level solution design. Do expect they know the SharePoint object model, know how the performance impacts of developing point solutions on top of an enterprise infrastructure.

Information Architect – Expert in ECM and information architecture. You’ll pay a premium for this resource, but it’s worth it. Most deployments overlook the need for this person. Maybe they have worked with other ECM applications like Filenet or Documentum. Knowing SharePoint is useful, but not necessarily a must have. If they have 10+ years experience with ECM applications, they can learn SharePoint’s model very quickly. In fact, most Documentum or Filenet or Lotus consultants I know who have 15+ years experience all say the same thing — they’re doing exactly what they did 10-15 years ago — just at an enterprise scale and with SharePoint.

Systems Engineer / SharePoint Administrator – a Windows certified resource preferably. Someone who knows how to install, configure, secure, troubleshoot IIS, OS, hardware, Virtual images, and network issues and in a global WAN or extended extranet environments. When users can’t access SharePoint, you will not only need a really competent resource here — but you will be buying them drinks often!

DBA – SQL Server experts who should learn how SharePoint stores data and files, how to care and feed for it, limitations, and even options for storing files outside the database, etc…

So don’t understaff your SharePoint project. The ROI is real and you’re making a mistake if you think you can offshore everything or pay a junior resource $40 or $50/hour onshore. While some of these roles might be filled by a single person, you will likely pay more for someone who can wear many hats — and you should pay more for 1 person who addresses multiple needs (that normally would be addressed by multiple resources). In this world, you get what you pay for….so don’t risk an information mess in your SharePoint deployment. Get the right resource with the right skills for the right job….and yes, I’m available if you need help! 🙂

At this week’s J Boye conference in Philadelphia, I joined a panel reviewing some of the “hot topics” from the event. As you might expect at a gathering of web and intranet managers, the issue of governance kept recurring.

We could debate what governance means — I define it as consistent structures and processes for making effective decisions — but everyone agrees governance is critical to long-term success.

I don’t claim to be an expert on website and IT governance, but after a couple decades of helping people make technology decisions, I’ll boil down my thoughts on the topic to one simile:

Governance is like sex.

•People tend to talk about it more than they do it, and…
•…Most people don’t do it as much as they’d like
•At least one key player needs to really want it or it will never get started
•There are many different ways to do it satisfactorily
•It’s more art than science
•It’s more successful in environments characterized by mutual trust
•Other people can give you a lot of good advice, but only you can make it happen
•You may not get it right at first, but that shouldn’t stop you from trying
•A shared sense of fairness encourages repeatability
•In the end, bad governance is better than no governance at all
So hopefully at least by now you’re smiling. If you have any particular (but not X-rated!) governance success stories you’d like to share, please chime in via the comments below.

It’s been a long time coming and I finally thought I’d spend the time to focus on SharePoint Governance. The explosion of this platform…and it is indeed a platform…has been a challenge for many organizations. High growth, inability to audit access, outdated content, lack of policies are all issues that many organizations have encountered with SharePoint. As a result, there are security risks, duplication of effort and resources, silos of information, lack of business continuity planning due to the absence or enforcement of proper governance around SharePoint. And most of all I simply hear that users can’t find anything in SharePoint!

To date, I have yet to see a really good set of guidelines or framework around governance and SharePoint. There’s some material out there but it just doesn’t encompass what it takes to deploy, manage, market, and govern SharePoint in its entirety — and simply miss the point of governance. So I’m going to dedicate the next few blog entries to the topic of SharePoint governance.

What is governance anyway? I’m not sure there is a one exact definition of the term governance in relation to SharePoint. SharePointJoel had a good working definition of governance which I’ll paraphrase and add my own spin to to it:

Governance uses people, process, technology, and policies to define a service, policies, roles, responsibilities, resolve ambiguity, and mitigate conflict within an organization. It’s about balancing IT control & security with user adoption and empowerment.

Governance

Ultimately, good governance will help prevent organizations from creating an information mess … which is what many have today. And setting up and enforcing proper SharePoint governance is intended to maximize and optimize the investment in SharePoint by setting a foundation for:

1) User adoption and empowerment

2) Ensuring the management, integrity, findability, security, confidentiality, and availability of information as an organizational asset

3) Proper usage of the application

When I approach a conversation about governance of SharePoint with clients, I break it down into four categories – each of which I’ll define in more detail in future blog entries. The reason I break it up this way is because you can manage this thing called governance more easily and different resources might be required for each category.

SharePoint has unquestionably garnered a lot of attention from business users and IT. Toby Bell, Gartner Inc.’s research vice president, calls SharePoint 2007 “nothing short of a phenomenon.” He says the growing number of searches for SharePoint on Gartner.com indicates high interest in the product and some confusion about its value.

Indeed, the true costs of deploying and supporting SharePoint are not well understood. Fundamental misconceptions about SharePoint prevent organizations from deploying it effectively and realizing its value. Many IT executives view SharePoint as a shrink-wrapped product that can be installed and configured in hours or days. In fact, it cannot. SharePoint is truly an enterprise information platform and must be treated as such. That means SharePoint configuration work needs to be well-planned and designed—not conducted in an ad-hoc fashion.

What’s more, because SharePoint has been popular among users, SharePoint sites have popped up all over enterprises, resulting in what is known as “SharePoint sprawl.” The ability for users to easily create and manage a SharePoint site is one of the product’s benefits, but the subsequent sprawl takes up lots of storage space, increases costs and makes it harder for users to find documents due to inconsistent metadata and tagging.

This article explores the true costs of SharePoint—both expected and unexpected. By gaining a firm handle on these costs, IT leaders will be able to identify whether the product is right for their organizations and will be better prepared to take advantage of SharePoints many benefits.

Expected Costs

When determining the true cost of deploying SharePoint, CIOs need to consider the expenses typically associated with rolling out any new software product, such as the cost of licenses, server software, virus protection, hardware and infrastructure, and IT staff. Here’s a breakdown of the costs IT leaders can expect to incur when deploying SharePoint.

1. SharePoint Product Licenses: Microsoft offers different licensing options for SharePoint. Pricing for each of these options can vary considerably based on an organization’s licensing agreement with Microsoft. In this regard, it is important for IT leaders to determine if they are going to be employing the free version of SharePoint, known as WSS (Windows SharePoint Services), or if they’ll use MOSS (Microsoft Office SharePoint Server) Standard, Enterprise or SharePoint for Internet Sites.

WSS is the base level of SharePoint that is freely available with Windows Server 2003 and above. No client license is needed for it. MOSS Standard offers additional functionality including records management capabilities and enhanced searching. MOSS Enterprise offers even more: Web-based electronic forms (InfoPath on the Web), the business data catalog (BDC) for connectivity to databases, and Excel services for rendering Excel spreadsheets via the Web in SharePoint. Both versions of MOSS require the purchase of a client access license.

The version of SharePoint a CIO selects will depend upon the functionality his or her organization needs, and the cost of those licenses will in turn depend on the number of instances of server software that is running at any given time and the number of users.

2. Microsoft SQL Server Licenses: The purchase of SharePoint doesnt include the cost of Microsoft SQL Server, which is used to store the actual SharePoint content and corresponding metadata. In most cases, companies pursuing SharePoint are already running a SQL Server. If so, the SQL Server database servers could be used, or an additional SQL database may need to be installed and configured as part of the SharePoint server farm. The optimal database configuration will be predicated upon requirements for scale, redundancy and performance. Pricing will vary significantly depending on the configuration and the type of software license agreement a company has with Microsoft.

3. Windows Server Software: All SharePoint Servers will be required to run on Windows Server 2003 or Windows Server 2008 regardless of whether they’re physical machines or virtual machines. The SharePoint farm can be fully contained, run on one Windows Server, or the farm can be distributed across multiple Windows servers depending on requirements for scale, redundancy and performance. Pricing will vary for Windows server depending on the configuration and type of license agreement.

4. Virus Protection and Backup: SharePoint platforms need to be secure. To that end, Microsoft offers a number of virus protection and back-up products specifically geared toward SharePoint. Additionally, a number of third-party suppliers provide virus protection and backup products for SharePoint. The prices for these products vary. They can be user- or server-based or both.

5. Hardware and Infrastructure: The hardware required to run a SharePoint environment includes the actual computers functioning as servers (for MS SQL database, SharePoint Web front-end servers, SharePoint application servers), the disk storage (local or a storage area network), and the necessary networking hardware and workstations. Most companies already have the networking and workstations in place to support SharePoint; what they need are additional server-based components. If SharePoint is being employed over a WAN, for instance, CIOs may want to explore infrastructure optimization appliances, which can be deployed as software running on industry-standard servers or as pre-packaged hardware solutions. Software-based appliances start at $5,000 and hardware-based appliances start at $18,000.

6. IT Staff: The IT staff needed to support a SharePoint implementation will depend on a number of variables. For example, if users are building their own sites and content with basic SharePoint features, the IT support costs will be lower.

However, if an IT department is using SharePoint as a development platform for business applications, costs will increase because developers and quality assurance testers will be needed. Business analysts, project managers, IT configuration staff and IT help desk staff may also be needed. The amount of time these staff members devote to implementing and supporting SharePoint depends on the pace at which SharePoint is being deployed and on how much advanced configuration and development work is needed.

7. Third-Party Products: Like all software, SharePoint is not perfect in that it does not solve every problem perfectly. Tom Rizzo, Microsofts senior director for SharePoint, says that the product was designed to provide a rich set of functionality, and where gaps exist, third-party vendors have introduced specific products to fill such voids. Examples of third-party products include tools for image capture, metadata replication and workflow supplements. SharePoint, more so than any other enterprise content management (ECM) platform, has set the stage for a global market of third-party products. The cost of these third-party products varies.

8. Configuration Management: SharePoint 2007’s phenomenal growth has occurred despite the fact that it doesnt have overly mature capabilities for configuration, replication, and the promotion of changes to code. As a result, additional time should be allocated toward configuration management. The cost of configuration management will be predicated upon an organization’s process for promoting code from one environment to another. For example, for an organization with finely tuned and documented processes, it may take a week or more to prepare this type of configuration management effort for SharePoint.

9. Consulting costs: IT organizations may need to hire consultants to help configure SharePoint’s many administrative options and to help integrate third-party products with it.

10. Quality Assurance: QA testing should extend beyond out-of-the-box functionality to include testing of custom development, the integration of third-party products, and any formal configuration exercises. As a general rule, CIOs should allocate five to 10 percent of their overall SharePoint project effort to quality assurance.

Unexpected Costs

It’s the unexpected costs—the costs that IT leaders don’t think to include into their business cases for SharePoint—that eat into their ROI. To get the biggest bang for your SharePoint buck, factor these expenses into your SharePoint strategy.

1. Governance: SharePoints greatest advantage—its simplicity and ease of use—is often its biggest curse. Because it’s so easy to use, adoption is high. The drawback of high user adoption is that the product is used inconsistently. As a result, design and governance standards need to be created.

Time and effort needs to be put toward developing and maintaining a SharePoint governance plan that outlines the type of content that should be loaded into the system, records policies, standard processes and metadata constructs, and guidelines for approaching and supporting SharePoint projects. IT leaders don’t need to design an entire governance strategy up front. Instead, they should do some initial planning and let their governance standards evolve to reflect changing user patterns.

2. Change Management: After deploying SharePoint, users will need to change their approaches to creating and managing information. Given people’s reluctance to change, a proactive change management program is recommended. This may be as simple as a formal communication from the executive sponsor stating the importance of SharePoint. It could also be an internal newsletter, e-mail campaign to promote the proper use of SharePoint, and “lunch and learn” demonstrations to give people a sense as to how SharePoint can make their lives easier. The costs of the change management effort will vary depending upon its intensity.

3. SharePoint Application Training: Even if your users are familiar with SharePoint, using it to solve a specific business problem (such as automating a contract management or accounts payable process) typically requires some training. Training can be performed by your staff or outside consultants. Since SharePoint’s user interface is intuitive, the training effort for end-users is usually measured in hours rather than days or weeks while SharePoint administrators may need a few days of training.

5. SharePoint Community Participation: The SharePoint community is unlike any other ECM community. It is collegial, always on and continually expanding. On SharePoint Saturdays, for example, SharePoint experts volunteer their time to speak at Microsoft offices. There is no charge to attend one of these presentations, at which hundreds of people gather (a testament to the growing role of the SharePoint community.) SharePoint Saturdays are a great source of information, but should you elect to attend these events or the many SharePoint conferences taking place around the world, factor travel expenses into your SharePoint cost equation.

6. SharePoint Code Management: When development takes place in SharePoint, it should be managed in a controlled and traceable manner. To that end, CIOs should invest in code management and plug-ins for Visual Studio or other integrated development environments that allow for the creation and management of SharePoint source code. The costs for such tools can range in the hundreds of dollars to thousands of dollars.

SharePoint: Worth the Costs?

After digesting all of this information, you may wonder if SharePoint is worth all of the expense.

The fact is, managing enterprise information and processes is not a trivial exercise. More than 80 percent of enterprise information is stored as unstructured content. SharePoint gives structure to that content and makes it easy for users to find and access.

If CIOs treat SharePoint as off-the-shelf software, the costs will indeed be onerous. However, if CIOs treat it as an enterprise information platform and content management system, SharePoint will yield tremendous value—and potentially at a fraction of the cost of comparable ECM solutions.

If you are thinking about your overall collaboration strategy and how to best leverage SharePoint, there are 3 things you need to understand before you develop your approach:

1. What a collaboration strategy is. Collaboration can be both synchronous (real-time) and asynchronous (“offline”). Synchronous collaboration is your web meetings/conferencing and instant messaging. With SharePoint you are mostly talking about asynchronous collaboration in which users manipulate time and space to their own advantage with some degree of independence. Users can work when and where they want without being constrained by the schedules, time zones, or locations of others.

2. The degree of openness the collaboration strategy will address. Is it focused on project teams with a limited number of users? Is focused more on a business process? Is it more open and community focused? or is it focused on the individual and collaboration within their social network? Identifying the degree of openness will help define the scope of your strategy. I’d also include whether or not the collaboration is globally or regionally or line of business focused. This will help provide a focus for SharePoint as the technology incorporates several components from social computing to team sites to portals to workflows, etc…

3. Goals and Objectives – what are the business drivers and what do you hope to achieve? organize and capture knowledge? attract top talent? provide a platform for project management? external collaboration with business partners or clients? is it more document management focused? compliance? executive dashboards? collaborative business process management such as contract management or regulatory submissions?

You can then outline your approach for developing your collaboration strategy around SharePoint. Your approach might include identifying the current state, assembling an advisory panel of stakeholders and their requirements, evaluating SharePoint to determine the fit and gaps, design the high level future state and overall roadmap for implementing the solution.

Identifying the Current State – Take an inventory of the current state of collaboration technology within your organization. Where does the information live? What are users collaborating on? Types of documents and with whom (internal or external people)? How are people collaborating today? Fileshares or email? Externally hosted platforms? Document management system? Some combination of technology? Paint the picture of the current state of collaboration and the technologies involved. I’d also include costs of those technologies if you can identify them. It’s likely you’re spending a total of 6 or 7 figures on several technologies depending on the size of your organization.

Deliverable: Current State Summary

Stakeholders – Assemble a panel of stakeholders (global in nature if possible) and interview or survey them. Ask them how they collaborate, what tools they use, what their priorities are, and frustrations/challenges they face. I’d also inquire about their definition of success if they were to leverage a tool like SharePoint successfully. Does the stakeholder hope to just stop emailing versions of documents and be more organized? Or do they foresee cost savings from process improvements with forms/workflows (more of a six sigma approach). Draft a generic requirements list for SharePoint (including features like calendaring, workflows, secure team space, etc..) and get feedback on it.

Deliverable: Stakeholder Requirements Summary and a High Level Requirements Table.

Evaluate SharePoint – Once you understand the current state and have spent time on stakeholder requirements, it’s time to look at SharePoint. What components of SharePoint do you need? Will SharePoint address requirements out of the box? Where is room for customization or branding or workflow/forms development? Does business intelligence fit into the picture pulling data from ERP or CRM or datawarehouse systems? Look at the features & functionality of SharePoint and develop. If you don’t know SharePoint well, you’ll need some outside assistance from a technology consultant or your Microsoft Sales Engineer.

Deliverable: Fit/Gap Analysis.

Future State and Roadmap – Design the future state both at a high level functional/conceptual perspective and technical architecture level around SharePoint. Try to focus on the ideal state as the vision. This would include all the components you might need (base architecture like web and database servers as well as BDC, excel services, or forms). You might already have a SharePoint implementation in place. However, the current state will tell you if you have all the right components to meet your stakeholder requirements. The roadmap will provide the game plan to get you from the current state to future state. Break it up into phases and try to keep it simple if you are first deploying SharePoint. The first phase should build the baseline infrastructure for future phases. You can’t build a house without the foundation first. Subsequent phases can include expanding the deployment. I’d also focus on 1 particular

Deliverable: Overall Collaboration Strategy Document including sections for the executive summary, the current state summary, stakeholder summary, requirements, fit/gap analysis, your future state/roadmap, and of course costs and risks.

Depending on the size of your organization developing a collaboration strategy around SharePoint might take anywhere from 10-12 weeks — if you do it right. Investing in this type of planning will help maximize the ROI of SharePoint and set the foundation for a successful deployment. In my next series of blog entries, I’ll tackle the topic of SharePoint Governance. The is a lot more technical information on SharePoint on the web, but not enough on governance — at least not enough comprehensive information.