Business Analysis Consultnik

Easy to Use vs Hard to Misuse

2011-12-13T15:32:00.000-08:00

It’s an awful thing to admit, but I think old mainframe green-screen applications are easier to use than slick web applications; where modern web apps have the advantage is that they are hard-to-misuse. “Easy to Use” is very different to “Hard to misuse”. They are two very different things with very different implications for system strategy, enterprise arch, and business requirements.

• Easy to Use: As a regular user or seasoned operator I want to be able to do things effortlessly with a minimum of interruption so that my workflow, thinking, or customer service is not interrupted.

• Hard to Mis-Use: As casual user or end customer I want it to be obvious to me how to accomplish normal tasks so that I can complete teh activity with a minimum of frustration and get on with my day.

I’d illustrate with calculators. I know I over-use the calculator similes; but I’m a geek and if you’re reading this chances are you are to.

Of my four favourite calculators in my house, I consider them all “easy to use” – but in really different ways:

My HP12C financial calculator is simple for complicated calculations (Thanks to RPN) or financial calculation (Thanks to dedicated functions; but my wife can’t even use it to do simple arithmetic. It’s very easy to use – it’s just very easy to misuse it as well as normal people don’t think in Reverse Polish.
My Blue HP is simple for my wife as she just types in the calculation, or for me when I’m learning new techniques as it displays everything on screen. It’s very hard to “misuse” this calculator as it feedbacks everything you’re doing to you, and uses the “standard” mental model of arithmetic.
My Casio Calculator watch is simple for use on the go; despite the numbers being tiny and a lack of dedicated functions.

So the things I’d like to point out from this:

Being hard to misuse generally comes from the systems metaphor matching to users mental model with the minimum of differences (My wife think of 1 + 1 = 2, as does my calculator.)
Being hard to misuse is helped by copious user feedback – that is useful for keeping people calm that their operation is on track but may not be absolutely necessary (think confirmation screens, double entering passwords, etc)
Being easy to use generally comes from dispensing with the feedback and cues and exposing only the information the user needs to know (Simple, powerful inputs. Command lines, etc)
Being easy to use is enhanced by coming up with a different metaphor (Instead of “1 + 1 = 2” you get “1 push 1 +”) whose benefits are only obvious with prolonged usage.
Easy to use is all about context. What makes my calculator watch easy is the tiny keys and screen which give portability – but in a desktop calculator this would be a major fault.

When you get it really right you come up with something that is both Easy to Use and Hard To Misuse. I think Google Mail is a great example. The core metaphor of “tags’ is simple and understandable, but can be very powerful once you work at it. It’s interface gives you a lot of feedback on what’s going on – but in a clear way that guides you through. It provides lots of keyboard shortcuts– whilst giving novice user cues.

Little Change In No Silver Bullet

2011-08-24T18:20:00.000-07:00

While I was doing some offering re-read a classic article that I remembered from my old battered copy of mythical man month called “No Silver Bullet”.

What it drove home to me was how absolutely central the work we do as BAs is to the value that IT delivers to an organisation, regardless of whether it’s always visible. It’s an old article (1987) but still as valid as the day it was written.

Article Text: http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html

Lecture Notes on Article: http://www.cs.colorado.edu/~kena/classes/5828/s09/lectures/02-nosilverbullet.pdf

What struck me most was how little the fundamental problems of building solutions have really changed. Especially this quote “I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.”

What we do is probably the hardest part of the solution development process, and the part that adds the most value. If the PM, Arch, and implementers all do their job fantastically then the best result is that the solution is on budget and on time. If we do our job well then the system that we deliver can make a real impact on people’s day to day lives, how well they do their job, and the effectiveness of their enterprise as a whole.

P.S. Some of the article is a touch dated. Time-Sharing is no longer a big change for example, and OO is not an innovation anymore; However Ada remains sadly under-used. Other bits are very prescient, such as a move towards iterative change driven development (e.g. agile), buy-vs-build, and even a touch of cloud.

Setting Scope in Dimensions

2011-05-05T22:03:00.000-07:00

Scope definition is the most contentious, and most useful, of a BAs tasks early in a project. It's a key part of mitigating the project's risks by promoting consensus on aims.

Personally I'm most happy when I can promote disagreements over scope within a project. Too often people are using the same language to say two different things, and do not realise there's been a disagreement until too late. A disagreement is proof that I've been successful in bringing this misunderstanding to the surface early, so it can be dealt with during initiation instead of implementation.

My favourite way of doing this is by describing scope in three chunks:

In-Scope: My responsibilities as a project
Out-Of-Scope: Things that will not be delivered or considered
Dependent-Scope: Other people's responsibilities, that my project relies on

Out-Of-Scope is In-Mind

The best way do this is in the out-of-scope section. It's really the only scope section worth mentioning. Seeing a chunk of scope as explicitly out is much more confronting than it not being explicitly included. It's for wishful thinking to take over, and for stakeholders to see what they want "in-scope" if something related is also there, the out-of-scope section removes this false comfort.

In Your Scope is Out Of Mine

Dependencies on other projects should also go in the scope section. Theses are essentially things your project will not deliver, but is expecting others to do. Inviting the responsible parties from these projects to sign-off on your scope is an opportunity to get disagreements sorted early. Nothing focuses the mind like having to put pen-to-paper on a document that explicitly says what you are responsible for.

Multi-Dimensional

Explicitly structuring your scope statements around which 'dimension' of scope they refer to can make your scope clearer, encourage you to think about the projects in different ways, and make a point unavoidable by restating it from three or four different angles.

Each "dimension" of scope is a single narrow class of items that may be in or out of scope. I've listed a partial brain-dump of the dimensions you could use below.

Problem: User issues to address or ignore
Functional: User facing features that are included or excluded
Non-Functional Requirements: All non-functional requirements can be part of scope, either as area we are targetting to improve, or where we make no promises. (Note that I'm a big fan of phrasing these as negative NFRs - things we can do without is what drives intelligent compromise.)
System: Which technical systems we are responsible for, or will not change
Interfaces: System interfaces or integrations that we take responsibility for changing, or normally rely on others for
Activity: User activity or tasks considered, or ignored (Useful as part of a process when you highlight activities to automate or stay manual)
Users/Customers: Which user bases are considered, and which excluded
Organisational: Parts of the organisation whose issues and needs are in scope - very useful when deciding stakeholder and interview lists.
Legislative: Which parts of law are to be complied with, or whose compliance is a main point of the program
Deliverables: What documents, sing-offs, or artefacts are included
Detail: How much details (Descriptive vs Prescriptive) will be included
Supporting: Which activities or systems will be able to function based on our delvierables. This one's quite useful to say you will produce just-enough to support a particular activity or example (say, estimation) but not enough for another (say, full-build)

Logo for Android

2011-03-01T17:37:00.001-08:00

I am really enjoying having Logo on my phone. Making that little turtle run around takes me back to first learning about variables and sub-routines on an Apple ][e. Good times.

This is almost definitely my geekiest post ever.

This message and any attachment is confidential and may be privileged or otherwise protected from disclosure. You should immediately delete the message if you are not the intended recipient. If you have received this email by mistake please delete it from your system; you should not copy the message or disclose its content to anyone.

This electronic communication may contain general financial product advice but should not be relied upon or construed as a recommendation of any financial product. The information has been prepared without taking into account your objectives, financial situation or needs. You should consider the Product Disclosure Statement relating to the financial product and consult your financial adviser before making a decision about whether to acquire, hold or dispose of a financial product.

For further details on the financial product please go to http://www.bt.com.au/general/rse.asp

Past performance is not a reliable indicator of future performance.

In Praise of Context Diagrams

2011-02-14T21:26:00.001-08:00

The context diagram is probably the most neglected part of a BA’s bag of tricks. Nothing gives you the ability to collaborate with people so easily on a solution. A single slide with a good context diagram neatly summarises exactly what some functional component does, and who it serves. Whether it’s for a whole company, a system, or a software component, the context diagram applies just as well.

There’s lots of fancier ways of doing the same thing that give you a lot more information on context, aims, implementation, and scope – but none of them are so useful as tools to collaborate.

The beauty is that all you have to do is sit people down in a room, draw a circle in the centre of a white board and ask people who uses it. You then draw the users around in an arc in the top half of the board. Then ask what systems we rely on, draw those in an arc in the bottom half. Now ask what each user/system does with the solution and draw these requests and responses in as the arrows between external participants and the system.

It’s not fancy, there’s no certification course, but it can be the most useful meeting you have the whole project if you get it right.

Also, if you’re an external provider you can make these diagrams look very slick as you’re not restricted by a particular notation or layout. These give you a great way to advertise your competence, while displaying that you’ve understood the context.

Now – tricks!

If you’re scope doesn’t cover the whole diagram you can use highlighted areas of the diagram to show in/out of scope, or multiple stages.
The MS Visio shapes for work flow diagrams and departments are a great source of icons for actors
Minimise the number of systems you show, it should be mainly about users, systems are only their if they’re really significant.
Maximum of four lines between any one user and the solution
The “solution” in the centre of the diagram doesn’t have to be a system; it can be an organisational function, group, process, physical object, or anything really.
If it helps – think of it as a top-level data-flow-diagram. But I don’t even know if they teach structured design in IT courses any more so that may not help you.
Each arrow from users/systems to the solution could end up as one or more use cases or as a story grouping.
Arrows going between users/systems to the solution can be verbs to capture actions, or nouns to capture data transfer. If you can stay consistent that’s nice, but it’s not %100 necessary.

P.S. In fact now I come to think of it most of what I learn in Structured System Design is generally under-used by the larger community. Perhaps because there’s no industry consortiums or consulting houses to push the method like there is for UML, BPMN, RUP, Agile, and all the other usual suspects?

Traceability and Business Rules in Word

2011-02-01T22:26:00.000-08:00

A really good LinkedIn question from Adriana Beal on LinkedIn prompted me to write-up a neat little MS Word trick that can be useful for managing requirements traceability or business rules in MS Word.

It lets you create create consolidate of text scattered throughout your word document in a grouped list at the end using the same mechanisms as Tables of Contents, Indexes, and Tables of Figures.

This lets you do things like:

Reference business rules throughout your document and then include them all in

one appendix

Show a list of all Use Cases in your documents

Show a list of which Users, Screens, Systems, or Data Entities are involved in each Use Case

These are the basic steps:

Create a custom paragraph style in world name it something like "Business Rule"
Every time you reference business rule in your document put it on it's own line and apply this style (In our project we had a special section in each use case for the business rules)
At the end of the document create a custom table of contents that lists all of the Business Rules in your document (Right click table, click edit field code, select field options, and you can then select which word styles show up in your table of contents). The resulting field code looks something like {TOC \f \n \h \z \t "Business Rule,2,Use Case,1"}

If you want a sample document that shows how to apply this style I've shared one from drop box: Sample File Download.The major downsides are:

It's restricted to a single document
You have to be a bit of a word nerd

Honestly it's a realy pain, and if you have an options you should use a wiki or a real requirements management tool. This is just a last ditch option to make requirements in word a little more practical.

Guirella Centre of Excellence

2011-02-01T19:43:00.000-08:00

It's "reccomended best practice" these days to have a BA Centre of Excellence for any decent sized organisation, and most pieces of improving the performance of the BA function in an organisation being with getting senior management buy-in for starting one. This is fair enough.

But what if you can't?

I knocked togather a few powerpoint slides on low cost, cheap, fast ways to improve performance of the BA function in your organisation if you can't do anything formal. Essentially it boils down to:

Encourage social contact amongst BAs
Do information sharing at informal brown-bag lunches
Have a good bookshelf on-hand
Have conversations about basic theories, i.e. "What is a requreiment?"
Use BABOK and IIBA to enhance the "professionalism" of being a BA

This all comes down to encouraging self-directed learning, and a team pride in the BA role.

Guerrilla BA CoE

View more presentations from harrislloydlevy.

Building Living Specifications

2011-01-18T19:14:00.001-08:00

Producing new functional requirements for each project is evil and should be illegal, and punishable by death or working as a tester [1]. It is a basic cause of incoherent system, lack of holistic system thinking, and a lack of coherent documentation to support testing.

We've all had the experience of trying to understand the behaviour of a system and wading through reams of the original specification, change requests, and series of follow-on project specs, so why do we willing perpetrate this mess?

Probably a few main reasons:

1) The model of monolithic documents being prepared, signed-off, and developed against encourage this beahviour.
2) In the short-term it's the fastest way to get your individual project over the line
3) It's how we've been taught to do it
4) When we do decide to do something about it, we don't get angry that we're documenting badly, we get angry that we're documenting _at all_, and we implement some messy mix of agile and waterfall.
5) Wanting to have "all the information in one place" for decision makers (Which is a really valid point)

So what can be done about it? I'd generally propose a few changes that don't involve a massive change to current practices.

1) For new projects try to split out the project ephemera from the functional design that will be re-used.
2) Instead of having a singel plave for all project documentation, have a seperate place for storing project documetnation, system documentation, and process documentation. This reinforces that they should be treated seperately.
3) Gently ease into some business architechture questions, because if you're not using projects as the basic unit of information, you're going to need soemthing to replace it, and a system centric-organisation is a pretty poor substitiute.
4) Get some soom document/knowledge management systems. Shared directories will not work if you're moving towards lots of smaller documents. Consider Sharepoint as your first stop, and moving towards a Wiki and a Modelling tool in the long tem.

All of these mitigate against most of the objections I raised earlier, but they still don't give you the "single view" of the changes you're making for the project. Unfortunately there's no magic-bullet here. The more solution centric you make your documents, the less project centric they become.

Ideally you could mix-and-match content together into dynamic documents. But there's just no good tools for that, confluence is closest but really isn't there yet. There's a good summary of why up at http://confluence.atlassian.com/display/DISC/Using+Confluence+for+professional+documentation.

[1] Nothing against testers. It's just that most BAs hate working as testers.

Business vs Functional Requirements: I don't care.

2010-12-22T21:45:00.000-08:00

Either I’m getting very lazy or I’ve reached a new point of sophistication in my BA practice because I really don’t care that much about the difference between business and functional requirements anymore. Maybe I’m just sick of the fact that it’s almost a point of pride for people to have their own definition.

Not to mention that fact that half of the time the “business” requirements aren’t from the business they’re from customers or regulators, and that “functional requirement” documents include non-functional things like service-levels and look and feel.

Half the time I don't even consciously differentiate between business and functional requirements. I just elicit a bunch of requirements, get the business to sign off to confirm that it looks like we have a shared understanding, and then specify a solution separately.

For me that's the big separation between classes of documents that BA produce

* Elicited Requirements: Documents conversations and consensus with stakeholders, embodies a shared understanding of situation, with the BA's role being mainly a drawing out from stakeholders.

Elicited requirements could be business, functional, stakeholder, objectives, KPIs, NFRs, show tunes, user stories, wire-frames, or just whatever works best for all stakeholders to communicate.

This is a big mess of "business" and "functional" requirements.

* Specified Solution: Documents a single concrete solution that addresses the situation embodied in the elicitation stage, with the BA's role being to design a solution based on the elicited requirements.

In this model I end up collecting mostly "functional" requirements.

I grant this represents my background working as a system integrator. In a fixed-price environment you really want to manage scope by keeping all that vague text in the elicited requirements separate from the model.

This has always worked well for me, with the following provisos:

* Traceability between elicited reqs and the eventual solution is key. You need to show where you took into account all the things your stakeholders said.

* You still need to understand the difference between business and functional requirements on some level so you know where you can implement something differently from the user request (And note it is such in your traceability)

* I’d never talk like this to someone just starting out as a BA. I think when you’re starting out you need to be much pretty dogmatic about the difference between stakeholders expressed needs, and their underlying objectives to avoid becoming an over-paid stenographer.

Customer Needs, not Functionallity

2010-12-09T19:45:00.001-08:00

My Lamy ink pot is so well designed that every time I refill my cheapy $30 fountain pen I get a real sense of satisfaction, because everything just works.

I can feel that they've actually though about:

how a customer will use their product,

the acions they'll take immediatly before and afterwards, and

what place the product has in the customers life.

An inkpot is a fairly simple thing at it's heart. You just need ink in a well sealed container, lamy obvioulsy have great ink, and athe container closes tightly but it's a few little additions that make me willing to pay the %20 price premium over their competitors.

Lamy's have added two main feautres:

An integrated dispenser for plastic backed tissue paper around the base of the ink pot

A little reservoir in the bottom of the pot so that it's easy to get your pen or bladder all the way into the ink, even when you're down to the last of the ink.

So; from a BA point of view what have Lamy done that is so applicable to software design?

Firstly - they didn't think about themselves as providing a function (Ink, Email, holding customer records) instead they saw themselves as supporting an activity (Refilling a pen, communication, communicating with customers). By looking at a wider business-process context they were able to better integrate multiple functional components into something useful to the end user.

From a BA POV they took a wide process, and collapsed distincy activities together by providing a single interface that matches what the customer wanted to acheive. This is putting the customer's needs first, and the functionallity later.

Secondly - they looked at the whole lifecycle of usage. They introduced features that covered the whole product lifecycle, giving the customer unexpected bonuses towards the end of their product use; which usefully for a retail product is just when they're about to re-order.

But what's really great is that there's a synergy between the two, that little reservoir on the bottom is what paper dispenser clips to. There's also ongoing revenue from selling paper refills.

The only thing it's really missing is a way to easily open it when the ink has dried the list shut, maybe if base coudl be made square'ish you could get a grip more easily?

Requirements as risk mitigation

2010-11-28T14:06:00.000-08:00

Really detailed use cases, and complete entity-relationship get a bad rap because they can be very complex to read, and are often not particularly good at describing the solution to end-users[1].

As a result they can get called a waste of time. We assume that requirements must be easily understood by business and IT stakeholders, and they seem to fail this rule - but most people persist with them out of a sort of gut-feel that they're useful despite being confusing to most users; and they're right to.

These sort of requirements mitigates your risk of internal incoherence, unwritten assumptions, and unexplored options. They may not be immediately readable by end-users but they ensure that the author has done a structured analysis of all the possibilities.

For example I had a project go wrong once because we assumed that each purchase order resulted in a single invoice, (e.g. a 1 to 1 relationship) when the reality was more complex (many to many). If a detailed ER diagram had been constructed the author would have raised this as explicit assumption. Similarly detailed use cases with very formal treatment of alternate paths are great at driving out odd little edge conditions.

Sometimes we produce requirements not to describe it to others, but to make sure we're across all the detail ourselves. This isn't the sort of work that gets users excited, but it does guard against something going wrong down the track.

[1] I've got some other posts about how to mitigate this, but that's another discussion

Three Types of Requirements

2010-09-16T15:51:00.000-07:00

There are really only three methods for describing requirements in the whole world, these are:

* Imperative: "The system shall....."
* Prescriptive: "X = Y * 5. If X then Y. Use Cases, ER Diagrams, etc".
* Narrative: Bob hits X, Y happens, then Z. This is because A is true. If B were true we would do this.

Imperative is how everyone starts of doing requirements in their first job. Those long lists of "requirements" that make everyone's lives so miserable. IMHO you should never use these for anything but the simplest project.

Prescriptive is the model we move to after we've been hurt by scope creep a few times. We'll just lock everything down in a detailed unambiguous model that is 300 pages of impenetrable UML, and then we'll be OK. We won't have capture what the user actually wants, but at least we'll have documented it unambiguously.

Narrative is where we realise that our systems are only part of larger stories, and need to be seen in that context and we make the customer the centre of our design by giving them the starring role in the story. User Stories, or well-written use cases are good examples here.

This distinction has nothing to do with functional vs. business requirements. It's a seperate dimention about how we document requriements. The type of requirement is a compeltly seperate discussion.

Discreditting by Diagram

2010-08-02T19:28:00.001-07:00

When you are putting together a before and after diagram you want them to be as clean, and as similar to each other as possible. This means that the effect of any changes is clear, and unaffected areas are obvious.

Sometimes though you just want to make the diagram as complicated and ugly looking as possible to get a point across or make a sale. You can't make it look like it's just a bad diagram - you have to give the impression that the author has really tried to make it comprehensible it's just that the underlying idea is bad.

The classic use of this is the IT department trying to get money to do a systems consolidation or re-engineering. The architecture team will dutifully come up with the ugliest diagram of spaghetti known to man, that will get presented as proof of how bad things really are.

Turns out politicians know this trick too; as shown below:

This diagram published by the Republicans on the Joint economic Committee “explaining” Obamacare is a classic of the genre. Undoubtedly high-price (and worth it) consultants have been consulted to make this look so complicated.

High res version here

It has all the classic tools to over complicate something:

Mixing Domains: This shows organisation structure, regulation, stakeholders, responsibilities, impact, legislation, and everything else all on the one page. This lets you put hundreds on boxes on the page

Lots of Boxes: Goes without saying - put as much as you can in there. Go crazy.

Complicated Legend: By having so many domains you get to put an overly complex legend on the bottom that shows all the different sorts of things. This requires lots of different shapes and colour coding. Which leads me to:

Colour: Use at least 7 or 8 different colours. This makes it hard to concentrate on text, and as a bonus you can have them all as similar shades so that when you print it in black and white you can’t tell the difference.

Lot of lines: All blank space should have lots of lines running through it. This way you add a lot of visual complexity, but it’s so hard to see what’s connected to what that you don’t add any content.

Acronyms: Put tons of Acronyms in that way no one can understand it without a glossary, and once you put in a glossary that’s another box of dense text to add to the complexity.

Tiny-Text: Throwing in some boxes with minuscule text give the impression that there’s even more complexity going on under the surface.

Miss the point: Put a crucial stakeholder or system in some out of the way corner, and then put something ridiculous in the centre.

Note: For the purposes of this article I don't particularly care about whether Obamacare is overly complicated or not, a good thing or not, it's just an interesting look at how the diagram designed can push messages.

We must hate trees a lot..

2010-07-27T02:21:00.000-07:00

Why must every document I see start with at least 3 pages that are completely useless? Most of them manage at least 6, and I've seen up to 20.

Sometimes I just want to take these docs, scroll through until I find the first statement someone could reasonably disagree with, and just delete everything before this point. I don’t think anyone would miss it except for some putz who will insist it all the goes back in on the ground that it's "standard".

This useless filler generally consists of:

Title page. Generally containing no more content than is available in the document headers and footers anyway.

Distribution and sign-off page. This never contains any record of actual sign-off, the distribution lists is always out of date. Old emails will always be used to substantiate the real distribution in any case.

Version history. This is either so terse it’s useless, or so involved it takes three pages. It is never used by anyone; again the email trail is used as the de-facto history. Maybe if you document control system supports version that could be used.

Glossary and Abbreviation. A list of items that are either so obvious that all reader’s will understand and know them already, Acronyms so obscure that even spelling them out helps no one, or items explained in-depth inside the document anyway. No one will ever read or use this.

Document Purpose/Audience/etc. A whole bunch of explanation about what the document is meant to do and for whom. Arguably defensible for a “one-off” type of document; but for a standard template that you use again and again does the audience really need reminding that the purpose of a business case is to secure funding? It’s either things readers already know, or if they don’t know it they need more education than you can fit into the document intro.

Project scope/benefits/overview/context/etc. A whole bunch of generic description of the project that’s repeated (in slightly different wording) in every single document. In the best case scenario readers will just skip this; in the worst it will be different between documents causing confusion.

What’s the end result? 40 page documents where content that really matters doesn’t start until page 10. I’ve personally produced mounds of documents that are over %75 filler. This increases the cost of producing documentation, slows down review, and damages document readability. You can see why the whole idea of documenting an IT project is under attack.

What’s really galling is that this document bloat doesn’t come from business customers demanding more – the pressure is from inside the IT. Look at a memo, or a board paper. You’re lucky if there are more than a few centimetres of document meta-information at the top. A paper going to the board to recommend a few million dollars of spend fits on a single A4 sheet; but the smallest IT document we manage to make as long as war and peace, but with as much content as a limerick.

Solutions?

Manage meta-info (versions, approvals, distributions, etc) in the same system that manages your documents. If your system can’t support that and you really think you need it (unlikely) then at least move it into an appendix.

Remove purely aesthetic cover pages, unless you’re writing a book it’s just getting in the way.

Centralise repeated information in a living document. The project scope and overview document should be the only place that summarises repeated general project information. Put all the effort of re-drafting, re-reviewing, and re-writing the same content in every document into keeping it up to date instead. If you really have to reference it at the start of the document, if you really, really have to then copy and paste it with a explicit statement about where it was copied from.

Do what I said at the start of this post. Start at the top of the document, scroll down until you find the first statement someone could reasonably disagree with, and just delete everything before this point.

Kick-Start Templates

2010-07-22T00:09:00.000-07:00

If you were ever looking for a basic set of documents for your SDLC it's hard to go past these:

http://www.processimpact.com/goodies.shtml

It's no surprise they're excellent as they from from Karl Wieger's consulting company, and he did (literally) write the book on software requirements.

Culture (The real stuff)

2010-06-24T06:37:00.000-07:00

A long while back I almost ended up working for a truly innovative consultancy in Australia, but then I thought better of it. Seriously - you can't be a thought leader in Australia.

At the time I turned down the offer I had a vague sense that there was something about Oz that would make it a challenging place to be employed by a very American style consultancy, but I couldn't actually put my finger on it.

Now I know that we don't like leaders (especially self-appointed ones like consultants), and we're at best ambiguous towards thought. So saying you offer "though-leadership" is just going to get your head bitten off.

That's probably one of the things that makes this country the best, freest, places on earth; but it can make working here a bit challenging sometimes. It's probably why our most successful leaders (Hawke, Howard) are people you can imagine having over for a BBQ.

Just as an example watch me miss-communicate badly with an American over at Bridging-The-Gap. Even though I agree whole-heatedly with the sentiment, I just can't help pointing out everything that could go wrong. Of course as an American she can't help but respond with how excellent everything is; and because I'm an OCDD bastard I can't help but provide a few links in return.

Why? Because I'm an Australian; and that's what we do. We don't complain as such, we just like to point out that things won't work, and that if they do by some miracle there will be some other problem soon.

Of course there's also that stubborn streak and black humour, that keeps Australians going even as they're saying the whole thing will fail. If I found a company with that I'd sign up in a flash. I reckon Atlassian may have been one such company before it got big (Ironically it was Confluence I was discussing with the afore-mentioned American)

I should thank Professor Spillane for this insight. His philosophy course as part of my MBA was actually education not just plain old training. Probably made me a frummer yid too.

Update: I forgot to add the most important part: how you should actually sell yourself in Australia. The following has worked OK for me:

Emphasise experience, not knowledge or acclaim. Saying you've been doing this for ten years is good, saying you wrote a book on it is bad.
Sell avoiding negatives not massive improvements. Aussies (rightly) don't trust over-the-top sales pitches about how good everything will be, but we are ready to listen to someone who says that they have tips on how to avoid the worst.
Be clear about trade-offs. We will instinctively look to denigrate any innovation, but by being clear on the down sides as well as upsides of what you propose at least you're part of the conversation.

P.S. The money at this consultancy was also bad - which was obviously the real-reason I didn't take it.

P.P.S. Who are the people are actually reading this blog. When I started it it was just to keep in touch with a team of BAs that were on multiple client sites, so I'm pretty shocked that anyone who doesn't know me would take this time to read it.

Brilliance of Use Cases

2010-06-06T18:54:00.001-07:00

Use Cases in whatever form are probably the single most wide-spread and effective requirements gathering tool for one really simple reason:

They close the gap between narrative requirements on one side, and a specified design on the other.

It really doesn’t matter what you’re calling requirements and what you’re calling design (No matter what you call design I’ll find someone who’ll call it requirements). You can always use some form of use cases to close the gap between the narratives that the consumer of the deliverable experiences and a specification of how the deliverable will provide that experience and respond to inputs. Whether it’s a user story, business use case, API use case, or anything else; use cases close this gap like nothing else.

In my experience they’re the one deliverable that’s as useful for users and developers if done right. There may be other deliverables more suitable for specific project, or better for some stakeholder group, but you can’t go too far wrong starting off with use cases.

In a way they’re the quintessential BA artefact. They’re a Rosetta stone that talks to both the users, and the deliverers in their own language.

P.S. Yes - I know it’s pretty useless to talk about Use Cases. Let’s just assume I mean the term as a generic catch-all term for everything a reasonable person could call a use cases. I should be a post one day about my two dimensional model for describing the different sorts of Use Case.

P.P.S. I have strong opinions about BABOK vs IESB. How geeky am I?

Broken Metaphors

2010-06-03T21:56:00.001-07:00

The number one cause for bad software design is using the wrong set of metaphors for a solution.

Excel and the Macintosh Equivalent (Numbers) is a perfect example. Excel's core-metaphor is functional; but once you spend more than five seconds looking at a Numbers screen you realise that it's wrong. It's wrong for all sorts of perfectly justifiable reasons, mainly historical and compatibility, but it's still wrong.

· Excel: Sheets are full of cells of calculations or data. You can have multiple sheets.

· Numbers: Pages are full of tables of information. Each table can contain cells of data, calculation, or a mix. Wikipedia calls this a “Layout of lists” metaphor.

Essentially numbers separates out how block of information are presented (Pages) from grouping related numbers (Tables) where excel groups them together into the one metaphor (Sheets)

So what? Doesn’t introducing more core-metaphors just make the solution harder to learn? Well no, once you have metaphors that match up with how users actually do things other functionality falls into place a lot more naturally.

Take for instance formatting of tables. In excel if you have multiple related squares of information you’ve got to adjust the formatting cell by cell, range by range; in Numbers this is more natural as you have a “Table” that can be directly formatted.

Or take referencing between tables. In excel lots of users will never use more than one sheet because they don’t feel comfortable using cross-sheet referencing, but in Numbers it’s seamless as you can directly reference a Table and calculation (Total of Sales, instead of “Sales!A23”)

It also just makes Excel ugly when used without much thought, where Numbers produces quite clean well laid out pages if just used in the “natural” way.

The Excel product team get this. Recent versions of Excel have a concept of Tables, but they’ve had to hack it on top of the Sheet concept to keep backward compatibility.

In summary – if you get the core metaphors right up front then everything else is simpler. Don’t be afraid of making the core metaphor a little more involved; it could save you a lot of complexity in the long run.

Customers & Price Differentiation

2010-05-17T15:14:00.001-07:00

Disclaimer: This has nothing to do with BA work.

While shopping for a new Moleskine recently (yes, I am that guy) I noticed that the more expensive/up-market the physical retailer, the cheaper their Moleskines were.

My father always used to tell me the same things about wine and scotch. Cases of VB (Cheap beer for any non-Australians) got more expensive as the neighbourhood went up-market, but prices for Glenlivet, Glenmorangie, and Penfolds (Expensive wine for the non-Australians) went down. My father and I had in common high-end tastes, and low-end budgets.

Why?

My father’s explanation was roughly this:

In a lower-class area someone gets a bit drunk, wins some money gambling, and decides they going to buy something expensive and they’re going to buy it right now.
In an upper-class area someone resolves to replenish their wine cellar or bar and thus decides to buy a specific item and they’re going to buy it when convenient

So the idea of a price-conscious consumer looking for the cheapest price for a product is turned on its head. They’ve decided to buy at a set price no matter what the item is. So there’s no point giving them a discount on 16 year old Balevines – because they’ve decided on a price-point so you maximise your margin by having high-margin product in every price range over the normal level.

The traditionally quality-conscious consumer on the other hand becomes price-conscious within his market. You can’t tempt him with a cheap Canadian Club when he wants Talisker, but a convenient and price competitive offering on the Talisker may do it. You need to be price-competitive in the higher end of your market, where people will shop-around, but can afford to have higher margins in the lower end.

As it is with Scotch, so it is with Moleskines.

The cheap-and-nasty stationery retailer in Sydney CBD has the Memo Pockets at almost $30 and hidden up the back; while the relatively up-market one has then at $23 and placed right at the front of the store. Even more interestingly the up-market retailed is even price competitive with EBay to within %10. Retail and price differentiation is so dammn interesting.

If there are any retail companies out there (especially in the rag-trade) that want a Business Architect please give me a yell. I would love to be part of empowering front-end retail staff to make pricing and product-mix decision at a micro-store level by delivering an awesome analytics and what-if analysis right to the register.

Focused Communication: If it's not on-topic, it's just off-putting.

2010-05-12T16:53:00.001-07:00

Every box, arrow, and bullet-point that doesn’t directly give across the information you are trying to convey is worse than useless, it directly distracts from your message.

When a Use Case includes User Interface details, not only does the UI description suffer from being in the wrong form, but the use case suffers from having information that distracts and obfuscates the central point of a Use Case. A Use Case is mean to encapsulate the back-and-forth of interaction between participants, trying to cram in details about how information is presented and how the user gives feedback just hides this.

Processes are where people always get this wrong. I was talking with a friend recently on a paper he was writing comparing three process models recently. He was trying to make a point about removing unnecessary emailing and waiting in an application process but this was hidden by the sheer volume of information on the minutiae of user interaction, and information collected that was in there as well.

I’m not making a case for only doing “simple” modelling or communication. I like an incredibly complex model as much as the next guy (Assuming the next guy is a border-ling OCDD, modelling obsessive). It just has to be the right sort of complexity; if reality is complex you need a complex model to explain it. Hell – sometimes it’s complex on purpose. I once did a process model that had to be printed in 4 point type to fit on one A2 page but the point of that was to get across how out-of-control complex the system was.

Just make it focused on what it needs to do, and be brutal about cutting out any information that isn’t immediately needed into a separate model.

(P.S. First test of email blog posting.)

Language is to Thought, as Modelling is to Design

2010-05-10T03:50:00.001-07:00

I'm a touch obsessive about using modelling correctly and consistently, whether it's ER, BPMN, Use Cases, or sequence diagrams it's worth doing rigorously to the standard.

Sloppy modelling comes out of, and causes slopping thinking. I'll even take it a step further - modelling is thinking.

If we use the metaphor of language this is obvious to us. Someone who doesn't have the words to describe something can have a flash of an idea, but he will struggle not only to describe the idea to someone else - he will also struggle to tease out all the details and implications of the idea.

An economist has a lot of language to describe what is happening along a supply and demand curve. Having this language allows him to communicate with colleagues easily - but also to think rationally and easily about what is happening inside a market. He has all the mental shorthand readily available.

Similarly a process modeler has a lot of boxes and arrows to describe what's happening in a process and how two people may collaborate. So not only can he communicate with the workflow developer, but he has the vocabulary to do it.

Case in point - I've noticed that has BPMN's support for messaging has improved people are thinking more and more about how processes communicate. It's not that it didn't happen before, but now we have the language to describe it.

In both cases the purpose of the language is that you shouldn't even think about it anymore. You shouldn't see use cases, process modelings, or ER diagrams; you should see interactions, collaboration, and entities. It's only when people model badly that you have to stop to think about models.

A word of warning though - languages box you in. Using the BPMN view may blind you to something that's more obvious in the text-narrative view. The Class diagram view may blind you to something obvious in the ER view. The Keynesian language of economics may blind you to traps of govt inefficiency blindingly obvious if you are speaking like Milton Friedman.

A lot of people assume that you can simplify language as long as you get across the basic idea, and this is true up to a point. But if you don't know the language, you'll never know what you've left out.

This is a very long winded response to a conversation I had at work yesterday about what sort of training we should send budding process-improvement champions on. Someone suggested a course that focused on strategies and process patterns was best, I held that focusing on teaching them to talk about processes was all that was necessary. If they've bright it's all you need, and if they're not it's not going to work anyway.

Resistance to Change

2010-03-10T17:23:00.001-08:00

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

2010-02-11T02:51:00.000-08:00

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.

2010-01-13T02:36:00.001-08:00

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

2010-01-13T02:28:00.000-08:00

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

2009-11-29T19:41:00.001-08:00

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?

2009-11-09T16:46:00.000-08:00

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

2009-11-04T20:28:00.000-08:00

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.

Reply quickly without being rude

2009-10-11T23:11:00.000-07:00

To clear up a backlog of email its sometimes necessary to write very short answers, which can offend some people.

So change the email signature on your desktop email client to "Sent from my Mobile Device. You can then reponse as briskly as you like without fear of causing offence as everyone will assume you were pecking away on a smart phone.

--
Sent from my mobile device

Use Cases happen Between Coffees

2009-10-07T16:06:00.001-07:00

If you remember this one thing you will practically never go wrong with getting your use cases at the right level of granularity.

Use cases end whenever the user would comfortably get a cup of coffee. This probably goes for process tasks as well. All my ramblings about Elementary Business Processes are just commentary to this idea.

(For a long time I was walking around saying this without realising it was a Cockburn line. So I hereby retroactively credit him for all my past uses of this concept without accreditation. It wasn't until a recent IIBA newsletter I even realised it came from him.)

Requirements Planning

2009-08-27T16:32:00.000-07:00

What's a good requirements plan?

It's certainly not measured by how thorough it is, in fact too much verbiage could be a sign of a bad one.

It's not the one that results in the most detailed and comprehensive set of requirements.

It is most definitely not the one that gets the project through to the nest stage in the fastest possible time.

So what is a good one? In my opinion a good requirements plan give you

The requirements necessary to define an appropriate solution, documented in a form that can be easily consumed by stakeholders, elicited and defined in a way that is sympathetic to the nature of the organisation and project, that can be executed in a timely and cost effective manner.

Parsing that out there are four essential elements to a plan:

Requirements: What requirement types will you elicit/define and at what level?

Artefacts: What form will you document these requirements in?

Techniques: How are you going to interact with stakeholders to elicit requirements and to validate and designs?

Execution: When and who is going to perform this work?

For every one of these except Execution you can pick up BABOK 2.0 and get a list of possible answers

I think it's always worth setting some time aside at the start of the project to come up with a requirements plan separate of the project plan. It doesn't have to be formal document, it doesn't even have to be written down, it doesn't have to (and probably shouldn't) remain static over the project, but it should force you to sit down and understand why this project is different from all the others.

Because if you're not consciously planning, you'll just end up doing the same thinking, and having the same conversations throughout the project and it will take up even more of your time, and you'll do it worse than if you'd thought about it up front.

P.S. I know I've ignored change management, and traceability - but this is a blog not a textbook.

Types & Levels

2009-08-18T19:48:00.000-07:00

I've struggled to reconcile two of my favorite frameworks for talking about requirements for a while now, and I think I've finally got the idea settled in my mind. Basically I'm using BABOK 2.0 defs for , My classifications are

BABOK 2.0 requirement classifications
- Business
- Stakeholder
- Solution Functional, which are further broken into:
  - Behavioural
  - Process
  - Information
  - Interaction
- Solution Non-Functional, and
- Transition.
Bruce Silver's Three Levels of Process
- Prescriptive
- Descriptive
- Executive

For ages I was just using the Silver levels as a sort of Zachmann levelling for processes (proper ones, not the hand-waving level-0 processes), then I started using them to describe the other Behavioural, Information, and Interaction requirements as well, now I'm realising that I should be applying them to all the requirement types in one big matrix, and once I do that I can start putting actual the names of actual artefacts in the intersections between them.

Now it gets interesting, what's a Prescriptive vs. Descriptive Business Requirement? How are behavioural and process artefacts different on the descriptive level? etc. This is getting into definitional debate land that I don't really care about but it's a nice way to get a list of things on one page.

So what use is that? Well, it's the menu items you order off at the beginning of the project for what you intend to produce. It's a major input to requirements plant. It allows you to define what you want to collect (e.g. Stakeholder Requirements), what level you want to collect it at (e.g. Prescriptive), and the intersection between these defines an appropriate the artefact (e.g. Use Cases).

If you decided that full use cases are too much work, or unsuitable you can pop up to the Descriptive level and see that for Behavioral requirements, maybe some User Stories are the go. I doubt I'll ever use this in practice, it's way too complicated and involved, and only BAs who think about method more than they should will like it, but at least I have a coherent internal view I can use myself.

Now if only I could get the same clarity around business rules..

COTS Workflow you already have, you just don't know it

2009-08-03T19:08:00.000-07:00

Most organisations already have an purchased, implemented, and widely used world-class workflow and case management solution with great reporting and metrics - they just don't know it.

It's your humble IT help-desk and issue tracking software.

The core of this software's functionality is to define the process by which events are dealt with, manage and manage and track the work that needs to be done to respond to these events, and report on the results.

Just think how useful this would be for:

Customer queries
Purchasing (Your own lo-fi purchase-to-pay process.)
Leave Requests
Expense Requests
Training Requests
Case Management
Sales Cycles

Basically any long-running, manually intensive process is a candidate to be tracked and reported in such a system.

Obviously there's significant down sides to using a ticket-tracking system instead of a "real" BPM suite, integration with external apps is horrible for instance, management and dashboard reporting cab be pretty sparse, resource assignment is generally primitive, and the process modelling side will be nowhere near as pretty or support the full expressiveness of BPMN 1.1.

But all this matter less than you think. You have a system here and now that can quickly and cheaply (so cheaply) solve many of your internal process issues - but IT has just kept it for themselves.

So go start playing around with whatever you have - (or install Trac/buy Jira if you don't have anything) and start working. All you need is a process map, and a state diagram showing transition, and who is responsible at each stage, and you can have a system implemented and ready to start training in less than a week. Less than a day if you've done it before.

If you're willing to get fancy you can also use the fact that the notes and description section for tickets in tools like Jira has most of the power of it's Wiki available so integrating in information from external sources is easy.

So what are you waiting for - what process in your organisation would be better served by a ticket-tracking system and what are you going to do about it?

References:
http://en.wikipedia.org/wiki/Issue_tracking_system
http://www.atlassian.com/software/jira/

Does your specification destroy trust?

2009-07-09T20:14:00.000-07:00

I just read a great article in HBR "Does your contract destroy trust".

In a nutshell it was asking if the way you wrote your formal aggreements guarnteed animosity by locking everything down so tightly there was no room to show good-will and the kind of mutual flexibility that good relationships needs.

The application to BA work is obvious - when you produce functional requirements to detailed that every aspect of the system is locked down, and twenty pages of assumptions you may find yourself in more trouble with arguments over scope than you would if you had left things more fleixble and shown mutual trust.

Obvioulsy there's far more to change management than documents and processes - but it's worth thinking about.

There's an old saying that "Good fences make good neighbours" that I tend to use a lot to explain why unambiguous functional specifications can be useful - but this article has made me think about whether having an impenetrable brick wall as a fence would be too much of a good thing.

P.S. I suppose this is one problem iterative methods don't have as much.

You should know SFIA

2009-07-09T19:00:00.000-07:00

For those who aren't aware SFIA is a pre-rolled skills matrix by the British Computing Society that defines a number of skills (80 or so) and then what it means to be at each level of that skill.

For anyone involved in career planning, or defining skills matricies, or even looking at where they want to go in their own career it's a seriously useful body of knowledge.

Even more impressively you can probably get some value even out of a give minute peruse of their summary sheets and introductory booklets.

http://www.sfia.org.uk/

Finding Great BAs

2009-06-16T22:44:00.001-07:00

Thank g-d we've had a lot of success in our team finding great BAs, and I think a lot of the reason we've managed this is great interview methods.

"Good enough" methods get you "good enough" people.

Thanks to the slow move toward professionalisation of BAs, and the profusion of interview question coaching sites around most people with a decent memory and half a brain won't have any trouble answering the "good" questions.

Any schmuck with Google and time on their hands to know the answers, even to the behavioral questions. Examples are below:

Who do you define a business use case?

Which UML diagram are useful to Business Analysts?

What does the word "requirement" mean to you?

The user wants a new feature that was not previously discussed and you're in UAT - how do you proceed?

"Great" questions for "great" people

For great people you have to go to a completely different level of question. Ones with no "right" answer and lots of scope for follow on questions.

A lot of these are the classic "Microsoft" questions, such as "How would you move Mount Fuji?", "Why is a kidney dish shaped that way?", "What's the best requirement you've even heard?", "My business needs a CRMs - what would you suggest?"

Based on how they response you see if they can:

Separate the "how" from the "why"

Acknowledge and validate their assumptions

Discover your implicit assumptions and needs

Explain their thinking verbally and physically

Really listen to, comprehend, and elicit requirements

Which happen to be all the things that separate good and great BAs.

I've got one question that's a semi-mathematical logic puzzle - but we force people to give their answer on the white board without using words or number. This will tell you in under twenty seconds if someone can put together the explanatory diagram that are so important to any Snr BA or Business Arch.

If you have the time - roleplay

I love to roleplay BA scenarios. Taking a small problem from elicitation, through design, getting interviewees to practice specific skills (Interviewing, use cases, data models, process models, test design, change management, as you go.)

Problem is is takes forever. Half a day is about the shortest amount of time you can do anything useful in.

Lets face it, go with gut

Sometimes you just know within the first five minutes. Really great BAs have a certain way of engaging with people, keeping conversation going, making sure they understand what you say, and being generally empathic while logically rigorous that's just obvious during a short conversation.

Our Results

We've hired people who completely flunked the BA method and skills questions but just gave such awesome interactions during our puzzle section that we know there was something there. Every one of these people has turned out to be a high-performed with just a little bit of mentoring.

On the flip side I've seen people hired who absolutely nailed the BA method and behavioral questions - but who flunked the puzzle section. They're invariably been low performers (for their years of experience) who mechanically replay the same methods, tactics, and ideas year after year. Not a lot of value-add,. Classic case of people having 15 years of experience, but its the same year 15 times over. Great for domain experts - lousy as business analysts.

P.S. All the examples I've listed here are our second-class questions. I'm not sharing out our best ones unless you're looking for a job :).

BA Career Path

2009-06-10T18:09:00.000-07:00

There's always a lot of discussion about "BA Career Paths". It's all very interesting but I'm not so sure it's always useful.

I'm not sure the profession is mature enough to provide a real career path for BAs (except on paper). A more pragmatic path may be recognising a real career path is impossible at the moment and focus on providing support for the right on-ramps and off-ramps can be more constructive than defining a formal career path.

The PM shift is a common one, but I've also seen a number of BAs make the switch to Solution and Enterprise architecture, into the business proper, or as strategy/process consultants.

The PM/Architect/BA Troika all have significant cross-over of needed soft and hard skills. Looking at the bullet points of needed skills you've put down for Jnr/Mid/Snr BAs I could use that list for any of the Troika.

I tend to look at BA career "progression" going along three axes, each combination providing a different off-ramp:

Technical vs. Business (Do you get systems working for business, or businesses using systems?)

Project vs. Program (Do you deliver results, or deliver power points?)

Do vs. Control (Are you delivering yourself, or managing the delivery of others?)

There's no intrinsically "Senior" end to any of these axes.

"Snr BA" tends to be different in each organisations - sometimes its the person who sets overall strategy, sometimes it's the person who manages the BAs, sometimes it's the person who elicits the business requirements (In the BABOK sense) and does program of work managements. Sometimes its just someone who's been around for the longest time.

Modelling Behaviour

2009-06-09T14:41:00.000-07:00

Whatever type of behaviour you expect from stakeholders, you'll probably be right. The way you act when you expect them to be a certain way (Disengaged, hostile, or intelligent and open) will push them in that direction. Treat people like they already are the sort of stakeholder you want.

I regularly have great engagements with stakeholders who are considered to be "difficult" and it takes is listening to them, treating them like reasonable people, and remembering you're there to serve the business project sponsor - not the IT dept.

The only truly difficult stakeholders are disengaged ones, anyone engaged and passionate enough to cause you problems will probably be a key ally if you can show them that you have their best interests at heart and are there to listen to them, not to dictate a solution.

Deliverables, Objectives & Benefits

2009-06-03T22:23:00.000-07:00

When summarising a project and whether it should it's very easy to get mixed up about what information is being presented. It's easy to mix up ideas abut the projects aims, methods, benefits, requirements, and intentions. I like to use a really simple model when describing the one-slide view of a project for business.

It consists of:

Deliver ables: What the project will actually deliver, e.g. a new work flow system.

Objectives: What is the hoped for outcomes of theses, e.g. increased operator efficiency, lowered waiting times for customers.

Benefits: How delivering these benefits will actually the organisations, e.g. Reduced Costs, increased customer satisfaction, compliance with legislation.

These can then be easily linked together. Deliverables contribute to one or more objectives, and objectives deliver to one or more benefits.

You can then quantify how much each deliverable will cost, and how much each objective delivers to each benefit. This feeds straight into your cost/benefit analysis, or more realistically provides a simple way of presenting it that transparently links it back to project activities and benefits.

Why are BAs so undervalued?

2009-05-24T21:35:00.000-07:00

Perhaps I have a chip on my shoulder but of the standard Troika that kicks off most projects (BA, PM, Arch) the BA is the most often undervalued role. In every single metric I can come up with to measure organisation esteem (Salary, reporting lines, training budgets) of these roles BAs come out third.

Considering the calibre of BAs in most organisations this is pretty understandable, with little organisational support, no clear career path in, no clean career path up or out, a fledgling professional body, and little formal power over a project it's no suprise that BAs end up being dogs-bodies instead of drivers. This is a symptom not a cause though.

In reality a good BA does more to make a project delivery exceptional business value than any one besides the business representatives. Good project management, architecture, technical delivery, etc, all these help you deliver well, and make it cheaper and faster; but if you want it to be actually better for the users - getting the requirements and functional design right is the way to do it and that's the BAs job.

So why the disconnect between the high value and the low valuation? At source I think it comes down to four things:

A) Most BAs are bad at their job, so even if the good ones are tarred by association
B) Deliverables are not as visible or "epic". PMs and Architects get to produce big gannt charts, architecture road-maps, present to steering committees etc. BAs sometimes get this level of visibility much less often, and generally only as a project representative - not as part of something bigger,
C) No organisational power centre to promote the role, and ensure the wider concerns of BAs get an ear. There's no equivalent of the PMO or Enterprise Architecture office for requirements.
D) Facilitators less valuable than deciders in the eyes of modern business culture. This is the big one. Deciding is just considered more powerful and important than facilitation. The ability to allocate resources and make calls is just intrinsically higher status than the facilitating and agreement promoting role that BAs play. It's just our culture.

Categorising Tools for BAs

2009-05-18T21:09:00.000-07:00

People talk a lot about "BA tools" and "Requirement Management" without really defining terms.

I think it's worth at least defining some of the different types of tools that are out there so you can compare apples with apples. As a candidate list:

Collaboration: Systems that help groups of people work together to build a body of knowledge. Word documents on share drives, Wikis, doc management systems, etc in this area. These sort of tools can be used for everything.

Requirement Tracking: Systems that allow BAs to collect "requirements" as a list of statements and then track which are in and out of scope, which are included in a release, who approved them, and the like. These tools are primarily used in the Elicitation and Requirements Analysis knowledge areas. As mentioned Adam's "Bright Green Projects" looks like a great pre-rolled offering in this space. Requisite Pro falls mainly into this camp.

Solution Modelling: Systems that assist you in building a rigorous description of the systems functionality. This covers tools like Enterprise Architect, any of the BPM tools, ERWin, etc. These tools are primarily used in the Solution, Assessment, and Validation knowledge area

Solution Validation: All of the testing tools, coverage, execution, automation that this conversation has been conveniently ignoring.

All of these are "Requirement" management according to the BABOK definition of a requirement - and no tool falls neatly into any camp, but neither does any tool adequately cover all areas.

IBM's suite probably covers every area but it really is a behemoth.

P.S. Tools are the caps one of BA Capability improvement - not the foundation. Tools can often do more harm than good in an immature environment.

BA work is about building bridges between different domains, and tools (almost) invariably hurting in one domain, as much as they help in another. Microsoft office is worse in a completely different way though. Wiki & Issue tracker is a decent compromise - but is also not without problems.

Changing tools without a mature BA practice will likely just leave you with a new set of problems and higher monthly licensing costs. I would strongly suggest that the money and time you could spend on tool setup is better spent setting up a BA Community of Practice and put on a spread so your BAs can tell War Stories to each other over lunch.

Plan vs Change Centric

2009-05-11T21:41:00.000-07:00

The definition the latest BABOK has for Plan and Change centric project delivery methods is very useful. It's not exactly ground breaking to break methods/processes into different camps based on whther they are Agile or Waterfall - but the terms are pretty loaded. I think these terms capture the essential differences between these two camps.

It's not that one camp has different component tasks, it's just that one puts the plan as the central tool for delivering change, the other puts the change being delivered at the centre of planning.

You see this really clearly in the way that BABOK 2.0 describes the Requirements Anlysis tasks. The same basic activiteis are always done, but how and when they are done changes depending on process.

It's just nice to have a neutral non-emotive term.

It also reinforces that good BAs are good BAs regardless of methodology. If you know how to do it right for Waterfall you're going to be able to hit the ground running with Agile. The hardest bits don't change. Empathy, communication, listening, lateral thinking, modelling, and problem solving are always the core-skills.

Elementary Business Processes

2009-04-29T16:52:00.000-07:00

I go a little crazy whenever I see most "process" artefacts. There's something about the wooliness of most models that drives me nut. This then gets justified with "Well, this only a level 3 process diagram, not a level 4" and then follows a long useless discussion about what Levels 1 through to N really mean.

At which point someone produces some consultancy's slide pack that include a formal defintion of levels 1-4 and everyone walks away thinking we all aggree; that is until you try and reconcile process artefacts from two seperate projects and you find you can drive a a truck through the ambiguities in most of these defintions.

So what's the solution? I don't claim to have anything definitive but I do think that by building models based on at least one well defined and understood idea, and defining further concepts based on that we can come up with something more useful.

In summary: Don't start with defining "Level 0" process is. Define the bottom level and let the concepts flow from there.

Elementary Business Processes

The only really firm defintional ground I can find in this domain are "Elementary Business Processes", these are defined as:

An elementary business process (EBP) is defined as a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state (C. Larman, Applying UML and Patterns)

This is happily a defintion that can be used for:

A task in a BPMN diagra

A single use case

A step in a "Business Use Case" (Using the term in it's proper sense, not just as a vague use case)

The atomic piece of your functional business architecture.

This is a well understood and generally aggreed piece of functionallity that can then be used as a building block for everything else. They provide the central tracing point between all your different views of the world. You can link them to:

Organisational Functions

Orinisation Units

Stakeholder Requirements

Systems

Events (I'll talk more about events and EBPs later)

Services they Produce/Consume (e.g Service Orientated Analysis)

Logical Entities (Through a CRUD Matrix)

Applications

Disaster Recovery Requirements

Support documentation and responsibility

And just about everything

EBPs provide yout the atmoic unit of functionallity while doing functional modelling in the same logical entities and screens do for data and unser interaction modelling.

This unit can then be used to integrate your functional requriements to the steakholder requirements, information arch, and application arch.

Data Models

2009-04-27T20:07:00.000-07:00

I'm a big fan of the Conceptual or Logical data model as a way of driving communication about the problem domain. Without one it's almost guaranteed that you will miss requirements and make some bad assumptions about the way users think of the world.

At a fundamental level a Logical Data Model is simply a glossary.

When I say Customer what do I mean?
When I say Location how do I describe it?
When I say Measurement what information does that entail?
When I say a Charge has a Recipient what sort of thing is the recipient?

Unless you can answer this sort of question you just can't reasonably communicate about much else.

One of the problems is that fully-laden ER diagrams are the most "correct" way to capture this information and also incredibly intimidating for end users as they're just so busy and technical looking.

To counter this I tend to strip my ER diagrams down to basics and then pretty them up. This isn't always appropriate, I've taken an example below from Bridging The Gap where the detailed mapping from an old to new system was important so the fully-blown ER was required.

This take a very busy & technical looking document like this:

To a quite simple, focused almost cartoon like output like this:

This trades off some accuracy and level of detail for possibly much higher user engagement, and you can do it without losing any fidelity about the things you actually are trying to communicate, e.g. composition of each entity and their relationships.

Reading the BABOK - Chapter One

2009-04-27T18:49:00.000-07:00

Of all the geeky things I've done, being excited to read the BABOK has to rank pretty highly (And I used to wear my mobile, palm pilot, and leatherman all on my belt at the same time so that's saying something.)

My excitement has been justified though - this is a great effort from the IIBA and has been well worth the wait. It finally gives the BA profession a foundation for more involved discussion. It's early days though, and this comes out in it being a very self-conscious artefact, lots of references to why it was written, where it comes from, what it's not trying to do, etc.

Business Architecture is obviously out-of-scope though. I hope that will be the next stage of BA professional maturity.

The basics structure of the document goes like this

There are knowledge areas that deliver outcomes

Knowledge areas have tasks that are performed to help deliver these outcomes

Tasks can be undertaken using one or more techniques

The business analysts who do this would be advised to have some competencies before they attempt this

Concepts

But the real value lies in the definition of core-concepts, the definition of "Requirement", and the classification scheme is pretty similar to v1.6, e.g.

Business

Stakeholder

Solution (Functional)

Solution (Non-functional)

Transitional

I'm a bit disappointed that the term "Non-Functional" is back in. I preferred Quality-Of-Service, but considering how widespread Non-Functional is it's not a surprise.

Knowledge Areas

Maybe I'm a bit of a waterfall guy but the line between problem-definition and solution-definition in the knowledge areas was a little blurry for my liking. It's all a little blurry between Enterprise Analysis, Requirements Analysis, Elicitation, and Solution Validation. I think I'm in a minority here though.

There an explicity caveat earlier in the doc that the level of details is left undefined as it's so project dependant, but I would have like an acknowledgement of the difference between Requirements and Models, and between Prescriptive and Descriptive models. I've blogged about this before.

I had a view of 1.6 where Elicitation deals with a lot of Business and Stakeholder requirements, which are turned into Functional and Non-Functional requirements by Requirements Analysis, which are then QA'd and Refined through Solutions assessment and Validation. See the picture below for a gross simplification

Tasks

Only a BA could write this section. It's a whole sections defining now what we're going to talk about it, but the structure we will use. It's useful, and I like it (I'm a BA after all) it's just such a "BA thing" to do.

A task almost seems like the EBP (Elementary Business Process) of BABOK. The smallest thing you can possibly do by one person that adds value and leaves the deliverables in a consistent state. The whole EBP concept deserves it's own post some other time though.

It's important to note that tasks don't mean things done all at once, and done only once. They're very agnostic between waterfall, iterative, and agile. Tasks are things that are done, and it doesn't matter if it's part of a monolithic document drive process, or a light-weight agile process.

Tasks inputs and outputs

What they do include though is the inputs and outputs of the tasks, and each KA has an overview of the inputs, tasks, and outputs. This is more like a value-chain than anything.

It's all very useful stuff, but I'm having trouble getting past that fact that everything is documents in a quasi-BPMN notation that's not really communication to me the overall relationship between the tasks and KAs. That's the sort of things you expect from a methodology though.

I have an A4 diagram around somewhere of the relationship between BA tasks, their inputs/outputs, and the rest of the solution delivery function, but it's very specific to software development and very specific to an iterative lifecycle.

This whole section really just gets my appetite up for the techniques section. Having a series of pre-rolled summaries for descriptions of techniques will be very useful.

Underlying Competencies

This area is pretty wet. Behavioral Characteristics, Communication Skill, and Interaction skills have so much overlap I'm surprised they haven't been whittled down a little.

Overall Impressions

Great stuff. Even if chapter One was the whole BABOK it would still be useful. It sets out the structure well, defines it's terms, and gives me a structure to think about BA tasks in. I'm already thinking of how we can re-write our BA Performance Review and Interview Evaluation process to line up with the BABOK Knowledge Areas, Tasks, Techniques, and Competencies.

Blog the BABOK Part 1

2009-04-26T23:19:00.001-07:00

I'm going to start trying to go through the BABOK 2.0 chapter by chapter and blog my impressions as I go.

My first impression is that half of the names in the reviewers and contributors list don't have a the IIBA Accreditation (CBAP). This isn't a great sign - but it's defintely improving.

It's also nice that it has a cleaner, simpler, and better edited feel. All the blanks sections and pieces that felt cut and pasted from a google search are gone now.

I'll start with the first few pages tomorrow.

Subjective Quality - Negative Quality Requirements?

2009-04-21T19:23:00.000-07:00

Doing Pesach reminded me what subjective feature "quality" is. For those who don't know observant Jews basically use pretty much an entirely new set of kitchen equipment for 8 days every year during Passover. Just google it if you really want to know.

For the past few Pesach's we have used a dirt-cheap K-Mart special kitchen starter set for all our cooking needs, and a bunch of the most basic electric fry pans and blenders you can buy. And every year I love them. They do exactly what I need to do, do it with no fuss, and then I put them away for a year.

But if I were to use the same set all year I guarantee I would hate it, they have no fancy features, they feel cheap in my hand, the knives lose their edge every second tomato, and a host of other things.

But because my expectation were well managed, and they do the basic minimum well-enough for the price-point I am actually very satisfied.

The manufacturers compromised on some non-functional requirements to deliver the ones I care about.

So why don't we do this for NFR in our own docs? We spend so long talking about the ones that we want to be good - why don't we list the ones we really don't care about?

For example my kitchen set could have:
* Can fall apart after 6 months of normal use (That's 23 years of Pesach after all!)
* Can be ugly (8 days, who cares? We use disposable plates and cutlery for the table anyway)
* Does not need to be dishwasher safe (We don't use our dishwasher either, hence the plastic plates and cutlery)

These negative quality requirements are actually useful in designing a solution. The undifferentiated mass of positive quality requirements in most design docs are really only used to hold the delivery side to account (e.g. blame the vendor or IT) later on.

In a way it's a lot like "Scope" documents. Don't bother reading what's in-scope, whats out-of-scope is the important bit.

Break for Two Weeks

2009-04-05T17:43:00.000-07:00

Will be away from the 8th of April until the 20th.

A meaningful and kosher Pesach, and a big Chag Sameach to all of those for whom it is applicable.

0 Bug UAT

2009-04-01T16:18:00.000-07:00

This post has no informational value it's just to brag.

I have just exited the UAT phase of my current project with 0 defects. Not 0 Critical/Major defects. 0 defects of any sort whatsoever. The testing was quite comprehensive and thorough too.

How?

Mainly developers who did fantastic Unit and Integration testing at they went to ensure high quality deliverables, but ongoing regular user engagement with lots of demos and user access to the system during development helped to. Of course all this was only possible due to the savvy and engaged user base.

It's not about having a project-team where everybody is in the 5th percentile of awesome-ness (Though a few of our team are), it's having a team where no-one is in the bottom 20th.

And by "Project-Team" I of course include the business stakeholders, UAT authors/testers, docs reviewers, and SMEs.

It's just SDLC nirvana at the moment. No surprises. No fire-fighting. Just predictable well-planned, well-paced delivery of value to the business.

P.S. I'm getting a lot more people reading this blog than I thought I would (Not saying much). I really only intended it for my team in the consultancy I work for. If you're reading and I'd know who you are drop me a comment or email - I'd love to know who's interested.

Wiki Way - Documentation without Documents

2009-04-01T15:30:00.000-07:00

The environment we work in is highly integrated and involves massive amounts of collaboration. We need networks of related information, but our tools encourage documents that are monolithic silos of obsolesce.

The requirement I gather may be reused by another project in a different system, my definition of a "Customer" is going to be reused by three different projects, my project will impact some functionality that will later be impacted by three different processes, and all of the information in "my" documentation is going to have to be re-read and re-written by a horde of others.

Integrated solutions, silos of documentation

So what we should have for documentation is a collection of discrete pieces of information, shared between projects, systems, departments, and people, referenced from a multitude of places depending on need. This is a Wiki.

What we actually have is a graveyard of monolithic documents that are an arbitrary collection of information based on whether they were written at the same time, that only one person writes, and (if you're lucky) one group will read once. This is documents on a share drive or even an ECM.

Our whole environment is so integrated that a single business process could have come out of dozens of projects, crossing many systems form disparate projects, why shouldn't it call come together in one cross-linked place?

Documentation is great, Documents are bad

Every time you cut and paste from an old document to a new one you are not only wasting time but you are implicitly throwing away everything in the old document for reasons I mentioned a while back.

We have to communicate the same information to many different stakeholders and we assume that we know best every time we pack things together in a "pack" - but it's just plain Hubris to think you know best what others need to know. Best to put everything down and let them pick.

Long Lived

More than %80 of the solution definitions put in documents are never used again because by the time they become the main focus so much of the context around them has changed that the whole document is out of date. You've got to make it easy to change little things about items you impact in the main place they are documented if your information is going to live past you. Wikis make this far easier.

Modern Wikis have so many easy to use funky tricks to re-use and summarize content in different places that you'll be amazed where information ends up getting re-used and read, and if it gets read the chances are that it will get updated.

Presentation not Layout

Most word processors are just plain bad at letting you focus on content. The fact that a Wiki takes you back to paragraphs, headings, bullet points, and table is a strength.

If you want something pretty there are ways to do it, and if you want structured content there are also ways - but my advice would be get back to basics and concentrate on what you want to say not font or bullet points you use to do it.

Separate Project from Prosperity

What absolutely kills any hope of information re-use in documents is that most SDLCS don't differentiate between information needs for the project and for prosperity. You project scope ends up including system scope as well, your test cases include a list of test run along with the long lived definition of test-conditions. This is just crazy but there's no way around it as long as you have to produce a pack for sign off using a document.

I think issue tracking systems are pretty nice here also - but that's a different conversation.

Collate to present

When you have all of your information out there modern Wikis make it trivial to bring it together into one page/place to present for sign off. You don't need to change your deliverables to use a Wiki, you can just generate the content the Wiki way and then collate as needed. Then every time you change the system description all of your deliverables are auto-magically up to date (As well as any other projects that may reference you)

This still one of Wikis weakest points for software development. It takes some trickery to store a point-in-time version of a page but it can be done. The pages you end up creating can also be pretty ugly but I'm hoping somebody (Are you listening Atlassian?) will produce output as good as the PDFs form Wikibooks.

Easy

Seriously easy. I'd say it's easier to switch to Wiki from Documents than to switch to a new set of templates; especially for a younger workforce.

Don't let it just be IT

Chances are if you have a decent sized development community there's already a guerrilla Wiki effort going and there's a real temptation to make this an IT tool, or have separate IT and business areas. That's a mistake.

Wikis have such a network effect going though that by playing nice with others you'll get amazing returns. Business users, process owners, HR people, canteen managers, all have parts to play. Having the deep context about the business linked in with the IT information is what will keep you aligned.

Not all Rosy

It's not all rosy though, we've used documents for documentation for a long time for some pretty compelling reasons. They're convenient, a trusted metaphor, have fantastic control, easily printed, and easily shared by email.

Step away from the requirements/design tool

Heart on my sleeve time, I don't believe in tools.

They over-structure everything, lock you down into their way of doing things, over-organize their own domain and neglect everything else, and make ivory-towers where the tool-user condescendingly "publishes" out information to the plebes who don't have it installed.

Tools get mis-used as a best-practice or process-improvement piece. I've never seen this work. BAs or Architects without the skills or processes needed are still just as ill-prepared with a tool. Spend the money on putting a copy of the BABOK Wieger, Cockburn, and Gottesdiener on everyone's desk instead.

The high-end Tools are also incredibly expensive to buy, maintain, install, support, and train; and once the vendor gives you the first taste you'll always need just-one-more-product.

Next Steps

I wish I could point to a sample of a Wiki showing a business' architecture and systems but I can't. Next big post will be give a rough structure of what you could start off with.

Big Releases Coming Up

2009-03-29T18:10:00.000-07:00

Just a gentle reminder:

BABOK 2.0 is just about to be released the the public (IIBA members have had sneak peeks since forever)

BPMN 2.0 is also just a few months away

If you're as geeky as I am, that's pretty exciting.

Business Requirements at the Mall

2009-03-26T20:17:00.001-07:00

One of my conversation starters on requirements used to be to take people on a walk around whatever mall is closest to their client site and visit a few different stores.

I'd try and go to two different places where the physical product was the same but the atmosphere was widely different. For example you could go to:

* Borders CD Section and JB Hi-Fi
* Kikki-K and Office Works
* Country Road and Polo Raplh Lauren

These stores core product is widely different even though their physical product is the same.

Borders and JB Hi-Fi both sell CDs and Music but their presentation, layout, pricing strategy and advertising could not be more different. Kikki-K and Office Works could not look more different if they tried, yet both sell Pens and Paper.

Why?

Well they are solving different problems for different customers in different situations. Different "Business Requirements" in BABOK speak.

They have different stakeholders with different expectation and preferred trade-offs so even if the physical product seems to be the same it's worth spending the time to understand the users and environment to deliver, price, and present it correctly.

When I say this with a store everyone nods and understands, but when we start talking about software everyone jumps straight to solution.

The lesson from Retail is that even if you guess the correct solution if you haven't spent the time to understand your market and their needs, chances are you're not going to deliver it to their expectations.

P.S. Kikki-K does this to perfection. Every square centimetre of their stores yells that they will make you into some super-organised, efficient, effective, blond, Swedish person with impeccable handwriting. Once they've sold you this dream getting you to pay $12.99 for a pad of paper is easy.

Best. GTD. Thing. Ever.

2009-03-26T20:10:00.001-07:00

Manilla Folders made out of textured plastic so that they alwasy look neat. Found at Officeworks for less then $10.

Does anyone else wander around officeworks as a means of relaxation? I've had a few other people admit they do the same thing. I think the relaxation comes from imagining an organised me using all those products.

Want to be a better BA? Be a better Marketter.

2009-03-22T20:04:00.001-07:00

The deepest thinking I've done about BA tasks recently actually happened during a class on marketing. A few of the core marketing concepts such as understanding your customer, core/actual/augmented product, and perceived quality have really affected the way I work.

I probably found it so useful because the lecturer (Dennis Price of RetailSmart really pared ideas down to their basics, explained them well, and then applied them to marketing. Unfortunately by the time he applied them to marketing I was already applying them to Business Analysis so I got a pretty lousy mark. That's a small price to pay for learning a lot though.

Some great posts:

Taking Criticism. Relevant to anyone who has documents peer-reviewed.

Core Produce, Augmented product, etc

Joel vs 37 Signals

2009-03-20T20:37:00.000-07:00

I shouldn't be frustrated with JoelOnSoftware (See last post) considering he has more insight about software development in one post than I think I've mustered in my whole career. His case for functional specs is probably the best article on why you should write functional specs you can read in under ten minutes.

37 Signals "Nothing Functional about Functional Specs" is an excellent case for what's wrong with bad functional specs.

Meanwhile the rest of their approach is probabvly only feasible is you're a Web 2.0 startup doing a consumer-facing app with all internal resources and great people. Which they are so more power to them. I'm just not listening to them when I'm delivering fixed-price, mission-critical, sensitive projects to government departments.

If you don't have a BA you will be forced to invent one

2009-03-20T18:27:00.000-07:00

Just like a PM, Tester, or Architecht any team that doesn't have a formal BA identified will end up creating the role in some round-about way.

This post from Joel on Software about a "Program Manager" is a case in point. It's pretty much just a rediscvery of the need for a BA - which is just frustrating. Every development method or team that thinks it can do without a BA really just makes-do with a bad one named something else, and then blames the user for their problems.

How heavy is your SDLC?

2009-03-18T09:00:00.000-07:00

Everyone complains about how many non-value add activites are in their Software Development Method - but how do you actually measure it? It's a truism that you can't manage what you can't measure so surely you really ahve to measure this.

Here's my proposal.

How much documentation would be required to deliver "Hello World"?

Are we talking a few pages, a stack a few centimetres tall, inches, feet, kilos? Remember this is everything it takes to get it from a twinkle in a stakeholders eye to supported in production. Business cases, support plans, test reports, meeting minutes. Everything - and no "small project" exemption because they're often more trouble than they're worth.

We could even classify methods by their order of Magnitude.

Scrum and XP are probably around a centimetre of docs. User stories and Index

cards are pretty thick after all.

The IEEE standards are definetly into the inches

My own company is probably a little over an inch - but we're quite disciplined about trimming it down to match for the situation

RUP is definetly a few inches

I assume military projects would be into the kilos

Mindmaps

2009-03-17T17:45:00.000-07:00

If you do a lot of mind-maps like me you probably should be using Freemind. It's Free, Fast, keyboard Friendly, and Fully Functional.

It's a great tool to capture and structure throughts and notes at the beggining of a project if you've outgrown your notepad but don't quite require a wiki and ticket tracker just yet.

If there was some cross-breed of TiddlyWiki and FreeMind that would be jsut perfect.

Free Mind
Tiddly Wiki

Reviewing Document Deliverables

2009-03-11T17:11:00.000-07:00

Here's a scenario I'd like to run to review the diocumentation deliverables produced during software development.

Collect stakeholders from representative groups.

Get a room with the wall covered with butchers paper.

Draw a box representing each deliverable on the walls of the room.

Write each piece of content in each deliverable on index cards and stick them in the boxes they're currently in.

Take the cards down into stacks

Everyone votes on what they need for their function to work (Not what they produce, what they need) using one of the many requirement prioritisation tricks around

Throw the bottom %50 away.

Assign the cards to whoever produces them

Define dependencies and set out a time lines

Owners collect cards into deliverables based on the time line

Say hello to your new deliverable

Anyone game to let me try it?

Being religious is a lot like being a woman

2009-03-10T18:07:00.000-07:00

I often find that I'm a bit of an Outsider in groups, but an Insider in the one-on-ones. I have a lot of great relationships wiht individuals but have the impression there's some sort of boys-club network going on behind the scenes that's not really accessible unless you get plastered at after work drinks and email around the sort of things that fall fould of the email Acceptable Use Policy.

There was an article in HBR that really influenced me about how women network. Even though I'm not a woman I suspect anyone who is in a group that precludes them from particpating in a lot of the workplace social rituals has similiar issues and mitigation mechanisms.

The term "Outsider/Insider" sums it up well for me, that feeling of having a lot of contacts inside an organisation, a lot of empathy with the organisation, but not quite being a part of it. It really allows you to enter a mental space where you can work on the organisation not in the organisation.

Update: Someone aksed for a link to the HBR article. It's subscriber only but a quick summary is on HB online and BNet

Great day at ModernAnlyst.com

2009-03-05T14:19:00.000-08:00

If ModernAnalyst.com isn't your homepage it probably should be.

There's always a great articles and comments up but these two were stand outs.

http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/842/Business-Architecture-The-tool-for-strategic-decision-making.aspx#Comment274

http://zachmaninternational.com/index.php/ea-articles/26-articles/68-architecture-is-architecture-is-architecture?tmpl=component&print=1&page=

Symbolism

2009-03-02T17:28:00.001-08:00

I don't think you can underestimate the impact that symbolism can have on your software project. There's a series of tricks that rely on this to get stuff done, but the area I find it most useful is sign-off.

I almost invariably get wet-ink on a page, I get that page laminated, and that page goes on the wall.

Why?

Forcing people to sign with a pen makes them more likley to engage with a document than an email sign off. Don't ask me why it just does.

Laminating a document makes it official. It's a sign that we actually care about what we just aggreed to.

Visible tracked process. It's great to see your project grow and progress through gates.

This was all inspired by something I read in GTD about how improtant it was to have a labeller on your desk and how people jsut work better with nicely labelled file.

Planning & Requirements

2009-02-26T16:56:00.000-08:00

Reading GTD I'm seeing even more parallels between his world-view and the BA world view.

In particular He lists "Five Steps to Accomplish Any Task"

defining purpose and principles

outcome visioning

brainstorming

organizing

identifying next actions

Once you read the descriptions they bear an uncanny resembelance to the hierachy of requiremnts types defined in BABOK. (Business -> User -> Functional).

But so what?

Well, he has some great advice that when you've got no clarity on why you're doing something you should go up the stack, but when you can't get somethign started or finished you need to go down the stack. This is great advice for BAs.

Don't be constrainted by the exact stage of the project you're in - you should always be prepared to switch contexts to respond to the environment.

When there's confusion about what to do, you go down the stack, when there's confusion as to "why" to do something, go up.

P.S. http://www.minezone.org/wiki/MVance/GettingThingsDone has an amazing notes page on GTD. Great summary of the basic poitns.

GTD is Agile for your life

2009-02-24T20:46:00.000-08:00

As a geek who is not very well organised I try a new "system" once every year or so and generally follow it for around 8 months. This time around I'm giving GTD/Getting Things Done a go.

Reading the book I've realised it's agile for personal organisation. At a fundamental level they're both about concentrating on short, deliverable iterations and only doing the detailed next-step planning as you go.

Reading the David Allen on defining "Projects" in GTD I was struck by how similar they are to Agile user stories, there is even an emphasis on defining them by how you would test they had delivered. This is just pure Agile.

So, basically GTD is Agile for your life. Agile is GTD for your project. I wonder how well some of the Agile project management tools like Mingle and Jira would work for GTD? I bet Jira would be great.

Keep It Simple Stupid

2009-02-23T17:32:00.000-08:00

The bit of being a BA that I am worst at, and so the part I work hardest at, is to simplify instead of complicate things.

Like most BAs I have a pretty high tolerance for complexity, especially if it makes things "elegant" or "flexible". I'm also a sucker for the simple basic idea, that can then be used to implement a thousand complex functions.

Now we all know that complexity equals cost. Development cost is the least of it. Complexity easily costs more in test/fix than in the development stage. Organizational Change, user confusion, and lost productivity is where the real costs of complexity lie.

So what's the solution? For me it's two fold:

Put the user first. Start with what the user is trying to achieve and work from there. Most people think "How could th system do this?" instead think "How does the user do this?".

Put complexity to use simplifying things. Be like an iPod. Simple up front, with the complexity hidden away.

This means being driven by user/business events and the required user/business response not by a system, and not by what functionality is available. In most projects if you start with the business process and work in you'll get off on the right foot.

Need BAs?

2009-02-17T16:19:00.001-08:00

Does anyone need some good BAs? If so drop me a line. I'm locked away for a few months but I know some other people who are looking.

Wiki Patterns

2009-02-15T17:10:00.000-08:00

The www.wikipatterns.com site is a great repository of patterns about Wikis. There's a few ones I'd like to submit if I get the time to write them up properly.

Separate Project and Persistence: The wiki should really strongly separate the project related ephemera from the information that will be useful long after you deliver.

Publish In The Process: Ensure that the use of the wiki is embedded in the formal gating processes, but mostly in people day to day tasks. The Lunch Menu pattern is very helpful here.

Insivible Panes and Broken Windows

2009-02-11T21:45:00.000-08:00

The Microsoft Office documents that you probably spend half your life writing and reading rarely live much longer than a few months. Why?

I think there are two major reasons that stop documents being re-used and living past the project they were developed for. These are:

Invisible Panes
There is such an overhead to changing a document that most people don't bother. Change control acts like a pane of glass protecting the document from changes. Version numbers, dates in file name, change-logs, checking out and then in, reviews, all the minutiae of changing a document is so high that it is a wonder it happens at all.

This is not even a rational cost/benefit call it becomes a psychological effect where people don't even see that they *could* make some small changes.

This means change is only cost-effective when it is a large volume of change from the one personal batched up together. Updating a few lines, fixing a spelling mistake, or fixing some out-of-date point is hardly worthwhile. 5 seconds of typing is completely subsumed within the admin time to make it happen.

End Result?

Documents are written by a small groups of people in big blocks in a short intense period by people who own a particular document, however...

Software is developed by large groups of people each performing a series of small tasks over a much longer period by people who have diffuse knowledge of the whole environment.

Ask yourself - how long would it take to you change a comma to a full-stop in a signed-off document stored in your system of record?

This mismatch means that most documents are valid once, and never get updated again. They could get re-used for the next project, except for..

Broken Windows

Once a document gets a little bit out of date it will never be updated. If one part is old, the document itself becomes "old" and will stop receiving any small updates. If will then become even more out of date and becomes out of data or receive in the dreaded moniker "in the old format". New projects will find it easier to start all over again. So if information isn't kept up-to-date it will age rapidly.

Just like a few broken windows in a building encourage more vandals and the building will quickly becomes a dump - so too a few imperfections in a document means the entire things is condemned.

Solution?

Properly structured Wikis tend to fix both these problems. They remove %98 of the overhead to make an edit, and if your content is in lots of small wiki pages people will be far happier to update a few pieces of information on one page - than embark on a full-fledged clean up.

Really - it's all about embedding knowledge management and cleanliness into your day-to-day organisational processes - instead of structuring your activities around the tools like most people do.

Who owns the business process?

2009-02-11T20:02:00.000-08:00

This is so simple it should not even have to be said, but I've seen it wrong so many times, so lets recap quickly:

BAs do not own the business process

Architechts do not own the business process

Workflow implmentation teams do not own the business proces

The process improvement team does not own the business process

Your high-fallutin' BPM consultant does not own the business process

The person who owns the business process is, unsprisingly enough, the business.

You can question, suggest, cajole, advise, and escalate - but the people who will run, manage, and live with the process long after you're gone are always the ones who have to be in chage.

To think you can waltz in and make big changes without causing flow-on effects takes a lot of arrogance, or a lot of incompotence, or some combination of the two.

It's all about having respect for the stakeholders and realising that as a BA you're working for the business, not on the business.

Cyber Chase is Awesome.

2009-02-09T20:16:00.000-08:00

This is completly off-topic, but..

Cyber Chase, the childrens TV show that teaches discrete match to children is awesome.

http://pbskids.org/cyberchase/

I just wish I could find some complete DVD box-sets (For my kids naturally).

"Technical BA"

2009-02-05T19:57:00.001-08:00

I often have people half-way through a project remark "I thought you weren't technical.. How do you know that?".

This is because I really try to hide my technical background as much as possible because I know other people can do it better. The only two uses I've found for it are:

Rigour: When producing a functional design if you're rigorous in how you apply modelling you can generally produce something a lot smaller and easier to read than if you just waffle around.

Being a bastard: It's a lot easier to be pig-headed and be the voice of the business if you can call bull-dust on people who want to pursue "Technical Elegance" over something the business actually wants.

BA as Stenographer

2009-02-02T20:04:00.000-08:00

Am I schizophrenic?

Just one day after mouthing off about BAs injecting themselves into the requirements process far too much I feel a need to go on a rant about BAs acting as glorified stenographers. Just writing down whatever the user says and presenting it as a requirement.

I don't think this contradicts my last post, as I'm talking about different types of requirements. When you're collecting business requirements your job is really a drawing out, elicitation and ellucidation, when you're developing functional requriements is where you actually ahve to analyse and be creative yourself.

The problem comes when people get it round the wrong way, they get all creative about business requirements ("Hey! Lets solve this problem no one cares about in a way that no one wants.") and then just write down every functional requirement ("If the user says they want a thousand pop-up boxes every time they do everything who am I to say that could get annoying?").

User Requirements fall somewhere in the centre I suppose.

So now I end up right where I always end up. The fact that people don't differentiate between types of requirements enough.

User Knows Best

2009-02-01T15:12:00.000-08:00

Why, oh why do BAs make up their own requirements? Stakeholders generally have a pretty good idea og things they want already without you piping up about new functional requirements that are unrelated to any stated user, or even business, requirements.

I've been in so many situation where the user's justification for an enhancement is "The BA suggested it, but we don't really understand why". This ends up costing tens of thousands of dollars to produce something no one needs - and all project methodologies are vulnerable to it as soon as the project team starts speaking for instead of with stakeholders.

The root cause is a muddled defintion of "Requirements", and a failure to apply the simple lesson that you have two ears and one mouth and they are to be be used in that proportion.

Fake it till you make it

2009-01-26T14:49:00.000-08:00

Requests for a more seniority or responsibility from people I'm mentoring are always so hard to respond to. There's such a range of emotions behind the requests, desire for more responsibility, status, earning-power, recognition, and respect that you've got to be very careful.

What I generally respond is that you don't get a (sustainable) senior role in a consulting organisation by managing upwards, you get it by the reputation you have among your peers for insight and ability to execute.

So get people to think of you as "Senior" and the position will generally follow.

Be the "go-to guy" for certain areas, cultivate a reputation for giving insight and new ideas, make sure you are liked and respected.

Puckering up to VPs, working long-hours, and sacrificing the work-life balance of yourself and your staff to satisfy unreasonable demands wont work in an organisation you'd want to work for.

So what's the practical outcome of this:
* Bone up on your theory, being able to give the why as well as the how separate the wheat from the chaff.
* Help other deliver great work, and be a cheer-leader for them when they do.
* Schmooze outside your circle.
* Pick small achievable visible tasks that are tangential to your main responsibilities and deliver on them.
* Don't publicise things working on if they may not be delivered. Promising the world and not delivering kills your credibility no matter what the reason.
* Help and protect any reports (or colleagues) you do have from unreasonable requests of organisational nastiness. Even if it doesn't help you in the short term it's the right thing to do and will be remembered.

This all sounds fluffy so far, but there's two things that aren't exactly "nice".
* When someone isn't performing and you've realised they never will in their current role don't try and keep them around to be "nice". It's just a waste for everyone.
* Ass-covering and effective escalation are two sides of the same coin. Make sure that you are not responsible for any risks that you can't control for. Cover your ass my escalating risks to the person who can actually mitigate them (This is a post by itself)

Disclaimer: This could be good advice or it could be total bull dust. It's worked well for me so far, and while I'm not exactly a partner earning mega-bucks but I've been pretty happy with my career progression since I switched to the BA-space.

I like the BABOK because it doesn't rock the world

2009-01-22T16:30:00.000-08:00

I love the BABOK because it so uncontroversial. There's nothing in there that people really disagree a lot about, nothing out of left field, nothing too prescriptive of a certain way of doing things.

It's just a nice place to go when you want a pre-rolled consensus on defintions, roles, activities, and artefacts. It doesn't give any straight answers, but it functions really well as an assumed body of knowledge between two BAs that let them have a conversation without having to stop and define every second term.

Consultants say No

2009-01-21T21:18:00.000-08:00

Why should you hire consultants from a firm instead of cheaper direct contractors?

Basically Consultants will say "No" more. The extra IP, support teams, and experience are just bonuses. It's the things we (d|w)on't do that add the real value.

(Thanks Yaw)

People, not process

2009-01-21T21:04:00.000-08:00

Changing your methodology isn't going to help if the problems you're having are cultural or systemic.

Every three to four weeks somebody tries to sell me on some new methodology or way of software, generally it's some agile, scrum, XP, iterative, test-drive, fully buzzword-compliant system that comes complete with 2 case studies, web-based management tools. (Generally it's someone in chinos and a polo-shirts, occasiaonlly suit pants and a highly-patterned suit. It's barely ever someone in a suit-and-tie.)

I sort of half-buy it. There's some fantastic ideas in a lot of "agile" methodologies that I gladly steal, and I'm sure it works great for a lot of projects, but they still rely on:

Smart People (Guess what, Bad People will deliver Bad Results regardless of Process)

Thinking about what you're doing and why

Good engagement and trust with end users

A steady source of funding with good scope-control mechanisms

And really if you have these, most methods are going to deliver. A lot of the people who get excited about lighter approaches have a habit of comparing the worst real-world water-fall project experienced to the best imagined agile project they can think up.

I may just be biased against the "no-spec/agile" stuff as I do so much work on fixed-price/fixed-delivery projects.

It's not that I haven't seen my share of useless 200 page behemoths that will never get read - I just think there are less radical, less risky solutions (e.g. Wikis, BA Compotency Centres, proper Requirements Management) and if people spent half the time they spend on polishing and improving their agiles processes on traditional processes they'd get a much higher return.

The least I can do..

2009-01-21T14:27:00.001-08:00

A lot of the conversation I have around BA deliverables focus on all the different information what *could* be useful, rather than the minimum that will pretty much always be used. I'm constantly frustrated by the amount of information duplication and useless sections in most project documentation

I think I've got a pretty good default-minimum documetnation set worked out that has been applicable in my last few roles in a variety of different software development projects. It's my defautl starting set for all software development projects, I've even used it in Agile projects. The only difference is that I update the docs in parallel with development on a wiki instead of producing the documetns beforehand.

Project Vision Document(Business Requirements in BABOK)

What problem we are trying to solve
Business Context (Just how people rely on each other to get their job done, no systems, no data flow diagrams)
What success looks like

Business Requirements (User requirements in BABOK, but everyone calls them Business Requirements)

One page picture of possible solution
Requiremetns in the form "As a.. I want to.. So that.."
Conceptual Data Model (Entities, and if they are related, no attributes or cardinality)
Business Functions and Elementary Business Processes affected

Functional Requirements (Functional requirements in BABOK, but also called software requriemetns, systems specification, design, etc)
- System Behaviour (Use Cases, ACtivity Diagrams)
- Process Models (BPMN)
- Logical Domain Model (ER Diagram)
- User Interfaces (Wireframes, black & white)
Traceability
- Vision to User Requriements
- User Requirements to Use Cases/ER/Process/UI
- Test Cases to Use Cases
Testing

Project Vision Testing (UAT - Did I get value from this project?)
Functional Testing (Did it support the functionallty and use behaviour in the User Requriements?)
System Testing (Did it exhibit the behaviour specified in the functional design?)

I'm leaving out the technical side (To the extent that it's even a different side) because I don't want to get into it, I'm also ignoring all teh changes that come about from differnet project types (Integration, Portals, CMS, COTS, CRM, ERP, etc. All of these have their own twists.)

I'm also really heavy on the testing side - I like my V-Model testing. I like the idea that you verify you did-it-righ, and you validate you did-the-right-thing as distinct activities.

Ways to fail a BA Interview

2009-01-18T16:57:00.003-08:00

* Saying I want to be a PM. If BA is just a stop of point to becoming a PM what sort of BA are you?
* Not answering questions with Questions. If you answer questions instead of asking them what sort of BA are you?
* Not asking what the interviewer wants to know. If you don't elicit requirements n ow what sort of BA are you?
* Poorly laid out resume. If you can't use word what sort of BA are you?
* Resume over 4 pages. If you can't think of how most people read your document what sort of BA are you?
* Nothing but bullet points in your resume. If you can't write a full paragraph what sort of BA are you?

On a side point..

I ask some really nasty questions in BA interviews, really open-ended strange questions about odd problems. I find the way people answer, and how they drive teh conversation more revaling that standard interview fare.

We've hired one or two people who messed up every "What is a Use Case?" question, but gave fantastic answers to the open-ended scenario questions, and they've been fantastic. In previous companies we've hired people who gave textbook perfect answers, but failed the open-ended questions, and it's been a disaster.

If you want to interview to find good BAs its nto important that they give the "right" answer. It's more importnat how they answer. Most important though is how they question.

Types of Models (and why they're not requriements)

2009-01-18T16:54:00.000-08:00

I think a lot of the time when the analysis portion of a project goes astray the problem lies in people not knowing what they're modelling and why.

Knowing why we're modelling is hard. This is often the underlying reason people ask the question "How detailed should we be?". Modelling is generally on one of three levels:

Are you doing this to build consensus and set scope? Then go for an "Descriptive" model.

Are you doing this to define what will get delivered? Then for for an "Analytical" model.

* Descriptive: Like a Monet. Enough to evoke the feel of the thing you're modelling, but not enough to actually build it.
* Analytical: Like an architects drawings. Enough to give an unambiguous definition of what it will be.
* Executable: Like the actual object. When you define a work flow in a work flow systems - you're not modelling you're actually building.

Notice that this is completely different to types of requirements. User Requirements may be captured using models that are Descriptive, Analytical or even Executable depending on the project. They may not even be captured with models.

There's a difference between capturing requirements and modelling a solution. Though these is a rough correlation between user requirements and the Descriptive view and functional requirements and the Analytical view.

(The three levels of modelling are taken from a Bruce Silver blog post about process modelling that's fairly widely referenced: http://www.brsilver.com/wordpress/subscribers-only-2/three-levels-of-process-modeling-with-bpmn/)

Documents Considered Harmful

2009-01-18T15:49:00.000-08:00

The more BA work I do the more I realise that our basic tools aren't well suited to how most people develop software. Documents are far too static, un-collaborative, and unlinked, while the big integrated suites are way too big and integrated to be useful in most environments.

I've had some success in the past using Wikis and Issue Tracking software for requirements, design, and testing, but this has problems of its own - especially when it comes time for sign-off and communicating with people who want a concrete document to read and sign off (like me). True you can get a documetn out of a Wiki, but it's normally a schlep and the result is fugly.

I guess I'd be fully sold on Wiki route if you could:

Easily put together document from a set of pages at a set point in time and retain it as a project artefact.
Make the resulting page pretty (Would outputting to LaTeX and from there to PDF be so hard?)
Track Sign-Off across multiple pages

You've really got to put as thoguht into setting up your Wiki structure, and how you'll use issue tracking - but more on that later.