Translating your process into Nintex

"Know your process”, this seems like a simple, straightforward statement, but I found that many users just do not know it as well as they should. I wanted to share my thoughts, findings, and approaches on how I tackle this within my own company and hope to hear about how you, as a workflow developer or form guru, approach your customers.

Initial idea

We all have been in those meetings where someone says "this would be a good candidate for a SharePoint workflow and/or form", and dread the next steps (or you get giddy and excited over a new chance to prove your skills...I geek out way too much!). The flood of a million questions starts to pour in: Why SharePoint? Are we replacing something existing? Is the current process broken? Who owns this? And so on. For me, I take this time to gather my own information. I pour over the current process as an end user and see what the experience is TODAY, and take notes on its strengths and weaknesses. With this in hand, I can hold an intelligent conversation with the process owner as well as the stakeholder.

Requirements Gathering

There are a lot of different approaches on this so I am going to stick to what I know and what works best for me. I will meet with the process owner; the one that uses the form the most or manages the process. This way I am really getting the most out of what NEEDS to happen rather than what people WANT to happen. Here is where I see what the process does behind the scenes and begin to understand how we can translate it into SharePoint and Nintex. This is also when we see just how much of the process is unknown, undocumented, or (my favorite) "well that is just how we have always done it". At this point it can go one of two ways; start developing a solution because the process is detailed out and you have a clear understanding of what needs to happen (I am beginning to think this actually doesn't happen...) or we go back to the owner and help them detail out their process.

Detailing out the process

Let’s say that for some crazy reason your process is not detailed out (pretend if you have to). What I like to do is get the process owner involved. They can tell me what happens for each step at a high level. I have even started to ask owners to create a simple Visio diagram of the workflow so that way they can visualize it, but if I cannot get that piece, I generally white-board it out. This also lends a hand to the owner so they can see just how the process works and see if they are missing or overlooking something because it has been ingrained in them over the years. I try to ask questions along the way and challenge the process where I can; do we need to email them multiple times or can we do it once at the end? Do we need to do multiple web service calls or can we consolidate down? Sometimes we find new ways; sometimes we learn that it HAS to be a certain way due to security. Either way, it gets both sides involved and understanding the process inside and out. It helps to show all of the expected outcomes and what items are needed along the way. Once I have this, I have a blueprint for what I need to develop.

Developing a solution

For me, I spin up a site in our test environment and start building. This gives my customer a tailored site that is just for them and it keeps everything else clean; I know what I am testing and where the tests are located. Once I have a stable version of the process, I open it up to the customer and say "have at it!” I force them to meet with me, face-to-face, and review what they like, dislike, want, don't want. The reason I do face-to-face is that emails get lost, glazed over, and generally ignored. This forces the customers to engage with me and take a look at what is going on. It also allows them to have a voice and feel as if they are building it too. I ask the customer for when they want to start using it and try to manage expectations from there. We all know that this is not one and done, but a reiterative in nature. Meaning that it takes time to develop, a lot of back and forth, but we can provide working solutions and with customer feedback we can refine the process as it evolves.

Going back

All too often we deliver a process to a customer and a few weeks later they reach out and have changes. This is because they did not account for something or the user experience is not exactly how they envisioned it. This is generally not a big deal since we can update workflows without taking outages. We can update forms without major interruptions. We can add new logic to lists without anyone noticing. Even if your process is "set it and forget it", I do encourage you to go back and take a look at it again and ask yourself is there a better way? I find myself learning new things from this community every day and am blown away how much knowledge and passion there is out there for Nintex.

Please let me know your story and what tips or tricks you use to translate the needs and wants into working Nintex solutions.

Great topic. I like to get the customer to document their process. I prefer them to document it in Visio if possible. That really helps when you are converting it over to a workflow. I also see that there are a lot of processes they do manually that can be done by the workflow. For example, I had a customer who would during his process total different fields. I said Nintex can do that for you and save you a lot of time. Imagine the time he saved calculating totals every time he entered a record!!!!! He couldn't believe he didn't have to do that anymore. There were quite a few other places in the process that became automated instead of manual. The lesson is just because they have a process, doesn't mean it can't be improved. Find ways that Nintex or SharePoint can help.

I recently discovered that a step in a workflow that I am build was overlooked because the users thought we could not accomodate the process. At first glance, we took it as truth and just allowed them to continue with that step being manual. I did some digging and got my hands on the code (insert evil laugh ) and I find out that all that happens is the system sends an email and some ancient database consumes it and adds a record. I went back and asked why they thought we could not handle this and the response was they did not realize it was that simple.

Point of the story is even when someone says it is too complex or cannot be changed, challenge it. Not in a way that they get defensive, but ask questions to have everyone understand the process; what happens, what triggers what, what systems talk to each other, etc.

Needless to say, I added the notification step into their workflow in a day and same results; saved time and effort!

We're in the middle of UAT for a Nintex & SharePoint project and I remembered asking end user to draw up a list of requirements and process flow during requirements gathering. It was met with a "oh don't worry about it, the process is really simple. We just need to be able to review, approve or decline documents between two teams".

I asked the user to at least prepare a document outlining the steps and would be helpful if it came with some form of diagram to help with the discussions. The user reverted with a one-pager which was clearly insufficient (in my head).

I engaged one of the BAs to whiteboard and after a few sessions with the user and other players, we ended up with a 3 page visio diagram.

Needless to say the user was shocked with what the process really looked like 'behind the scene' and the development phase of the Nintex/SharePoint solution went rather smoothly.

When building out your site and workflow architecture, I think it's so important to document your process in different ways. I think the most valuable training / transfer information for the process is developed during the actual building process, but many times people will wait until the very end to consider those pieces. For me, I like to ensure my users have a basic visual map, a detailed workflow map, and then documentation. This has also proven incredibly useful in describing my own thought process and identifying issues.

- Basic visual map: The SharePoint libraries / content types / lists in one colour, the workflows in another, with basic labeling to explain their purpose and whether it's in-flow or out-flow, and where it fits in.

- Detailed workflow map: We all know what this looks like

- Technical documentation for people who may have to troubleshoot / change / rebuild in the future.

If you're on the side of costing out your scope, that basic visual map is also extremely beneficial!