Best User Interface Ever

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

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

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

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



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

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

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

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

Best. Interface. Ever.

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

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

This is the iPod shuffle of children's toys.

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

What sort of "consultancy" are you?

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

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

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

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

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

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

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

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

Reports for people not databases

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

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

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

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

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

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

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

Reply quickly without being rude

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

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

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

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

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?

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

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

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

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

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

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?

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

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

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

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

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

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

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?

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

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

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

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

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

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.

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.

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

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

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?

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

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

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

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

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

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

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.

Fake it till you make it

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

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

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

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..

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

* 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)

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

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.