Often, corporate policies governing a work-flow or project management processes are outdated or were decisions that were made arbitrarily. Sometimes there is a reason behind them. WHat are the best ways to challenge the assumptions, when trying to brainstorm on ways to improve workflow or project management processes?
Do not challenge ... drive out fear by listening and substituting leadership. Listen. Understand. Offer solutions not challenges. Challenges are something you do in high school or maybe junior high ... grownups lead.
Sometimes just asking questions is enough to get a bad policy revised, but you must ask tactfully to understand first. Often bad policy was instituted because of an incorrect over-reaction to problem. Sometimes bad policy is a necessary antidote to a problem. It is necessary to understand the original problem.
Develop and assemble a team of allies [choose people with power, who can get things done -- avoid people who are just whiners] ... your team will help overturn the policy and it will be useful in the future. Apply patient diligence as you continue to work with and through other people.
Couple of ideas -
First, get a group of those involved at all levels of the process, then remove yourself (the group) from the day-to-day work. You want to be looking at the processes and work-flow only, not an actual project. A real actual project will introduce specifics and cloud the reasoning.
Then start at the beginning (how do we solicit work), and work your through every step of the process to close, and at each step ask yourself and the group, "what do we do here, why do we do it this way, what problems do e routinely encounter, is there another way to do it, etc?" This is why you want people from all levels. There are invariably reasons or thinking that you're not privy to. So get input from everyone. And at each discussion point, find out the "why's" for the current state, and see if there's another way.
Once you have group consensus on what's the best way, move to the next step.
Some processes contain a component of self-improvement where the process has a built-in process for changing itself. This might provide an opening to start a discussion. Before starting this it is important to understand and clearly state the goals of this assumption challenging. What greater good for the corporation and, in particular, the assumers might result?
I think data is the most solid ground from which to challenge assumptions. I would collect data on current performance and try to run a pilot program to collect data on potential improvements. If data from the industry at large or a competitor shows room for improvement that can be very convincing.
I also find that if I approach data collection with an open attitude, and am willing to question my own assumptions that I have more success winning over defenders of the status quo.
It probably goes without saying, but politics can make or break this kind of thing with or without data.
According to Gartner, most organizations' level of process maturity is level 1 and 2 on a 5-level scale. This kind of question is indicative of an "immature" organization from a process perspective. This is a critical piece of information because the level of maturity dictates the approach.
Processes gain weight over time. Work flows are created to solve a temporary issue, but they remain. Controls are created for the same reason, and are never removed despite the driving issue is no longer in existence. Outputs are created and delivered but are no longer used in the subsequent process.
ASSUMING the organization is on the low side of maturity, I would start with the mapping of the as is processes. Not all of them; I would start with what is known to be problematic at this stage. This is a facilitated effort involving a representative sample of folks who do the work. I would not use some fancy BPM tool but would throw stickies on a wall so that the team can actively participate.
Once that is finished to everyone's satisfaction of completeness, I would begin the analysis. Process analysis starts with the output. No work needs to exist except to produce something of value in the supply chain. So the first set of questions are: what is the output, who gets it, why do they need it. This very first part of the analysis will likely cut 20% of the work being performed!
The second piece of the analysis is the work flow itself. The complexity of the as is map is a good initial clue. If there are a ton of carbon copies, forks and merges, and decision points, you have a lot of areas that are candidates for removal or modification. The questions become: why does this role need to see this information, if it is removed, what happens.
The outcome of the analysis is likely a good 'to be' map. In a lower maturity organization, rolling that out quickly to capture a quick win is advantageous; it will trigger the motivation for deeper analysis and continued leaning.
I assume you have the support you need, and the company's management will be with you on this. Then, the idea is as simple as:
- Make sure you speak about the same workflow. It would be no surprise if there are no one who knows the whole workflow. Sometimes each departament knows the best only it's part and has a slight knowledge about the rest. Take step back, speak to almost everyone. Visualize the workflow if needed.
- Make a list of the problems. It may look as an easy task but often each asked person has its own understanding of what problem is and, often, it's a strongly subjective understanding. Dig deeper and ask questions as long as you need to get clear vision of internal connections and possible causes.
- Identify risks and achievable profits. It should allow you to prioritize the list. They say if you want to eat the elephant you need to make it 'piece by piece' - it's much easier with priorities assigned to each piece.
- Monitor progress and react. For sure, you should manage change as every other project, but also you should remember it is very unlikely one will came with the best solution to the problem on a first try. You can make it work a lot better if you iteratively improve.
- Do not abandon to challenge the assumptions. Even if you fix a lot, the environment changes all the time, so you will be soon able to start over again...