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).
Start Clean
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.
Key Takeaway
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.
Questions
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.
A lot of tech projects start with a blank sheet of paper and progress with requirement documents and sophisticated change management tools. Although it may seem on the surface that requirement and change management processes add to the workload and time, the end products are easily managed thus saving time and being more regulated.
ReplyDeleteMaddie,
ReplyDeleteThanks for the comments!
I was actually thinking of a tech project experience when writing this post. When the fact that someone currently prints, then saves, becomes a criteria for anything new, there is a lost opportunity to innovate, since all the technology that saves, then prints is excluded because it "doesn't meet the user requirements"!
Very interesting post and I'm happy to find this blog, looks like a good one. I read an article recently that brainstorming sessions where everyone gathers in the room are much less effective than asking people individually for their ideas. Brainstorming with larger groups tends to promote groupthink and are more likely to result in ideas closer to the status quo whilst asking people to think outside of the box individually is much more effective.
ReplyDelete"Green",
ReplyDeleteThanks for the kind words.
That is an interesting thing to think about. We usually hear of brainstorming as a way to get "outside the box", but thinking about the anchoring concept it makes sense that things would converge onto something.
Not everyone does well in a group setting, so supplementing the brainstorming with individual sessions will add ideas that otherwise would be missed.
Thanks for your comments!