OK, before we go further, let me clarify. Yes, of course you have to map the process and understand where information is and what exactly is being brought together for consumption. What I’m going to go on about here is what happens when we build out that process.

So anyway, there we are with our construction paper on the walls and enough flow charts to trawl for fish! We map everything out, model it, test it and get user feedback. At the end of the day (well, really at the end of your SDLC) you have successfully replicated the user’s process and now they use this new process to do how they used to do.

Wait! But what did they used to do? It doesn’t make sense to build anything that does something the business already does unless there is some value added. Most of the time that value is in a saving of time and effort, but why are we replicating the process? We should be looking at what exactly they are trying to accomplish. I’ll make up some kind of example here to illustrate my point, hopefully (if not, at least it should be entertaining).

Let’s say John is explaining to an analyst how he handles parts in his shop.

John: “I have a pull cart for this part.”

Analyst: “Why?”

John: “Because it’s too heavy to move.”

Analyst: “Where does it have to be moved to?”

John: “The other side of the building.”

Analyst: “Why does it have to go there?”

John: “Because it needs to be painted.”

Analyst: “What do they do after they paint it?”

John: “Oh, after it dries they bring it back here so I can put it together.”

So the flow gets mapped out and they build a conveyor belt system to move the parts back and forth. And there was much rejoicing!

OK, don’t get too picky with the analysis, just follow along. So here we see a solution built out to improve the process, but the real question should have been, “what do you do?”

John: “I get parts, send them to be painted and when I get them back I put them together.”

Analyst: “So you assemble the part after it’s painted?”

John: “Yes. Once it comes back I put them together.”

So looking at the what, instead of the how, we decide we don’t have to build anything to move the parts around, instead we just move the painting area next to the part area and now they don’t have to move the parts around at all. Less down time waiting for parts to move around, less chance of a mishap, etc. This is because what they are doing is painting and assembling, but how they did it was by moving the parts around the shop.

All kidding aside (and cheesy example), I have seen time and time again, not just in my business, but in others’ as well, that the process gets mapped and then built and in the end the users get something layered on top of their workday to accomplish what they were already doing just with a different tool that doesn’t bring additional value added.

So all I’m saying is to think of what needs to be done when developing solutions and not just how it’s done. You’ll end up with not only a better process, but a more efficient one with added value and everyone will wonder how they ever got things done before.

A most important step in beginning any change to their process is to start with the people and engage them. They need to know you’re here to help them, that any change will be driven by their needs. It’s as simple as asking them what their pain points are with their current day-to-day and what they wish they could have different. You need to partner with them and help deliver “their” solution. Remember, you’re supposed to be the guy with “people skills”, or even better, you’re the conductor. Everyone plays their part and it all comes together.

In the end, when you walk away and have improved the process, they should be feeling like they accomplished something, and everyone takes a bow.

First, @SharePointLee gave a great presentation regarding the five personalities of SharePoint users. Everyone seemed to know someone that fit into one of those personalities. I myself was the investigator. I always need to know what we can do, how we can do it better, and of course, can I have it now! Head on over to SharePointLee get this and other great information about SharePoint.

I ended with Christian Buckley speaking about metadata. He is a SharePoint Evangelist and Senior Product Manager for echoTechnology. He had us think about a centralized model vs. a decentralized one. Food for thought. Check him out at BuckleyPlanet.

Next time a SharePoint Saturday comes near you, be sure to heck it out. I am sure you will get some good information out of it and meet some great people at the same time.

It’s FREE and open to the public, so don’t miss out! See you there!

Check out http://www.irmuk.co.uk/bpm2010/ for full conference information, e-mail customerservice@irmuk.co.uk, or call from the US 011 44 208 866 8366.

Maybe I’ll see you there!

Today I ended up at the receiving end of some foul words and dismal attitudes regarding a limitation in a system. I’m sure many of us have been there before, where the end user is complaining about something the system “ought” to do, but doesn’t. However, in this situation it was actually by design.

I recently sat down with several Stakeholders where we reviewed the current process and it was unanimously decided that there should be some limitation on a particular process. Only certain users should be able to perform a particular function within the system. So we clarified what our next steps were and we went back to our respective cubic-hells. I went on to submit the changes, prepare documentation and procedures. All the usual stuff. The Stakeholders went back and each had respective meetings with their staff. All was good in the world. Right? Nope!

Apparently they did have their meetings, but didn’t actually inform the staff of the changes. So naturally you know what comes next. I get an email from a user that the system isn’t working properly. It won’t let them or their colleague perform a needed function. I immediately went over to the users area to assist them, but it was too late. I got an earful about ..well basically everything.

In the end, the users were referred back to their management where they were then properly informed of the business decisions made resulting in the change for entitlements. While still not thrilled with the change, at least they now understood the reasoning behind the changes and that went a long way to placating their feelings.

Lesson Learned: Even if someone, such as stakeholders, are tasked to communicate information to the user base, be sure you have something in place to confirm that supposed communication took place. Otherwise expect dissent!