SharePoint can be scoped into three areas of professional competency, with very few people being competent in all three and the fourth category being users. When thinking of these tips, I have to ask myself to whom am I giving the 5 tips to: SharePoint Architects, SharePoint Administrators, SharePoint Developers, or SharePoint End-Users.

SharePoint is one of those fantastic products that third-party solution providers can literally make fortunes off of producing workaround solutions for sale. As I say this, I can think of about 20 different tips to give you. Then again as I look at the list, I can see ten really good tips that can turn you into a SharePoint deity. Even better, looking at those 10 tips, I can see five acutely dangerous tips that will make you a SharePoint Zeus. If you are ready, put on your serviette, take out your cutlery and let’s cut this piecemeal to shreds.

We know what this powerful application server can do. In a business sense, we can use it to create “sites,” as we call it, or, in layman’s terms, websites. We can use it for social computing, forums or communities. We can use it for content management. We can use it for search like Google, Bing, Yahoo, and the rest of them. And we can use it for business intelligence, reporting, dashboards, and other cool things that make a business agile, such as plugins into other line of business (LOB) applications to mine and interpret data.

In my top 5 things to know that will make you an instant authority in SharePoint, the first isn’t technical; it is actually in the common sense domain:

TIP #1: IT IS ALL ABOUT THE BUSINESS REQUIREMENTS

The first step in your journey as a SharePoint authority is to know, and know again, and without forgetting, that it is all about the business requirements. Everything that you throw into your SharePoint farm must support this requirement or be the requirement. You cannot afford to add a feature or a third-party add-on that you “feel is good” for the farm. It is not about what you feel is good; it is not about giving the client more than they bargained for in features. It is about staying true to the requirements given.

Any attempt to gold plate this requirement can be interpreted as something negative against you, either now, or in the future. Your intentions may feel good, generous, heavenly and to the progress of all humanity on planet Earth and in space, but I can assure you that in the business world it is not about generosity, kindness or virtues, it is about business. So, you need the discipline to stay true to the document. It is an absolute necessity; otherwise your business integrity may be at stake.

One of the reasons to avoid feature overload, except a part of the requirement, is because you cannot exhaust all the features that SharePoint has to offer. If you load it all in or activate them all, you will find that your client might get overwhelmed by them. However, if you are in a non-business environment, meaning you are playing around with SharePoint with a team or on your own, go ahead and play with all the features you have. This is what every SharePoint expert does in their spare time. This is how we master it, how we know what is what, what does what, and what meets what requirements.

To do this successfully you need to do the following:

  1. Ensure your stakeholders’ team comprises the business team, the technical team, and the key users. This means you have to be talking to the right people. I have seen scenarios where top management is the only people in this ensemble. This is both good and bad depending on the internal structure of the organization. If you do not get this right at the beginning, you will have a dead-on-arrival job on your hands, just a time-bomb waiting to blow up in everyone’s face, and the most interesting part of it is you will be the fall guy. Ensure you have the right crop of people so that when you get to item two below, you will get the right results.
  2. Typically, you will be provided with a document containing the business requirements prepared by a business analyst. Read the document thoroughly and prepare your questions. In doing this, do not ask technical questions directly, but ask the right business questions even though in your mind it maps to a technical solution. Do not focus on SharePoint as a technology and do not attempt to sell it as a platform, except when you observe that your client is already brand loyal to SharePoint. It will all end in SharePoint anyway, so it does not make any sense to do product loyalty on your client. Your questions should focus on getting clarity and avoiding ambiguity based on the document you have been given. If it happens that you have not been given any requirement document, and your meeting, for whatever reason, is the requirement document, make notes of the discussion to create your business case document.
  3. Discuss the licensing options and budget. I have seen cases where licensing is already handled by the client, and I have seen cases where you as the professional have to handle that. Remember also that licensing does not end with just SharePoint itself. How about additional software that will be used such as Microsoft Office, Microsoft SQL Server, Microsoft Exchange Server, Microsoft Lync, etc.? These are applications that are required in any business use of SharePoint. Identifying these and the licensing options is very important.
  4. Maintain, review, communicate, and obtain validation or sign-off on your interpretation and/or perception of the requirement document. Keep revision records of these documentations. As your work progresses, changes will unavoidably come in, and it is always due to either business environmental factors or technical internal infrastructure constraints of the client. When these changes come, document them, communicate them, validate them, and obtain a sign-off. As your work progresses, document your work as well, knowing that at the end it will serve your client’s end users, administrators, developers, and key stakeholders.

This is a story-note for making sense out of the above point. John Doe wanted to learn how to drive a car. So John Doe went ahead to learn about steering a car, engaging gears, accelerating, braking, parking, using the wiper, topping the gas tank, changing the engine oil and cooling the engine. Using the horn and turning on the heat and aircondition. He even learned how to change the tires. John Doe was so good at these things, he successfully drove a car in his father’s backyard in three days. Well, sad to say that John Doe died on the fourth day. Did you know why? John Doe did not learn about traffic rules. So John Doe is dead.

What that means is this: it doesn’t matter what you can configure in SharePoint. As long as it does not align with the client’s needs as documented in the business case, you will be considered a failure whether you are a SharePoint architect, administrator or developer. This is my first tip in your journey as a SharePoint authority.

Tip #2: SHAREPOINT ARCHITECTURE

This is the second most important aspect of SharePoint mastery. Architecture is a big word, and a big buzz word. We can talk of the architecture of just about anything in IT. In fact, the mere mention of it in any discussion, even if you practically know nothing about IT, is enough to make anyone listening to presume you are an expert on the subject matter. In SharePoint, architecture is of two domains or knowledge areas. The first is the physical and logical architecture. The second is the programming or functional architecture.

In the physical and logical architecture you need to be able to do the following successfully:

  1. Logical Architecture – This is the part of SharePoint that makes your solution map to the business requirements. They include but are not limited to:
    1. The client needs a platform to host all their activities. The solution to this is a SharePoint farm.
    2. The client wants a tool that can let users access resources. The solution to this is service applications and web applications.
    3. The client wants a portal accessible to internal and external users with security. The solution to this is zones.
    4. The client wants users to be able to store small to large volume of files and be able to access them easily, and these users work in departments and different entities within the company with varying needs and methods of working. The solution to this is content databases, site collections, sites, lists and libraries, items, and workflows.
  2. Physical Architecture
    1. Hardware
      1. Storage
      2. Memory
      3. Network Load Balancing (hardware type)
    2. Software
      1. Windows Server 2008 and all required server roles
      2. SQL server database configuration
      3. Messaging/SMTP configuration
      4. Network Load Balancing (server software type)
      5. All required SharePoint roles and prerequisites

It can be quite overwhelming to drill down below this point, but if you can have a grasp on this (not necessarily on nitty-gritty as I would have loved to do, perhaps in another write up) you are well on your way to being a SharePoint authority.

I remember a SharePoint 2010 deployment that had a bottleneck around this area. The environment had 80,000 likely users and spanned the country, with users in disparate geographical locations onshore and offshore. At the end, the farm hosted 24 servers, from physical to virtual, and marked one of the biggest single purchases they had ever had in a single platform.

It took a lot of reviewing, with questions asked over and over as to storage because of the need to envisage future data growth. I remember one manager who couldn’t but blurt out, “Is this really necessary? This is overkill!” He could not figure out why one server should have 32GB of memory, all being 64bit. All this drills down to performance, high-availability, traffic, and with branding and thousands of workflows running, you don’t want to be fingered as the culprit for an irritatingly sluggish, slower by half than a snail, SharePoint farm.

TIP #3: SITE COLLECTIONS AND WORKFLOWS (Out of the Box and Custom)

This is the next tip I want to give you in being an authority with SharePoint. It will be plain useless if a farm is ready but it cannot be used for business. In this sense, to be used will imply providing it as a solution to real business problems; namely from the most mundane and simplest functions to the most complex functionality any end user could ask for. You have to master site collections and their components and turn it from just being a storage repository for files to actually being or aiding as a process management tool, or anything whatsoever your client may want it to be.

This comes with good knowledge of:

  1. Metadata management skillsets – This is the component used in building forms, and is the building block for triggering workflows. These in turn produce data and properties for classifying or categorizing data. This unit of data manipulation is required in every conceivable tool SharePoint can be used to make, such as providing references, filtering views, displaying relevant information, and, because metadata is indexed and searchable, it is a key to information retrieval in the SharePoint search engine.
  2. Content type management – A content type is an aggregation of columns and the data type they are intended to store. You can use this to represent types of files such as a travel request, project proposal, or business-specific document types, and is useful in providing re-usable templates across multiple site collections, and if published as a content type hub.
  3. Enterprise search working knowledge – This is an automatic value-add in any environment. If you can get your search engine working, your users are definitely going to be happy.
  4. Out of the box workflows and custom workflows – Using predefined out of the box workflows can help solve process-related business problems such as document review, content review, document approval, publishing approval, among other things. In scenarios where this is insufficient, knowing how to use SharePoint Designer® comes in not just handy but vital. You can create just about any complex workflow and triggers to run either independently or with dependencies. These workflows can be doing calculations, sending emails, updating column values, creating new items, and so on. This is one of the parts where SharePoint is indeed a valuable business tool.

 

TIP #4: BUSINESS INTELLIGENCE

At the core of business intelligence is timing (is the data or information on time, slightly before it is needed, or exactly when it is needed), accurate information (is the data or information correct or a correct representation of what it is expected to represent or be) and based on these two, a well-informed business decision making for business decision makers. This is what Business Intelligence (BI) does.

This tip is relatively deep, and I intend to stay at the surface of it, and mastering a few BI techniques is vital to being a respected SharePoint authority. BI comes to work in any organization using SharePoint in either one of three ways or all of it altogether. There is personal business intelligence and self-service. The second is business intelligence for the community, and the third is business intelligence for the entire organization. Perhaps I really should not put it into segments for the fact that the implementations are not different techniques, just the scope difference – namely the audience consuming BI.

The tools and techniques include Excel services which enable you to store your Excel workbook on the server, a place we call a trusted location, and then to publish that to users who view through a browser and can interact with the data, and with the perks of permissions. With Excel services alone a whole lot can be done. I have seen several implementations of this using web parts that do amazing things (dashboards, KPI, with some Silverlight® or Flash Player® runtime) and deliver the right results to the business.

Apart from these you can also use data from other business applications like SAP, Oracle, Siebel, SQL, and just about any other. This allows your users to connect to these external data sources without leaving the SharePoint page they are working in. Other tools include using Visual Studio® Business Intelligence Development Studio (BIDS) to create the components you need working with backend SSRS (SQL Server Reporting Services), SSAS (SQL Server Analysis Services). I am apt to want to dig into this even deeper, but suffice to say that these skills are not as hard as they look.

TIP #5: USER SUPPORT

This is the last tip to the pinnacle of being a SharePoint authority. You need to be there to help your users resolve their issues. In any fairly sized environment where SharePoint is used, it is impossible to have a day go by without a call from at least, best case scenario, one user. The call can be about anything as mundane as looking for the upload document button, which the user will tell you it was right there before close of work yesterday, or last week Friday, or even this morning before he/she shut down the computer, and now it is mysteriously gone, and they could ask if they should reboot the computer to resolve it, that is if the computer has not already been rebooted twice before you were called.

Don’t get mad. And don’t laugh on the phone either. You never can tell, who knows, you may have injected a jQuery or few lines of code somewhere that is hiding the button. You don’t want to laugh at your user which is unprofessional in the first place, only to discover you are the culprit.

Learn and hone basic, intermediate, and advanced user support techniques to make your users happy. Make available user guides or manuals for sites you create that are a little bit working off the normal way SharePoint user interfaces or controls work. It is good practice to make these guides and how-to’s available on the same site or the intranet store somewhere, and perhaps in leaflets or soft copies ready to be emailed to users who need them.

There we go! This is where I wrap up on my 5 tips to being a SharePoint authority. Perhaps in another article I can give you other tips for being an authority in specific SharePoint aspects that aren’t as general as this one. SharePoint is a huge product, and is hard to dissect in few pages. But I assure you that if these 5 tips I have given you is in you, and abounding, they will make you neither unproductive nor unfruitful in your SharePoint authority, and power, and empire, and kingdom building quest.