Skip to main content

Tag: Validation

Snake Oil or Miracle Cure? Is Agile all it’s Cracked up to be?

The Agile Manifesto was born out of frustration by a group of developers who were fed up with how software was being developed. Software development is a learning experience, and no one understands this better than those who are actually writing the code.

Waterfall was a misguided concept that seems reasonable on the surface but does not work in reality. Since software development is a learning process, it is impossible to think of every single requirement up front and have them signed in blood before starting development. We are all familiar with the limitations of Waterfall. However, how many of you have seriously debated or discussed the limitations with Agile?

It seems to me that Agile is too often viewed as the silver bullet cure to all of our delivery issues. Management is constantly under fire from the C-suite to improve the quality, timing, and costs associated with software development. In response, many organizations are diving into Agile with the belief it will cure all of their ills. Billions of dollars are being spent on Agile consultants and software solutions to manage requirements and project plans according to the Agile principles. All of this is being done with the best of intentions. With all of the certification programs, books, blogs, software and training programs devoted to Agile it seems to me that excessive process and red tape is taking over the concept of being “Agile”.
In multiple organizations, I have heard comments such as “We can’t change the questions we ask during standups – if we do we are not Agile!” A number of Agile practitioners have stated to me that if we change the frequency of retrospectives or other Agile ceremonies, then we are no longer “Agile.” This concerns me.

The goal of software development is not to be Agile. The goal is to deliver high-quality software that solves our customer’s business needs. If we achieve this goal, we will meet our revenue targets and grow the business. Being “Agile” is a worthless goal. Customers do not care if a company is Agile or not. They care about the quality of the product.
Do you think Apple would have more customers if they advertised that they were Agile?

This may be coming across as being harsh, but I want to emphasize that there is a risk of losing sight of the ultimate goal when implementing Agile. So if I haven’t ticked you off, and you are still reading you are probably thinking “Ok, then what do we do about it?” We get stuff done; that’s what we do. I am a proponent of my own software delivery methodology I call “Get Stuff Done” or GSD for short. That’s what we all want to do when we get to work; we want to get stuff done. Companies pay us for how well we Get Stuff Done. Many times our processes and red tape get in the way. Think about what you typically complain about at work. I’ll bet that many complaints are about the processes you are being forced to adhere to. Believe me, I’ve had many conversations with colleagues which debate the actual business value of some of the meetings and processes we are forced to follow.

So how do we go about work and just Get Stuff Done? Well, we’ve all heard about the Ice Bucket Challenge so here is a great first step to take.

I encourage you to take the GSD Challenge! For one sprint or iteration, I challenge you to turn off your electronic system for storing requirements and tracking progress. Just say no to using TFS, Jira, Blueprint, Project Server or whatever system you are using. Collocate your team in a conference room. Get yourself some multicolored sticky notes, index cards and Sharpie markers. Write the User Story titles and Acceptance Criteria on the index cards. Prioritize and size each story by writing the priority and story points directly to the card. Tack the cards up on a whiteboard for everyone to see. Have the team write their tasks for each story on the sticky notes. Use a different color for each group (development, test, project management, etc.). Paste the sticky notes next to the story. As each task is completed, move it across the board to indicate it is complete. If you learn something new, and a completed task now requires more work, simply move the sticky note back to in progress. Your team’s progress will be visible to all. Want to know the status of the project? Simply walk into the conference room and take a look. The GSD methodology relies heavily on two skills humans have perfected and used successfully for thousands of years. Bipedal Propulsion Technology (BPT) allows us to use our feet to get up and walk over to colleagues to communicate using Human Voice Technology (HVT). In my opinion, BPT combined with HVT is far superior to email as a communication tool. As a bonus, BPT is good for you! It gets the heart pumping and progress can be tracked using a FitBit or iWatch!

{module ad 300×100 Large mobile}

Collocated teams using GSD don’t have to worry about reserving a conference room for meetings. Calendar conflicts disappear, and email communication significantly decreases. Want to call a meeting using GSD? Simply use your Human Voice Technology to call out to the team “At 1:00 PM we will be having a Sprint Planning meeting!” It’s as simple as that. Don’t worry; with a bit of practice, you will get the hang of using your HVT more often. I understand that email and texting may be seriously eroding your HVT skills but I assure you it’s like riding a bike, it will come back to you. I suggest for maximum success with your GSD challenge you consider providing the following amenities within your collocated room:

  • A large conference table with network & power connections for the entire team
  • Additional monitors to allow for dual monitor connections
  • One or more whiteboards
  • A projector and projection screen

A little preparation will go a long way to ensuring your GSD challenge is a success. Once the team is collocated, and the user stories are tacked up on the board, you may follow your preferred Agile ceremonies. Standups may still occur at the same time each morning with the team gathered around the whiteboard to comment on their current tasks and what they plan to work on for the day. Standup is a great time for the team to update the board together by moving sticky notes around as needed. I suggest a Retrospective at the end of the GSD challenge to collect feedback from the team on their experience. This should be extremely interesting and provide insight into how the GSD Challenge differs both positively and negatively from your current process.

If you consider attempting the GSD Challenge be prepared for significant pushback from some team members. One of the most common initial complaints about colocation I have heard is “I don’t want to give up my office. I need to think and not be disturbed.” My response is that if your reward for developing software is an office, then you have not actually experienced a fun and rewarding environment. Your reward should be developing quality software in a fun environment that makes millions of dollars, not an office. The team should be allowed to develop their own norms concerning how they will work. For example, when someone truly cannot be disturbed they can wear a special hat or have a funny sign draped over their monitor. Have fun with the challenge and begin working and collaborating as a team. I bet you will be surprised at how little you actually miss your office and the electronic systems most of us rely on to track our progress.

The GSD Challenge is not meant to bash Agile or Scrum. It is to get you actually to think about how you are working and whether the principles you are following actually provide value and allow you to Get Stuff Done. The Agile and Scrum principles are guidelines. They are not laws which must never be violated. Listen to your team and adapt to what works for them as opposed to ensuring that someone can call your group Agile or not. Quality software and making money is the goal. We must never lose sight of that. Thanks for reading and I hope you consider going back to work and getting stuff done!

Playing Hockey Without a Goalie

I was watching an NHL game the other evening. The team was playing a hockey game without a goalie.

Apparently the team had decided that their goalie was too expensive. So they traded him away to another team.

Then the backup goalie was sick. And his equipment didn’t fit anyone on the team, so they decided to “go without.”

In a pre-game interview with the General Manager, he said that it was strictly a financial decision. They felt that the team could fill in the goalie role by sharing it amongst themselves.

If it worked out as he expected, then they might consider this change as a permanent part of their hockey team structure.

At the very end of the interview, he wondered –

What does a Goalie do anyway? For 90% of the game, they’re idle. What a waste of money. Why not get the team to “pitch in” and fill that role? It just makes good sense.

Unfortunately, this story ends badly. The team lost 22-1 in the game. Apparently, no one on the team wanted to put themselves “in front of” +100 mph pucks, so the goal was essentially empty for the entire game.

Imagine that!


Now before you think that I’ve lost my mind, there is a point to my totally made up story. It relates to the ScrumMaster role on Scrum teams.

Not that long ago, I read a LinkedIn article by Ben Linders. You can read it here –

Why Implementing Dedicated Full-Time Scrum Masters Is Difficult – What’s The Alternative?

In it he makes the case that not committing to full-time ScrumMasters is sort of normal behavior. He seems to be saying that it is too costly, too inconvenient, misinterpreted, or too hard to actually COMMIT to doing Scrum as described in the Scrum Guide.

That instead, there are other approaches that are “as good as” having a full-time, dedicated, highly skilled, ScrumMaster.

I simply disagree. And I have a hard time when thought-leaders in our business make these sorts of overarching statements. Sure, I’ve seen all of the anti-patterns that Ben implies. Yes, it’s a hard role. And yes, a large group of the clients I’m coaching initially approach it this way. But I think it’s my job to try to get them to think of applying Scrum principles and practices in a thoughtful, as-intended way.

And being a solid hockey goaltender is a hard role as well. But I don’t think that “doing without” or cobbling something together that marginalizes the role is the way to go.

Wrapping up

Now I’m not trying to pick on Ben. It’s just that his experience is that ScrumMasters are not considered a necessary investment when you’re moving to Scrum. That’s ok.

But I want to go on record as follows:

IF you’re playing hockey, then you need a goalie!
And a skilled goalie, who is full-time, and who is equipped to be successful in their role.
IF you’re playing Scrum, then you need a ScrumMaster!
And a skilled ScrumMaster, who is full-time, and who is equipped to be successful in their role.

That’s just the way I see it.

Stay agile my friends,


Here’s a Meta-Cast podcast episode that nicely compliments this article –

How to Ask the Right Questions Part 1: The Paradox of the Right Question and how to ask it

In my travels one of the more common questions from new and experienced business analysts is “how do I ask the Right Questions?” There seems to be a belief that expert business analysts have a knack for choosing just the Right Question that will produce the answers that will solve the problem. So I thought I’d write a short piece about asking the Right Question, primarily to remove the anxiety and concern business analysts seem to have about asking the right question. I discussed the concept with a couple of business analysts and during the conversation I realized that the problem was not in knowing what to ask, but rather in how to ask it. My short piece blossomed into a four-part article, first discussing the paradox of trying to determine the Right Question to ask, and tips on asking the right question. The second part addresses what questions to ask to make sure you ask the Right Question. The third part focuses on how to ask the Right Question to get the right answer. And the fourth part deals with avoiding asking the wrong questions, or more specifically asking the Right Questions in the wrong way.

The Right Question. It conjures up a image of the business analyst spends time preparing a list of questions, and agonizing over each one to determine whether this one question is the Right Question for this particular stakeholder at this time in this specific situation.

With that kind of pressure on the business analyst to be sure to ask the Right Question, no wonder one of the business analyst’s more frequent questions is “how do I ask the Right Questions?” The issue is never “how do I ask questions?” but always about the “Right Question“. So let us talk about the Right Question and how to track it down and ask it.

Why is it so important to ask the Right Question?

First of all we need to understand that questions are the mainstay of the business analysts’ process. The business analyst lives on information. The more information the better. The business analyst needs information in order to analyze. The analysis of the information is what produces the problem, the solution, the requirements, and the results. And information is acquired by asking questions: first, of yourself, and then of others.

So what is a right question? As with many things in life. One of the better ways of determining how to excel in a particular area of expertise is to see how those we consider to be experts do it. I have mentioned Sherlock Holmes in the past as a model for business analysts in terms of critical thinking and analysis, but Sherlock Holmes was also a consummate interviewer. He not only gathered information with his magnifying glass, microscope, and keen eye, he also questioned witnesses and his clients, not to mention the perpetrators. A classic plot pattern that apparently started with Conan Doyle has Sherlock Holmes apprehending the culprit and then asking the wrongdoer to explain the details of the crime. This begins an description occupying a good portion of the book or story explaining all the details of Mormon revenge (A Study in Scarlet), stolen treasure (The Sign of Four) and so forth.

Perhaps a more current and non-fictional model for asking questions might be better for us to understand what the Right Question is. David Frost and Barbara Walters are examples of people paid lots of money to ask the Right Question. There are also print journalists of note who break stories by apparently knowing the Right Questions to ask.

So why is there such a focus on asking the Right Question? Perhaps because the literature seems to indicate that there are Right Questions out there floating around and the business analyst simply has to grab one and ask it. For example, the lead sentence in an article written in 2011 by Wilco Charité titled “Asking the Right Questions: Process Discovery” says, “If you are an internal Business Analyst or consultant asking the right questions in a Discovery project is a critical skill.” [1]

And there are further exhortations from various people of note: Actress, activist, and author Vanessa Redgrave says, “Ask the right questions if you’re going to find the right answers.” Entrepreneur Robert Half says, “Asking the right questions takes as much skill as giving the right answers.” And anthropologist, Claude Levi-Strauss suggests: “The wise man doesn’t give the right answers, he poses the right questions.”

Perhaps the belief that there is a Right Question comes from the many lawyer shows in which Perry Mason or Jack McCoy (Sam Waterston in Law & Order) always seem to ask the question which causes the person on the witness stand to break down and confess the murder or say some incriminating statement that turns the case around. Or the detectives like Miss Marple, or Hercule Poirot, or Columbo, who seemed to be able to ask the Right Questions that produces an rendering of the crime and catches the perpetrator.

And how does the concept of the Right Question affect the business analyst?

Even when a business analyst feels as though they have done a particularly effective job of elicitation, and have all the information that defines the problem and / or solution, there are “surprises” that crop up after the elicitation phase is theoretically done. And that is when the business analyst commiserates with other business analysts saying, “They didn’t tell me about that! If only I had asked the Right Question!” Business analysts need to get information and it seems that sometimes only the Right Question will get that information.

What is the Right Question?

So with all this concern about asking the Right Question, perhaps we should determine what a Right Question is.

Trying to figure out the Right Question to ask is a paradox. You cannot know if you’ve asked the right question until you have received an answer. If the answer to a question gives you the information that you are looking for then you have asked the Right Question. But you only know that it was the Right Question after the information gathering session is over and you have analyzed the results. And if you ask many questions to get the information you are seeking, how do you know which one is the Right Question?

So, what is a Right Question? The Right Question is the question that gives us the Right Answer. We may never really know what the Right Question is. Only the Right Answer is important.

For example, in perhaps the greatest interview of the 20th century, David Frost got former president, Richard Nixon to say, “I let down my friends. I let down the country. I look down our system of government and the dreams of all those young people that want to get into government, but now think it too corrupt. I let the American people down and I have to carry that burden with me the rest of my life.” This answer has been quoted and referred to many times and is the climax of the stage play and movie “Frost / Nixon”. But does anyone remember the question that preceded. Does anyone remember the right question? What remember is the right answer. And, in fact, that answer was the result of dozens of questions over several sessions, all asking for the same answer, which was finally given in response to just one question.

The bottom line: we can never really know we have asked the Right Question until after we have all the answers and analyze them to see if we now know what we need to know; we have the Right Answer. But, then, of course, you have to know what the Right Answer is before you ask the Right Question. And that might be the problem.

How do you ask the Right Question? Ask more questions

“Asking more questions reduces the need to have all the answers.”
Donald Peterson, former CEO of Ford Motor Company

The real answer to asking the right questions is simple: keep asking. When you ask enough questions, in and among all the questions you ask are the right ones. As long as you listen well and keep the focus on the problem or the solution, it does not matter which questions are Right. In the end, the Right Questions are those that get you relevant information. [2]

The only true way of asking the Right Question is to keep asking questions and asking more questions. The more questions you ask the greater the chances that you will get the answers that you are looking for: especially the Right Answer.

In addition to eventually asking the Right Question, asking more questions has the advantage of increasing the amount of information we as business analysts have to analyze, increasing our chances that we have found the Right Answer.

Consider our models, David Frost and Barbara Walters who always seem to ask the Right Question . What we see is not the full interview, but an edited version. The editors put the show together for entertainment, cutting out the questions that were not so Right, and adroitly placing the commercials right after a particular Right Question so that it will have the most memorable effect. To get the one hour dramatic interview with Prime Minister Tony Blair, President Richard Nixon, Michael Jackson or Jane Fonda, Frost and Walters had to prepare thousands of questions and probably ask hundreds. Many questions were pedestrian and many probably got answers that are not pertinent, or at least not entertaining or informative.

And those Pulitzer Prize winning journalists have reams of notes from hundreds of interviews consisting of hundreds of questions to produce a single news or magazine or article. A major part of a journalist’s work is the editing of the information gained from interviews and other information gathering into a cohesive whole

Business analysts do have a form of editing: it’s called analysis. The analysis is done after the information is collected, not before. We don’t analyze what we are going to ask so that we produce the Right Question; we just ask as many questions as we can and get as much information as we can so that we can determine the Right Answer afterwards. While there are techniques to getting more information, determining the Right Answer relies almost solely on the ability to analyze. More on this later.

How do I ask more questions? Redevelop Intellectual Curiosity

One personal characteristic that will help you ask the Right Questions is intellectual curiosity. When you can inculcate a desire to know everything about everything, questions, especially Right Questions, come more easily.

Business analysts possessing intellectual curiosity have voracious appetites for learning. They do not shy away from new or unfamiliar concepts but rather try to incorporate those concepts into their understanding. They tend to be very good listeners who absorb information like sponges.

Life coach, Dr. John D. Skare, Ed. D, defines intellectual curiosity as “a term used to describe one’s desire to invest time and energy into learning more about a person, place, thing or concept””

Are you really interested in the person or persons you are questioning and the information they possess or are you more interested in completing the requirements document? This intellectual curiosity is what drives us to ask more questions. Just as a child is curious about the whole world and his or her part in it, we can be curious about the whole business and our initiative’s part in it.

Developing intellectual curiosity is not difficult. We all are born with intellectual curiosity As children we truly want to know what the world is about, and what our place in the world is. We ask questions and more questions. Children, especially two-year olds, do not have to learn the “5 Whys”. They ask Why automatically without thinking. Over the years as we grow up we are taught not to ask questions. Research shows that young children have hundreds of questions every day, but by the eighth grade those same children ask only two questions a day on the average. Why?

“In school, we’re rewarded for having the answer, not for asking a good question.”
Richard Saul Wurman, original creator of the TED Conferences

Maybe it’s because the adults we are asking don’t know the answers and tell us to stop asking, or maybe we just get frustrated and stop asking. Perhaps it’s because we are conditioned by that age through school to have more answers and to ask less questions. [3]

As adults, especially in business, there is also another reason: we cannot afford to appear stupid by asking questions. People believe that they got their position or place at work because of what they know, their experience, and asking questions will belie that assumed knowledge. The belief is; if you are a “knowledge worker” and therefore paid for your knowledge, asking questions shows a lack of that knowledge and places your job, and perhaps career in jeopardy. And this includes business analysts. Despite the exhortation, “there are no stupid questions.”, Most people appear to believe more ardently that there are Stupid Questions, then that there are Right Questions.. After all, I don’t hear anyone asking how to ask stupid questions, and I doubt anyone that article titled “how to ask stupid questions.”

So what to do to recapture the attitude of intellectual curiosity? Think like a child? Well, yes. Listen naively as though you have never heard the information before, even if it is the eighth straight interview or information gathering session on the same subject. Assess the information you are receiving critically and think about what question you might ask. For example,

  • Are there any words that might be ambiguous?
  • Am I making any assumptions?
  • Is the responder making assumptions?
  • Can I get more details about what they are describing?
  • Can what they are describing be construed generally?
  • Is the information relevant to the question (if not why not? And how do I get relevant information)?
  • Why is the responder answering the question in this particular way? (e.g. giving closed ended answers to open ended questions)
  • What else don’t I understand about this answer or this situation?
  • Why are they not able to answer a particular question? Who can answer it?
  • Are they answering because they assume I expect an answer and not because they really know?
  • Do they want to answer my questions now, or at all?
  • And so forth

Is that all there is to asking the Right Questions?

To ask the Right Questions, you have to know what to ask, who has the information to answer the question, when the question is indeed answered, how to ask the question so that you get the information needed, how to analyze the information to produce the needed answer, where to place the answer among all the other information you have received, and when to go back to ask the question again.

Distilling it down: there are three basic skills to asking the Right Questions.

  • Know what to ask the Right Question
  • Know how to ask the Question the Right way
  • Know how to analysis to determine the Right Answer

Since I’ve run about out of word space for this part of the article, I will end here. The next parts will address

  • How to ask the Right Question by knowing what to ask
  • How to ask the Right Question by knowing how to ask it
  • How to avoid asking the wrong questions

Look for them in upcoming Business analyst Times issues.

Don’t forget to leave your comments below.

[1], March 14, 2011
[2] Blais, Business Analysis: Best Practices for Success, John Wiley, 2011
[3] Coleman, Ken, One Question, Howard Books, 2013. Not only does this book describe the reason why we don’t ask questions and the importance of asking them (in the introduction) but it also contains examples of interview where Right Questions are asked. Remember however, the book and interviews are edited.

The World’s Theory – The History of Business Analysis & Evolution of the Business Analyst

As we all know, the role of the Business Analyst has evolved significantly over the last two decades. As more companies have realized their need for strong business requirements to support their IT efforts, Business Analysts have achieved a permanent role in most organizations. But how did we get here and what sparked the birth of Business Analysis as a craft? This can be explained by what I call “The World’s Theory”.

From times past, more specifically, since the birth of the first programmable computer in the 1940’s until the early 1980’s, computer systems were used primarily by the government, universities and the companies that made computers.

Basically, they were the only entities that could afford to use technology. Not just on the cost front, but also the cost of time and effort. There were many reasons why technology was so expensive in these ways at the time, namely,

  • Data storage was very expensive and took up an enormous amount of space,
  • Data was difficult to access since the data was stored in one-directional flat files,
  • It was difficult to write programs to access the data,
  • There was limited functionality built around mainframe systems, and
  • The only user interface was achieved through the “green screen”.

However, in the 1980’s – early 1990’s, things started to change. Data storage became less expensive, relational databases were introduced, new object-oriented programs such as Java were invented and the first graphical user interfaces came into being. All of these events led to a boom in information technology and business’ and programmers went wild chasing “the next big thing”. But something was missing. Although information technology had advanced to where mainstream businesses could utilize computer technology to improve their business processes and more quickly react to changing business environments, technology actually started to become more expensive. Why?

The value of technology was apparent, but critical dollars were being spent on software rewrites, updates to meet business needs not previously identified, increase in maintenance costs and resolving software defects. As business users continued to interface directly with software engineers their needs got lost in translation. They simply could not speak “technology-talk” and articulate their needs effectively while programmers could not always interpret what the business users were trying to convey. Boom! The world of the business collided with the world of technology and the craft of today’s Business Analysis was born.

Now, pseudo-Business Analysts had been around for a while, but they were not Business Analysts as we know them today, much like Project Managers of the era were not known as we know them today. Business Analysts were usually called Systems Analysts and the role was typically played by a software engineer in addition to his programming duties. This was not an ideal situation for the previously mentioned reasons but mainly the difficulty in truly understanding the business model of the organization and applying that understanding to the technology solutions.

So in order to support the business model, the role of the Business Analyst had to be developed and has done so over the last twenty years. In order for IT systems to deliver success for the business, three factors need to be present: 1) the business needs must drive the development of technology solutions, 2) the implementation of a technology solution must be accompanied by the necessary business changes, and 3) the requirements for IT systems must be defined with accuracy. The Systems Analyst of the past was preoccupied with #3 but the operation of a business in today’s global economy demands all three be met.

The modern Business Analyst is not only concerned with the requirements, but also the meaning of the requirements.

  • Business Drivers – why do we need to make change?
  • Business Vision – what does the business look like after we make the change?
  • Business Objectives – how do we measure our success?
  • Business Requirements – what elements need to be implemented in order to realize the business vision?
  • Business Rules – what conditions govern the behavior of the implemented solution?

Notice that all of the above deliverables are preceded by the word “Business”. Hence, the word “Business” precedes “Analyst”. The Business Analyst is not just technically savvy but also in tune with the operational business model for the company. This allows the Business Analyst to be a well-rounded individual with skills to speak to business problems and define technology solutions.

And the importance of the Business Analyst has really been recognized in the last decade as businesses more readily seek technology solutions to complicated business problems. But because of the added business focus a Business Analyst provides, businesses have been able to utilize the Business Analyst to solve problems that do not require technology changes such as business process improvement, organization changes and the streamlining of operations. More and more, Business Analysts are becoming involved at an earlier stage of project work where they can not only define the business requirements, but outline the current state and future state of the business as it relates to the business problem and solution. You can also see Business Analysts taking part in the development of business cases with cost/benefit analysis as well as the selection of technologies to support the solution.

In the past, many businesses said, “Can technology help us solve this problem?” But the question no longer comes exclusively from the business perspective but rather from the technology strategists when they say “What can technology do to enhance the product offerings and market opportunities that exist for the company?” Information technology enriches the business offerings by not only supporting core competencies, but giving businesses the ability to focus on those competencies without the distraction of ancillary business operations such as human resources and supply chain. And Business Analysts are at the forefront of this concept since they can speak not only to the technology solution, but how that technology solution should be implemented to meet the market desires. This is how businesses achieve competitive advantage. Not by wasting time and resources on rewrites, maintenance and defects, but putting action in motion to use technology to better reach customers. And the Business Analyst plays a key role in making that vision a reality.

Don’t forget to leave your comments below.

Smart Parking Meters and Other Enhancements we Could all do Without!

As my fellow commuters and I drove into work this morning, the mood in the car couldn’t have been better: it was Friday – and the last workday before Christmas. The traffic on the motorway into Auckland was free-flowing, the sun was shining in a clear blue sky and everybody was discussing where they would be spending their Christmas break.

The conversation turned to a new parking scheme introduced at one of the holiday destinations. New, smart parking meters on the town’s High Street would sense when a car had parked in their bay, and send a message to the nearby parking wardens. The idea was that by the time a warden had walked over they would find either a car with parking paid up, or a car which had been parked for long enough without paying to earn itself a ticket. Armed with their new real-time targeting systems those wardens became the lethally effective guided-weapons they always dreamed they could be: the poor man’s RoboCop, if you like. The poor motorists of the town never stood a chance. The strike rate of the wardens hit close to 100% and the designers and sponsors of this brilliant new system celebrated in the Town Hall.

But then came the complaints. Shopkeepers and Business owners on the high street unanimously hated the new parking meters. They already struggled to compete with the allure of the big out-of-town shopping mall, which offered two-hours worth of free parking, and now this parking-warden feeding frenzy was just about the final straw. Things were looking bad for the High Street…

It’s a great example of designing a solution without fully thinking through the problem. “A solution looking for a problem” is how one person described it, although I think it might even go a little deeper than that: I think this solution knew exactly what problem it was trying to solve, and it did so brilliantly. But nobody had looked at the ‘problem’ in the context of the overall strategy or objectives for that High Street, to see how much of a problem it really was in the first place.

Sound familiar? How often have we as BA’s found that we have spent time and effort coming up with a really neat solution, only to find that it doesn’t quite fit, for some reason that wasn’t covered in the original scoping process?

Attending the BBC conference in Sydney last September, I listened to Kevin Brennan, Chief BA for the IIBA, talking of his vision for BAs to move out of the realm of gathering requirements, and even out of the realm of designing solutions, and move up into that space where we actually look at how we can add value to the organisations we work for. As BAs we’re very good at the first two. We have all the tools and techniques and methodologies, but they only take us so far. If we want to design better High Streets, or even better towns, rather than just better parking meters, we need to look beyond the process of business analysis, and think about adding value.

That’s not to say there is no place for the tools and techniques, because there is. But the other thing I noticed was when the audience at the BBC conference was asked what Business Analysis involved they all came up with words like listening, communicating, empathising, and understanding.

I was relieved to hear this, comparing this to answers I’ve heard from junior BAs on occasion. They all gave responses that focused on the tools and techniques. They used terms like gathering or documenting requirements, modelling, eliciting, analysing. Not a soft skill in sight. But without the soft skills we never will get beyond the mechanical work of being a BA and move on to adding value. That’s why I stress to the students I’ve taught that there’s far more to being a BA than the techniques, important as they are. You can be a BA without ever employing these techniques. I know, because I’ve done it. It might not be pretty, but we got to where we needed to go. And I’m sure that’s better than designing the best parking meter in the world, for a street that doesn’t need it.

I’d love to hear what the rest of the BA community thinks of my point of view, so please don’t hold back: tell me I’m wrong, tell me I’m right, or if there’s anything else you want to tell me, just get in touch!

Don’t forget to leave your comments below.