I find it absolutely shocking how many organizations don’t have clearly articulated road maps for their project processes. Processes are either complex multipage text based documents that no one ever reads or are simply tribal knowledge loosely held in the team members head with no two people have the same understanding of what the process is or should be.
Defining your road maps and communicating them to your team is the first step in creating repeatable processes and driving team accountability. They are also tremendously valuable tools for helping newer, inexperienced team members understand the overall process and their role in it.
But formalizing the informal processes is often done in isolation with little to no input form the people who perform the tasks. I have heard people say, “Its not perfect but its got to be better than how we are doing it today”. Wrong! Those tribal based informal processes do actually work today….they may be ugly or cumbersome or fail to drive accountability or quality but they work. If you build a formal process that doesn’t work 100% of the time, then it will fail on a regular basis and people will quickly abandon it and go back to the informal way they have always done it.
When you commit to creating your process road maps, you must also commit to get all the appropriate deliverable and task owners (R – responsible) and their customers (A – the people to whom they are Accountable) involved. They will be able to define the process at a task level and will have a much better understanding of their inputs and requirements than their manager will.
When building your process road maps, follow the steps below;
1) Print the inputs and outputs to the process on sticky notes Identify the owner of the input/output and give them a unique identifier (this can be as simple as sequential numbers or letters). Also note on the sticky the role that owns the I/O’s.
2) Define the in-process deliverables (these are typically documents that get created or updated as part of the process) and again print on sticky notes with the owner role and a unique identifier.
3) Define any sub-processes (these may be things like document review processes or change management processes and that are either already defined or can be defined with a different group of stakeholders). Print these on a different colour sticky note with the sub-process owner role and unique identifier. Try to identify as many sub-processes as possible to make your session more productive.
4) Define all tasks that must be completed to develop/update the deliverables and again print on sticky notes with the owner role and a unique identifier.
NOTE: steps 1 – 4 should be done by the lead cartographer (the person leading the process road map exercise) through one on one meetings with individual R’s and A’s prior to coming together in a workshop setting.
4) Set up a workshop with all contributing stakeholders. Ideally you won’t need more than a couple hours. If you have a large group, I recommend splitting them into teams of 4 – 6 people (ideally representing all the roles associated with the process). Then get each team to begin laying out the process on a white board starting from the left with the process inputs and stepping through the process until they reach the outputs, connecting the steps with lines on the whiteboard. Be sure to identify on a sticky note, any key decision points or qualifiers that will create multiple paths and again be sure to identify the owner for the decision and give it a unique identifier. For example, if you are developing a Contract Development process, a qualifier may be whether the contract will be lump sum or cost reimbursable. The subsequent paths for these options could look very different.
5) Have the teams review each other’s road maps and let them determine whose map is the most complete and then use it as your first revision.
6) Have all participants now focus on the chosen process map and walk through it as a group. Add any missing tasks, deliverable, decisions and qualifiers. If you find yourself focused too much on a sub process…again peel it off for later discussion / resolution.
7) Once complete, it is now the cartographers job to transfer the sticky note map to a process flow chart software (I like Visio but there are a lot of others out there). You can use simple graphics software but without he intelligence of the flow-charting software you will find yourself getting increasingly frustrated moving things around while maintaining relationships between tasks.
8) Issue it to the stakeholders for review and markup and revise. You will likely find yourself going through multiple iterations and at times needing to pull the group back together to resolve conflicts and disagreements.
9) Issue the road map for implementation and then apply it…but be willing to change it again as problems and challenges arise.
This is not the easiest thing to get through but once you have clearly defined maps, you can then start executing your project(s) with clarity, commitment and buy-in. You have visual tools to help your team better understand their responsibilities and their accountabilities and you have a structure on which you can drive project excellence and sustainability.
Also, I have heard people complain that the process maps are too complicated and they certainly can be but you have to understand the complexity of the process before you can begin to simplify it or automate it! If you get confused by standing back and looking at the entire process, start at the beginning and go for a walk making decisions at each fork in the road to see if your journey makes sense. Fix it if it doesn’t then start again…reworking it until it meets all your needs in an efficient manner.
