CHAPTER 8

Promoting a Feedback Process

// JavaScript function to open a new modal dialog window
// Pass the URL of the new item form (the survey response form) and a title
function OpenModalDialog(url, title) {
      var dialogOptions = {
      url: url,
      width: 800,
      height: 600,
      title: title,
      dialogReturnValueCallback: ModalCallback
   };
   SP.UI.ModalDialog.showModalDialog(dialogOptions);
}
  
// JavaScript callback function to close the modal dialog window
function ModalCallback(dialogResult, returnValue) {
   SP.UI.ModalDialog.commonModalDialogClose(dialogResult, returnVal);
}

On the topic of notifications, this can be a way for you to provide feedback to your users. Keeping them informed will help you head off any potential issues. It can also draw their attention to things, such as a survey that you want to use to collect their feedback and participation. SharePoint Central Administration has a great example of one of these notification bars that draws the administrator’s attention to actions they need to address. Figure 8-1 illustrates the notification bar that the SharePoint Health Analyzer displays when it detects issues.

SharePoint includes other types of notifications you will notice as well. For example, Figure 8-2 shows a screenshot of the notification that SharePoint displays after you share a site with “Everyone” on the People and Groups page within the Site Settings. Notice the little notification in the top-right notifying you that “Everyone” now has access to the Search site.

Gathering System-Generated User Feedback

Not all feedback has to come from a survey or direct user responses to questions you ask. You might have heard the adage, “vote with their feet.” This describes people’s ability to walk off and find more beneficial solutions elsewhere. A store’s customer might vote with their feet by shopping at a new store where they find better service or lower prices. Your internal customers might vote with their feet by deciding which system to use and how much they adopt it. In voting by using and adopting the system, these users are providing you with feedback.

Back in Chapter 6, I discussed some measures you can use to capture different usage metrics. Those will help give you a sense of usage and how your users might be voting with their feet. One tool in particular that will help you to collect feedback based on how your users are using SharePoint, and that is the Site Usage Analytics reports. Figure 8-3 shows a screenshot of the View Usage Reports available for a site collection. You can access these reports by navigating to Site Settings of a site, and then under the Site Collection Administration section, click the Popularity and Search Reports link. In these reports, you can gather information related to user actions or user events, such as viewed items or clicked links. You can see what the most popular site is and which of your users interact with which types of sites.

You can also use the search analytics in the Search Usage Reports to discover what your users are searching for and what they find. Figure 8-4 shows a screenshot of the View Usage Reports available for the search service application. You can access these reports by navigating to the Search Administration page for the service application, and then under the Diagnostics section on the left, click the Usage Reports link. These reports can give you insights into how they search for information and the terminology that they use for particular types of information. It can also reveal what users could not find, either because it does not exist or because the terms they use to search are different from the language of the content itself. This can also help you discover different types of popularity for information that interests your users as well as how they interact with search.

These analytics reports can reveal how your users use SharePoint. As you look at the reports, try to answer questions that will help you to build a profile of your users. Some questions might include the following list:

• What is the most popular use of SharePoint?
• When is SharePoint the most popular?
• What do users come to SharePoint to access or accomplish?
• How do they achieve these goals?
• Does anything indicate a part of SharePoint does not meet their needs?
• Is there functionality or information available in SharePoint that users are overlooking?
• Which features are users ignoring?
• What sites have users abandoned?
• Have users designed their own workaround for something?
• What other customizations have users made to their sites?

These types of questions can help you paint a portrait of your users and how they use SharePoint. To answer some questions, you will have to go beyond the analytics report and look at the site itself. I usually focus my attention on the most popular sites, because they have the highest adoption and therefore they can provide the most insights into usage. The other sites offer useful information too, but depending on the size of your deployment, you may not have time to manually review each site beyond their usage analytics reports.

Gathering all this information can answer many questions before you even survey your users. Do not burden your users with providing you with information that you can discover yourself. That way, you will know more ahead of time about the information you do have to collect from them, and you can collect it by making the most efficient use of your users’ time.

With all this information in hand, you can identify what you still need to learn from your users. Usually, this type of information is more specific to their business processes and the reasoning behind why they do some of the things in a particular way. This type of information is not apparent in usage analytics reports and surveys will usually end up missing it as well. This type of information is what you need to engage with your users to discover. You will discover this information by either interviewing them and have them explain their business processes, or by shadowing them to directly observe their business processes. In the next section, I share some tips on how to interview your users and in a later section, I look at how to shadow your users as they perform their tasks.

Interviewing Users for Feedback

It may seem as if interviewing users is an easy task and maybe should not warrant a prominent section in a chapter on gathering feedback. After all, you talk to people every day and ask them how they are doing and what they did over the weekend. I do not doubt that you know how to interact with people and ask them what it is that they do. Nonetheless, interviewing users for feedback is a little different and it requires special care if you want it to be effective.

The biggest trap you can fall into is to rely on your knowledge of SharePoint and the capabilities it delivers and to use this knowledge to drive your discussion with your users. By this, I mean that as a user tells you a problem, you begin to think right away about what that means in SharePoint, or while the users are describing what they want or how they want it to work, your mind wanders to think about how you can enable that in SharePoint. I refer to this as solutioning, or jumping prematurely into a solution design before you have fully understood the problem.

I call this a trap because it can be very easy to drift into designing a solution as you hear a problem. People inexperienced with SharePoint do this in their quest to understand SharePoint and where it might fit – perhaps they have a mandate to deploy SharePoint and they are trying to match the features to some requirements. However, this is not limited to novices with SharePoint, as experienced solution architects can often fake or bypass business requirements because they know the product and its capabilities so well. It is an easy trap to fall into, and one I try to be conscious of to avoid falling into it myself.

Jumping to a solution too quickly will blind you. You will miss opportunities that you would have uncovered by staying disciplined and focused on analyzing the business problem in depth. Ultimately, this means that you will deliver a solution that does not align tightly with specific business value. Instead, you will deploy features that are loosely associated with a symptom of a business problem. You do not want that and I doubt it is ever intentional, but from what I can tell, this is how it creeps in and happens on projects.

For me, I think this stems from my innate desire to please people, so when a user explains a challenge they have, I want to jump to a solution and give them some happiness by describing how whatever idea jumps into my mind will solve their problem. My mind wanders and I cannot control that, so I am going to get these ideas and flashes of solutions as users describe their business needs. My process then is to recognize these ideas without distracting the user with them. I usually add a quick note so the idea is not lost, and then I continue with actively listening to the user describe their processes and challenges.

Active listening is the key there. If you are actively listening to your users and asking them to expand on issues they bring up or the ways they are doing things, you will discover a lot. I try to take notes and write questions I have or things that I am wondering so I can come back to them later during the interview; this way I do not have to interrupt the user but I also will not lose ideas I can later explore. This also lets the user drive the interview while I merely prod them with questions.

As you ask your users questions, try to frame them so that the questions are both open and broad. I particularly try to avoid asking any technology-specific questions or leading questions that lead to a solution. For instance, I would consider this as an example of a poor question: Which of these SharePoint 2013 features do you think will benefit you the most? If you ever hear me ask a user this question, then you know it is time to break for lunch. Instead, I try to frame my questions so that they are more general and open, and so they are more about the user and their business needs. For example, this is a question I ask users: What frustrates you the most in your work processes?

There is certainly an art to framing effective interview questions. A good rule of thumb that I use is to keep questions focused on the user and their business processes and business needs. The following lists a few of these types of questions that I use when I interview users.

• What challenges or frustrates you?
• What do you think is unnecessary?
• What do you do that you feel is inefficient or redundant?
• How do you find things or people on the portal?
• What shortcuts do you take to speed up a process?
• What part of your day runs the smoothest?

As users think and answer these questions, they can give you ideas on areas you want to inquire about deeper. Keep asking open questions and practice active listening as they answer. This is what gives you deep insights into the business problem. User interviews are not for designing solutions; they are for gaining a deep understanding of business processes and business problems. Once you have collected all this information, you can go away to analyze it and begin to envision a solution.

Even with brilliant questions that are open and that focus on the user rather than the technology, you still may not fully understand all the intricacies of a business problem. One reason for this is that maybe the user is unaware of an aspect of their process that they do not think to bring it up. It could have always been that way, and because it has become almost second nature to them, they do not even think about bringing it up to you. To uncover these types of details and help yourself form a broader picture of the business problem, you can shadow users performing their job. When you shadow a user and analyze their processes, you will typically spot things they did not think to mention.

Shadowing Users and Analyzing Business Processes

Your first challenge when you shadow a user is to blend in – you do not want to interrupt or interfere with their work. Usually when you shadow someone, you are shadowing them for a period of time, such as an entire shift. Since your presence could include a large proportion of their day, you should try your best to make yourself unobtrusive. This is not only to prevent the user you are shadowing from regretting that they are allowing you to shadow them, but also because the more invisible you can make yourself the less you will influence the business processes you are analyzing.

Unlike conducting an interview, shadowing a user works best when you merely observe. As such, you should minimize your questions and focus on capturing notes. This ensures that you do not distract the user from the tasks they would normally perform, and therefore it will help you get a more accurate picture of how they work. If they do things that you wonder about, you might make a note and then schedule a debrief session with the user later to gather more details.

Although, it would probably be awkward for both of you if you did not say anything, so it is okay to have some conversation. I try to keep this conversation light and a little more informal as opposed to an interview. Typically, I would have a user describe the tasks that they are performing, but I would avoid prying into details of the tasks or anything that would slow down performing their normal job. This approach seems to strike a good balance between staying engaged with the user you are shadowing while avoiding causing any interference.

When I shadow a user, I like to make a lot of notes about their activities, business processes, and people or departments that interact with them. I usually draw rough diagrams about any processes or interactions, and later I can polish them in Visio. I might review the diagrams with the user later during a break or a debrief session to ensure that I understood the process correctly and that I did not miss anything. Usually, this can reveal even more as the user thinks through their processes and mentions any exceptions or alternate paths it could take.

I find shadowing users often produces several diagrams and pages of notes. It generates a ton of information and insights into the business problem, and this is a good thing. After all, you are on an information gathering expedition when you shadow users. This provides detailed, granular data about the business problem – data that you collect by observing and analyzing. I find this process is beneficial and the insights into the business that shadowing provides are valuable. However, at the same time I realize that this is not always practical or even necessary.

Admittedly, shadowing users is a time consuming activity. If you want to gather information at this level, you have to prepare for a time investment from you and the user. You also have to select a representative of the users, because shadowing every user is probably not practical or even worthwhile. Shadowing is a tool you can consider, but you will have to weigh whether the feedback and information it will collect will outweigh the time costs involved with conducting a shadowing activity with a user.

Directly observing your users provides the closest level of user feedback. You may find this approach useful for when you want to gather feedback before expanding your SharePoint service into a new capability area. This is also a useful technique to employ when you are gathering requirements and preparing to replace another system with your SharePoint service. Because it is so involved and it requires a significant time investment, I usually save it for gathering feedback I can use for major projects, such as new system deployments or service expansions.

Building Internal Evangelists

If you are providing a service that truly addresses business value, then your users will have plenty of reasons to help evangelize your service. By addressing business value, I mean that you are providing a technical solution that really addresses something that helps your users do a better job or it makes their job easier. This solution probably goes above and beyond their basic needs and it strategically adds something to the process. When you deliver that kind of value, then your internal evangelists will almost form naturally, but you can do things to help facilitate the process.

First and foremost, evangelists need a reason to get excited and be passionate about whatever they are going to evangelize. If you are following along with my guidance in this book, and particularly in those areas where I discuss offering a SharePoint service that you align with business value, then this should position you well for internal evangelism. When you offer a great service, then finding people to promote and speak passionately about it should be easy.

I am not talking about a stereotypical portrait of a used car salesperson. (I do not mean to offend all used car salespeople; just the shady ones). Your users are not walking on to a car lot and hearing, “what will it take to get you in this car today?” Your job is not to push lemons – cars that will soon break down and will only cause the owner headache after headache. You are not there simply to push numbers, or at least I am not and I assume you are not either. My process is all about driving the right solution: a strategic asset that contributes value to the business.

Internal evangelists are your power users and early adopters. The main difference between being a power user and an evangelist is that the evangelist has added support from the SharePoint team to carry the message to the masses. When you pair the evangelist’s passion for the SharePoint service with communication tools and other information that will support their efforts, you unleash an extension of your team. Some refer to these individuals as product champions, while others might just stick with calling them power users. I choose evangelists because this is a good descriptive term for what I hope to facilitate through them. It is also a consistent term with how many software companies market and promote their products in the market.

Think about product evangelists from software companies. Part of their job, of course, is to communicate and engage with the community. However, a bigger part of their job is to create other evangelists in the community – non-employee evangelists who are so passionate about a software product that it drives them to share that passion with others in their community. There are many motives for this, such as a desire to feel part of a community or a longing for recognition, but the underlying motives is their passion for the product itself.

A great example of establishing successful community evangelists is the MVP program at Microsoft. Microsoft does not pay an MVP, but Microsoft builds a relationship with them to provide them with extra product information and support, all to help facilitate the MVP’s passion for community evangelism. Microsoft has formal product evangelists, and then they have many more informal product evangelists sharing their passions in the community through events such as user group meetings. Other software companies are similar in their approach to community evangelists, and the reward for the community evangelist is a closer connection to information from the product team on the thing they are most passionate about. It is win-win.

I find this is the ideal model to base an internal evangelism program on, mostly because it has been so successful. At its essence, you need to connect with those users who are the most passionate about your SharePoint service. They want access to information and other experts who can answer questions when they are stuck. They enjoy being the voice of the service as they share their experience and insights with other users. Most importantly, they want to connect you with the frontline where they can provide suggestions or feedback to influence future directions.

Here is where you tie internal evangelists back to this chapter’s topic: feedback processes. For one, they are users from the business and they have their own feedback to share. For another, they hear feedback from their peers and can share that as well. They can see opportunities with the SharePoint service that others will miss, in part, because they have such a close connection to the business and a level of domain expertise as a business user. They may be passionate about the potential for your SharePoint service, but make no mistake, their motives underneath that passion is because they recognize how the SharePoint service offers value to their domain of expertise. In order to enable and encourage their passion, you need to provide them with tools that will support their connection and sharing with other business users.

Some tools you can use to support evangelists and promote community-based knowledge sharing include creating a SharePoint community site forum or a wiki or a blog. These sites are also a place where you can discover potential evangelists within your organization. You can even use them to harvest a lot of feedback from the comments or forum posts that different users contribute. Whether it is trouble they experience using the SharePoint service, or new ways they found to realize value from the existing service, their posts can provide precious feedback for your team.

Community-driven sites and processes offer the ultimate potential for a feedback process. Internal evangelists can seed these sites with ideas or they can moderate discussions, and ultimately these evangelists can champion any issues or opportunities back to the service delivery team. This builds on and extends the other feedback processes I discussed in this chapter, but it also likely offers the richest form of feedback that aligns with business value.

Consultant Comrade

For the full-time business analyst consultant, collecting feedback is probably how you fill most of your days. I hope some of the ideas in this chapter added tools to your business analysis toolbox. More importantly, I hope that this chapter reinforced the notion that you cannot simply go and ask users what they want from technology; you have to go and understand what makes them tick, and then use your expertise to interpret that into a technology solution.

Business analyst or not, any consultant engaging with a client to deliver a technology solution has to involve him or herself in some level of gathering feedback from the users. You can add even more value by teaching your clients how to continue to gather feedback after you roll off your project. This can be actual tools you deploy, such as the SharePoint surveys and custom web parts I discussed in this chapter. It can also involve you mentoring their processes so your client knows how to monitor usage patterns and interpret feedback from the data logs and usage reports.

One great thing about consultants, and one huge motive for clients to bring them in, is that they are outside help: they lack any attachment to an organization’s way of doing things and they lack any allegiances to internal politics. They are often oblivious to certain things that would otherwise get in the way of one’s neutrality, and for this reason, users might perceive a consultant as more objective than an internal resource. Whether or not it is accurate, this can give a consultant an advantage for collecting objective end-user feedback. This might also help you articulate another value proposition for your services.

You can be quite systematic in your process and approach for collecting and analyzing user feedback. Thinking about this reminds me of the auditing process an accounting firm can conduct for their clients. The firm would approach auditing their client’s business processes and the different aspects of their business in a systematic fashion. They would observe and trace business processes, analyze any paper or electronic forms, examine inventory management, assess internal controls, as well as investigate any financial aspects. Accountants would shadow workers in the course of performing their jobs, look for bottlenecks in the business process, consider supply-chain processes, and on and on.

If you have ever been involved in one of these thorough auditing processes, then you were probably as fascinated by it as I always am. In university, I took a few accounting courses, so I guess I know just enough to be fascinated. If I ever continued with accounting, I might have specialized in internal controls and a few other areas of management accounting. (Of course, financial accounting has its own internal controls built in to the nature of ledgers and double-entry journal entries, where I find the mathematics of it fascinating as well). My point is, this approach works for large accounting firms and is systematic to make the process efficient and to avoid missing anything. You can make your process for collecting and analyzing user feedback just as systematic and then you can use this process to communicate the value in your services.

I would start by looking at the system generated data you can gather to collect the initial feedback. This data can come from those traffic logs and usage reports that reveal how users interact with the system. You can manually look at actual sites to see how users interact with the system. You can review service requests to read what users struggle with using. All of the system-generated techniques in this chapter will help you to make this first pass and build some initial insights into where potential problem areas may exist, and what you want to learn more about, such as what survey or interview questions you will want to ask. From there, you can build a survey to test some of your theories of potential challenges and fine-tune your insights into any usage patterns or usage struggles. Next, you might shadow users in the course of performing their jobs to observe their processes and identify areas where they struggle or face some level of obstruction. Finally, you can use this data to help you design your user interviews and the areas where you need greater insights or feedback.

Once you gather all this information, then your job is to go away and analyze the problem. I mentioned it earlier in the chapter, but it is important, so I will mention it again: for any issues or opportunities that users raise, you need to avoid thinking about how the issue would translate into a SharePoint solution. I am always shocked at how quickly an analyst jumps to a SharePoint feature when they spot a usage problem, or when they let their mind wander and think about SharePoint implementation details while users are describing the business problem. If you do this with too much regularity, then you have not yet learned the ways of an effective business analyst. Luckily the techniques I have given you in this chapter will put you on the right track.

I refer to this process as solutioning and it is probably my greatest source of frustration on a project if I have a team of novice or inept analysts who constantly jump into solutions before they truly understand the problem. If you are an analyst and you are working on a project with me, your job is to analyze the problem – to truly understand the intimate details about how users work and where they face challenges. Once you have the problem defined, then it is time to work with me or another solution architect to further analyze what you discovered and to start envisioning potential solutions together.

The time to design a solution is not when you are listening to your users telling you about their challenges or business needs. I do not mean to rant here, but I am stressing the point because I frequently observe business analysts who are interviewing end-users and they immediately jump into a solution. They hear a familiar phrase from the end-user, such as one describing a coordinated process for gathering information. Then, as if it has activated a switch with the analyst, they begin to ask leading questions that are SharePoint specific, such as whether a workflow and an InfoPath form would solve the problem. It might, but the user probably does not even know what that means unless they have subject matter expertise. There could have been a different solution to solve the problem and provide greater value, but the analyst missed the opportunity by focusing on a solution too soon. For example, you might discover an automated process that works with e-discovery to coordinate and combine information, but you will miss this if you pigeonhole yourself into a workflow solution too quickly.

If you narrow in on a potential solution too quickly, you will miss a deeper understanding of the problem and the potential for uncovering other opportunities. Worse still, once you prematurely mention a potential solution to your end-users, then they start to form expectations. Understand the problem first, and then go away to envision the solution. As an outside consulting services provider, you can articulate this as a value proposition included in your systematic process for collecting user feedback, analyzing business problems, and envisioning optimum SharePoint solutions for your clients.

Inside Story: Notes from the Field

Years ago, I was working as a SharePoint administrator managing a few farms. One of the challenges I faced was that people could use whatever system they wanted, whether that was SharePoint or some other server product an IT group offered or a cloud service provided. On the surface, this might not sound so bad as I can focus on providing better service to those who chose SharePoint. However, this was during tough economic times and the company seemed to go through waves of layoffs, and so I certainly wanted to maximize demand for SharePoint, and thus demand for my position.

I needed to attract users to the SharePoint service, and often I had to compete against collaboration and wiki products users were already satisfied with and used to using. Now I was not just pushing technology for technology sake, instead I focused on standardizing a platform and consolidating our infrastructure. Ultimately, the business case was to enable a greater permeation of collaboration. With a consistent platform across departments, franchises, and business units, my users could reach greater cross-team cohesion.

The vision and business case sounded great. Nevertheless, its value depended on everyone adopting a common platform, and so I could not directly link any immediate benefits to motivate adoption. The greater trouble was that no one was going to mandate it either. My only option was to build a great and compelling service, and then to evangelize it across the organization. I needed to offer compelling value that directly aligned with the type of work that users needed to do in their job function.

Early on, I discovered that users across the enterprise lacked confidence in IT systems in general. It seems the organization experienced data loss at times, and systems were not always reliable. This was true, it seemed, with every system in production operations, at least from the perspective of most end-users in the business. Their perception was that IT did not understand the business or their job function; IT just did not engage itself as a business partner as far as they were concerned. They almost thought of IT as an adversary: a group slowing them down and inundating them with needless policies and procedures rather than seamlessly working behind the scenes to support them.

Here sat my challenge: how could I attract and connect with users to deploy an effective SharePoint service when they did not even think that IT had their best interests in mind? If they doubted I wanted their needs to drive the solution, then why would users ever make time for me? My users were very busy, so it is hard to schedule time on their calendars anyway, and especially if they perceive it is for another IT-focused project that my department is forcing on them.

Engaging users is difficult if they do not think of IT as a business partner. This is where some of the other feedback techniques I looked at in this chapter can come in handy. In a way, I can sleuth together some of their biggest pain points by analyzing how they interact with systems and what areas generate the most complaints. If I can uncover a few key problem areas for strategic influencers in the business, then I also uncover my path to engage with them. When they see me being proactive and solving issues for them, then they will also warm up to the idea that I am engaging to build a partnership with them and add value to their business.

A proactive path to engage a reluctant business user is one that removes a headache for them first. It builds goodwill and demonstrates my commitment to providing a service that aligns with their needs. For example, I had users who wanted to view design diagrams embedded within a web page. Currently, the team was using a wiki page with JPEG images, but I sensed that I could offer a richer experience in SharePoint. Now, this was before the Visio viewer functionality available in modern versions of SharePoint, but I still knew that Visio was a rich diagramming tool for processes and layouts. Knowing that Visio worked well with SharePoint, I developed a web part that wrapped a Visio viewer component in HTML to display on a SharePoint page. Anticipating this value, I was able to make this rich diagramming experience available in SharePoint with all of its collaboration functionality, and I addressed their desired web experience as well.

Sometimes addressing the problems and desired experience can be as simple as my embedded Visio example. Sometimes they will be more involved. Whatever the case, the process is the same: gather feedback from your users and come up with a proactive initiative that will solve problems for them or add business value. Accomplishing the initiative itself is good, but it reaches beyond whatever endeavor you are addressing and it nourishes relationships between your IT service team and your business users. It is an approach that bridges a connection and contributes to a healthy service that your users adopt.

This approach resonates with your users, and it has a ripple effect that builds momentum across the business. Similar to the adage, actions speak louder than words, proactive actions that anticipate your users’ business needs will speak loudest of all. They will be the most authentic and in turn, they will encourage a rich feedback process. When your users see you take such initiatives that make them and their needs your priority, they will feel encouraged to make the effort and share their valuable feedback on how to improve the service. Surveys and analytics can help, but when you build a relationship between IT and the business into a close and strategic partnership, then you will unlock the most valuable feedback.

Wrapping Up

In this chapter, I discussed different techniques to capture user feedback on your SharePoint service, including feedback on new opportunities where the service can expand to add additional value and feedback on what problems interfere with their ability to perform certain tasks. I discussed how to capture feedback by using surveys and analyzing system generated usage patterns. From there, I looked at how to interview and shadow users to gain insights into their business processes, and I considered how to use feedback to detect potential adoption issues and to build internal evangelists.

Not all your user feedback will relate to your users’ experiences on the existing service. You may also experience a different type of user feedback where user enthusiasm for new features can place demands on what your SharePoint service offers. In the next chapter, I look at how to manage and prioritize these demands for enhancing and expanding the SharePoint service. I pay particular attention to how you can manage and funnel these improvement requests while setting user expectations and avoiding being pulled off course.