Resistance to Change

Recently I lost my trust calculator. A black & boxy Casio DX-100 that I remember buying on my first day of high-school with a crisp $20 note I bought from home.

Now just bear with me - that relates to Business Analysis eventually.

I found it difficult to use at first, but I grew to love it. Over years of high-school, a computer science degree, and a good chunk of my MBA, I think I had used every single function the calculator had and knew my way around it like the back of my hand. I found using it effortless, that perfect user experience where you don't have to think about the device, only what you want to achieve.

Then, to my horror, I lost it half-way through doing Accounting for my masters.

I was actually slightly depressed at the though of having to use any other calculator. I know this is weird, but you have to understand that my relationship with the calculator is four times older than my marriage and that I'm a geek.

So I bought a new calculator. $40 this time. It was all curved edges, sleek lines, and translucent blue plastic. I hated it.

It's true it was (a lot) easier learn than my old one, and had lots of new features, but I didn't know how to use them yet - and even when I did work them out if felt strange, and wrong.

Worst of all a function I used constantly, saving a number to memory and then recalling it, took an extra key-press, and that extra key press was all the way up the top of the calculator. Which drove me crazy.

Even though I knew that objectively my new calculator had more features - I resented it. Every time I saved a number to memory I would silently pine for my old calculator.

Until a few days ago when I found my old dull-black calculator, started using it again, and realised how much I missed all the new features of the shiny-blue impostor. So I went back to using the shiny-blue one.

I wish I could say that this means I now am happy with the shiny-blue one - but no. I still resent the extra key-press for the memory function.

So what are the BA lessons here? (Asides from the fact that I think too much about calculators)

Users value lost utility, more than they value gained utility.

Old systems are viewed through rose-coloured glasses, no matter how bad they are

The cost of learning a new system is intimately felt by users - expect resistance

Even when users rationally realise the new system is better - don't always expect them to be happy, because..

People have emotional attachments to systems that aren't always apparent

I think the last is most important. I went through a whole project with and only found out afterwards that one of the main stakeholders considered the original implementation of the system we were working on the most professionally satisfying and productive point in their career.

The result was they implicitly saw any move to retire bypass the system as slight on them personally.

Resistance to change isn't just about technology, costs, benefits, and features. Even when we think we are being rational we generally aren't.

I'd hidden contraband in the back of that calculator case during a math lesson almost twenty years ago while looking out over a grassy quad. This shiny-blue monstrosity that I'll use for my accounting exam doesn't even have a compartment for that.

BA Bookshelf

Now obviously the best BA bookshelf is a couple of hundred meg of articles on your USB key, but failing that physical books are nice too. Probably the best bang-for-buck in any training budget can be had by buying a nice collection of books for your team and getting them to read them.

It doesn't matter if they all get lost (they will) the impact of a $50 books is bigger than a $1500 training course, and doesn't require any lost billing-days. So what should you buy?

Get a one good book each on:

What requirements are: Karl Eugene Wiegers, Requirements 2nd Ed

How to use User Stories: Mike Cohn, User Stories Applied

Process Modelling: Bruce Silver, BPMN Method & Style (Haven't actually read it, but everything Mr Silvers says is gold so I have no problem recommending it blind)

How to run a good Workshop: EGB, Requirements By Collaboration

Use Cases: Alitair Cockburn, Writing Effective Use Cases (What else?)

Enterprise Arch: W. Ross, Peter Weill, Enterprise Arch as Strategy

I suppose you could thrown in something on data modelling as well - but seriously if you have the head for data modelling you're fine, and if you don't a book isn't going to help. Same for UI design. For the record I have a head for data modelling, but I always need help with User Interfaces (Thomas! Mahesh!).

And this post is not proof-read because I don't have time. I'm going to try and post more often now, which means less quality too.

Amazon List Here

Consultnik no more.

I should probably mention for the tiny minority of readers who don't know me that I'm not actually consulting anymore. I chose to contract directly about a month back as I got a particularly good offer at the right time and the time overheads of doing internal consultancy work and client work at the same time weren't compatabile with finishing off my MBA, while not compromise my religious learning.

It was excellent though - and I fully intend to send my resume back to the consultancy that employed me if I ever decide to go back to consulting. They are a great company.

P.S. My previous post comes out of thoughts I had about how to sell BAs as a service in a consultancy environment separate from delivery work, its just a coincidence that these posts are next to each other. No criticism of anyone intended.

Foxes & Henhouses

When you're beginning an important IT project you're no short of friendly Consultants, System Integrators, Product Vendors, and Outsourced Providers who are willing to offer their advice and help; all with the projects best interests in mind. Many of these provider will also provide you with Business Analysis services to aid in the execution of your project.

However there will come a time when the requirements of the business conflict with the interests of the stakeholders delivering the project, and your Analysts will always be in the center of these discussions – and whose side do you want them to be on?

How can your vendor supplied Analysts deal with a situation where the product they are selling doesn't meet your needs? How often has a consultancy sourced BA suggested anything that doesn't involve follow-up work for their consultancy? How often does a System Integrators BA ever advocate for a scope-increase, even when it's justified?

All of these conflicts of interest come to a head later in the project, typically around a table trying to civilly decide if a given change is a bug or a change request while everyone mentally calculated how much budget is left in the project, and how much slack was built into the profit margins anyway.

The horrible thing is that none of this is conscious - everyone always tries to do whats right. It's just that your views are so conditioned by the influences of your peers and your background.

Best User Interface Ever

I've just found the best user interface that has ever existed. It's a single button that does exactly what you want it do when you press it, there are just a few catches:

* You have to be a toddler
* It only works for radio controlled toys
* You have to want the toy to run around, and not particularly care where it goes.

Thankfully, this is for toddlers - who never care where a toy goes as long as it keeps going, so this is perfect!

What makes it so perfect is that the simplicity of the interface ensures that the toy basically never gets stuck in corners or under things. It transparently enforces a pattern of movement that gets you out of nearly anywhere!



So, how does it work? Well the toy only has two states

A) Going forward
B) Reversing in a clockwise circle.

If you hold down the button you go forward, once you let it go the toy reverses backwards. As a toddler this means that as long as I hold the button down (While yelling with joy) the toy goes forward, as soon as I get disappointed because it hits a wall, or wedges in a corner it reverses itself out.

In the worst situation if its really stuck I get angry because it's stuck and start pressing and then releasing the button (Which is what toddlers do by instinct) then I've done a three point turn and am out of trouble.

Best. Interface. Ever.

This interface is:
1) Appropriate to the user
2) Does what it needs to
3) Encourages the correct behavior in error situations
4) Doesn't get in the way of the experience

If I ever design a UI half as good as this for an IT system I will have done well.

This is the iPod shuffle of children's toys.

Even the device itself is simple, you can see below how the axle is housed in an arc so as long as its going forward it's straight but reversing immediately swings it around.

What sort of "consultancy" are you?

The word "consultancy" gets thrown around a lot and covers some very different organisations and value propositions. These range from just a few people sharing business-cards to true though to McKinsey.

1. Body Shop
At this stage you are just an outsourced agency to find contractors for clients. There are no real relationships between people on client sites it's just an volume game. The value proposition is just out-sourcing your interviewing and trawling through resumes.

2. Bunch-o-Mates / I know a guy..
At this stage one or two key senior people work as contractors out on client site, and bring in their friends and ex-colleagues to the same site. There's no real sales function it's all done through one-on-one relationships. The value proposition is a pre-assembled team of high-quality people.

3. Ad-Hoc Delivery / Hands & Feet
Once your bunch-of-mates hits a certain level of sophistication you can start to out-right own delivery of certain functional projects using whatever methods and IP is already used by the client. Commercially this is when serious profit and risk start to occur. Most organisation that delivery like this rely on one or two "heroes" (normally the owner) to actually deliver and manage client relationships.

4. Repeatable Delivery
Once you've gone through a few delivery cycles you actually start to know a thing or two about what you're doing. At this point you have the methods, IP, and embedded practices to actually reliably repeat delivery of similar solutions. At this point the founder starts to be less involved in the day-to-day and can probably start calling yourself a consultancy with a straight face.

5. Domain Expert
Knowing how to do it internally is great - but being able to pass that knowledge onto other is even better. In the Sydney market PlanIT for testing and Object Consulting for system modelling embody this trend well. Once you have a strong reputation you become sought out first for smaller consulting gigs to improve practice at clients, then as a plain old trainer.

6. Trusted Adviser
At this stage when you say no to your client they stop and listen and your ideas are incorporated into the heart of your clients strategy and execution. You're a trusted source of option and options in your domain or beyond. Congratulations. You don't need to be McKinsey, even if you're just a trusted adviser of a specific domain like data warehouses or mail-rooms that's a great achievement.

(Got some ideas from here while goggling good examples of trusted advisers)
http://onstartups.com/tabid/3339/bid/1699/Startups-Are-You-A-Trusted-Adviser-Or-A-Responsive-Assistant.aspx

Reports for people not databases

Collecting reporting requirements needn't be a boring experience. Too often we try and specify lots of functional detail about the report that doesn't really help instead of concentrating on what's most important. That's why I use user stories to document the reporting stakeholder requirements as well. Just use the following form:

• As a report consumer
  
• I want to know the answer to some questions
  
• So that I can make some decision and take some action
  

The crucial piece of information is how people are going to use the report, what value it adds, and what will be done as a result of the information it contains.

This is the basis of your design, if you get this right the form design flows naturally, if you get it wrong no amount of detail in the report specification is going to save you.

Your reporting requirements shouldn't be relegated to some technical back-water. Theses reports are often the widest public interface to your application, and often the view that the most senior users of your application will see.

If you're willing to put in the effort to separate problem elicitation from solution definition for your functionality, you should be willing to do the same for your reporting.

P.S. Getting your logical model right is an absolutely necessary pre-requisite to the functional design. If you don't get that right your're bound to fail.