Archive for October, 2010

October 27, 2010

What’s information architecture & why is it important anyway?

In many organizations, SharePoint has emerged as a multi-purpose platform to manage information and automate business processes and activities.  It’s often times easy to rush into building a solution without thinking enough about something called “information architecture” (IA). 

IA is a term that most of us probably haven’t heard of before SharePoint.  In traditional content management system implementations, the focus was on developing a taxonomy as part of the solution.  Rarely was the term IA used.  So what is information architecture anyway?  According to our friend Wikipedia, information architecture refers to the analysis and design of the data stored by information systems, concentrating on entities, their attributes, and their interrelationships. While that may sound synonomous to taxonomy, the categorization of the information is really only part of developing a sound information architecture for SharePoint.  When it comes to SharePoint, IA is essential and provides a necessary foundation for everything we do and every solution we develop on the platform. 

So why is IA important?  A solid approach starts with the end in mind and there are 3 key drivers to think about when designing your information architecture for SharePoint:

1. Findability (search)

2. Usability (reporting/browsing/filtering)

3. Security

It doesn’t matter if your looking to leverage SharePoint for your intranet portals, for collaborative team spaces, ECM, web 2.0, business process workflows or business intelligence.  Before you jump into the solution and start created sites, you’ll want to first think about what information is being stored, who has access to this information, and how will people find what they’re looking for.  As I mentioned before, developing a taxonomy for the a SharePoint document library or content types may only part of large IA approach.  At a broader enterprise or solution focus, three key things should be considered:

1. Sites

2. People

3. Content

Is there specific metadata you want to associate with your sites (or site collections) that relate to how they’re provisioned or secured or that map to your organizational structure?  Do you intend to have a site directory to make it easier for people to navigate and browse for what they’re looking for?   If you plan on leveraging SharePoint to search for people, what metadata will help users find someone they’re looking for?   Will individuals have certain security classifications that prevent them from accessing certain areas of the installation (e.g. a farm or site collection)?    Of course content is more obvious and is where content types and taxonomies come into play.

No matter how you intend to use SharePoint or what solution you plan to develop, start by addressing your information architecture needs.  Those “information architecture” related questions I outlined will definitely have an impact your deployment and ultimate adoption of the technology.

October 21, 2010

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:

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.

October 7, 2010

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.

Tags: ,
October 5, 2010

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:

And another good link with some real world examples I found is here:

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: 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 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.