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.