Nov
14
Methodologies vs. the BA BoK
November 14, 2005 |
This post is a semi-personal opinion; I haven’t run this past the rest of the BA BoK Committee yet.
The BA BoK is not a system development or process change methodology, nor is it part of one.
A methodology should provide a project team with several things:
- A set of defined roles to be played in the team
- Guidelines as to which team roles can be combined in a single person
- A breakdown of major deliverables
- Sample deliverables and deliverable formats
- A listing of tasks to be performed
- An outline of a project plan
In other words, it tells the project manager (or equivalent) who to get, what they should be doing, and when. The value in a predefined methodology is that you don’t waste time arguing about job responsibilities, or authority, orthe work that needs to be done. That usually happens anyway the first time a team runs through a method, but after a while they should know their role and everyone else’s.
The BA BoK does not do those things. I’m saying that because some of the feedback we get suggests that people are hoping it will, and they’re going to be disappointed.
Where methodologies set out to define a set of team roles, the BA BoK sets out to define the knowledge and skills a person needs to have in order to fill a specific set of those roles (in different methodologies–the ones typically assigned to a person known as a Business Analyst. If you have those abilities, and you’re working somewhere where there is no defined methodology, you should be equipped to articulate what you can do and know how to do it. But there’s no way for the IIBA to say what you should be doing unless we also know what other roles exist on the project, and what deliverables they expect from you.
Comments
1 Comment so far
What I'm Reading- Do You really Believe in What you Do?Requirements Defined - Seilevel's Software Requirements Blog
- C.R.A.C.K. Requirements managersBetter Projects
- ‘IT has no inherent value’IT Project Failures
- Business Analysis in an Uncertain EconomyJonathan Babcock
- Why We Lost Focus on Development PracticesAgile Management Blog
- Talking about what we doRequirements Defined - Seilevel's Software Requirements Blog
- BPM is not Software EngineeringGo Flow
- 3 Big CaliberRM Gotchas And How To Fix Them Part 1Requirements Defined - Seilevel's Software Requirements Blog
- Project World and World Congress of Business Analysts (PW&WCBA)Better Projects
- Troubled ProjectsHerding Cats
I agree that the BA BOK is not and should not be a BA methodology. I also don’t think that a BA methodology is what we, as a profession, should be focusing on. Every project and every business problem is different and a successful BA should be able to assess the problem and use whichever tools are appropriate to put together a relevant requirements package. A very important skill of a BA is to be able to analyze the problem and design a solution process.