Day 1

I am doing a blog of my experiences here at the Bob Mixon Mastering SharePoint class. There should be a new blog entry each day talking about what I learned and some thoughts I took away.

http://www.masteringsharepoint.com/

http://www.bobmixon.com/speaking/Pages/default.aspx

I knew going into this class it was going to be awesome. I knew I needed to take away from it things that I could use internally at K2. We have a KM, Portal based on SharePoint and it is used extensively. I know now that when I implemented in over 1 year ago I did a lot of things wrong. I know I would do it very differently. Now after this week I hope to plan changes along with some others internally that will correct those changes.

The day starts off with the overview.

SharePoint Overview Section

Some key points of the morning

Knowledge management solutions are never done. BPM is never done. You are constantly changing them, adding to them, refining them. AS business changes and we know it does, you need to have your software change with you. How quickly can you change it? How much insight into your processes do you have that shows you where it needs to change and why..?

Today’s business is fast paced, Streamline operational business processes to eliminate data errors. You need to take the knowledge gathered from internal operations, internal production systems and external relationships and be able to use it for proactive decision support.

Too often we are asking our employees to make decisions in their everyday life, and are hoping they are well informed. However are we doing our part by making sure they are well informed and have proper access to the best information easily and quickly. Not doing so makes them much less productive. This also puts the business at risk by making faulty decisions and not putting enough information and insight into the hands of those that need it.

Improving overall organizational productivity is a MUST. How can you accomplish this? This does not just happing by using technology and hoping that will do it. If you think so you are not looking at the whole picture. The important part is more of a mindset, an attitude and a discipline. Having the tools in place is one thing. But putting them into place is not enough. You need to architect them correctly and ensure they are done well enough so that people use them, and use them well.

What is a portal? The real definition of a portal is:

Persona based delivery of content based on who you are. You want it to present info to you based on what you do, who you are and what you should be and need to be seeing.

Collaboration

Collaboration provides a means for employees, vendors and customers to work without time or location boundaries. It must be **Simple and easy to use, this is often an overlooked aspect of design. If you don't make it easy to use, they won’t.

Bob and his content provide a great deal of good definitions of terms then relating that to MOSS. Breaks it down to a base level and what it will really mean to you, and your business. Including a great diagram that breaks out the different versions of SharePoint, I know this is such a common question. Microsoft has a spreadsheet here….

http://office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx

But I really like the diagram; I am trying to get it.

Now we get into the BDC. The infamous BDC- There was surprisingly some people in the class that had used it, I had gotten the impression that the BDC was not well utilized across the implementations of MOSS. Many of those in the room which had used the BDC used the the BDC MetaMan to get it going. I can’t see how people would do this without a tool like that. There is just too much to think about.

Now comes some very interesting parts as I really wanted to see how he positioned workflow and how people reacted. Most of what he presented I had seen and heard before. The OOB stuff is basic; the SPD stuff is better but can still be grown out of quickly. Most of the real work will be done in Visual Studio using WF. This is where he hit us with a great point. WF is not AGILE. BPM requires Agility. You can build it yourself, but needing ANY changes will take a great deal of time given the complexity and learning curve. Then you are left not being able to respond to changing business requirements and have a limited growth curve since it takes so long to make changes.

He also raised a real good point that I am not sure how I feel about at this point. He says There is NO reason to build any ASP.net website or application without using WSS or MOSS. It is a rich full featured, enterprise class development platform. And you can customize every aspect. There is so much there. If you were going to build a new windows application that stores data, would you develop your own storage engine or would you use SQL or Oracle. Bob related that you can build a web application or site 10x faster relying on WSS as a platform over just using ASP.net etc. This is often a similar argument to one I have made about K2 and is another view of the old build or buy decision. One that I believe will become more and more clear moving forward as people shy away from in depth development projects and will drive towards application integration and application assembly. Putting pieces and parts together and focusing on the business value and not the plumbing.

What is federated? The real meaning to submit queries to multiple search engines have them return the results and compile and list that info out. MS federate; means just return results from external services such as file shares, internal sites, and external sites.

Teams Roles and Responsibilities

Who is involved with the SharePoint design and the Implementation. More importantly who owns overall responsibility for it?

Bob says:

Why shouldn’t IT own the SharePoint solution? It is a business management solution, not a technology management solution. Solutions like CRM, or other LOB etc, IT should not own. The business needs to own them since they are for the business and they need to be managed by and requirements driven by the business. It’s quite the amazing thought really. Now this does not mean that IT will not administer, but they should not OWN the decisions. The business needs to, it is managing their business, it is helping their business, IT is the tool to help them know what the limits are what the caveats there around Availability, scale, performance, back up, restore etc. But the core of it, the process of it, Business must drive it.

Important Point: Chances for success will be increased by proper interfacing with the RIGHT members of the organization. If IT just goes off and builds what they think, it will FAIL

The council IDEA

There is a good deal of time spent in Day 1 talking about the ideas of establishing a “council” or multiple ones depending on granularity those involved and need. He recommends that you establish a council that drives the direction, and makes decisions. Business and IT should jointly sit on this. This is a GREAT idea, and has so many aspects that can be of benefit. This can be a management thing where evangelism is pushed from the top down, and a grass roots effort from the bottom up. Ideally this could even be both to have an even more rapid happy adoption. The more people adopt and the more people that use, the more ROI you can achieve.

Get some “Why” people, your cheerleaders, your advocates. You can have the Why people running around. (Why aren’t you using SharePoint for that, Why isn’t that on SharePoint) (Would be nice to have (why aren’t you using K2 for that?) J Don't forget on this team you need users, user education and evangelism will be a key to a successful roll out. Having the right members on this team that can help plan and lead that will be a great benefit.

There really seems to be a lot of additional stuff you need with the idea of a governance council. You can break this out and add in steering committees, working groups etc. I think that setting these things up at some level is the biggest step. Much like change management the important factor is that you are starting and you are doing, you can expand, grow and evolve from there, this can expand as your use of and knowledge of SharePoint does as well. There is too much stuff in the class around this kind of topic; you really need to take the class to get a good understanding of it, or course I recommend it highly.

The Librarian

Get a Knowledge manager, SharePoint librarian, Information Architect. Once architected and implemented you need to have a dedicated person who is responsible for managing the Information, the knowledge, the data. You need someone who is constantly on top of that. Granted with K2 and a solid process and solid architecture this can be alleviated some, but he is right. You definitely (in order to get full advantage out of a KM or IM, WCM in SharePoint) need someone overseeing this not in just Admin terms but in Knowledge and information terms.)

When trying to get funding or justify a MOSS project or really any project for that matter it is important to show the mapping. Map what it results in to a strategic priority. Customer support, increased efficiency, decreased hold time for customers etc. This is a huge key to a project and picking the right ones. This is also a key reason to why IT cannot own these types of initiatives, they simply (typically) do not have the appropriate insight and experiences to know these, and understand them enough to be able to raise them with enough credibility.

We discussed a Very interesting idea several times throughout the day from different aspects. Of all the problems that are going on out there with SharePoint. People everyday are seemingly starting a SharePoint project and not properly setting it up with a good amount of planning. I have talked with a lot of different consulting companies whose primary business is not going in at the beginning of a project but going in after someone tried to implement SharePoint and having to re-do a project that was supposed to be over but people were so unhappy with it that they had to bring in a new firm to help fix it. It’s amazing to me how often this happens. It ends up costing them 3x as much to re-plan, un-do, re-do. When will people learn?

Don't call it an Intranet

An interesting idea was brought up about marketing your SharePoint project internally. Don't call it an Intranet. Call it KM. Intranet term has too much preconceived notions and baggage. This does make sense at leads to another point. Bob says that if he could pick one group to run SharePoint he would pick Marketing and Communications, because they are the best ones to help communicate and evangelism internally. They are experts at it and know how to avoid those terms.

Part of the overall implementation team and the implementation plan needs to be end user training. Not enough people take this into account but think about this. What happens if you roll out a GREAT KM, Portal and no one knows how to use it other than just read the basic info on it. Very few people know how to really take advantage of the key features that really helped sell the value of the system to MGT, no one can truly collaborate and be effective? Too often this is the case. If you were rolling out a new CRM or HR application you would definitely roll out training in all flavors for this. You would have cheat sheets, self help guides etc. Why not when you roll out SharePoint? One key resource that was brought up and I have mentioned this before is do something easy like get the Sheppard’s guide. Look here http://www.sharepointshepherd.com/default.aspx It can add a ton of value with minimal effort.

Big theme of the day…

It’s not a technology issues, problem, and its not necessarily a technology solution. You use technology as a tool to help solve it. However the key to the solution is about the rigor, the process, the plan.

Functional Business Requirements and Planning

The afternoon session, it was a good big lunch so if I fall asleep while writing some nudge me..

The all important Why, What, How, know these points they are HUGE

· Why the solution is important to the organization

· What the goals of the solution are

· How will the solution be implemented?

Have a continuous review of these questions.. You may have a specific focus in the beginning, but regularly expanding that and growing based on the answers to these questions will drive additional success.

One good point is that “How” is the last entry on the list. How is last, don't worry about it till you have the other info.

Seeing Value and showing it.

Do you see value in your information and or your processes? If you do then you have to go through the processes and planning do it right. Architect it properly and run in properly on the right hardware, with the right backup and recovery plans. What happens if someone deletes a site collection or in K2 land deletes one of the databases…If you truly value this, you will spend the time to do it right. You know the saying if something is worth doing….It is worth doing right.

One piece that makes sense here is controlling requests. You could build a great KM solution that people start to use and use and use. However if you don't treat each new area, or library properly and manage the requests for them you could be a year out when people are once again saying. “I don't know where to put this document there are 5 libraries and or sites that it could go in” People at that point become frustrated because now they in the same situation again where they once were before you did all this SharePoint work. But it’s worse since you spent a lot of money to fix it.

Short tip: Take small agile steps, short sprints. Get small wins, grow evolve, let it catch on organically. Throughout the cycle, remember what worked, learn from each step, and its mistakes. I think this can be true of both MOSS and K2. Personally I would not start with the largest most complex process you have that will take 6months of work to get it going. I guess he agrees with me..:)

Some good links for information on Governance such as Checklist documents for SharePoint

http://office.microsoft.com/download/afile.aspx?AssetID=AM102306291033

http://masteringsharepoint.com/media/p/46.aspx

These are some good resources for more information on SharePoint governance.

Leading the horse to water and hoping it will drink, or If you build it and they will come mentality does not work for SharePoint. I would argue that it would not work for a lot of things like this, including K2. You have to build these systems with them in mind, asking them for feedback, knowing what they need. If you build this awesome system with tons of powerful features and the interface is extremely different from what they are used to and they are required to do things very differently than before. Trust me, they won’t use it. They will find ways to get around it.

Sit down and ask Questions Seek first to Understand

A good deal of information and knowledge can be had simply by going and talking to users about what a day in their life looks like. What do they do every day. What processes are they involved with, how do they do it? What steps do they take and why? What kinds of things do they have problems with? Now if you can really seek to understand these people and know what they are doing then you are way ahead of the curve. Imagine sitting down with several of these people and being able to help them by automating their processes. How long would it take before the news spread like wild fire? How long would it take for people to realize the value? How long would it take for that person to become an evangelist for you and tell everyone how awesome this project is? Think that would help? Now take a step further... (Probably down the road some) imagine empowering that person to help themselves. Imagine them being able to build out their own process and collaboratively publish that process with IT quickly and easily. That’s power.

Key Characteristics for SharePoint or any KM solution

· Make it simple and easy for people to get info into the system, while making it easy to know where to put it.

· Make it easy to find and navigate the system.

· Make the system capable of getting relevant search results. People need to make decisions quickly so making it easy to search and get back what they need that is ACCURATE NOW.

Taxonomies

I liked the way Bob presented out building out a solid taxonomy and how much it helps not only in Navigation but also in Search. It was good to know that I without knowing it followed some of the best practices and followed some of the hierarchies.

The taxonomies he went over were

· Document Type

· Organizational Type

· Functional Type

· Topical

· Faceted – The best for search. Which I actually used the Faceted Search I got off of www.codeplex.com it is AWESOME.

An interesting point with regards to getting relevant search results is not about crawling the content in a file through the use of “Ifilters.” The key is in Taxonomy, and Metadata, and doing this properly. He gave a great example. If I had a series of contracts and I wanted to search by customer number. If I did not have a metadata field for those contracts that was customer number the search engine would be forced to process each file and dig through it, thus indexing everything in it. So if I am forced to search for 123 (the customer number) it will return what I am looking for probably. But it will also return every other character string that is 123. Thus creating a huge list of results, and make it harder to find the good one.

How much of your content will actually be really classified and have a good taxonomy around it. Bob relieved my fears when saying its only about 30%. This can go up some with more technical environments. I am very thankful in our case since because we have a ton that needs to be done. He says 3-5 metadata fields per item. 5 is the max. That sounds good to me, I think that is good because people don't have to spend a lot of time filling in fields or in most cases not filling in fields.

Well that’s it for the day. My brain is full. I can’t wait for tomorrow though. What a class.