Office Over Easy

Whenever I’m trying to convince someone to do something for other people, especially when it comes to asking a technical person to document their processes, I always say something like, “when you get promoted because of the success of this project, this document will be the help you wish you had to get started in this role.” I never really liked the image of getting run over by a truck that my successors used to try to convince me to write down what it is that I do. Sort of seemed like a curse or a dare to the universe that once the process was written down that I had fulfilled my purpose and it was okay to off me. What a horrible thing to wish on someone. It was as if keeping that process in my head was the only thing keeping me alive (anyone read Terry Pratchett? That was a theme from one of his books).

As much as I loved Seth Godin’s Tribes, I don’t really follow him on this indispensable theme he has in his latest book. I suppose that most people consider being indispensable a good thing. Everyone wants to feel secure and needed, right? I’m all about problem finding and niche work and knowing your value, but I don’t confuse that with the selfish act of wanting to leave a company at a deficit because of one person’s influence or knowledge. I’ve been indispensable and it’s lonely and stressful and you never get promoted because when you’re indispensable, no one is motivated to develop you out of that role. I don’t want to be insignificant but I wouldn’t wish a truckload of indispensable on anyone.

My advice when I consult companies on how to make SharePoint change the way people work is to make sure that everyone knows how to do the job one level up and one level down from them to ensure that they all know how their assignments and deliverables fit into the big picture. If they have to fill out a status report, then make sure they see how that rolls up into their annual review. If it’s a required process, then tying it back to their bonus structure is a lot easier than hounding them every week to turn it in.

Have your business analyst design a solution to:

·         Create a new report – Start with the form they are using now and see what you can do with it. Give them options and show them a side-by-side comparison of what it looks like to use a custom page layout compared to assigning an existing template with a content type. Show them what a forms library looks like to the end user. Weigh the advantages of each against the effort to change the way people work. Remember that a file storage solution doesn’t sell. Why do they have to save the same document in a new place? A change in layout reinforces the change in location.

·         Destroy the old report - After they buy into the technology proof of concept, take the opportunity to analyze what the report is used for. Are employees pouring their hearts out in bullet points while managers scroll to the bottom to see whether or not the employee is planning to take any vacation this month? Streamline it so employees are only reporting what’s being used. I haven’t met a person yet who loves reporting, so if changing the process minimizes the effort to complete the task, you won’t be able to change this process fast enough.

·         Document the process - Don’t ever guess what the business need is and don’t believe what the business says is the problem until you get everyone into a room to agree on the current process.  For best results, try to have a rough outline complete – that may come from an administrative professional who compiles everyone’s reports or a manager who approves them. Most analysts stop there. Don’t. An individual opinion is just perpetuating what’s probably wrong with the process. The next step is to get the workers into the room and go over the swim lanes with them. I typically find that the simplest task branches out depending on circumstances.

With the workers, don’t start with them submitting the report. Start with how they find the report template. Are they opening up an old one and using file save as? Are they all using the same template? Do they have to wait until they’re in the office or on the network to submit the report? What else can delay the process of getting it turned in on time? Are they waiting for other people to give them information? If so, then how are they getting that information? Is the process consistent for all managers or do some departments do things differently? What are the consequences if the report does not go out? Would anyone notice or care? While they will all agree that something is being done a certain way, most will have an opinion on how it should be done or what would make the process less painful for them. Take good notes.

·         Do something new – don’t try to solve a problem until you get buy in that it’s a problem and that they want to fix it. That’s why this is the fourth step and not the first. I see a lot of analysts ‘fix’ something and then the user looks at the trainer and says, ‘what was wrong with the way we were doing it before?’ At times like that, you don’t want the answer to be, ‘because it’s new and new is fun, right?’ No. No it’s not. Not to a process person. If you’re going to change a task that took 12 easy steps that they’ve been doing the same way for 24 years, then you better have a good reason. You better be fixing something that the user has complained about for the past 24 years. Replacing 12 easy steps with 10 hard ones isn’t helping them get back to their actual jobs any faster.

Before you propose a solution, you need to know how this report fits into the department and get it back to something that motivates the employee. It doesn’t even have to be something that affects their bonus. It could be something that makes the end of the year report they have to do easier. Why solve one problem when you can solve two at the same time. Wouldn’t it be awesome if there was a check box the user could click when filling out a weekly report to have that item automatically show up on the performance review they have to do at the end of the year? As a manager, wouldn’t it make sense to have the weekly report tie back to departmental goals to ensure that everyone is focused on the work the group is being judged on? Instead of telling people to document what they’re doing, how about having them report on what you told your boss they’d get done this year? Is the weekly report different in format than the annual review? Does it have to be that way? Is there any way you can get both processes into alignment? Can you make the weekly report a monthly report instead? Is it possible to eliminate the report all together by opting instead for a weekly meeting workspace that tracks decisions and tasks? All options are on the table but make them pick one that will work. The more they stray from the familiar, the harder it is to get people to change. Think baby steps. Maybe the meeting workspace is Phase II.

·         Develop and test – You got so excited that you almost skipped this part, huh?  The truth is that it’s typically best to let a fresh set of eyes take over. The mistake I see a lot of analysts make is that they are not the best versed on the technology. Talk to your developers and other analysts to review the solution and make sure there isn’t a better way or something available that you didn’t know about. If there are two analysts than there are two solutions. Getting consensus in IT for providing consistent solutions is a big win for the business. This is not an isolated case in one department. This solution could have far reaching implications and when another department sees it and wants it then their analyst needs to know how to do it too. This is where the indispensable thing really chaps my hide. Don’t be the bottleneck in the IT organization because you want to horde a solution. It doesn’t make sense for everyone to have to wait on you to do this for them. Worse is the fact that steps are more likely to be skipped as you do more deployments. Then, the analyst starts to think that because everyone is having the same issue that they all look the same. They start to think that taking the time to get everyone in a room to document the process is a waste of time or skimp on the next step so they can hurry up and help the next group. If you hear yourself cut off a client to say things like, “I know what you need” or “We’ve seen this before in another group,” then you need to slow down. Always start with the old form. Always get buy in that it’s not working. Always document the existing process. It’s not new to you, but it’s new to them. Don’t ever forget that. Stick to your process of how to improve their process.

·         Train them on the new process – Redraw the process map and call everyone back in the room for a hands-on demonstration. In this example, you would show them how to fill out a status report and submit their annual review. Make them all do one together – from finding the form to getting it approved. Make sure the manager attends this session and make it required. This ensures that someone sat them down and told them that they had to do this report differently from now on. Users need a roll-out. Do not skip this step or there will be a painful transition of some people doing it the new way and some people still using the old form. Management needs to enforce the new process by not approving anything done the old way. Workers need to hear managers say that to them out loud. There is no excuse for not changing – we did ask you what you thought.

·         Evaluate the new process – Check back with the client after a few weeks and then six months later and each year after that. Don’t let it go another 24 years before someone is willing to fix the process to meet the needs of the business. Are they ready for that meeting workspace solution yet?

Process is the great unifier and a perfect entry point for IT into the business. It’s a great project for people who are new to the industry and it puts IT back into a position of helping people do their work more efficiently. Don’t just roll out SharePoint and wait for people to figure out how it can help them and don’t roll out training that mimics the marketing presentation the vendor gave to the CIO. Make SharePoint matter to them. Make sure it makes a difference.