How do your stakeholders see your beer can solutions?

by Laura (Brandau) Brandenburg on October 12, 2009 · 2 comments

in Communication

Please indulge this second diversion into the world of Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. Although this book really has nothing to do with business analysis, it has everything to do with how we approach technology and as I read it I keep seeing our profession in a new light.

In the latest chapter Pirsig writes about the classic-romantic split, exploring where technology fits into our world through his friends, John and Sylvia, who are regular technophobes.Their approach to motorcycles mirrors my approach to the printer–if it doesn’t work call the mechanic (a.k.a my fiancee).

As technophobes his friends rely on technology but deeply resent it. (Yes, this is exactly how I feel about the printer.) Pirsig finds that this is because they see things for what they appear to be instead of what they actually are. (Yes, I see the printer as something that “just prints” and not as a complex machine networked to multiple computers where all kinds of things can go wrong.)

This “seeing things for what they appear to be” is a “romantic” notion in the philosophical sense of the word. The story starts when Pirsig suggests using an old beer can as a shim to help fix a motorcycle. John, the “romantic”, responds negatively. He chooses not to fix the motorcycle because the solution involves using a beer can. He’s looking at what it is (just a beer can) and not what it can do (an elegant, cost-effective solution to fix the motorcycle).  Pirsig, on the other hand, sees the beer can not just as an effective solution, but as one of the best. You couldn’t actually buy something better than an old beer can to solve just this problem.

I think business analysts see this in our day-to-day project lives too. Some stakeholders fit more on the romantic side of the equation. Our solutions must not just be effective, they must have flair. Maybe they want the solution to use the latest technologies available or maybe they are looking for an automated solution when a manual fix or process change will do just as well.

No matter,  there are times when we get push back that has nothing to do with what the solution is, but simply how they perceive it. As business analysts, we are often trying to rationalize with these people. But don’t you see how perfect this BEER CAN is? It will fix your motorcycle!

If we keep forcing our rationality, we’re not likely to get anywhere. They are blocked. The rest of the book unfolds a new metaphysics for getting around the classic-romantic through Quality (what in other classical literature is called the One, the Tao, etc). Quality really is the source of all things and if you live a life infused with Quality you avoid the classic-romantic split because you can see things both for what they appear to be and what they are. You don’t feel compelled to choose between the two.

In a sense, John and Pirsig are lucky. They are driving separate motorcycles. They can make disparate decisions. John can choose to pay a high price for flashy motorcycle repair and Pirsig can work away in his garage using his own tools and the occasional beer can.

In software projects, we do not have this same luxury. We’ve got to find a way through it. And simply pushing forward is not going to work. Pushing forward without recognizing that each of us got to this very same point through completely different paths of thinking will only create an explosion. In these situations, we often find ourselves taking a step back. We begin to talk about larger project concepts like scope and return on investment. We ask questions such “Will this project generate the value for this fancy solution?” Is it worth it? Does it have Quality?

Of course, it can be difficult to have a metaphysical discussion in a regular old conference room. But I think if we realize that sometimes the challenges we face in alignment are, at their root, metaphysical differences in how people view problems and technical solutions, we might find ourselves on a path toward better communication.

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

  1. Business analysis and motorcycle maintenance, more in common that you may have thought.
  2. When to stop analyzing requirements and start shopping for software solutions
  3. Help your stakeholders discover technical possibilities to define new project concepts

{ 2 trackbacks }

Tweets that mention How do your stakeholders see your beer can software solutions? -- Topsy.com
October 12, 2009 at 12:43 pm
Software development is all about communication « Chris van Zadel professional blog
October 16, 2009 at 3:47 am

{ 0 comments… add one now }

Leave a Comment

Previous post: Managing Complex Projects: new book given PMI top honors

Next post: Expanding the business analyst role–good or bad?