To Certify or not to Certify that is the question

Seems that there are definitely two camps on the topic of whether Business Analysts should (or need) obtain a professional certification.

I've have been involved in a few discussions via LinkedIn regarding this very topic - The Real Truth: Why you need a CCBA or CBAP Certification.

One camp thinks that there is no requirement for a certification, as no job descriptions ask for this, and that they are only promoted by those who offer study courses, training, the certification itself, or those who HAVE achieved the certification and want to justify the time and money they have put into this by pushing it as a requirement.

The other camp, sees the certifications as a way of demonstrating your knowledge and skills in the arena of Business Analysis.  It shows your committed to the role, have the necessary skills and (where recertification is required) keep up with the latest information.

I am sure the debate will rage on for a number of years, but from my point of view I WILL be attempting to gain an accreditation in the next year or two.  My thinking behind this is:

• I need an end goal to work to, to have a measurable outcome - SMART objective
• It will force me to cover all areas, not just the ones I am interested in or will aid my current role
• At the end I will have something quantifiable to show to my current and future employers
• If its the ISEB course I will engage with other BAs
• If its the IIBA CCBA/CBAP I can network within the IIBA

This leads me on to my remaining decision; British Computer Society ISEB diploma or IIBA CCBA/CBAP?

I'll update you on my decision when I have made it!

Project Failure Reasons - Any look familiar?

The Chaos Report is the first survey made by the Standish Group. This report is the landmark study of IT project failure. It is cited by everybody writing a paper or making a presentation were a reference is made of IT project failure.


It includes large, medium, and small companies across major industry segments : banking, securities, manufacturing, retail, wholesale, heath care, insurance, services, and local, state, and federal organizations. The total sample size was 365 respondents  representing 8,380 applications.

It is also hotly contested and disputed (as brief Google search will verify) – so do not accept this data as utterly without question true.

However, I bet a few of these ring true with most people involved in project work!


References:
http://www.smart-ba.com/download/Bite%20Sized%20Training/01%20Scope%20of%20the%20BA%20Role.ppt
http://www.it-cortex.com/Stat_Failure_Cause.htm#The%20Bull%20Survey%20(1998)

Smart-BA

As this blog is really a repository of information for myself and other BAs, I MUST post a link to the Smart-BA website.

"This is a site for giving away as much free stuff as possible for business analysts - things like manuals for passing BA exams, training materials, articles, templates, tips for tuning up a BA's cv and anything else that could be useful for a business analyst in the real world doing real business analysis."

I can see me reviewing a lot of this site and the related Blog

Personal Development

I have now completed 9 modules on Business Analysis via the Skillsoft online learning system.

GO ME!

It has got me thinking about whether or not I should go for official accreditation.  Don't really need it in my current role, no REAL benefit in gaining the accreditation but still it would prove that I have learnt the tools of the trade.

Then there is the question of which one: ISEB, CCBA or CBAP?

Not sure if I have the hours under my belt for the CBAP.  CCBA is in its infancy.  So that leaves ISEB.

I think I will need to weigh up the cost verses the benefits.  Something to look at next year.

Not very good at maintaining this am I?

Been a while since I posted here... oops!

Maybe I just haven't had anything to say.
Maybe I have just been tooooooo busy.
Maybe I only have confidential information.

Either way, it's almost the end of the year so let's sum up:

Two Thousand and Eleven (2011) was the year I stepped out of my comforting IT Development environment and into the unknown.  Ok, so it wasn't so unknown it was the same company, BUT, it was in a different arena (International Payroll), I had a new boss, my new boss was located some 4,000miles away in the States along with the development team (original development team).

Even though I was a Business Analyst within the Development department previously, I seen this move as a chance to focus on being a Business Analyst and not be drawn back into development duties. 

Well that didn't work!

Changes in priorities meant the development was now going to be run out of the UK... by my old team!  So, I was drawn back into development somewhat, with the Proof of Concept work.

Then came changes to the structure, resulting in my reporting line changing and priorities changing.

In all of that I have had a productive year, but I look forward to a more focussed year ahead, in terms of the project, my personal development and learning.

All in a days (well years) work for a Business Analyst.

Roll on 2012.

Nothing is certain but death and taxes (and changes to requirements)

The saying, 'there is nothing certain in life but death and taxes' has been used and modified over the years. 

So one more modification won't hurt... let's add on "change".  Change is inevitable.  I covered this slightly before in Requirements - The Moving Target  - "the only constant when it comes to business requirements analysis is that things keep changing"

In Adriana Beal's latest blog We are all part of the conversation, from inception to design and beyond, she mentions "No matter how good you are at identifying and documenting requirements, there will always be something left unsaid that may have a huge impact in project success."
 
One adaptation of the Death and Taxes phrase comes from 'Gone with the Wind', "Death, taxes and childbirth! There's never any convenient time for any of them"... so let's add "change" to that too!  Is there ever a convenient time for change?

Anyone else hearing the word Agile running through their heads?

Documentation OR Agile

God, it's been ages since I last posted on here!!!  Working away hard, nothing really new to post relating to this Blog.

Until today...

Project/Development methodologies can be a difficult subject; Traditional Waterfall, Agile or company specific.  You really need to know what the preferred method is, so you know what the project deliverables are (if any)!

I have been reading a few articles today to refresh myself on pros and cons, reasons for using and general updates on different methods.  The following article in the BA Times has caught my attention and I felt it was worthy of linking to.

BA Times - Business Analysis: Is it a Bottleneck in your project?

I think the title is a bit miss leading, but the article is very helpful.  Key paragraph to me (in my present project) is:

"I have seen a project work where multiple BA resources worked on the requirements and specialised in particular areas. The requirements were not completely detailed up front but the business vision was, and high level requirements were documented to a level that allowed estimation to be performed. Then as each iterative development phase started on each business area the BA responsible would verbally present his or her concept to the development team in detail, with mock screen shots or story boards, models of the process, and associated business rules. Allowing the developers and testers to see the complete picture as well as the detail is important and allowing them to ask questions and seek clarification on issues instantly speeds up the process of transferring information. If anything does change then an efficient and quick change management process is very important."

It sums up nicely what I am doing at the moment.  I have produced a high level BRD (for want of a better title - possibly a simple Requirements List is closer), I know what is required from the solution and I am awaiting a decision on methodology to be used going forward by development.  I know the methods that have been used by Dev in the past - having worked in the department for 3 years - but there has been talk of a more Agile approach being introduced. 

With high level requirements already in place, I can easily go down whichever path I need to, be it Software Requirements Specifications, Product Backlogs or, as per the article, present to the developers.

So what we want is a way of speeding up the requirements process without losing any of the detail or the communication to stakeholders that allows them to confirm the requirement and therefore deliverables are correct.

...

So in my experience a middle ground is important. We need to capture the business's vision in a document because it will be referenced a lot and it is an important we capture it in detail and clarity.

At the end of the day, we will be working towards a solution!  The path to the solution is important but not as important as the information being conveyed.