Planning & Requirements

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

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

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?

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

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

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?

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.

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"

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

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

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.