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.