Kick-Start Templates

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)

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

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

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

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.

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

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.