Why Certain SharePoint Solutions Aren't The End Game

Generally speaking, as an organization matures, business processes often need to become more defined and standardized to facilitate repeatability and scalability.  Business processes may also  become more centralized out of necessity.  For example, if you have a lemonade stand on ten streets in town and each one is independently managed, the independent stands end up wasting a lot of time designing their own signs, figuring out how to process sales, and making trips to the grocery store.  If the lemonade stands centralize and standardize then perhaps there is only one group in charge of designing signs, and another group for stocking inventory, and another group for collecting the cash.  Each functional group can then serve the rest of the lemonade stands and the whole operation becomes much more efficient.

I believe that SharePoint has experienced a lot of success by helping companies get one step closer to the centralized and standardized model.  A sweet spot has been opportunities with ten independent lemonade stands.  I thing collaboration sites bridge a huge gap  at this stage when companies don't have mature processes in place, haven't figured out how to do things efficiently, and transactional systems are nowhere to be found.  Only after intentional progress and many waves of iteration will a company achieve great efficiency in such processes.  SharePoint helps in that progression...but I don't think that it is necessarily the end game in all cases.

One advantage to using SharePoint is it is quick and easy to get a solution up and running and the solution is probably a lot better than an email and document attachment process that was occurring before.  We can make successes in these situations and they are great steps forward.  If you read the Budgeting Portal Case Study you will see how SharePoint was used for Budgeting and Planning.  However, there comes a point where we need our process data to be completely integrated with other process data.  It needs to be relational.  It needs to be consistent.  And the ways we consume and produce the data electronically needs to be consistent and intuitive for us to achieve the level of efficiency that we are seeking.  Sometimes, our processes get to be too grown up for SharePoint, quite frankly.

The Budgeting Portal that I have been demonstrating at SharePoint Saturday events is only in SharePoint, temporarily.  Eventually, this is being moved to Hyperion Budgeting and Planning.  You see, a process that started off in email evolved to a document library in SharePoint.  Then it evolved again within SharePoint to include list data.  It continued to progress and get more sophisticated with custom databases, TSQL views and stored procedures, SSIS packages, SSRS reports, dashboards, and Data View Web Parts.  Then the practical limit within SharePoint was reached.  The data in the Budgeting Portal needed to be tied more closely to other financial data that could only be maintained in a financial system.  It became inevitable that this solution would need to become part of the overall financial system in order to facilitate the next wave of progression and efficiency.

Whether it is a lemonade stand or a budgeting and forecasting process, I believe that in many cases, we need to view SharePoint as a tool to help define a process, give it a place to become organized, mature it, and then transfer it to its permanent home.  I don't approach every project this way, but I am seeing this approach become more applicable and more common especially as transactional systems are becoming more flexible.  I believe that the core capabilities of ECM, collaboration, and social computing will eventually become very practical within CRM and ERP systems, which already provide business processes tuned for best practices and rigidity.  In the future, I believe that more and more SharePoint projects will be initiated, not with the purpose of being the end all, but rather with the purpose of promoting adoption of rigid processes in CRM and ERP.  SharePoint can help bridge the gap by being the interim solution where process discovery, definition, and initial improvements are made. 

SAAS Vendors Capitalizing on an Accessible from Anywhere Misconception

I think that there is a misunderstanding in the marketplace, a perception by Software as a Service (SAAS) prospects and customers, that the only way they can have a solution that is available from "anywhere" is if they choose a cloud solution. This is a ridiculous assumption and one that cloud vendors seem to be capitalizing on. World Wide Web accessibility should not be considered a discriminator for on-premises versus cloud debate, and it certainly shouldn't be considered an advantage for an SAAS solution option. If anything, level of flexibility in accessibility should be considered a disadvantage to SAAS offerings, since SAAS offerings by definition, require some form of WAN or Internet connection.

For on-premises deployments of Web-based software products, accessibility from the World Wide Web is a matter of corporate policy and network configuration. In many highly secure environments governed by extensive policies, procedures, and directives; it may seem "impossible" for a business group to receive permission to have their Web portal published externally, to the World Wide Web. This is not a technical matter. This is a policy matter. In that regard, SAAS does make the "impossible" possible, by allowing business groups to bypass rules that they would otherwise need to follow if they went the on-premises route. So, is enabling a customer to circumvent a procedure truly a competive technical advantage to SAAS? I don't think so, and I don't think marketing should communicate it as such.

I think an underlying problem that this situation highlights is that many businesses still lack the ability to effectively prioritize their Information Technology initiatives and align those initiatives with the demands of the business. It is easier and more beneficial/less costly for a business unit to go rogue with an SAAS solution than it is for them to work with IT. This situation also points to a flawed management practice of allowing business units to dictate their own technology solutions as opposed to following a single Enterprise Architecture strategy. Whatever the case, "accessible from the Web" isn't a technology discriminator for SAAS, and vendors shouldn't confuse people into believing that it is.

References

LeClaire, J. (March, 2012). Should CRM Apps Be in the Cloud? Retrieved March 12, 2012 from http://www.crm-daily.com/story.xhtml?story_id=030001S1KJNI&nl=1&full_skip=1.

Lessons from an ERP Project Failure and Vendor Law Suit

A customer/vendor conflict: 

In a recent Computerworld article, Chris Kanaracus explains how Epicor Sued Over Alleged ERP Project Failure.  In the article, the customer attributes the project failure due to shortcomings in Epicor software.  Customer states, "The project did not go well due to a variety of shortcomings in Epicor's software."

Here is my analysis:

In my experience doing these sorts of procurements, when specific business requirements are defined well and included in the RFP, SOW, and contractual documents, then many project risks (both cost and schedule types) are shifted to the vendor. If the vendor agrees to meet a specific requirement and both customer and vendor sign the contract, then vendor is on the hook. However, if the requirement is not documented in the initial contract, then the vendor may later push back by describing the requirement as "out of scope" and will only do the work if they can bill the hours. Scope creep is not only common in ERP projects, it is actually a well-accepted fact.

As a casual reader of the article, I must state up front that I don't have all the facts in this story.  I only know what I read in the article.   So, based on the article and past experiences I can go out on a limb and suggest two things that might have happened:

1. The customer failed to specify the steps of a key process and include those details in their contract with Epicor.  Therefore, the process became ambigious and unclear.
2. Epicor team attempted to remedy a technical shortcoming through additional pro services (billable time), and they failed to reach customer satisfaction before the bill got to be a million bucks.

Lessons to be learned:

This article reminds us of some key lessons that we can use when working with vendors.

• Invest as much time as necessary into defining processes well.
• Identify specifics even if they are obvious or assumed.
• Include specific business requirements, solution requirements, use cases, story board, and other illustrations in the vendor contractual document.
• Group related requirements into "categories" and seek fixed pricing estimate for each category (this forces vendor to do more careful estimates and makes the project easier to manage).
• Create a project completion checklist up front (should map closely to the categories) and include that the contracts.
• Realize even if you defined requirements really well, you still might miss important ones.  Therefore, remember to buffer the project budget to cover requirements that may have been missed.

A fixed bid estimate may cost up to 25%-40% more than a standard estimate, but that is a significant discount over the 500%-1000% overrun that is not only possible, but likely if the requirements are not clearly spelled out and the work begins.

References

Kanaracus, C. (August, 2011). Epicor sued over alleged ERP project failure. Retrieved October 20, 2011 from http://www.computerworld.com/s/article/9219127/Epicor_sued_over_alleged_ERP_project_failure?taxonomyId=144&pageNumber=1.

A CRM Vendor Pricing Whitepaper and Its Proper Place in the Overall CRM Procurement Process

SugarCRM recently published a whitepaper titled, "CRM Vendor Pricing: A Comparative Analysis."  The whitepaper explains pricing models for the CRM industry as a whole, and then provides detailed pricing information for a short list of CRM vendors.  The whitepaper also provides a Total Cost of Ownership (TCO) analysis of the vendors (SugarCRM, 2011). 

The reason I am posting is because this whitepaper reminded me of a common pitfull organizations fall into with CRM projects and I thought I would write about it.  The pitfall I am referring to is beginning or leading a CRM project discovery with vendors and products, instead of through a more analytical process focused around business requirements.  While the information in the whitepaper is certainly useful, I believe it is most relevant to project teams who have already gotten to the point where they are evaluating a short list of CRM vendors to compare capabilities, pricing, and other aspects of the overall investment and just need some help collecting and understanding pricing models and numbers. 

Based on my observations in the field, I believe that too many organizations initiate a CRM project based on superficial vendor or product information, such as advertisements or pricing.  I think this is a huge mistake and very common.  Instead of a reactive approach, I believe that the best possible CRM vendor/product selection decision is one that spawns from due process.  The project management processes that I've found to be very supportive, leading up to a CRM vendor/product selection, include the following:

1.  Project Charter - Purpose, business case, initial scope statement, team, affected organizations, order of magnitude
2.  Requirements Analysis - Surveys, interviews, general business requirements, technical requirements, solution requirements
3.  Scope Management Plan - Project scope baseline, requirements traceability matrix, boundaries, constraints, etc.
4.   Request for Proposal (RFP) - Template with detailed questions to be issued to vendors
5.  Vendor Evaluation Round 1 - Identify all possible candidates
6.  Vendor Evaluation Round 2 - Use requirements to eliminate and reduce list to a "short list", try to narrow down to less than 5
7.  Vendor Evaluation Round 3 - Issue RFP to short list, conduct demonstrations, narrow down to 3
8.  Final Comparison - Present full comparison of final 3 vendors with advantages/disadvantages, cost comparisons, etc.
9.  Vendor/Software selection

Based on the steps listed above, the whitepaper and the type of information it contains, really comes into play around step 6.


Reference

Blytheco (2011). Blytheco Sets its Own Competitive Prices for Sage CRM. Retrieved June 8, 2011 from http://www.blytheco.com/sagecrm/price.asp

Blytheco (2011). Sage SalesLogix Price List. Retrieved June 8, 2011 from http://www.blytheco.com/saleslogix/price.asp

Sage (2011). Sage ACT! Pro 2011. Retrieved June 8, 2011 from http://www.act.com/products/2010/act/

Salesforce.com (2011). Sales Cloud. Retrieved June 8, 2011 from http://www.salesforce.com/crm/editions-pricing.jsp

SugarCRM (2011). CRM Vendor Pricing: A Comparative Analysis. Retrieved June 8, 2011 from http://media.sugarcrm.com/white_papers/CRM_Total_Cost_of_Ownership_Analysis.pdf

Sonoma Partners (2011). Microsoft Dynamics CRM Online (SaaS / Hosted). Retrieved June 8, 2011 from http://www.sonomapartners.com/microsoft-crm-pricing.aspx

SugarCRM (2011). Sugar Subscriptions & Pricing. Retrieved June 8, 2011 from http://www.sugarcrm.com/crm/products/editions.html

Focus More on Birdhouse Less on Hammer

Mauro Cardarelli recently plugged something I said, "focus more on the birdhouse and less on the hammer." If Mauro hadn't used that analogy with me a few times before, I probably would have used a different one like, "focus more on the crazy noodles and less on the fork."

The birdhouse analogy refers to the focus of conversations and presentations at SharePoint related conference sessions, meetings, and discussions.  My underlying criticism is that it seems that the community has become more focused on what the SharePoint platform can do and not focused enough on the business solutions that we are building with the platform.  I think the community stands to gain a lot if more emphasis was placed on what we are building with the platform, why, and how we measure value to the businesses receiving these solutions.

I understand that we do need to know the SharePoint product well in order to develop useful business solutions with it.  However, I think it is easy for us become consumed by the SharePoint platform; and its capabilities and limitations and lose sight of the fact that SharePoint is merely a vehicle that helps us get to a destination.  The business solutions are the true end game, not the platform and tools we use to build the solutions.  Some of the design patterns and methodologies we find to be effective may even be transferrable to other technologies. 

As workers, we in the SharePoint community are responsible for ensuring that the solutions we develop will provide the outcomes that the sponsors and stakeholders expect. I think that if we spend too much time trying to figure out the best ways to get "there," and too little time on establishing complete and clear visions of where "there" is, then we are missing the target.  As a community, I think we may miss valuable opportunities to share lessons learned and best practices for solving common business problems using the SharePoint platform. 

When we only focus only on the hammer, we miss the point.  Let's have more conversations and presentations about the birdhouse, how we designed it, why we designed it a certain way, and what we learned from the whole experience.

Missing the Point on Spirit of Governance

Over a short period of time in the SharePoint community, the term "governance" has evolved to describe a class of software products or features. Yet, IT governance has nothing to do with what tools a SharePoint administrator has. Instead, IT governance has everything to do with the people and processes side of things; and the decision making framework that, when in play, can be used to determine that a portal should exist, who should manage it, who it should serve, how decisions will be made affecting it. Governance is really about policies, processes, roles, responsibilities, and priorities (Ross, 2004).

The scope of an effective Information Management Governance Model spans beyond a specific solution, such as SharePoint Intranet or collaboration portal, and encompasses the Information Management practices occurring throughout the organization. A SharePoint governance model should be a subset to that. Putting this in the context of documentation, an overarching Information Management Statement of Governance document should exist and define the framework at the global level, while specific statement of governance documents should be maintained for each Information Management system within the organization; SharePoint being one of those.

The IT project management framework is another significant and relevant topic to governance. The project management framework established the processes followed to initiate, plan, and execute IT projects. These processes should include such activities as the evaluation of new SharePoint projects in the context of the organization's overall information architecture. Aligning the project management decision making with Information Management, business, and IT decision making results in solutions that have backing, are sustainable, and actually provide business value.

The spirit of governance is really about defining what the processes should be, and if generous enough, explaining why to some extent. In the end, governance models maintain decision making integrity amongst people...that is not something a portal administrator can do by running a report or recovering a deleted site.

Reference

Ross, J., Weill, P. (2004). Recipe for Good Governance. Retrieved August 4, 2010 from http://www.cio.com/article/29162/Recipe_for_Good_Governance.

General Business Requirements vs. Solution Requirements

What came first, the solution or the need? Let's hope the need, but we all know that is not always (often not) the case. With the great technologies available to us today, rapid application development enables us to solve problems. But, does the ease of development actually create a new set of problems? Yes, it does.

When the software development process is lengthy and drawn out, it forces many planning activities such as requirements analysis, design specifications, and planning. Not doing these things leads to costly adjustments later. The lengthy process also forces organizations to really think about what solutions they are developing and how these solutions fit into the big picture. We've got it pretty easy today. With portals, collaboration, search, BI, content management, and workflow platforms today, some times doing it "wrong", undoing it, and doing it again is actually less expensive than the cost of planning and documenting.

Yes, I am familiar with the twelve principles of the Agile Manifesto (Agile Alliance, 2001). I like agile development when it follows some organized processes and produces artifacts that can be used for reference later. You still need documentation for future development, disaster recovery, and repair.

However, what I don't like is "premature solutioning" or the practice of directly jumping from a problem to a solution design without any sort of further questioning, analysis, thought, or sanity checks. When you encounter a problem, and immediately form a solution and begin developing it, a lot is lost. You are not considering what other stakeholder needs are, what other colleagues are already working on, and how this "fly by the seat of your pants" solution actually fits in (or doesn't) into your overall information architecture.

Working with my colleagues, we recently began formalizing our thoughts around the solutioning process. One of the first roadblocks we encountered had to do with semantics. We began observing that our push for "requirements" was being misunderstood. When a problem-solution situation arose, we would explain that we needed to analyze requirements. The response to this typically included design specifications. We would then stop and say, no, we don't want detailed design specifications, what we want is to understand the problem better and understand how it impacts other people, so we can create a solution that will fit into our information architecture in a way that adds value and doesn't undermine anything else we are doing.

After a few more of these scenarios we decided that we had to make others aware of our solutioning process and how we think, so that everybody would be able to communicate with each other better. The first thing we did was make a distinction between the types of requirements that we would discuss in the course of solutioning.


We decided on the following:

General Business Requirements - Facts and opinions that help understand the problem better. These are not design specifications and do not explain a solution. Instead, this information explains what the business needs are.

Solution Requirements - Facts and opinions that define how a solution is supposed to look, feel, or act. This information directly dictates the design specifications.


So, now when a new request arises, we start by gathering "general business requirements." We then consult with stakeholders, policies, procedures, standards, goals, etc. and analyze the information. Once we have all the facts, we begin to design a solution. At that time, we ask stakeholders to help us define the "solution requirements." The result of the latter activity is a design specifications document. Next, we schedule and plan the development activities and proceed from there.


Reference

Agile Alliance (2001). Principles Behind the Agile Manifesto. Retrieved July 24, 2010 from http://agilemanifesto.org/principles.html.

How Communication Gaps Can be Viewed as Opportunity for Business Analyst Function

I find myself analyzing things quite a bit throughout the day. Some people accuse me of thinking too much. I don't know, it is just a natural thing I do, I guess. I ponder a lot.

One thing I ponder about from time to time is the impact that words have on work, people, and communications in general. Words are very significant in my profession. Words appear everywhere. In Web portals, they are used to instruct people how to use the Web site or how to perform a function. In presentations, words are used to concisely deliver a big message, one little message at a time. A funny thing about words is how they conjure up different emotions and different meanings to different people.

So, how does all of this relate back to the theme of this blog? Well, UX topics aside, there are some interesting behavioral patterns that I recently noticed, because I had been fixated on words. Recently, I happened to be observing a debate between colleagues, regarding the best way to configure a feature of a new Learning Management System (LMS). For background, this LMS Web application is intended to deliver courses and track professional development information for employees. It happens to be a third party product.

During the course of debates I realized that there is a distinct difference between the way that the software developer interpreted the name of a software feature versus the way that a business stakeholder interpreted it, in the context of them working together on the system implementation. Both individuals were working together, exploring how the third party application works, and trying to figure out the best way to leverage the product in order to meet the business requirements.

During this adventure, the two individuals came across a product feature called "curriculum." Here is the behavior that I noticed:

The software developer evaluated and experimented with the "curriculum" feature and tried to figure out different ways to use the feature in order to meet the business requirements.

The business stakeholder, performing the same experiment, forcefully attempted to make the software behave as they understand the word "curriculum" to mean in normal business context.

The two individuals then reached a disagreement when the software developer offered various options for how the feature could be used, while the business stakeholder argued that "no, a curriculum means this and so it must only be used like this." Not only did the two disagree on what the word means in general business context, but both also disagreed on the appropriate way to approach the software configuration task.

Do you see the distinction?

The software developer views the "curriculum" not for what the label means, but for what the actual program capability is and how it interacts with other related capabilities in the system. On the other hand, the business stakeholder had a fixed idea because of the label.

What is the point of all of this? Business analysis. A business analyst function is extremely important on a Web application project. Whether this function is performed by a dedicated expert, absorbed and performed by the project manager (or other resource), there needs to be a person who can understand the business requirements while also understanding the developers' way of thinking so that these two perspectives can be united and a common goal can be met.

User Experience (UX) in Web Portals

Planning and executing information management projects accounts for a major portion of the overall effort. However, there is still quite a bit of time that is required to be spent on refining and communicating concepts to colleagues and to the business. Perceptions about why you are developing a portal or system and what it will look like have a tremendous amount of impact to the success of a project.

User Experience tends to be one of the facets of information system design that draws quite a bit of controversy because it is very subjective. Combining information architecture concepts, system capabilities, features, security models, business requirements, functional requirements, standards, and policies to develop a design will get you most of the way there. However, there are still some very volatile aspects to the design process; these include emotion and perception.

The measure of user experience of a system is highly subjective. People's attitudes, situations, level of knowledge, and other factors produce an emotional response every time the person uses the system. Although I have lots of past experiences, projects, and communications to draw from for guidance on how best address matters related to UX debates; I've decided that I really need to collect some factual information to keep in the toolbox. I think that behavior studies, polls, statistics, and other sources of research are required to build a solid fact base to support decision making. It is simply not good enough to speculate how people think and how people will respond to a particular system design.

I plan to invest some time in this topic and then reflect on my findings in subsequent posts.

I Respectfully Disagree

As I was searching for some references for a risk management white paper that I am writing, I stumbled upon an old PowerPoint on the Web titled, "Risk Management and ROI: The IT Leadership Financial Conversation." It was created by Peter G. W. Keen of Delft University in Sepetember 2004. This PowerPoint was used to educate an IT Leadership community attending a CIO summit.

As I looked through the PowerPoint for some insight to use in my paper, I started finding statements such as:

"ROI from IT: There is none. There never will be." (Keen, 2004)
"ROMI not ROI: Return on Minimized Investment" (Keen, 2004)
"80% of IT costs are hidden below the surface - and a navigation threat" (Keen, 2004)

The more slides I viewed, the more I realized that I completely disagree with the intent of the message; essentially to encourage CIOs to view IT as a business liability which needs to be tightly controlled and driven primarily by its cost drivers.

I disagree because I think a better approach for CIOs to take is to understand the purpose of the technologies their teams are evaluating, understand the costs and benefits, and choose projects which support the objectives of the organization. Managing cost should be part of the decision making process, but it should not be the primary driver. When cost is measured, all aspects of cost should be included. And, the financial benefits of the project should also be measured and included.

The objective of Information Technology is to facilitate two very important capabilities for today's businesses:

1. Revenue generation
2. Business productivity (process efficiency)

Most leaders in the IT space generally understand the financial benefits of the IT projects they choose to pursue, but perhaps the IT industry as a whole generally does not place enough emphasis on methodologies and practices for measuring and translating these back to the financial statement. This would require more focus, analysis, calculation, and validation.

To be clear, I am not saying that all IT projects are sensible and they should be done blindly. However, what I am saying is that it is incorrect to characterize IT as a business function that shows no return on investment.

If you deploy a technology that allows people to attend meetings over the Web instead of traveling to another location, then your costs are those which are required to implement and maintain the technology while your savings are those which you do not spend to travel? Both sides of equation need to be considered, not just cost.

I also disagree with the claim that 80% of IT costs are hidden. I believe that if budgeting is done properly, most IT costs are completely visible and manageable. There are always some unforeseen costs with IT, but by learning from past experiences, it becomes possible to anticipate these variations.

In summary, I disagree with the PowerPoint. Information Technology can have a positive ROI, and costs can be manageable and predictable. I think the real problem is some organizations just don't know how to measure these things effectively.


References:
Keen, P. (2004). The IT Leadership Financial Conversation. Retrieved December 5, 2009 from www.peterkeen.com/presentations/IT%20Risk%20Management.ppt.

Taking Cloud Platform Services Seriously

(Perspective from early 2009)

Based on conversations with colleagues and clients, I still don't think that the majority of long term, enterprise architecture strategies even consider Cloud Platform Services (referring to PAAS)...but I think this strategy may eventually become mainstream.

Despite the fact that the cost of hosting systems on-premises is reducing with time due to improved virtualization and management technologies, I think that in the not too distant future, there will be a point when the costs and risks of serving up certain types of applications in house will actually be greater than any compromise made by moving the same systems to a PAAS, cloud based platform.

The biggest drawbacks I see with PAAS are:
1. Perceived loss of security controls at the infrastructure level.
2. Perceived loss of control over infrastructure configurations.
3. Vendor lock-in.
4. Vendor price gouging.
5. WAN/Bandwidth limitations.

Despite the risks, I do think that visionaries are beginning to consider PAAS for certain aspects of their computing environment road map. I'm just not sure how much longer it will take before this approach is generally accepted and considered mainstream.

Where is the FAST Search Community?

I am truly excited about Microsoft's acquisition of FAST Search as well as the recent news about Microsoft's new Enterprise Search road map. Anyone who has deployed Microsoft Office SharePoint Server (MOSS) as an Enterprise Search solution or internet facing solution probably can appreciate all of the considerations that go into planning and implementing as well as some of the limitations that force you to think outside the box.

Prior to becoming proficient in MOSS Search, and prior to doing numerous Search Proof of Concepts on behalf of Microsoft, I spent quite a bit of time locked inside of a small office in the North End of Boston, researching, building and testing MOSS Search on a Microsoft VM. My primary sources of information included TechNet webcasts, blogs, Codeplex, MSDN articles, and the Microsoft Partner Support contacts. I've come to really appreciate the abundance of free flowing ideas and information that exists on the Web related to MOSS. The community is fantastic.

As I embark on new and exciting adventures working with FAST ESP, I am certain that the MOSS community will continue to contribute high quality information and will eventually expand to cover more topics related to FAST ESP. As of now, I don't see the same level of knowledge sharing occurring with FAST as I have seen with MOSS. I only hope that in response to Microsoft's acquisition of FAST as well as their reasonable product licensing model, that FAST will become more widely adopted and that a FAST Search community will flourish on the Web.

Fundamental Productivity through Cultural and Technical Progress

A decent information taxonomy (referring to the concept of classifying and organizing content such as web site structure, web content, documents, etc.) aligned with the proper technology, in an adaptive culture breeds some real value. When information is consistently produced, named, categorized, and published throughout a work place, workers naturally become more adept at sharing, using, and reusing information.

Research based activities are the most obvious targets for streamlining because there are often lengthy windows of unproductive time associated with research. Consider a technical support analyst's work as an example. Here is a person who spends his or her day solving problems for other people. The job includes receiving and interpreting a problem, communicating and clarifying the symptoms, assessing the potential cause, and applying and testing solutions. Each forward thought process towards a resolution is linked and in some cases limited to the analyst's own prior knowledge and previous experiences.

Imagine if the analyst has access to a knowledge base and colleagues regularly publish solutions to their problems to the knowledge base. Day in and day out analysts are solving problems and taking time to write up detailed articles describing the cause of the problem and the solution. Articles in the knowledge base are all formatted a similar way, with an id number, a title, an author, keywords, a description, and a solution. The knowledge base tool provides search functionality which is tuned to allow filtering on a these structured fields of information. With this type of tool available, the analyst is able to quickly parse through an abundance of prior knowledge and past experiences to find answers quickly.

The idea of being organized and productive is not limited to support analysts. This ideal can be applied to a wide range of occupations and business scenarios.

What does it take to achieve hyper productivity?

Vision; a big picture strategy with an underlying grasp of an organization's detailed business processes.

Leadership; dynamic thought leaders empowered to make decisions about how to manage other people's content.

Acceptance; an acceptance of a the current work place culture as it relates to collaboration.

Inclusion; motivating employees to be excited about being productive can also be challenging, which is why it necessary practice inclusion. Ideas that derive from within and grow organically are far more inspirational than any mandate received via corporate email blast.

Balance; what will work best for all stakeholders vs what each individual stakeholder holds important.

Technology; essential, yes, but most companies who are realizing benefits from a corporate portal, knowledge management system, or collaboration web site may already know that the technology deployment is often times the easiest part.

SharePoint V3: When To/When Not To Use Content Types

Content types allow you to structure documents and list items in a SharePoint portal. They give the functional ability to define and enforce uniformity throughout a portal. There is no question that content types greatly enrich SharePoint as a content management product. However, in determining when to use content types in a portal, there are several considerations.

Desire
Is there a knowledge management champion who can coordinate the effort of unifying a business unit or entire company?

Executive Sponsorship/Authority
Do the resources who have the desire to standardize content also have the authority within a department (or broader scope) to make descisions and execute changes (or the backing of an executive sponsor)?

Culture
Is there a sense of unity amongst business units or are they segmented?
Are the business units of the organization integrated in their nomenclature (or even individuals within a business unit)?
How easy is it to communicate ideas accross business units or within a buisness unit?

Resources Allowed for Design
Does the organization have the people and intellectual bandwidth, and focus to figure out how to categorize document and list types, provide name for content types, determine format of each content type?

Governance
Is there a system of checks and balances, perhaps a design committee, in place for change management to ensure that pros and cons have been properly weighed prior to making design changes?

Organizational Adoption
Will the producers and consumers of the content accept a consistent structure for their content, or will they shy away or complain about it?
Will the users understand the content if it is categorized?

Skill
Are the content producers and their supporting power users familiar with SharePoint enough, and trusted enough by peers to create content types, associate templates, and add the content types to libraries?

...these represent some of the overarching ideas that come into play when trying to determine when to use content types.

Here are some of the technical considerations:

Site Structure
Does the portal design include one site collection or many?
Do the content types span accross site collections?
Content types work well within a site collection. But, when your content types span several site collections then it becomes a little tedious keeping the content type definitions in synch with each other.

Portability
Since templates and site exports (.cmp) can rely on content types, which means you need to set up the content types on multiple site collections.

Orphaned Data
Custom List or Document Library W/Multiple Content Types + DataSheet View + Unique Columns on View = Users can apply values to metadata columns that don't actually exist for a content type, and the metadata actually gets stored (no hard damage, just not clean)

Benefits of Content Types
* Allows you to name types of content
* Makes consistent metadata structure for each type of content
* Allows you to associate a unique document template
* New button shows the name of the content type instead of generic New Document or New Item
* Allows you to define parent/child relationships, allowing you to create a logical tree structure for taxonomy design
* Allows you to easily provision a new custom list or document library, the columns are already defined in the content type, just add the content type
* IE Script Error (mentioned above)
* Orphaned Data (mentioned above)
* No easy way to synchronize accross site collections (can use PowerShell to export/import)
* No security gains, not able to secure content types, still done at item or library level

Site Columns Without Content Types
* Great middle of the road, save time by predefining columns in a site collection, but avoid some of the technical issues with content types
* Limits you to one document template per library (back to the generic new button)
* Limits you in that all items or documents in a list or library now must have the same columns as each other

Under Promise and Over Deliver

When project sponsors for business application projects are gearing up for a new project they are exposed to products, lingo, marketing material, and all the things that create a buzz. Often times they see demonstrations or presentations that glorify the technologies (that is how these things are sold, right?). Sponsors are sold on ideals. They see a fine tuned demo and are convinced they can have the same thing.

Its great to experience the hype and the excitement of a new project, however, when a project is set in motion a reality check can quickly screech the record player...a message that there are technical limitations preventing a particular goal to be achieved as it was initially designed.

A big part of being satisfied at the completion of a project, is having accurate expectations when the solution design is established. This means being educated about the limitations and obstacles you will face along the way, before you even begin constructing. It also means being cautious about making promises.

SharePoint Intranets, Evolving Beyond Department Sites

I admire software application, user interfaces that are built around a purpose. The most popular business application in the world, Microsoft Outlook is a great example. It provides messaging, task management, calendar management, and more. The buttons and menus are organized in a manner that is suitable for sending email or tracking a task. The user interface is intuitive, easy to use, and makes sense.

I think a trend for SharePoint intranet deployments is that they will include designs which are less influenced by content categorization and taxonomy and more influenced by functionality.

When you think of various SharePoint intranets that are being used in businesses today, you might struggle to draw a correlation between the user interface and the functionality. I think that has a lot to do with the fact that implementers are responsible for coming up with a design, a context. I think a common habit among implementers has been to design the applications around organizational structure of the company. When SharePoint sites first started popping up, they weren't much more than web folders for documents, and their main "purpose" was sharing documents as an alternative to a file share. So, the user interface design took on a shape similar to how documents are categorized in a folder share. I think that categorizing documents by department resulted in a trend of SharePoint portals that have a department based design.

I think a challenge now is to recognize where SharePoint came from, that department site designs are out of date, and applications built on it are no longer just HTTP enabled versions of Windows Explorer. We are now dealing with real business applications with real (and custom) purpose. User interfaces need to evolve accordingly.

If you've spent a significant amount of time performing a job function as a SharePoint portal user, in an environment that is organized by department you may have come to the realization like I have that organizing collaborative or actionable content and information according to department doesn't make a lot of sense all the time.

One way to evaluate this is to think about the audience (I mean audience in the general sense) the sites's information is addressed to and what the audience is supposed do with the information. You might find that when the audience doesn't have to "do" anything with the information other than consume it then it might work well in a department site. For example, an announcement is posted to an HR department web site that there is a new employee handbook. The audience simply consumes this information. They are not expected to collaborate and edit the handbook. In this example the department site probably works ok.

Its really when you start getting into information that you are working with when department sites start to fall apart. Collaboration using list items, documents, forms, and workflow occurs around a subject, not around a department. So why try to categorize the information you use to collaborate on, into a department? A SharePoint user who is performing a function doesn't care "who" owns the content any more then they care when it was created. It would make more sense to me if the user interface design promoted what users are actually doing in the system as opposed to who owns the subject matter that the user is working with.

Sharepoint revelation: it can leverage SOA, it can be a composite application

What happens when business users are demanding a single user interface? What happens when they want their data to be truly integrated and relational? What happens when all the other applications fall short?

The answer is to bring together data and functionality from other systems and create one single composite application.

Microsoft Sharepoint is a great architecture to leverage for this purpose. It offers an excellent portal and web part infrastructure. A solid authentication and security model can easily be achieved. It is easy to recover Sharepoint web applications. Sharepoint is scalable. Customizable look & feel and navigation...its there. In short, Sharepoint addresses all the aspects of web application overhead that may currently prevent you from being able to focus on and deliver those things that the business units are demanding.

Sharepoint is robust, but often times businesses require functionality that out of box web parts cannot achieve because these web parts tend to function at the "surface." In other words, unlike an off the shelf software application such as a CRM system which may store user data in a relational database, the back end data model for Sharepoint user data is relatively flat. Sure, you can create web parts to view external data from the other systems, but a lot of times business units want more than that. They want their portal to "be" the other application. This tends to be the line in the sand where many Sharepoint implementations stop. However, this boundary represents a new frontier for some. This is where you start thinking about how you can build a composite application using Sharepoint.

Building a composite application is all about breaking down functional components and being able to use them independently. For example, the act of adding a new contact record to a crm system. This is a simple, but vital action. Do you need an entire CRM application to do this? Who says you need to be in the CRM system to create contact records? Break down the programming and logic behind the act of creating a contact record, package this as a web part, and deploy it to Sharepoint. In this example you would keep your CRM system in place and extend the existing data and functionality to a Sharepoint web application by way of web parts.

On a broader scale, take a look at the various business applications in your environment and make a list of the functional components that each one is comprised of. Imagine what it would be like to have all this functionality in one single UI. The bulk of the effort to achieve this in Sharepoint is making each functional component available independently from its native software application and creating web parts for each of these components. Once you have done that you can use them througout the Sharepoint web application.

The ROI for a project such as this will be high in situations where you are buying user licenses and maintenance for your other business applications and when the users are only actually using a portion of the functionality that is being purchased. This is where a composite application project has some real value.