Think Communities, Not Portals!

If you are planning your SharePoint 2010 upgrade and looking at redesigning the hundreds of intranet sites — stop right there!   Don’t redesign, rethink your corporate intranet.

I spend a fair amount of time with clients discussing the redesign of their sites and in most cases I continue to hear the word “portal” mentioned.   When I think of portals, I jump into my time machine and go back a decade or so.  Portals are plain and generally have static web content with outdated information that is seldom accessed by employees.   Look at your intranet today and it’s likely you’ll see a SharePoint site with all kinds of links that’s not very interactive or relevant to individuals.  Maybe you have top-down executive blog that is posted to once a quarter or once a month if you’re lucky.   If the corporate intranet page wasn’t set as the employee home page in the browser, I wonder how many people would actually visit it?  .  Sound like your intranet?  So what’s the point of upgrading to SharePoint 2010 if you’re just going to migrate those plain boring sites you have today?

It’s time to break away from the traditional thinking of intranet “portals” and design a collaborative infrastructure around a complete “community model”.  What do I mean exactly?   If you compare a community to the traditional portal, you may think it’s just a matter of semantics.   However, the concept of a portal is a push relationship as someone is pushing content to you.  Communities are social, interactive, dynamic, and provide a context for individuals to subscribe, collaborate and contribute to.   Communities source information from the bottom up as well as the top down.  Communities have a pull relationship — meaning the community pulls on users to contribute and users pull on the community to consume.  The fact is that every piece of content and every person in your organization is part of some community whether you realize it or not.  The largest and most open community is everyone in your organization and there are likely hundreds or thousands of sub-communities.   Communities also provide a degree of openness in your organization.  So if the information you wish to share has more defined security requirements, that’s when you manage it in a secure team site as opposed to a community.

Now I know what you’re thinking — “we have to have a hierarchical intranet portal”.   Really do you?  Do you need it to be hierarchical?   Sure you might need a directory for people or sites for easier navigation.  You also need enhanced search capabilities as most people would rather search than browse.   Just think about it — is the public internet hierarchical?   Does Google or Facebook or LinkedIn have any hierarchy?   In comparison, you could look at Yahoo as a traditional portal — static, boring, and a site people rarely view anymore.  And that’s why Yahoo has lost market share and relevance today.

Let’s face it — for many of us Facebook is our “portal” on the public internet  and something we visit 1 or more times a day because it’s social and relevant to us personally.  LinkedIn may be your “portal” into your professional life and network.   Do you really need a traditional hierarchy of intranet sites and portals?   Or is it more important to capture, share, and collaborate on information within the context of a community?

 

How do you deal with the critics and skeptics in your organization?

I recently came across this interesting video of a Harvard Professor discussing selling ideas within an organization (link available at the end of this post).  And it’s no secret that SharePoint requires a fair amount of evangelizing to change people’s behavior, sell solutions, and influence decision makers.  SharePoint is suppose to be a productivity tool – right?

In the video, the Professor discusses tactics the naysayers use such as confusion, fear mongering, or death by delay.   And I can honestly say I’ve witnessed them all — especially when you start discussing the “social capabilities” of SharePoint.  It’s kind of ironic actually that simply suggesting technology to improve the socialization of ideas and business discussions is met with such social dysfunction.  Anyway, the interesting thing I took away from the Q&A in the video was how to address the naysayers.  Professor Kotter recommends thinking through what the skeptics might say and then inviting the critics in to address their concerns head on.  He goes on to say that the discussion (or heated discussion) will get people’s attention — who might otherwise ignore the ideas as a result of our own personal information overload.   And come to think of it information overload itself just might be another tactic the skeptics use — if you like conspiracy theories of course.

Now when it comes to SharePoint and solutions built on SharePoint, I have to question whether or not it’s best to get a group of cross functional (or dysfunctional) stakeholders or business process owners together to agree upon a technology that many don’t understand.  So I’m going to pose the question to the community and hope the readers and lurkers out there might share their experiences or stories on some of their personal or organizational challenges?   Is it legal or compliance concerns?  Political?  Fear of losing control?  Is it mainly social features that raise objection?  Or SharePoint in general?  What’s your SharePoint story?  And how has your organization addressed the skeptics?

Link to video:  http://blogs.hbr.org/video/2010/10/how-to-stop-good-ideas-from-ge.html

Project Information Management

Just about everything we do can be thought of as a project or series of projects.  In our professional lives, companies create their strategic plans and budgets based on a series of initiatives, programs, and projects which filter down throughout the organization.  And collaboration within organizations mostly revolves around the fundamental element of work today — the project.   When you think about using a technology platform like  SharePoint to facilitate the management of things like strategic planning and the project management process, there are a few different levels to consider:

1. Project Manager Level – scope of an individual

2. Project Teams – scope of an single project

3. Portfolio and Project Management (PPM) – more complex and broader reaching scope with executive level oversight

You also need to think about the maturity level and culture of your organization.  How formal is your project management process?  Do you have a formal methodology and certified resources?   Or is most of the work you do project management “light” with some structure, use of MS Project, team sites, and resources who become “PMs by accident”?   Or do you have a formal mature Project Management Office?   Answering these questions will help you think about what technology capabilities you need to help facilitate the project management process in your organization.   For example, the diagram below shows what technology you might leverage depending on how mature your organization is when it comes to PM.

For individual project managers, SharePoint provides a platform to help you share, manage, and secure information.  Fortunately as a PM, everything in SharePoint is really just a list (in simple terms).  And tracking things in lists is core to what PMs do everyday:  issues, risks, requirements, change controls, tasks, status, etc…   Unfortunately, many PMs just don’t understand how to leverage SharePoint to manage project information and use the technology as a communication tool to both project teams and upper management.  As PMs, we continue to use Word tables and Excel and email documents to each other.  We’re held hostage by our inboxes, methodologies aren’t always followed consistently, project artifacts wind up in multiple repositories including SharePoint, and project information and status lack visibility.

With that understanding, there are several things an individual PM can control and implement on a SharePoint site simply by educating yourself a little or getting some assistance from a resource who has some SharePoint knowledge.   If you want to take it one step further, you can begin to leverage your SharePoint site as a “project information management” dashboard as well.   However, I won’t go into more detail here in this post. As a reference, I am providing a link to a presentation (free-to-download) that I gave on this subject with screenshots and more insights:  http://www.slideshare.net/getrichieb/managing-projects-on-sharepoint-rich-blank-july-2010

I want to close by helping you think about what that ultimate vision is for leveraging SharePoint for project information management. The diagram below illustrates this vision.  It starts with information architecture and governance of the PM methodology to define what project information and artifacts are required and what metadata and content types are needed.  Instead of burying tables of redundant information in multiple Word or Excel documents, think about how you can surface those same rows & columns inside SharePoint.  Also, envision the ability to aggregate the project information you are storing in SharePoint lists across all project team sites.  Think about the ability to view and filter critical issues and status across projects, drive analytics and executive decisions based on the information managed by SharePoint.  Think about how you can leverage SharePoint to reduce overall risk of execution and ensure PMs deliver on time and on budget with a high level of quality.

ROI of SharePoint – An Example

In a recent post, I talked about ROI of SharePoint and how there are many hidden “soft costs” within business activities — which are probably not measured in most organizations today.    A good use case for measuring ROI of SharePoint is a set of business activities around managing IT contractors.

Many IT organizations both large and small utilize contractors and consultants. In many global enterprises, you might have several thousand contractors in and out of your organization over a calendar year. The process of hiring contractors and consultants is often times a painful one. It takes weeks if not months, lots of back and forth emails, paper forms and approvals, resumes, interviews, rate discussions, on-boarding, and more… Project timelines are impacted and the demand for IT project requests starts to backlog because it takes too long to get the right IT resource into your organization and onboard. In the absence of an expensive “vendor management” system, the end to end process can seem like a chaotic dance of emails, paper, and documents.

Just as there is a cost in hiring a full time employee, there’s a cost of on-boarding a contractor. Additionally, if you’re not tracking vendors, candidates, or rates, how do you know you know you’re getting the best candidate for the lowest rate? Do you know the average bill rate of your contractors or for a particular vendor? Are you measuring the cycle time for an IT manager to initiate a resource request through the on-boarding? Do you know the dollar impact resource delays have on project schedules and costs? Do you know what metrics you should be measuring at all? These types of questions beg for a solution built on SharePoint to help you manage the information and documentation, communicate status, and report on key performance indicators (KPIs) you indentify to be important to your organization.

Before you even begin to start building your solution on SharePoint, you’ll want to begin by mapping the end to end business activities, approvals, and flow of information and documents. The next step involves developing an “information architecture” with the appropriate content types and metadata you are looking to capture. Part of this exercise involves understanding what KPIs you are looking to measure as that will drive some of your taxonomy. Where possible, you also want to attempt to estimate time and dollar costs of the existing process so you can compare those estimates after you implement the solution built on SharePoint. There are obvious hard costs like the hourly rate of a resource. Soft costs might be the time required for approvals, time waiting for hiring decisions, or interview feedback. There are also less obvious soft costs such as cost of turnover, lost productivity, low morale, lost sales, or missed opportunities.

So let’s look at an example to see how much lost productivity we might find in this example of IT contracting staffing requests:

1. Let’s assume you receive about 2000 IT staffing requests a year.
2. The average processing time for fulfilling IT staffing requests is on average 6 weeks (or 240 working hours).
3. The lost calendar hours waiting for staffing requests to process would equate to 480,000 lost hours per year waiting (2000 requests * 240 hours waiting per request).
4. Those 480,000 total calendar hours divided by 24 = 16,667 days total waiting.
5. Multiply 16,667 days waiting times 8 hours in a day = 133,336 Lost Productive Work Hours Waiting for IT Staffing Requests in this example.
6. The average hourly rate of your employees (those submitting and fulfilling the requests) is estimated at about $55/hour.
7. $55 * 133,336 lost productive hours = $7,333,480 as the Total Cost of Loss in Productivity

Once you understand the end of end process and estimate the current loss in productivity involved in the current set of business activities, you can then begin to set a target such as reducing the request fulfillment time by 50%.  Then you can begin to leverage the capabilities of SharePoint.  The assumption is you probably already have it inside your organization and all you need is your own Site Collection.  The costs are minimal and you can now provide IT managers a place to request resources via a centralized SharePoint web form and self-track the progress of their requests and candidates throughout the interview process.   You can empower the individuals who work with outside staffing agencies to manage the candidates and resumes, present them in SharePoint to the hiring manager and include the in-flow of information and documents all within SharePoint lists and libraries with appropriate metadata.   Managers can enter feedback and executives can approve billing rates.  Lastly, you can begin to report to executives and measure cycle times, average billing rates, and more — all from the data and information captured in the solution built on SharePoint.

Just imagine this SharePoint solution allows you to reduce the time it takes to fulfill IT Staffing requests by 20% or 50%?   In our example, that’s a cost savings of millions that are measurable and easily communicated to executives and business leaders to justify the cost of SharePoint and showcase the value and ROI of the technology platform.

iPads in Business…Scenarios, Use Cases, and SharePoint

Use of iPads in the business world is relatively new and somewhat bleeding edge. Generally, there are a few use case scenarios you might consider. One is for salespeople in the field who want to access slides or documents, or perhaps deliver a presentation to a customer or demo something on a web site. Another is for executives on business trips who don’t need full laptops and might use iPads to access their e-mail, calendars or presentations and documents.  Or perhaps you have a monthly Board of Directors meeting and are looking to move away from paper and digitize the meetings, notes, and documentation to ensure accurate record keeping.  iPads and SharePoint might provide a good solution.   Apple does provide some profiles of a few business use case examples:
http://www.apple.com/ipad/business/profiles/

And another good link with some real world examples I found is here:
http://www.ipadnewsupdates.com/ipad-news/heres-how-apples-ipad-is-invading-the-business-world-aapl-rimm-msft.html

I also recently read about health care provider Kaiser Permanente has reportedly been testing two iPads for viewing X-rays. And Mercedes-Benz Financial has reportedly equipped some car dealerships with iPads so sales personnel can take customers’ information for credit applications without having to sit down at their desks.  Of course doctors, lawyers, retail staff, warehouse workers and other people might use iPads while on their feet and mobile.  We’ll no doubt be seeing iPads at a restaurant near you very soon:  http://mashable.com/2010/05/19/urbanspoon-rezbook-ipad/ VERY COOL STUFF!

No matter what the use case, there are a few considerations when thinking about iPads in a business context:

Browser support.
Most web apps only support specific browsers — and unfortunately Safari on the iPad is not always supported. So if you have existing web apps (or even client-server apps) they wish to access via an iPad, there may be supportability issues depending on what the web app requires on the browser side or the client-server requires — which in most cases is Windows and Internet Explorer.  For example, SharePoint 2007 supports Microsoft Internet Explorer specifically (and is limited in its functionality when you access via Firefox or Safari on a MAC). And SharePoint 2010 is a little more open with browser support but doesn’t explicitly support Safari.  However, there are 3rd party iPad apps recently released this year that can enhance the SharePoint user experience on the iPad.

Wireless Support and Security.
Another concern is wireless support and security. It’s a wireless device — and an iPad would be dependent on the performance, security, supportability, and accessibility of the wireless network.   So you better test the dead zones and accessibility in the physical environment where the tablet devices will be used.

Hardware concerns.
Well documented out there….limited RAM (256mb), no USB ports, etc…   So make sure you understand the hardware limitations.   If iPads hardware doesn’t cut it, perhaps you need to consider the upcoming Blackberry Playbook or other vendors.

User experience.
Think about Starbucks.com for a minute. Access it on my cell phone, I get a store locator presented to me. Access it via a web browser, I get a different experience. The point here is that what you see via a normal web browser may not work for mobile devices or iPad tablets.  So think about the user experience and you may have to present different information in different ways.

UI Design.
One of the challenges with iPads involves the UI design. Because the iPad is a touch device, “normal web pages” may not work best for end users. For example, a contact of mine is actually customizing the site UI of SharePoint a little with larger buttons for users to touch the large buttons and open files more easily. Additionally there is the ipad “pinch” to shrink and enlarge the screen — and some other UI considerations there as well.  Fortunately, there are a few third party ipad apps that enhance the SharePoint experience. I haven’t spent enough time testing them to provide any insight here — and there are more come out as time goes on. Just Google “SharePoint on iPad” for specific apps and vendors.

The bottom line is that any business should identify specific use cases in which they envision potential uses of iPad devices. Look at the business process or value chain, document it, and develop a plan for deployment, process improvement, and change management. Start small with a low risk pilot. Maybe it’s order/inventory on the factory floor or maybe they start by using iPads for internal training just as academia has adopted iPads before the mainstream. At the end of the day, iPads are a hand held device — they’re portable, easy to use with a large enough screen to actually conduct business or transact something. It’s really no different than other technologies and there should be some tangible benefit gained by using iPads (as opposed to using them because they’re cool). While the iPad is definitely the innovator — you might look at competitors like Blackberry Playbook recently announced. More RAM, faster processor, wifi and hooks to uses your existing blackberry mobile phone for wireless data access.   Of course, as much as it’s about the device, the apps are equally as important to drive adoption.  And Microsoft really needs to step up its game and start developing apps specifically for these iPad-like devices to enhance the Office and SharePoint experience.

Why is measuring a hard ROI for SharePoint just so hard?

Traditionally when it comes to implementing technology, the financial bean counters and decision makers have looked for hard dollars for the ROI of a technology investment. However, when it comes to SharePoint, it seems we have thrown a hard ROI out the window. In a manufacturing or factory environment, it’s generally easy to measure hard dollar costs of raw materials or labor costs or costs per hour. Centuries of economic theory and practice led to the pioneering of the “scientific method” in the early part of the 20th century by Frederick Taylor and Henry Ford among others. Implement “robot X” into the assembly line and produce more widgets and save on labor costs. We have also had a few decades of TQM (total quality management) which has evolved into many buzzwords all seeking efficiencies in productivity of manufacturing and supply chains. In Business School, I remember learning all kinds of management theory on these subjects and “generally accepted accounting principles” to calculate hard dollar costs and manage budgets to actual as well as profitability of goods sold. So what happened to measuring ROI of SharePoint and why isn’t there enough written on it?

I have read tons of articles on web 2.0, collaboration, and SharePoint. They evangelize about grand topics like innovation and creating opportunities through communities and connecting people through social sites. Some talk about the vision of enterprise content management being realized at an enterprise level. And some articles even try to address ROI and talk about the “downstream effects” of capturing ideas and information in blogs or wikis. Then we hear from executives and decision makers that evangelizing the technology sounds great, but all the benefits are “soft” and too hard to measure. Okay, so why not measure “soft costs”?

The reality is that all businesses have soft costs such as turnover, lost productivity, low morale, lost sales and missed opportunities. And any combination of those might drive soft cost dollars in your organization which can have big impact on your bottom line — sometimes just as much as the hard costs and other times even more. Many organizations simply don’t measure these types of costs because they don’t understand it or simply don’t have the capability to measure them. Or perhaps people are just focused on meeting deadlines without questioning the value or impact to the customer. Meanwhile, project management within many organizations seems like chaos, deadlines get missed, decisions are delayed, tiger teams get formed, and the insanity of our day to day work life continues. Projects that should take only a few weeks or a few months, takes 12 or 18 months to complete and quality suffers as does employee morale. You continue to wonder why things in your organization aren’t as easy as what we see on Google or Facebook. Then we recharge on the weekend, read the Dilbert cartoon in the Sunday paper, laugh and think of our own work environments, and do it all over again next week. All the while we continue to email each other on our smart phones and at best upload documents to a site on SharePoint. And if you’re paying attention, there are no doubt hidden costs in many of the things just mentioned.

In today’s economic climate, it’s time we take a hard look at dollars and sense and focus on driving analytics from a collaboration & information management platform like SharePoint. In my next series of blog entries, I’m going to focus on making measuring a hard ROI less hard and relate it specifically to real solutions implemented on SharePoint.

Now that I have SharePoint, what do I do with it?

It continues to amaze me how many organizations have SharePoint or go out and purchase it but still aren’t sure what to do with it.  While you could easily show them the SharePoint wheel or talk about features, functions or capabilities…it isn’t enough.   Simply saying SharePoint is a collaboration tool is not enough as “collaboration” itself is such an abstract term.  While you could simplify SharePoint and say that everything inside the application is really a “list” with rows and columns used to track things, that isn’t quite enough.  So it’s usually best to begin the conversation by relating SharePoint to people’s day to day work activities.  The goal is to show people there’s a better way of working than they do today.

Executives and business managers seem to understand ERP & CRM systems, data, reports, and transactional processes.  However, most people don’t realize there’s a whole set of collaborative “activities” that need to happen to actually generate the required data to enter into those transactional systems.  The below diagram outlines this in more detail.   It shows the business activities that occur before, during, or after entering raw data into number crunching transactional ERP/CRM systems.  It’s the top half of the diagram — the “Unstructured Activities” — that SharePoint as a technology platform focuses on.  SharePoint’s capabilities were designed to surface information and address unstructured content, knowledge, activities and the social interactions that take place in business.

Ideally, you’ll want to pick a business process executives and workers are familiar with or processes that touch a painful nerve in those individuals.  Maybe it’s the sales process, or onboarding of new employees, or some other internal operation or customer facing activity.   Have them identify all the Word tables and Excel documents in which they track information on their desktops.  Map out the value chain — the people, emails, documents, activities and workflows, and the points where raw data is used and decisions are made.   Once you do that, you can easily begin to propose and prototype a solution that can be implemented with the capabilities that SharePoint provides.   You can begin to educate people on what’s possible, show them how SharePoint can alleviate some common day to day headaches, and get them excited about the possibilities and changes to come.

Don’t Forget the Change in your SharePoint Investment

We have seen SharePoint sites pop up and virally explode.  We have seen SharePoint used in many cases as a basic document repository.  In some organizations, we’ve also seen SharePoint used for collaboration, project management, or even process improvement.  No matter how SharePoint is used in your organization, you’ve probably taken a standard approach to implement the technology with the typical project elements:

• Identify business need or opportunity.
• Define the Project.
• Design of Business solution.
• Develop new processes and solution.
• Test, implement, and train.

Or maybe you’ve gone one step further properly planning and outlining your roadmap to build out a centralized SharePoint infrastructure with a clear migration strategy for your legacy intranet or fileshares or collaboration spaces.  However, the traditional approach we normally take to deploy technology has resulted in many non-believers and those who continue to under-leverage the capabilities of SharePoint and rely on the old ways of doing things.

Yes, it’s important to create a solid technical infrastructure.  Like building a foundation to a house, you need a stable platform that can scale and perform for users no matter where they are in the world. And yes, you also need good governance of the SharePoint platform to manage and support users and the growth in demand.  While a secure technical infrastructure and good governance are 2 keys to a successful deployment of SharePoint, there is still one thing missing.   A critical ingredient which is not discussed or blogged about much is the change management component that SharePoint requires to break old habits and fundamentally transform how knowledge workers approach their day to day.   When I talk about change management, I am referring to people but not necessarily referring to the social capabilities of the software.  I’m referring to how SharePoint as a technology can reshape the “industrial psychology” of how knowledge workers connect, collaborate, communicate, and actually get work done in today’s service-driven economy.   While there are a number of methodologies and approaches to managing change, there seem to be a few common themes among the different schools of thought:

1. Assess your organizations readiness for change.  Is it incremental or transformational? Are people aware they need to change?  Is there a sense of urgency?  Do they have the desire?  Where is there resistance?
2. Knowledge about the change and vision.  People need to learn new abilities and ways of approaching the same work with the new capabilities that the technology offers.
3. Empowerment and reinforcement.  People need to take ownership and the behaviors need to be reinforced.  There needs to be some short term wins and long term vision and approach to make the change become permanent.

SharePoint needs to be seen as a productivity tool and not just a place to store documents.  For this to happen, building the best solution on SharePoint is not enough.  Training and adoption can’t be an afterthought that happen towards the end of the implementation.  Change management needs to be part of the plan and addressed up front.   At the end of day, SharePoint is a platform that is not just about information management or some broad concept like collaboration.  If you want to maximize your investment, don’t forget the change.  Ultimately SharePoint is about people and the ability to manage change throughout your organization.

Follow me on Twitter…

How to Staff Your SharePoint Project

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!

Storage Engineer – your SAN or NAS experts who understand performance and storage considerations mostly around SQL databases unless you opt to store files outside of SQL.

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!  🙂

 

Three Things to Consider in Your Enterprise Collaboration Strategy

This post was featured on CMSWire.com:

http://www.cmswire.com/cms/enterprise-20/three-things-to-consider-in-your-enterprise-collaboration-strategy-008261.php

Many organizations are planning or are already in the middle of deploying collaboration technology to their global organization. Before you go much further, ask yourself if you’ve identified these three elements of your collaboration strategy.

Perhaps you have invested in a single vendor eco-system like MS SharePoint for collaboration and information management. Like most organizations, you are looking for ways to reduce costs, create efficiencies, consolidate multiple repositories of information, innovate, connect people globally, change corporate culture and simplify the end user experience.

However, your executive leadership is not sure if your organization is optimizing the use of this technology and maximizing the return on your investment. If that’s you and your organization, it’s not too late to take a step back and review your strategic objectives and approach.  A solid collaboration strategy encompasses 3 key things:

1. Define the Business Context

Defining collaboration as synchronous or asynchronous is not enough. Making a decision to invest in SharePoint or Oracle or IBM is not enough. Build it and they will come is not enough.

Typically the best approach to deploying any collaboration technology is having a focused business context in mind. Multi-purpose collaboration platforms offer many features and capabilities. Part of a solid strategy is having a focused business context around social networking, team spaces, communities of practice, crowd sourcing, project management, knowledge management, business process management, etc…

You need to demonstrate real business value and evangelize that throughout your organization to further drive adoption and create a perception of collaboration technology as a productivity tool.

Identifying and applying the technology in a specific business context will help stakeholders and decision makers see how this thing called collaboration can alleviate business pain points, surface information and impact employee engagement and morale.

2. Identify the Degree of Openness

Further expanding on the concept of collaboration in “context” is to identify the degree of openness. Is the collaboration external, internal, global or regional, or line of business focused (depending on how your organization is structured)? Security and user access also come to mind here as it’s easy to create a mess of information within these eco-systems combining confidential information with more public content.

Identifying the degree of openness also includes defining your audience, the type of information you plan to collaborate on, and the overall scope of the collaboration. This will help focus your efforts, deployment, or investigation of collaboration technology as these platforms all offer several components from social computing to team sites to portals and workflows.

When you step back and understand the degree of openness, you may also realize that 3rd party solutions for administration or security just might be a mandatory requirement to protect intellectual property and sensitive information.

3. Establish Goals and Objectives

Project management 101 includes determining what success will look like for your organization. Often times when planning projects, goals and objectives tend be high level and don’t really provide a concrete definition of success. Setting the right goals and objectives will ensure stakeholders, decision makers and users are on the same page when determining if the collaboration strategy is a success.

What specific results should users and executives expect to see?

• Will this solution reduce costs?
• Provide a competitive advantage?
• Do your objectives simply focus on just improving collaboration within project management?
• External collaboration with business partners or clients?
• Improving employee engagement & morale?
• Is it to improve the search-ability of information and documents?
• Enabling compliance?
• Executive dashboards?
• All of the above?

No matter how you’ve defined your collaboration strategic goals, there is ONE objective you MUST have as part of your overall strategy: Develop a standard information architecture and governance of the collaboration platform. Collaboration is generally unstructured (compared to traditional and more structured taxonomies of document or knowledge management) and information architecture and governance are a must for any successful collaboration strategy and deployment.

Collaboration is About People First

As a concept, collaboration goes beyond the simple sharing of documents in a team site or a creating a wiki. It can be all encompassing from team spaces, email, web meetings, IM to communities, web 2.0 and more. At the end of the day, collaboration is really a broad spectrum of content creation, sharing and information management.

Multiple technologies from multiple vendors have been used to address this broad spectrum with email being THE main tool Executives and knowledge workers rely on day-to-day (mostly because of convenience, availability and Blackberries).

Collaboration is about people and allowing them to work when and where they want without being constrained by schedules, time zones or geography. Perhaps your organization has invested in multiple tools (from multiple vendors) to address your collaboration needs: You are using SharePoint for project/document management along-side Websphere Portals, Lotus Notes, Lotus Connections/Quickr, or Documentum eRoom.

In the absence of a solid strategy, the risk of failure or creating a poor first impression of collaboration technology becomes even greater which result in workers continuing to rely on email as comfort food.

Is It Time to Step Back?

The bottom line is this “buzzword” called collaboration has shown up on CIO radar screens as a “Must-Do”. Over the last few years we have seen vendors like Microsoft, IBM and Oracle all begin to offer a single “uber” eco-system to manage all of your collaborative needs, artifacts and related information.

As organizations have rushed to implement these all encompassing technologies from a single vendor, they proceeded without a holistic collaboration strategy, believed that somehow platforms like SharePoint would magically improve the current state, or simply failed to leverage all the collaboration capabilities with the right strategy, approach and governance.

Throwing technology at the problem just resulted in another repository, another place to store documents, another place to create a discussion and another mess in which they search for information when collaborating.

In spite of an expectation for a high ROI and a Google or Facebook-like experience throughout the global organization, users remain confused, continue to be overloaded with information, are limited in their collaborative capabilities, and still use email as the primary collaboration tool. If this sounds like your organization, then step back and look at your strategy.