It’s Not About the Tool!

November 16, 2013 by
Filed under: Agility, Process, Project management 

I’ve been building stringed instruments as a hobby over the past couple of years, and there are a few tools that I have become particularly enamoured with. I’ve got a nice little Japanese file that seems to be just the right size to fit into all the nooks and crannies to tidy things up, and I’ve got a laminate trimmer that’s got plenty of power but is really light and maneuverable compared to the big, clunky old router that I inherited from my dad.

They’re both great tools and have particular tasks that they handle quite effectively, but neither one of them solves all of my problems. I would never pick up either of them before really understanding the challenge at hand. This seems to be common sense, and I would expect most craftsmen would tell a similar story.

Why is it then that consultants often approach organizations with a particular tool or technique in mind before they understand the client’s challenge at hand, and why do organizations try to improve their performance by establishing a standardized approach to running projects? It may appear to simplify things on the surface, but it rarely is an appropriate match to solve the challenges we face (other than the short term revenue challenges for the salesmen).

As they say, if all you have is a hammer, everything starts to look like a nail. Rather than relying on a particular tool, we should always be seeking out a variety of tools, techniques, approaches that we can add to our toolkit, with an understanding of when it is reasonable to apply that tool. For knowledge work, this is simplified as the tools and techniques aren’t heavy, don’t take up a lot of space, and are often complementary to one another. Many are very simple, which makes them easy to understand for the masses (as knowledge work should be a collaborative game), and don’t require deep investment to acquire them. Indeed, I would suggest that many software solutions are highly overrated: project planning tools, for instance, can produce beautiful and often irrelevant charts of our projects. Nobody ever became a better author when they started using a word processor (other than getting feedback on spelling and syntax), and in many cases, use of technology falls into the garbage-in-garbage-out pitfall. A power tool does not allow us to stop thinking – as my father used to note, a power tool is often “a great way to create a lot of sawdust in a hurry”.

Any tool, any technique, any particular approach is merely a means to an end, and it’s far more important to understand that end you are trying to achieve first. Begin with the end in mind, as Steven Covey has famously identified as his second habit. What are we trying to achieve? Is it an insight into one particular aspect of our project, is it an estimate of how long we expect something to take, are we trying to gain a shared understanding of our plan of attack?

There is usually more than one way to solve a problem, and the tool we select (yes, it should be a conscious selection rather than a default) should be based on nature and complexity of the problem at hand, the utility of that tool to help us resolve that problem, the culture and environment of the team and business we are in, and our familiarity with how to properly use that tool. In teams, that familiarity concern spans all the participants – a Gantt chart might be a good way to represent progress on a large, complex project, but there are often people in the room that don’t understand what they are viewing on the chart. For large, long-lived, complex projects, persisting critical information such as data models or business rules requires documentation that is against the shallow interpretations of many ‘no documentation’ agile implementations.

Sometimes, armed with a large range of tools, applying several to the problem at hand can provide strongly complementary views. Alternative analysis views of a project can provide distinctly different insights, or alternative estimation approaches can expose gaps in each technique (never average alternative approaches, seek to understand why different results exist).

Every tool will have its particular strengths and weaknesses, there is no universal tool or technique for all situations. Those that might suggest there is simply have not had broad enough experience to understand this, or are in a tragically deep state of denial. Perhaps the next time you hear someone suggest their technique will work before they understand your situation, you can mentally prefix their assertion with the phrase “In my dreadfully limited experience…”. There is potential for overuse or misapplication of any tool or technique that exists.

Are you wedded to a particular tool? Have you been sold on a particular technique as the new saviour to all your challenges? If so, step back and critically consider a range of different tools or techniques. Always seek to grow your toolkit and understand the strengths and weaknesses (or potential for over-application) of tools, and consciously select the right ones for the job at hand. It’s a standard way of doing things for craftsmen, mechanics, and surgeons, but for some reason many knowledge workers fail to appreciate the need to do so.

Perhaps this is because too many people make a living by suggesting you need their tool before they understand your particular domain, culture and challenges. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    Fantastic course (Software Teamwork)! Great opportunity to interact with others in the field of project management with expertise in different industries. I gained knowledge from my team members and insight into my own self.

    — Jeanny Dhaliwal