Archive for ‘sharepoint consulting’

September 23, 2010

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.

August 16, 2010

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



August 6, 2010

Three Things to Consider in Your Enterprise Collaboration Strategy

This post was featured on

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.



July 28, 2010

Ultimate Guide to SharePoint Governance – download the outline now.


July 14, 2010

Does SharePoint Cause Information Management Problems?

Does-SharePoint-Cause-Information-Management-Problems?   Interesting blog post and discussion….my thoughts are below….

SharePoint as an application should provide better capabilities around administration AND information governance. 2010 is better but more out of the box functionality is needed.  As a result, organizations need to spend the additional money on 3rd party solutions for admin/security/governance — which, in my opinion, is a necessity, not a “nice-to-have”. However, tight times and tight budgets haven’t helped the situation. As a result we see alot of out of the box vanilla SharePoint deployments whose main use is a glorified fileshare. While that hasn’t been a bad thing — the simple fact that users can easily share documents (vs emailing them) has created a “Shareplosion” in many organizations — which further adds to the problem. Combine all that with a lack of information architecture, lack of internal marketing and little if any end user education— you have an “information mess”.

Perhaps AIIM might consider rethinking the term “information management” and rebrand it as “Information Governance”.  Maybe IT will spend more time and/or money on planning SharePoint with the right governance.  Good governance will empower users, make them more productive, help them find information better, and allow the business to create solutions that actually improve project management, collaboration, & business processes — way beyond simple sharing of documents.  Governance is all about — user adoption and empowerment being a direct correlation to IT’s ability to administer, govern, deploy, and support a stable application.  Governance is about BALANCE — balancing IT control against user empowerment to ensure security and foster adoption. And it’s not just “governance of the application” — it’s also about governance of the information.

The unfortunate thing is that governance often gets pushed aside in favor of other priorities….and I do understand why the subject is often ignored at many organizations.   It’s been several weeks since I started to post my formula for successful governance of SharePoint — and I’ve gotten sidetracked again with my own priorities….time to continue my discussion on governance..



June 15, 2010

10 Questions to Ask the “IT Guy”…

Good article I found…

If you run a company, you’re probably used to your “IT Guy” telling you that you need to do this and that.  It seems like there’s always an opportunity to upgrade, update, replace, implement, and install technology.  It could be new hardware, new software, new accessories, a new phone, a new server, new cabling…a new widget even…it could be anything….

How do you know when it’s just the IT guy finding “something to do” and when it’s really something that makes sense and will add value to the organization? After years of being in the IT industry and working with business leaders, we’ve come up with a “reasonability” test of 10 questions that can help establish if something is really worth doing and, if it’s worth doing, how it should be done.  The next time your “IT guy” (or anyone actually) suggests something, ask these questions:

1.    What is the business justification for implementing it? If there is not a specific business justification for doing it, there’s a good chance it’s not worth doing.  Will it increase revenues?  Will it reduce costs either over the short term or long term?  Can it improve the company’s competitive position in the marketplace?  Will it improve employee morale?  What is the business reason for doing it?
2.    Who is the one person who will be responsible for the success of the project? Many times your IT Manager will encourage the organization to implement some new technology, but then the success of the project will depend on other departments and/or users in the organization.  Who will be responsible?  Does that person have the authority to see the project through to its success?  Responsibility without authority doesn’t work.
3.    Define “success” for the implementation?  What will it look like?  What specific results will we see? Make sure everyone in the organization is on the same page when defining success.  Is the “go live” date part of success?  Are certain functions required?  Are certain reports required?  Have a clearly set definition of success.
4.    How much will it cost?  Upfront?  Ongoing (monthly, annually)? What something costs is never a simple thing.  There’s the initial cost.  There’s the ongoing cost.  There might be annual maintenance.  There might be annual support.  There might be future phase costs.  Make sure you get the number that includes EVERYTHING.
5.    Who will be responsible for the cost?  What happens if it goes over? Is the IT guy taking responsibility for the cost?   What are the repercussions if the cost turns out to be different?
6.    How long has it been on the market? Ask how long its been on the market.  Is this a new technology or an old technology?  If it’s an upgrade, will you be the first company to install the upgrade, or has the upgrade been out on the market for a while?    Our approach is generally to not be the first user of anything, whether it’s an upgrade or a new product.  We like to see products get at least six to 12 months of legs before recommending that our clients go forward, unless there’s some compelling business reason to ignore this rule.
7.    Can you get at least three references? Are there references for what’s being recommended?  While it’s great to spend the time calling the references, it’s even more important to know that references can be provided.  If someone can’t provide at least three references, the product or upgrade is likely suspect.
8.    Will there be downtime associated with the installation? Really.  Will the implementation happen over a weekend or during the week?   What happens if the installation fails?  Can you go back?
9.    Who do our employees contact when there is an issue?  How do they contact them?  Who is taking responsibility for support?  Is it an internal resource or an external resource?  What are the expectations for support?  24×7?   9-5?   How much downtime will you allow if the new technology causes downtime?  Is there a backup plan?
10.    Will training be required?  Who will do this?  How long will it take?

A lot of times training is taken for granted, or the need for training is minimized.  Don’t.  Training is the secret weapon of technology.  If you train your people in using technology, experience has proven that they are significantly more motivated in using the technology successfully.

June 1, 2010

Managing Knowledge in an Era of Information Overload

The following article was featured in Greater Charlotte Biz Magazine….

Managing Knowledge in an Era of Information Overload
By Rich Blank
The Starbucks ExampleImagine for a moment you walked into a Starbucks and the barista didn’t know how to make a cappuccino or latte! It’s well documented that Starbucks spends more on the education of its employee partners than it does on marketing. And no doubt that education, that “management of coffee knowledge and expertise,” is shared through some type of explicit training classes and written material.  There is also much time spent outside of the classroom, mentoring the barista hands-on and promoting a culture of sharing tacit knowledge and best practices of making a consistent and quality cup of coffee every time. Without their ability to manage and share knowledge and investment in people, Starbucks probably wouldn’t have been able to grow as fast, wouldn’t have been able to adapt to changing markets and customer needs, and wouldn’t have been able to earn billions in revenue. Starbucks provides a good example of the importance of knowledge management and impact that it can have on the bottom line.Knowledge Management 

Knowledge Management (KM) has been one of those buzzwords that have been talked about for almost two decades, offering the promise of somehow capturing that explicit and tacit knowledge as a strategic asset to leverage to competitive advantage. Some of the drivers around KM efforts include:

• sharing valuable organizational insights

• avoiding redundancy of effort

• reducing on-boarding time and learning curves for new employees

• retaining intellectual capital due to turnover or aging work force

• adapting to changing customer demands, environments and markets

So what do these drivers have to do with SharePoint?   Well, do any of these drivers relate to your SharePoint initiatives today?   Microsoft SharePoint is a valuable product to address these objectives. SharePoint is a fairly simple, highly reliable collaboration and information management platform that connects and empowers people through online business communities, where they can collect and share important tacit knowledge, documents and keep track of projects. The consolidation of knowledge onto SharePoint helps cut costs through lower training costs, increased IT productivity and cost-effective maintenance, all within a governable and compliant platform.  Although Starbucks wasn’t able to take advantage of SharePoint (it didn’t exist back in the 1990s), it provides a good example for the need to manage knowledge as it evolves.

Today, e-mail is overused and overloaded as a primary tool for communicating, sharing information and documents, and making decisions. Information is all over the place and exists in multiple repositories. Companies don’t know what they know and don’t know. Knowledge workers expect a Google-like experience within their organizations but just can’t seem to find the information they’re looking for. Information continues to grow exponentially and end users continue to experience the daily glut of information overload. Ultimately, information gets filed irretrievably, deleted or lost.  What can we learn from Starbucks’ success and their understanding that people and knowledge are indeed valuable corporate assets that rivals the way we think about raw financial or customer data?

We can learn that the keys to a successful KM initiative and ultimately a successful enterprise deployment and adoption of Microsoft SharePoint lie in the strategy, the people, the process, and the execution. It is important to have a good partner for implementation of the platform, one that addresses these specific areas: strategy, change management, process excellence, systems integration, and delivery management. The balance and intersection of these domains is how organizations can maximize the ROI of enterprise 2.0 technologies like SharePoint.

While collaboration has become one of the latest buzzwords, by itself collaboration is simply a process in which we connect, create, find, capture, share, and consume knowledge. And collaboration in the past and today continues to happen in the absence of SharePoint. However, in order to fully realize the potential of KM, it is essential to recognize and utilize the SharePoint technology as the collaboration platform, and then leverage it as a mechanism to manage and share knowledge.

Fully utilized, SharePoint is not just a platform for collaboration, but an ecosystem for capturing and managing knowledge that can transform your organization and help you realize the promise of SharePoint as a true enterprise collaborative knowledge management platform and strategic organizational asset, allowing you to identify opportunities and act upon them in a timely manner by getting the right people the right information at the right time.



October 3, 2009

7 Steps to Sell the Value of Collaboration to Decision Makers

UPDATE: The following presentation was delivered by me at the SharePoint Summit 2010 Conference.

One of the challenges in deploying an Enterprise 2.0 platform like SharePoint is first figuring out how to get approval for funding such an initiative.   I’ve read a few articles on ROI of Collaboration and the bottom line is that the bottom line of collaboration is often hard to quantify.  So how do you sell the value of collaboration to those individuals who make decisions within your organization?   It’s often difficult to wrap your arms around concepts like blogs, wikis, or communities and even harder to quantify those in some type of hard ROI.   However, there is a methodology to the madness of establishing value of these collaboration tools.   And that methodology can be broken down into 7 key steps:

1. Identify the current business challenges. These may include innovation, focusing on customers, lean and efficient processes, attracting talent, developing leaders, and sharing knowledge, and of course compliance and security of information assets.   Each organization may have their own unique spin of these challenges, yet there does seem to be a common set no matter what company you talk to.

2. Capture the voice of the customer(i.e. your employees).   Whether you focus on a line of business or functional area like human resources, go out into the business and talk to people.  Find out what their challenges are, what opportunities they see, what pain points they have, etc…  Make sure you start a list of “notable quotables” too.   Capture those catch phases and feedback.

3. Ask the question:  How? How will your organization meet those business challenges?  If you can’t measure the efficiency of a process, how do you know you improved it?  How do you service customers if you can’t connect with them easily?   How do you develop leaders when you can’t find the right people with the right skills or even share knowledge effectively and easily?  How do manage risk if you can’t organize your documentation or take the right corrective action.    With sooo many corporate initiatives going on in your organization, how will all this work get accomplished?

4. Outline guiding objectives. The answer is of course a collaboration platform (e.g. SharePoint).  But it’s not enough to just state that alone.  You need to develop some guiding objectives of what this platform will do and how it will achieve those objectives.   For example, one of those objectives may be to “get work done more efficiently”.   But how?   Well, SharePoint provides a visible business context to analyze and act on information.  SharePoint reduces learning curves, drives innovation –but how?  Through the sharing of best practices and ideas across time, political, and geographic boundaries.   SharePoint creates efficiencies in business processes – but how?  Through transparency, audit-ability of workflows, and documentation of unstructured work.    These are just a few examples of what your objectives might look like.

5. Identify Opportunities.   Maybe there are already initiatives in-flight within your organization that are deploying SharePoint.  Find those existing installations and capture the investment made and benefits they provide.   In those conversation you had with your customers, identify specific potential opportunities.  Then map those to their potential impact they have on driving revenue, reducing costs, developing people, or mitigating risks.   In some cases, the collaboration solution might hit all three.  Let’s look at an example.   Maybe you think an “Internal Facebook” is a good idea.  What value does that really provide in a  business context?   Well, expertise location, networking and employee engagement are just a few ways it adds value.  Now how does an “Internal Facebook” impact revenue and costs?  Well, if you can save time finding the right resource, you just reduced costs.  If you can find that resource and help a customer, then you’ve impacted revenue.  If you find the right resource, they can share knowledge and reduce learning curves and mentor others.

6. Find external examples. Talk your software vendors’ sales rep and find out where a collaboration platform actually benefitted a similar organization with like challenges.  Identify the business challenge, the solution, and of course the benefit.

7. Draw a picture. Try to visualize what this solution will look like and paint the picture of its touch points to other systems like ERP or CRM or Product Development or Project Management applications.   Make sure you incorporate those key objectives you outlined earlier in the picture (e.g. visibility of information, expertise location, social learning, etc…).

And there you have it.  I just gave you the outline for your Powerpoint presentation to sell your collaboration solution to decision makers.   Again the 7 steps are:

1. Identify current business challenges.

2. Capture the voice of the customer.

3. Ask the question – HOW?

5. Outline guiding objectives of the collaboration solution.

5. Identify opportunities for the solution.

6. Find external examples where a like-solution was successful.

7. Paint the picture.