I have an expression that my staff and clients have heard me use often. It’s a favorite of mine. “If you are a hammer, then everything looks like a nail.” It’s a paraphrase I know and as I was writing this article, I thought it behooved me to look up the source. It wasn’t much of a surprise that the author was someone who I read a lot of a long time ago, Abraham Maslow. One of his most popular theories was Maslow’s Hierarchy of Needs; something I have used in management consulting for years but discussing that topic will have to wait for another article on another day.
My focus today is hitting everything as though you are a hammer because it looks just like a nail to you. Maslow’s actual quote was: “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” (The Psychology of Science, p15, 1966, Abraham Maslow)
It is.
I have a staff of programmers who are among the best in the industry. It is a small core team of people who work on our enterprise timesheet system TimeControl and they are very, very good. Our small team services some of the largest and most complex project management and cost control environments in the world. We work for those in the public and private sectors, in defense, in aerospace, in research and development, in new product development, in the utilities sector and more.
For those who have read this column often you know that I espouse the belief that if you want to create a solution, you must first listen to the problem and many of those articles have come from my thinking in preparation for internal meetings when I coach our consulting and development staff on how we can best serve our clients.
Yet, our development staff are finely tuned developers and, guess what, every time someone asks them for something, their minds default to thinking of how they could develop it. It is something they are used to being on guard for and for the most part, they catch themselves before the client even knows it.
We ask them to think of not just how to do a thing but whether we should do it at all. When they think of how they could easily program something, we have them think first of how they will justify that the development is the best way to solve that problem for the client. Moreover, we ask our team to think of not just what it will take them to develop it but what the total cost of ownership of that development will be including lifelong support of that feature, managing the impact of that new feature on hundreds of thousands of other users and how we will need to test and quality assure that feature not just today but for years to come.
This blind spot that Maslow captured so beautifully in a single sentence isn’t reserved to developers. It’s something that I encounter almost every day.
We sell a flexible timesheet system designed to fulfill the requirements of multiple departments simultaneously. I have seen numerous deployments where the project team were involved in the early stages of deployment and then brought in the Finance team for their input. To what should be no one’s surprise, the Finance group look at how the Project team configured the timesheet and immediately determined that it was completely wrong. Payroll looks at a timesheet from the perspective how do I get the payroll out. Billing looks at it from a perspective of how do I get my invoices published. R&D wants to know if all of their research and development expenditures will be accounted for and, of course, project management wants to know if the timesheet will deliver the actuals for their planned activities back to the project management system.
By far the easiest sell would be to never get these people into a room. Instead, send the payroll timesheet salesman to the payroll people and make their sale there. Send the time and billing timesheet salesman to the billing people and make their sale there. Send the project management software people to the project people and show the timesheet already there and make their own sale there.
Sadly this is too often the case.
The result is the deployment of multiple pieces of software all doing something similar.
Several years ago, I spoke with a public sector municipal CIO.
“We have too many timesheets is my problem,” he said. “I’m reluctant to look at one more.”
“How many do you have?” I asked.
The CIO looked around the room to be sure we were not being listened to.
“Nine,” he said.
There was a long pause. He knew we were suggesting that our product could fulfill many of the requirements of those nine systems.
“I know we’ll never get to one,” he said, “but anything less than nine would be very good for us.”
In the end, I think they got down to 4 a couple of years after deployment our TimeControl. It’s not that TimeControl was the only solution. In fact, there were obviously many solutions to choose from. It was finding the less obvious requirement of flexibility that delivered the value to the whole organization.
Sometimes just knowing you’re a hammer can have you take pause and look twice. Is that a nail? Let me look again.
