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.
Wednesday, December 22, 2010
Thursday, December 9, 2010
Customer Needs, not Functionallity
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?
I can feel that they've actually though about:
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:
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?
Sunday, November 28, 2010
Requirements as risk mitigation
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
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
Thursday, September 16, 2010
Three Types of Requirements
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.
* 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.
Monday, August 2, 2010
Discreditting by Diagram
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.
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:
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.
Tuesday, July 27, 2010
We must hate trees a lot..
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.
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:
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?
Thursday, July 22, 2010
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.
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.
Thursday, June 24, 2010
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:
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.
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.
Sunday, June 6, 2010
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?
Thursday, June 3, 2010
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.
Monday, May 17, 2010
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:
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.
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.
Wednesday, May 12, 2010
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.)
Monday, May 10, 2010
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.
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.
Wednesday, March 10, 2010
Resistance to Change
Recently I lost my trust calculator. A black & boxy Casio DX-100 that I remember buying on my first day of high-school with a crisp $20 note I bought from home.
Now just bear with me - that relates to Business Analysis eventually.
I found it difficult to use at first, but I grew to love it. Over years of high-school, a computer science degree, and a good chunk of my MBA, I think I had used every single function the calculator had and knew my way around it like the back of my hand. I found using it effortless, that perfect user experience where you don't have to think about the device, only what you want to achieve.
Then, to my horror, I lost it half-way through doing Accounting for my masters.
I was actually slightly depressed at the though of having to use any other calculator. I know this is weird, but you have to understand that my relationship with the calculator is four times older than my marriage and that I'm a geek.
So I bought a new calculator. $40 this time. It was all curved edges, sleek lines, and translucent blue plastic. I hated it.
It's true it was (a lot) easier learn than my old one, and had lots of new features, but I didn't know how to use them yet - and even when I did work them out if felt strange, and wrong.
Worst of all a function I used constantly, saving a number to memory and then recalling it, took an extra key-press, and that extra key press was all the way up the top of the calculator. Which drove me crazy.
Even though I knew that objectively my new calculator had more features - I resented it. Every time I saved a number to memory I would silently pine for my old calculator.
Until a few days ago when I found my old dull-black calculator, started using it again, and realised how much I missed all the new features of the shiny-blue impostor. So I went back to using the shiny-blue one.
I wish I could say that this means I now am happy with the shiny-blue one - but no. I still resent the extra key-press for the memory function.
So what are the BA lessons here? (Asides from the fact that I think too much about calculators)
Users value lost utility, more than they value gained utility.
Old systems are viewed through rose-coloured glasses, no matter how bad they are
The cost of learning a new system is intimately felt by users - expect resistance
Even when users rationally realise the new system is better - don't always expect them to be happy, because..
People have emotional attachments to systems that aren't always apparent
I think the last is most important. I went through a whole project with and only found out afterwards that one of the main stakeholders considered the original implementation of the system we were working on the most professionally satisfying and productive point in their career.
The result was they implicitly saw any move to retire bypass the system as slight on them personally.
Resistance to change isn't just about technology, costs, benefits, and features. Even when we think we are being rational we generally aren't.
I'd hidden contraband in the back of that calculator case during a math lesson almost twenty years ago while looking out over a grassy quad. This shiny-blue monstrosity that I'll use for my accounting exam doesn't even have a compartment for that.
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)
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.
Thursday, February 11, 2010
BA Bookshelf
Now obviously the best BA bookshelf is a couple of hundred meg of articles on your USB key, but failing that physical books are nice too. Probably the best bang-for-buck in any training budget can be had by buying a nice collection of books for your team and getting them to read them.
It doesn't matter if they all get lost (they will) the impact of a $50 books is bigger than a $1500 training course, and doesn't require any lost billing-days. So what should you buy?
Get a one good book each on:
What requirements are: Karl Eugene Wiegers, Requirements 2nd Ed
How to use User Stories: Mike Cohn, User Stories Applied
Process Modelling: Bruce Silver, BPMN Method & Style (Haven't actually read it, but everything Mr Silvers says is gold so I have no problem recommending it blind)
How to run a good Workshop: EGB, Requirements By Collaboration
Use Cases: Alitair Cockburn, Writing Effective Use Cases (What else?)
Enterprise Arch: W. Ross, Peter Weill, Enterprise Arch as Strategy
I suppose you could thrown in something on data modelling as well - but seriously if you have the head for data modelling you're fine, and if you don't a book isn't going to help. Same for UI design. For the record I have a head for data modelling, but I always need help with User Interfaces (Thomas! Mahesh!).
And this post is not proof-read because I don't have time. I'm going to try and post more often now, which means less quality too.
Amazon List Here
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:
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
Wednesday, January 13, 2010
Consultnik no more.
I should probably mention for the tiny minority of readers who don't know me that I'm not actually consulting anymore. I chose to contract directly about a month back as I got a particularly good offer at the right time and the time overheads of doing internal consultancy work and client work at the same time weren't compatabile with finishing off my MBA, while not compromise my religious learning.
It was excellent though - and I fully intend to send my resume back to the consultancy that employed me if I ever decide to go back to consulting. They are a great company.
P.S. My previous post comes out of thoughts I had about how to sell BAs as a service in a consultancy environment separate from delivery work, its just a coincidence that these posts are next to each other. No criticism of anyone intended.
It was excellent though - and I fully intend to send my resume back to the consultancy that employed me if I ever decide to go back to consulting. They are a great company.
P.S. My previous post comes out of thoughts I had about how to sell BAs as a service in a consultancy environment separate from delivery work, its just a coincidence that these posts are next to each other. No criticism of anyone intended.
Foxes & Henhouses
When you're beginning an important IT project you're no short of friendly Consultants, System Integrators, Product Vendors, and Outsourced Providers who are willing to offer their advice and help; all with the projects best interests in mind. Many of these provider will also provide you with Business Analysis services to aid in the execution of your project.
However there will come a time when the requirements of the business conflict with the interests of the stakeholders delivering the project, and your Analysts will always be in the center of these discussions – and whose side do you want them to be on?
How can your vendor supplied Analysts deal with a situation where the product they are selling doesn't meet your needs? How often has a consultancy sourced BA suggested anything that doesn't involve follow-up work for their consultancy? How often does a System Integrators BA ever advocate for a scope-increase, even when it's justified?
All of these conflicts of interest come to a head later in the project, typically around a table trying to civilly decide if a given change is a bug or a change request while everyone mentally calculated how much budget is left in the project, and how much slack was built into the profit margins anyway.
The horrible thing is that none of this is conscious - everyone always tries to do whats right. It's just that your views are so conditioned by the influences of your peers and your background.
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.
Subscribe to:
Posts (Atom)
Posts
