“Do you want fries with that?”

Do you buy fast food? C’mon... admit it... you do, don’t you? Whether it’s once in a blue moon, once a week, or every day (yes, I’m talking to you!), we’ve all been into those places, whether we admit it or not.

So, we’ve all heard the phrase “Do you want fries with that?” (or its equivalent). Annoying, isn’t it? Sometimes you just feel like shouting, “If I wanted fries, I would have bloody well asked for them!” (or is that just me?)

Well, there’s one chain of fast-food stores I go to where the terminals used by the people serving you have been specifically designed so that they literally can not start entering your order until they know whether you’re ordering just a main item or a meal deal. This forces them to ask you whether you want a meal deal at the very start of your transaction, while you’re still trying to work out what extras you want on the main item: “Did you want that in a meal, or by itself?”

Whose needs does this system fulfil? Yours, the customer’s? Not really – usually, you just want to order what you want, without being interrupted with questions about items you might not necessarily want. The needs of the person serving you? Not really – they don’t care whether they ask you that question or not, just as long as they can record everything you ask for when you ask for it.

This process is being enforced by some marketing executive in head office. “Make sure they always up-sell!” And, away the BA went, to design a system that enforces upselling, despite the fact that this will annoy everyone interacting with the system – users and customers alike. The final result is a system which requires the user to enter either a main item or a meal deal as the first step of the process, even though this is not the natural way for many customers to place their order.

There are other ways to handle this.

I used to work in the fast-food industry myself, a long time ago. Home-delivery pizza. At one point, I was involved in revamping our store’s order-taking terminals. These were very simple creatures with small monochrome LCD text-only screens (it was the ’90s!), and a large touch-pad with various buttons indicating the various items on the menu. I wasn’t a BA at that stage; I was just a person who knew a lot about the store and its menu and ordering processes, having worked there for a couple of years, but who also understood computers. Regardless, the guy programming the system and I came up with something we thought was the easiest way to handle the “Do you want fries with that?” issue.

We decided to build it for the customer’s needs and the order-taker’s ease of use.

The user simply entered the items into the system, using the touchpad, as the customer requested them. The system then worked out whether any special deals had been ordered (1 pizza + 1 garlic bread + 1 drink = Meal Deal A), and advised the final price accordingly. There was no need for the order-taker to interrupt the customer’s flow of thought by asking extraneous questions; the customer wasn’t annoyed by being asked about things they didn’t want, but was happy that they automatically got the cheapest price.

So, when you’re in a business, trying to work out their needs, who do you ask? The executives? The customers? The users? We’re all told that we need to elicit the business needs – but whose needs are we trying to meet? Therefore, as well as eliciting requirements, we also need to decide whose requirements to elicit.

Users would never do that!

In one project I worked on, we were developing a piece of software to collect data from a physical external sensor. The sensor was going to be used outside, in various locations and conditions, and it would be connected to a laptop computer where the software was installed, for the software to collect data from the device for later analysis. 

As well as being the Business Analyst for this project, I was also the lead Tester (it was a very small project – just me & the developer).

During one testing session, with the software happily collecting data from our sensor-emulator (a little box of electronics built to simulate the output from a sensor, for testing purposes), I suddenly and deliberately yanked out the USB cable connecting the emulator to the laptop. The software crashed, and the laptop froze. I had to turn the laptop off and restart it.

I then helpfully reported this outcome to the developer, whose response was: “Why would you test that? Users would never do that!”

He was absolutely correct: in the normal course of events, a user would NOT suddenly disconnect the sensor while the software was collecting data. That’s just a silly thing to do!

However, this raises an important point: are you testing only for the perfect user? If all you’re ever going to test is what the users should do, then your tests are inadequate.

Because silly things do happen in the real world. Cables do get accidentally pulled out of sockets. Or deliberately, even. Or sensors stop working. Or users press the wrong combination of buttons. Or try to enter their address into the Phone Number field. Or accidentally try to delete the file/record they’re currently working on. Or... anything. And, if your system’s response to unexpected behaviour is to crash, and also crash the hardware it’s running on, that’s a problem. That’s a big problem. Systems should know how to fail gracefully, and not act like Samson, pulling the whole temple down around them in a fit of temper.

So, when I’m testing I always remember that it’s just as important to test the silly things as the sensible ones. 

Which can be fun, sometimes... YANK! J

For your grandmother

For your grandmother


I had an interesting conversation with a developer colleague about how to design a work flow for customers.

We were working on a system which received data from customers via email: the customer would attach a pre-approved file to an email, and send it to our system, which would then automagically extract the data from the attached file. This was seen as a necessary method for getting data from hundreds of small business customers who had neither the resources nor IT knowledge to set up file transfer protocols. 

The developer in question (a lovely chap, but a tad over-enthusiastic at times) suggested that we should authenticate the incoming data. This would prevent hypothetical nasty folks from trying to wreck our system by sending us bad data. I baulked at this, as I didn’t think we’d get our barely computer-literate customers to start entering authentication details as well as the basic data.

He then tried to convince me of his point of view (all friendly!). Here is his key argument (it was by email, so this is copied and pasted, word for word):

* * * * *

At an emotional level, I always pick on a skilled friend or ex-colleague, & imagine explaining a design decision to him.

“So, then we receive the email and ...”
“Wait, just like that?  What authentication do you use?”
“None.”
“WTF?  Seriously dude.” 

* * * * *


And, herein lies a trap. While it’s nice to build a system with all the bells and whistles, it’s not going to be used by experienced computer programmers. It’s going to be used by all sorts of people, from experienced developer to novice user. Furthermore, we had been reliably informed that some of our customers barely had the IT knowledge required to send an email.

If people can’t use a system, they won’t. And, there’s no point building the best system in the world if the customers don’t understand it.

So, my reply was:

* * * * *

Whereas I imagine the least computer-literate and most difficult person I know, and imagine explaining the use case to him/her...

“So, you open an email, attach a file -”
“How do I do that?”

... 15 minutes later...

“Now, you type in your username and password.”
“Where are they?”
“We sent them to you last year...”
“Oh. I can't find that email. Could you send them again?”

* * * * *

Remember – you’re not designing the system for a developer. You’re designing it for your grandmother.

An Accidental Agilist

I never set out to be an Agile Business Analyst. It happened to me quite by accident.

For starters, I thought I already WAS an Agile BA!

The corporation I was working in while I learned Business Analysis promoted the fact that its project methodology was based on Agile principles. So, naturally, when I was out in the job market and saw ads asking for Agile experience, I applied. Why wouldn’t I? I had Agile experience!

When I started work at my current workplace, one of the first things my manager asked me to do was to prepare a presentation explaining the Agile methodology to our stakeholders. They were unfamiliar with this philosophy, so it was best for us to explain what this was about before we started the project.

So, I sat down and wrote an informative presentation, explaining all about our Agile methodology: how we’d sit with them at the beginning of the process, and document all their requirements; how we’d then go away and work on these requirements; how we’d come back at the end of the development and ask them to test the program. It was a wonderful presentation.

I gave it to my manager for review.

He came to me a couple of days later and asked me to do it again. I was a little surprised but, well, he was the boss, and I was the new employee trying to make a good impression. So, I revised it and re-wrote it, still explaining about gathering requirements up front, then doing development, then getting the users to do their testing.

A few days later, my boss came to me again and explained that our company had an account with an online bookstore, and I might be interested in reading a book that was available there: ‘Agile and Iterative Development: A Manager’s Guide’, by Craig Larman. Well, why not? He’s paying me – if he wants me to read, I’ll read. 

So I read.

I read about sprints and iterations, and just-in-time requirements, and user stories, and story points, and The Agile Manifesto, and prioritising working code over documentation, and preferring response to change over following a plan – this was nothing like what I knew! And, embarrassingly, it was nothing like the presentations I’d written. I went back to my manager and said I’d revise the presentation again.

I then realised that my previous employer had led me astray. Their statement about their processes being Agile was misleading at best – from what I now knew, there was nothing agile whatever about what I learned there.

So I kept reading – every online book and website I could lay my eyes on, including:

• ‘Agile Estimating and Planning’, by Mike Cohn
• ‘User Stories Applied: For Agile Software Development’, by Mike Cohn
• www.agilemodeling.com, by Scott W. Ambler

I had no idea who these people were – I just knew that I needed to learn about Agile, and quickly. Thank you, Google!

Luckily, I had some time: the developers’ start date was delayed due to budget issues. So I read and read and read.

Then the developers arrived, and the project started in earnest. The project manager and both developers were experienced in Agile methods. I... was not.

We were using a hybridised Scrum methodology. So, I started writing user stories. I helped plan iterations. I sat with the developers and worked with them every day. I wrote test cases instead of requirements documents. I attended daily stand-up meetings. I did none of things I’d done before; none of the things I was used to. Everything was new to me.

I worried that I didn’t know what I was doing; I stressed every day that I was letting the team down; I tried as hard as possible to work in a way I’d never worked before. There were times when it got too much for me – and I’d take it out on our more senior developer, who would patiently accept my bad temper, knowing that it was directed more at me than him.

However... I adapted. Now, I can’t imagine working any other way. When I attended a BA conference recently, and a presenter started talking about how to write a better up-front requirements document, or how to manage change requests, I found myself thinking that this was a silly way to work. Why would anyone waste time writing a big up-front requirements document, knowing that a lot of it would change or even be out of date by the time it was needed? Why not simply write another user story, and add it to the product backlog, to be fleshed out just in time for development?

Without ever intending to, I made the transition from traditional waterfall to one of the Agile methods.

And... if I can do it accidentally, you (or your organisation) can do it deliberately. What’s holding you back? Fear of the unknown? I didn’t even know what Agile was when I stumbled across it. Fear that you won’t be able to change the way you work? I didn’t know what I was doing, but I managed. 

I’m not here to say that Agile is better than waterfall (that’s another blog post!). But, I will say to anyone who is considering making the transition: If I can do it, anyone can.

The Business Analyst who wasn’t (Part 4)

So, here I was, retrenched and ready to be a real, live business analyst. I had a few years’ experience acting unofficially in business analyst-type roles, but no official “Business Analyst” title to put in my resumé.

First things first. Fix that resumé. I was a Business Analyst, damn it, even if I’d never had the title!

And, out I went into the big wide world, graduate diploma in one hand, resumé in one hand in the other, and an immense supply of wide-eyed optimism.

Then I started reading the job ads. First, there were the ones which said, “Senior Business Analyst wanted. Must have 10 years’ experience.”. Clearly that wasn’t me. So, I shrugged and read further: “Business Analyst wanted. Must have 5 – 7 years’ experience.” Okay, maybe I should lower my expectations. I continued looking: “Junior Business Analyst wanted. Must have 4 years’ experience.” Say what? Even a JUNIOR business analyst has to have four years’ experience? But, I only had about 3 years under my belt – and that was stretching the truth a tad. 

Still, I sent application after application after application. And, I got rejection after rejection after rejection (when they bothered to reply at all...). I was close to giving up. I seriously questioned whether I had what it took to be a business analyst. Maybe I’d been deluding myself all along. Maybe there was a reason why I’d never achieved the title of “Business Analyst”.

Then, suddenly, I started getting some glimmers of interest. A phone call; an interview; an email. In one week I had four interviews! And, then, one of those interviews resulted in my getting a job with the title of “Business Analyst”. I had made it!

(Except that I still had a lot more to learn – but that’s a different blog! As is the story of how I passed that interview.)

However, I have a friend who is currently trying to attempt the same thing as me: to take his informal, unofficial, experience of analysing business processes and needs, and transform himself into a true business analyst. He’s asked me for advice. Unfortunately, I have none for him. My own transition resulted from a combination of persistence and luck.

As far as I can see (and I can’t see very far at all!), there seems to be no obvious career path for a person to become a Business Analyst. If you want to be a developer, or an accountant, or an electrician, or a doctor, there are steps to take, courses to attend, apprenticeships to serve. However, how does one set about becoming a Business Analyst?

Stepping into this profession from the outside seems to be impossible – especially when even junior roles require 4 years’ experience! It’s the old Catch-22: you can’t get a job because you don’t have the experience, but you can’t get the experience because you don’t have a job. 

So, how do people break into the Business Analysis profession? What should I recommend to my friend, or to other people in his situation? How does someone become a Business Analyst, except by accident?

The Business Analyst who wasn’t (Part 3)

Just as I was ready to start looking for a transfer to IT as a real, live Business Analyst, an opportunity came up which I could not pass up...

One of the first things I’d noticed when called in to act as user representative on the GST system project was that data which had previously been stored and processed in two separate systems was now combined in a single system. And, as someone who had had to perform large complicated calculations involving both sets of data each month, my first observation was: “Now that you’ve got all this data in the same system, you can get it to do all these calculations.” To which the answer was, “No. We’re only here to replace the legacy systems. Anyway, you’re too late – these decisions needed to be made months ago.” Oh, maybe I should mention – they only called for user representatives after the project had already been underway for a few months, and development was well progressed.

Well, I refused to let go of this idea. I went to the business process owner (who I knew, as a result of working in this process for years) and suggested this improvement. His first response was that it was impossible; it simply couldn’t be done; it was literally impossible to get the system to perform these calculations. I then embarked on a three-month campaign to convince him that it was possible. Bit by bit, piece by piece, concept by painful concept, it sank in. Eventually, he turned around from being my greatest obstacle to being my greatest supporter.

Naturally, having the business process owner on board gained great credibility for the idea. Soon (in corporate terms – it was actually about eighteen months later!), a project was approved to improve the GST processing system, starting with – surprise, surprise! – incorporating these complicated calculations. 

And, in recognition of it being my idea, and of my experience on previous projects, I was officially asked to be the business analyst for this project. I was finally acknowledged as a BA! Sort of. I was still officially in my old clerical job, and still being paid my previous salary – I was merely on secondment as a business analyst, and only part time, at that. At the end of the project, I would go back to my old job, and still not be a BA.

That project ran for about eighteen months, during which I was the BA in name and in actuality. I loved every minute of it (even when I hated it!).

Toward the end, the company underwent a massive restructuring program (yes, these things keep happening to me), and I was retrenched. According to HR, I was in my finance & administration department, but they clearly didn’t need me if they could loan me out to work on projects for the majority of my time. Coincidentally, the project manager for the GST project was also retrenched at the same time.

The project sponsor came back from two weeks’ leave to find out that the project manager and the business analyst had both been retrenched and were leaving within two weeks – but the project still had six weeks to run. Panic ensued! She then found out that she could keep only one of us, and only for the necessary six weeks. So, I found myself acting as business analyst and de facto project manager (with a mentor!) for the last six weeks of that project.

Then, I was retrenched. Again.

The Business Analyst who wasn’t (Part 2)

A decade later, I was on track to becoming a real business analyst: I would be a wooden boy no more! I studied Business Computing at university, and was determined to become a real Business Analyst (now that I knew that’s what it was called).

I had a great manager, who sincerely believed in helping her staff to develop themselves. She now actively sought out opportunities for me. Where she’d previously been pimping me out as an all-round troubleshooter, she now started looking for opportunities for me to start the transition to a more IT-centric role.

And, one came up within a year. There was an IT project underway to replace our existing GST processing mainframe systems with a shiny new GST processing system on our in-house financial systems platform. I was put forward as a “User Representative”, to help guide the IT project team with their requirements.

The Business Analyst on the team very quickly identified me as an embryonic BA. Soon, I was not just giving user feedback on the new system, but was brought in to help with design issues and user testing, and acting as a de facto assistant BA – including doing system testing. The BA even described me as Mr “Let’s break things with wacky permutations.” (as a compliment!).

Then... for some reason I’m still not clear on, they dismissed the BA. There was talk of bad performance, but I wasn’t knowledgeable enough or involved enough at the time to determine this for myself. However, they still needed a Business Analyst, and the nearest thing they had to one was... me! So, without anyone ever deliberately deciding anything, I was informally promoted from user representative, to de facto assistant business analyst, to unofficial unacknowledged business analyst. I only worked this out after the fact – at the time, I thought it was natural for user representatives to sit in on design meetings, and to write requirements documents, and to write UAT test scripts, and facilitate UAT sessions for the wider user community. BA? Nearly, but not quite.

About a year later, another IT project came up in my area of subject matter expertise. Again, I was brought in as a “user representative”, but the project manager and my manager both knew that this was code for “business analyst”. I was writing user stories, I was collaborating with the developers, I was intimately involved at every stage of the project, from start to finish (again, I was the UAT leader).

I was getting closer to my goal, but still wasn’t officially there. I’d acted as the BA on one and a half projects now, and I was ready to get the title. I was readying myself for a transfer to the IT division, when...

Stay tuned for Part 3