“I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding.” Abraham Kaplan, The Conduct of Inquiry: Methodology for Behavioral Science.
I was under my Jeep working on installing a new suspension and the control arms were not aligning properly. So out of frustration I reached for the nearest tool I could to hopefully “tap” the pan-hard bar into place. The nearest tool was a crescent wrench. I started tapping on the bar with the crescent wrench with no effect. Soon I was pounding on the parts hoping that they would somehow meld together. My wrench was now marred, but no, I was too lazy to get up and get a rubber mallet or dead-blow hammer, so I continued to wail on it. No effect. By now I was getting pretty ticked off at the lack of cooperation, so finally I crawled out from under the Jeep and went for a hammer. Not just any hammer, I was frustrated so I wanted my 5lb sledge hammer. I crawled back under the Jeep spewing a litany of colorful metaphors and back at it I went. I swung at those parts like Conan the Barbarian dispatching his foes. Still no success. As my arms tired, my judgement waned, and “swing batter swing…miss!” I missed the pan-hard bar and hit the fine threads on my heim joint. With all that mass and kinetic energy, I not only hit the threads, but destroyed them. That was quite the accomplishment since this heim joint was hardened chromoly steel at $120 each! ARRRGHH!!
I finally realized that maybe it was not the tool or application of the tool that was wrong, but the process in which I approached this job.
I have preached this same principle to many organizations. Don’t get tool centric. My erroneous approach with my Jeep can be related to any organization. “If a hammer is all you have, you will use that. If something doesn’t work, hit it with your hammer, if it still doesn’t work, try a bigger hammer, if it still doesn’t work, try reading the instructions” – Ancient Proverb. ????
In today’s world, we are all about the technology. We have an app or system to do everything for us, but often that can get us into trouble if the application of that app (tool) is inappropriate.
Often an organization may focus too heavily on systems or tools to perform their work and not enough on the process. We may fall into the myth that technology can solve all our problems. I use this set of pictures as an example.
If you have a problem, you get a product or tool to overcome the problem.
At first the tool or product may seem to deal with your problem.
that product or tool will fail in solving the problem. So, what is the common reaction? Build a bigger tool.
That new enhanced product may seem to work with the original problem.
But what about an enhanced problem? Is this new tool or product capable of dealing with these challenges?
Often not. We cannot always rely on our system, tools, or products to deal with every aspect of our problems. Tools should not drive organizational design, should not define all processes, and should not drive behavior. When we see a cool app, or tool we often get pulled into the flash and glitz and think, “Wow, wouldn’t that be cool to have that in our organization. That would make my job so easy if software XYZ were to run our project management.” Often, sales pitches for some software tools claim to come with their own processes. Be careful, those processes may not match your operating procedures and may conflict with a more optimal operating process. Some companies, after purchasing a software, realize that the software does not perfectly fit their operation’s processes or mandated procedures. So, what do they do? Customize the software. This can create a huge list of new problems when maintaining that software. Every time there is a software upgrade, new version, or bug fix, it may destroy all the custom features that were added by the company. This adds cost and complexity to the maintenance of that software.
To avoid some of these stresses and costs to an organization, it is best not to forget the importance of good process. Before adopting a new tool (software), define, map, and understand the processes that are needed to accomplish the work. Apply Lean Six Sigma methodologies to measure, analyze, test, and improve the process before bringing in a software solution. Once you are satisfied with the effectiveness of the process(es) then first look for an off-the-shelf software that comes closest to meeting the needs of the organization and processes. Avoid software that will require customization. Once a software is chosen, then some slight modification to the process might be needed. The point is look at process first and then to what tools can support your processes.
A firm I consulted with fell for the glitzy sales pitches of a certain project management software. They were impressed with all the cool modules and options. They paid a great deal of money for the software, implementation, training, and maintenance. It did not take long to realize that the software added a few steps to their old processes, and several of the modules did not interface with their accounting, payroll, and legal oversight systems. Now there was a lot of customization that was required to get these different systems to talk to each other. Several manual workarounds were added, and several modules could not be used at all and eventually additional software was purchased to address those gaps. Many employees began to be frustrated with the software and looked for other applications that could more effectively address their needs. Standardization went out the window as a bunch of shadow systems working in various parts of the organization began popping up. After suffering through this loss in efficiency for four years they decided to abandon the software and seek out a new one. I counseled them to define and analyze their processes first so when putting together their list of requirements they would understand all the system to system touch points, human to system interactions, and mandated protocol placed on that firm by other entities, like Government and other contractors. I helped them model the business interactions and the processes. Business modeling ultimately provided two information resources:
- A clear and unambiguous representation of the key business processes that define the business aspect being modeled.
- A set of “business requirements” that serve both business process automation and non-automation components.
It was a must to understand all the other systems or data repositories the new software would need to interface with. Then we analyzed the capacity of the users. Do the project managers and controllers have the knowledge and skills to effectively utilize the software? The leaders needed to analyze where they saw the maturity of their firm currently and where they would be in the future. Would they be stretching to grow into the application’s full capabilities, or would this new application allow them to grow in maturity? These were some of the areas we had to address before choosing which application would support them the best.
After mapping our SIPOC diagrams, business interaction models, processes, network diagrams, user profiles, user stories, and risk points with mitigation, we were ready to purchase a new project management application. We documented all these requirements and set off to search for the application that would most closely fulfil our requirements. We also researched each software vendor’s background, support capabilities, cost, and reach.
At the end of the day I reluctantly went on-line for help on centering and completing the suspension under my Jeep. I learned that there is a simple, yet very effective process with some specialized tools that will make the job quite easy. The best part was I could easily follow that process and those proper tools were already in my tool box. It was a costly mistake to misapply the tools I had on hand. One mangled crescent wrench, one $120 heim joint, and one bruised ego. I learned that it is important for me to look to the process before I use a tool, and even though I am tempted to buy a crescent hammer, I will refrain from adding it to my tool box.
Figure 1 ACME Crescent Hammer
Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.
|Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE|
|We hope you will consider joining our Facebook Community as well. Click on the image to your left to visit and join, or you can CLICK HERE|
Reading this article qualifies you to submit a request for PDU's from PMI.
This Article qualifies as follows:
PDU AMOUNT: .25 PDU's
For more information on registering your PDU's with PMI - CLICK HERE
At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!
If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE
Stan D. Prueitt
Stan D. Prueitt, a performance consultant in Process Improvement, Organizational Design, Human Design, and Project Management; holds motivational seminars, life coach workshops, Lean Six Sigma certifications, and performance seminars across the country. Stan draws upon his colorful past experiences and associations to blend simplicity, common sense, eternal principles, humor, energy, and wisdom into a strait forward approach to self and team improvement. His mentors and Martial Arts Masters have forged Stan into a wealth of experience and knowledge of which he freely shares. Students of his seminars leave with recharged spiritual batteries, focused purpose, energy for new opportunity, new understanding, and a tool set to become an effective change-agent in their own lives or organizations.
While currently leading enterprise integration and organization and process performance initiatives for the LDS Church Educational Department, Stan still finds time to consult to private and municipal organizations on the side. Previously he was not only a Director of Project Management at the Los Alamos National Laboratory but also one of the leaders in the Lean Six Sigma program. Stan led a team to restructure the organization to focus on process centricity, performance, enterprise project management, and to move the overall maturity of the organization from level 1 to level 5 of the enterprise maturity model.
As a true efficiency expert Stan wears many hats, he is a published author of 4 books, co-founder of two publicly traded renewable energy research firms, president of Thunder Ridge Wildlife Refuge, holder of one US patent and inventor of two classified weapons program inventions, adventure TV show host, Lean Six Sigma master black belt, Lean Six Sigma and Performance Management instructor, master instructor and holder of six black belts in the Martial Arts, owner of USLLC Tactical Marital Arts training center, professional off-road race driver, entrepreneur of two successful franchise chains, radio show host, project manager for research projects, motivational speaker, certified law enforcement officer, husband and loving father of five.
LinkedIn Profile - CLICK HERE