So, you have been tasks with creating (aka: fixing) your team/group/companies processes. Where do you start? Let’s start with the basics. First, written down or not, every group, team, function in your org has proceeses in place already. They have a way of doing their core functions, and it’s likely somewhat systematic and repeatable, even if not formalized in writing. Second, they are used to working that way, and you are there to upset the apple cart. Finally, at the end of they day, processes are ultimately mechanisms put in place to try and satisfy requirements. Not necessarily product requirements, which we’ll cover in more detail in a later requirements series dedicated to capturing product requirements, but requirements as in, “something they are required to accomplish, in a certain way, with certain acceptace criteria.” By tring to come in and impose new processes, you are setting yourself up for failure. You will recieve instant feedback. You need to get buy in, and there is no one-size fits all approach. The goal should be to document, then look to improve, and later expand and leverage tools, etc.
At the end of they day, processes are ultimately mechanisms put in place to try and satisfy requirements. Not necessarily product requirements, but requirements as in, “something they are required to accomplish, in a certain way, with certain acceptace criteria. ”
Keep the big picuture in mind as you travese this path, but don’t plan your complete route, plan your direction, an idea of the ideal final destiation. Allow for, and expect, a lot of detours, alternate paths, and accept that your final desitation might end up being much different than you envisioned at the start.
Start with Voice of the Customer
In this scenario, the “customer”, is the individual(s) that are completing the proceeses that you have decided to start with as your first improvement target. Manually write down their process steps, make observations, and ask a lot of “Why” questions. It’s important to decipher the requirements from the “how”. You don’t want to just document the solution, but the driving factors underneath. This is tougher than it sounds, people in general, and particularly engineers (A likely starting area) tend to communciation in solutions, and “hows”, not as much “why”. This is a great starting exercise for getting better and requirements gathering. Once you have docucmented their processes, and the requirements behind them, you can look toward the best next steps.
Process Basics – Key Considerations:
- Focus on observation and asking “why” on specific steps or actions rather than asking someone to describe the process to you. Take notes to possibly ask follow up questions later
- I am a big fan intial process work being done manaully. Don’t just immediately jump to a tool. If a tool is currently being utilized, consider pausing it’s use, and recreate the process manually just for learning purposes. That tool might be doing a lot behind the scenes nobody realizes.
- Don’t look to improve during this process. It often comes across as criticism. Feel free to ask for improvements, start small. “If you could change on thing about this process, what would it be”
- Take note of related input or output processes realted to this one, starting to build map of the “bigger picture” for later considerations
So now what? You have some information, you understand one key process, observed a few dependencies and hopefully gleaned some insights. In the next article in this series, we’ll take our first steps toward documentation and set ourselves up for making incremental improvements.