Know your process

"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.

Until next time!