On designing processes
Some notes on things to think about when designing processes:
Clearly define the goals of the process
A process can either help the business or the customer, and everyone involved in the process must be able to clearly articulate who it is for, and how it helps them. Avoid the temptation to jump into designing a process before you've properly understood why the process needs to exist in the first place.
Name your process according to its outcomes
Call things names that remind people of their outcomes, not their outputs. Focus on what you want to achieve with your process (versus what you want to get done).
When naming the outcomes of your process, make that a team activity. Naming things together is a fundamentally optimistic activity because it forces you to focus on the positive outcomes of your efforts. Naming your outcomes also helps the team navigate short-term conflicts, or even set the stage for short-term explorations in the future.
Ask people what they would do if they had a deadline tomorrow
This is as essentially complex as the process might need to be. Once you have identified the path people would take in an emergency, try not to introduce more complexity into the system. Chances are if the regular flow takes much longer or is more complex, people will default to the emergency flow anyway.
Try to not accidentally make your processes more complex than they need to be.
Complexity is sticky
Once you've introduced any complexity into your system, it's going to be very hard to take it away (mostly because change is hard). Generally, complexity in a system is distributed between people, processes, and tools. You can't take away existing complexity from one of these domains without introducing it into the others.
If you simplify an existing process, then you're either asking people to do a little more, or maybe you're introducing automation – which involves added tool complexity.
If you simplify what your tools do currently, then whatever load you shed from your tools must be handled either by added process complexity or by people.
Do things the hard way
Design your processes for people first, and add technology as you go. Don't hard-code technology into your process up front. You're going to push yourself into a corner when a parallel process comes up 3 years later and uses technology that doesn't play well with what you're using now; you'll end up creating technology or information silos (or more likely, both).