Here at Oasis Digital, we are always agile, and depending on the project needs, sometimes use Agile (in the “capital A” sense) processes extensively. Yet regardless of agility, iterations, steering, and so on, the planning and decisions made at the beginning (and in the early months) of a project often have profound and very difficult to change consequences later.
Therefore, while we would never argue for the straw-man Waterfall, we aim to think very hard about a project at the beginning.
System Administrators often find themselves caught trying to fulfill the promises and hype that come with a new system purchase. As ERP companies learned the hard way over the last twenty years, a system is only as good as its user adoption. Metrics cannot flow to management without individual users, on a consistent basis, doing their part. Those caught in this position are at the mercy of the original system designers. Fortunately there are some strategies that can help.
I would like to use JIRA, a project management platform from Atlassian, as an example. JIRA is one of a new generation of SaaS based, deeply configurable, business tools. I teach a class that empowers organizations to make this powerful tool their own. Reducing user friction is what I have found is the key to user adoption of a tool of this type.
An effectively designed product will present you with an incredible combination of configurable features. In the case of JIRA, you can have an almost unlimited number of:
When a company purchases a product with this many options, most new administrators open the floodgates to their users. Every field looks useful, and managers have a long list of things they want to track in their work. The result can be a menagerie of poorly named and organized fields that are tedious and overwhelming.
Fields are the single largest source of clutter in business apps so I will point my attack there. It is good to list out all the fields that you want. If a field is up for discussion, it must have value to some aspect of the business. There are three approaches that can be taken to reduce the number of fields presented to the user:
Similar ideas can be applied to other complex work processes common in business applications.
In every task within every job there is a context, and a certain set of information that is needed. System designers have learned to present the information the user needs at a particular point in the work process. There are many mechanisms in a JIRA workflow to assist with this. The most powerful is the idea of screens associated with transitions in a workflow.
In a JIRA workflow there are Statuses and Transitions, the primary building blocks of the workflow. I always describe Statuses as places of rest, with Transitions being the action of moving between those places of rest. When new administrators first build a workflow, they INEVITABLY focus on the statuses. After about the third try, they realize that transitions are where the action is, literally and figuratively.
Focusing on the transitions, or forward movement, means giving users the ability to speed up their work by making the important information available. A major caveat here: do not take away access to all the other fields and information. For example, it is common to “pop” a screen on a transition. If you do so, add a tab to the screen with quick access to all the fields and information. This will allow users to correct previous mistakes or misunderstandings without disrupting their workflow.
Business systems commonly are based around a workflow. Try to understand what moves your user forward in their daily efforts and push it forward in their view.
It is almost impossible to overstate the importance of this in any organization. We often preach focus in the business world but then we constantly break our workers’ focus throughout the day. I have written pretty extensively about workflow design and the need for focus. Here are a couple of points.
If you have task-driven work, then always present the user with task-oriented workflow transitions and statuses. It is common for a workflow to start out being about tasks and end up being focused on deadlines and time. This confuses users and causes them to have to think harder than they should to stay focused.
Maintaining user focus is an area where user personas are quite valuable to the person configuring a system. If the administrator has a good understanding of a particular job, and can visualize what that user is going through, they will build a better system.
Pride of authorship can be devastating to a system. Every organization is different, and your users matter. Listen to them and iterate on your workflows. Provide a mechanism, often another JIRA project, where users can make suggestions. Ask your users to critique screens and provide feedback about ways to improve their productivity.
Erring on the side of empowerment early in a system implementation can be the difference in making or breaking system adoption. It is common to want to restrict access early on and only give access when needed. This is very frustrating to users and I have witnessed the abandonment of systems over this particular issue. Users need to get their jobs done, and they will resort to Excel to make it happen! Once they abandon using a system because of restricted access it is very difficult to turn things around.
The success of implementing JIRA, or other extensive business systems, is like any other endeavor. It goes better with a proactive plan that considers implications rather than reacts to them. A system is only as good as the data entered, and a user that is empowered by a system will enter far more accurate and complete information than a user that must simply comply. By using these strategies you can chart the path to system adoption rather than abandonment.
The old saying about the cobbler’s kids that have no shoes is as true in concept now as it was a millenia ago. At Oasis Digital, where we find great solutions to increase the success of our customers, we have been so focused on those projects that we find ourselves lacking our marketing shoes. Our marketing efforts have been tertiary at best.
A few years ago we realized the need to develop our brand, a few months ago we started moving forward, and a few weeks ago we sat down and started the process with our team. I asked them to articulate what we are really good at, what they were proud of. The list was broad, and spoke to their understanding of the value they bring to our clients. Here is the list:
This is the first bit, what we do well. The further question is how do we do these things. Very often, how you do things communicates your value to your customers. For example, people find our training very valuable because it is intensely workshop based, and taught by an actual practitioner of the craft, not a professional teacher.
We are a values based organization, so the “what” and the “how” are not the full answer. When you answer the “why” you find the values that motivate your work. The answer I came to was two-fold:
The wording will change over time but our core motivator is solving hard problems that have value. We really enjoy that process. Adding value, helping people and businesses to be successful, those are solid values that we believe will resonate with the right kinds of customers.
I love the powerful words pushed forward by the team. They are full of meaning and demonstrate the consistency through the team of our values.
love, empower, build, communicate, help, teach, improve, finish, learning, effective, collaborate
I cannot wait to have these ideas permeate our web presence and our marketing communications. If we can push this to conclusion I believe we will finally have a nice pair of shoes!
Anyone familiar with JIRA understands that jumping into building a workflow without an overall plan can lead to problems. While navigating JIRA’s workflow editing tools, half of your brain is focused on your workflow design, and the other half is dealing with the tools. While I encourage new users to try their hand at the software, it is important to understand it is unlikely any first effort will be usable. Following are some suggested strategies that will help you avoid completely starting over, the normal result of a failed attempt at workflow development.
First of all, grab a piece of paper and a pencil. A good workflow takes some thought and some iteration. Fully expect to erase and redraw statuses and transitions if you want to have a truly effective workflow. The more complex the problem domain, the longer it will take. Common mistakes that can take a long time in the editor can be sorted out quickly on a piece of paper. Having a sketch makes the work more easily done (therefore also a possible candidate for delegation).
In my experience, a diluted focus is where even experienced JIRA users might fall down. Focus and flow are very important to the user experience. Focus can be diluted when the driving purpose of a workflow changes midstream. If a user is following a workflow focused on a task progressing through teams and suddenly has to deal with a time (deadline) based status, it can lead to frustration and mistakes. A good user experience is important in a support system like JIRA: a bad experience leads to poor performance. I believe this focus can be achieved by a good initial decision on what type of workflow to build. I break these focuses down into three categories; tasks, time, and resources. Each one is very different, and probably should not be combined in one workflow.
This is a natural way for many organizations to work, and possibly the best way to approach a workflow in JIRA. In this design mode you specifically map out the work based on the steps it will go through from start to completion. You should be able to easily describe statuses and needed transitions.
If you are concerned about a bottleneck in your staff capacity, inventory, or other resource issue, guard against modifying the workflow to accommodate this. For example, adding a status to the workflow to sort out an overcommitted resource will disrupt the workflow, this can better be handled within a task-based workflow by a screen popped in a transition. If you want to incorporate scheduling a coordination meeting, or other time issue, adding a status to represent this is also a bad idea. Instead, set a trigger to generate the meeting in a properly named status. Those are examples of diluting the effectiveness of a task-based workflow. If you do so, then you tend to start making workflow design decisions that can confuse users. This does not mean that capacity constraints and time considerations are not addressed. These can usually be exposed in filters and typically addressed in transitions.
If your world is filled with Scrums, SLAs, or Gantt Charts, or if your workflow is completely budget driven, then you should consider a time-based workflow. Build your workflow around the processes and meetings that will occur. A good indicator of a time-based design is that your statuses look quite similar to titles in your emails and calendar events. There are lots of examples of this type of workflow, such as the one below. In a time-based workflow you can use post functions and triggers to set dates in an external system and tie the timing of the tasks to various statuses, transitions, and custom fields. If you tend to sort and look at issue lists based on date fields, then a time-based workflow might be a good choice.
Another way to slice through a workflow is to strongly consider resources and people directly in the design. This type of workflow is focused on capacity, issue counts at various stages in development, and looking for where you need more resources or people to maintain productivity. Statuses will be related to the functions or resources needed for a step in the workflow. A workflow designed in this way will make heavy use of custom fields, components, and automated assignment of issues in transitions. If you tend to sort your lists by assignee or component, then you are a good candidate to build your workflow this way. Including similar items to a task-based workflow as described above is natural. Make sure your workflow is consistent from start to finish with steps regarding resource allocation spread across the entire work cycle.
If your workflow has more than eight statuses then you are likely going to find layout to be a struggle. One approach that can help is to think of the workflow as sections, or silos, of work. JIRA automatically does this for you by creating three categories to put your statuses in (To Do, In Progress, Done). You can take this into your layout by grouping these categories. There may also be pieces of your workflow that typically run in sequence with little deviation. Tightly group these in a small area to assist in the readability of your workflow. By thinking through this process you can avoid the spaghetti syndrome that permeates many workflows. Unfortunately, the best planning cannot prevent a JIRA update from making a mess out of your pretty workflow. But they can be easy to sort back out as long as you are using the same principles.
I show the Resource workflow example from the previous section below without this organization to demonstrate the point. I did not intentionally make it bad, I used the standard order generated by JIRA. The statuses are simply dropped in chronological order, and without some thought an intense mess can develop. Note how it is difficult to see the true flow of work.
When approaching the design of workflows in JIRA it is important to understand the need behind the workflow you are building, have a strong vision for that plan, and execute it with user efficiency in mind. The concepts discussed in this post are a good starting place, but there is much work to do to effectively execute a workflow. There are many good options for targeted training in this area, we recommend users start building workflows immediately and use that process as a platform to learn the system. As a user gains deeper understanding, they can immediately incorporate advanced concepts into their workflows.
