<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=266211600481844&amp;ev=PageView&amp;noscript=1">

Incorporating Technical Analysis into Business Planning for Nintex Workflow Projects

Feb 9, 2016 Nintex Scott Walsh

Business-and-Technical-Nintex-Workflows.jpgBack when we here at Aptera were just beginning our partnership with Nintex, our approach to process automation projects was built on the assumption that mapping and developing should involve different types of experts. The process mapping stage was to be led by a business analyst, someone intimately familiar with the goals of the workflow. Then the developers would take over to handle all the technical aspects of making the workflow function the way it needed to.

Over the course of many projects, though, we’ve evolved our process significantly. The biggest change has been that we now involve a Nintex architect in the process planning phase and a business analyst in the mapping and diagramming phase. The BA runs the show on the first day, with the architect simply asking a few questions and providing a little insight when necessary. On day two, we flip the script and the architect takes over, with the BA chiming in with some guidance if needed.

Nintex gives you a lot of flexibility in building workflows to a wide array of specifications. But what we’ve found is that the tools lend themselves better to certain nuances in workflow design that you probably won’t be aware of unless you’re an architect. That’s why it’s important to involve people who are familiar with how these nuances will affect how the workflows are built in the early planning stages.

Now that we’ve incorporated this insight and several others from our experiences over multiple projects, our current process goes through four stages.

1. Map the business process to high-level steps. 

These can be simple bullet points with notes associated, but they should be fairly concrete. This allows business users to start thinking more analytically about both their process and the decision points within it. The result should look something like a narrative featuring standard players and the clearly defined actions they perform within the business process. Integration points and other technical challenges should be identified in this step, but you shouldn’t try to solve them yet. This step generally takes about half a day and involves lots of discussion.

2. Analyze the process.

Spend some time analyzing the process to find obvious failure points or areas of ambiguity. This should be done immediately after the half-day business mapping step, and it should result in some draft notes related to the high-level process you’ve identified.

3. Perform an in-depth process walk-through.

Here’s where the Nintex architect takes over. The idea is to walk through the entire process that you’ve mapped out and analyzed—but this time from the perspective of the developers. This step can usually be covered in another half-day session, during which you’ll be filling quite a bit of white board space. During the walk-through, you’ll be assigning each step of the process to a specific Nintex Action.

This is when you answer questions related to success paths and what determines how the workflow branches. For instance, if a task is assigned, is there a reject path? What does it look like? Who needs to be notified at each of the different stages? Can people request changes?

Viewing the process through the eyes of the Nintex Action will help do two things. First, it highlights decisions affecting the user experience. So you assign a task to someone—what does that actually look like to that person? Can he or she approve via email? Would this action function better as an Exchange task?

Second, it allows us technical folks to coax end-users toward what we’ve come to refer to as “100% decisions.” In other words, what will happen at this stage 100% of the time? Not what happens most of the time, or what might happen, but what happens EVERY time? Visualizing it through the eyes of a Nintex action is helpful for both technical and non-technical participants and will allow for definitive decisions. The ultimate result will be a solid architecture that can be readily built with Nintex. 

But keep in mind the goal for this step isn’t to spell out every single Nintex Action. If you have a solid feel for what a web service will do, or what drives your switch, then you can leave it at that for now. But if you come away without knowing precisely how to configure the majority of your actions, then you’re not adequately prepared to move on to the next step.

4. Validation Scaffold

The final step is something that’s really helpful in most cases. Nintex provides a very intuitive workspace for building workflows. Sometimes, simply taking the work you’ve done and scaffolding out the appropriate actions for validation by your business users is an especially effective way to get everyone on the same page.

The eventuality this 4-step process is designed to avoid is one in which scope creep results in the project going past deadline and over budget. Properly calibrating the way a product like Nintex automates a business process provides the clarity and transparency necessary to ensure business users and technology providers are working toward the same goals, based on the same specifications. Showing end-users not only that we’ll solve their business process challenge, but also how we’ll solve it using a specific product allows us as Nintex developers to truly meet the expectations we have set.

Popular posts like this:

How Real Businesses Are Using SharePoint

Nintex Announces New Features to Workflow and Mobile Form Tools

How Nintex Simplifies SharePoint Workflows

The 4 Biggest Mistakes to Avoid in SharePoint Migrations

Posted in: Nintex

Topics: Nintex