Often when beginning a project one of the first steps is to document the current process and identify the key requirements of the major participants – suppliers to the process, the process performers, and the customers of the process.
The rationale for this activity is to make sure that all the important elements and components of the process have been accounted for. This makes sense. The last thing we want to do is to get 99% of the way through (spending 100% of the budget along the way!) and then discover we have a “fatal flaw”.
Doesn’t look too good on the annual review. No bullet point on the resume. And the chances of being involved in the next really cool undertaking? Nil minus!
We Interrupt This Blog in Order to Bring You….
There ia a bias people engage in during decision making called “anchoring”. Research has shown again and again that once a baseline has been put out there, or suggested, people anchor around it.
If we are asked to pick a number between 0 and 100, after hearing the number 10, we will pick a number, on average, lower than if we picked one between 0 and 100 after hearing the number 90.
…And Now, Back to Our Regularly Scheduled Programming
If we have a project group, comprising all possible components of the value chain and process flow, then we are likely to get a fantastically complete listing of requirements. People who perform a process day in and day out have a fantastically rich set of detail to inject.
“We need a P&L using a green hue, RGB content of 100:25:35, for revenue and rose hue, RGB content of 25:150:210, for expenses, derived from using an excel spreadsheet using data imported from a tab delimited file (we tried comma delimited once ten years ago and it didn’t work).”
Why are requirements lists like this generated? Because we are asking people with a vested interest in the status quo. And, contrary to what we might think, they did not fall off the applecart yesterday. Any time one of these big projects come around, there is one central question a) from the start of project, b) throughout the life of the project, and c) at the end of the project - “Am I going to have a job?”
However, there is an additional problem. Because we have listed out the current process, detailing in excruciating minutia the “requirements”, they now serve as anchors throughout the project’s life!
Should we truly be surprised that the fruits of the project effort…those long, hard spent months (if not years) of meetings, forms, and angst…look remarkably similar to our current process? Sure, some things have been “tweaked” here and there. Yes, we have re-examined things from beginning to end and gained some efficiencies (at least according to the agreed upon metrics). There is no surprise that we have gotten acceptably close to whatever targets or objectives may have been established (and we all agree on what factors might have prevented us from getting all the way there).
Sometimes we are asked to develop a process where we "start with a blank sheet of paper”. This is the process-development equivalent to zero-based budgeting, everything that goes onto the paper needs to be justified.
And before it gets on that pristine, lily white, innocent sheet of paper, we ask the “5-whys” and other penetrating, challenging questions. We make the proponent cost-justify it. We play devil’s advocate. We have other’s play devil’s advocate. We ask for alternatives. We look at the pros and cons of alternatives.
Essentially, it so arduous and painful to put a box on that paper that everyone thinks twice about proposing one and substantiating it.
Go through the process randomly – start from the end, work from the middle outward, swirl around the edges inward like a hurricane, etc. – in order to prevent the existing mentality from gaining that dangerous beachhead.
Then, once this “future-state” has been developed, it serves as the anchor from which we compare the “current-state”. The result is more change, more efficiency and effectiveness, and higher levels of customer satisfaction.
When considering change, think carefully about what mental anchors are being set in the process, and seek to take control of their establishment in such a manner so that the change objectives are more likely to be met.
Have you had an experience you can share about a project that was anchored by the status quo?
What processes in your organization are ripe for a “blank sheet of paper” approach?
Thanks for stopping by the Treasury Cafe!
Please share your thoughts, comments, questions and/or feedback - all are welcome!
If you like it, please share it. Your support is sincerely and gratefully appreciated.