"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
Friday, 23 December 2011
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.
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.
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.
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.
Monday, 22 August 2011
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?
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?
Tuesday, 19 July 2011
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:
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.
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.
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.
Saturday, 23 April 2011
Taz is ready for the Yorkhill Easter Egg Run
As you can see Taz is all ready for tomorrow charity event, the Yorkhill Easter Egg Run
The Yorkhill Easter Egg Motorbike Run has been a tradition in Glasgow for over ten years, and to many bikers, is the unofficial start of the biking season. Thousands of motorbikes, trikes and quads gather every Easter Sunday to take part in a huge procession through the west end of Glasgow, culminating at Yorkhill Hospital, where they drop off Easter Eggs and donations for the sick children.
Every year thousands of bikers ride to Yorkhill Childrens Hospital, in Glasgow, on all manner of bikes (some wearing fancy dress costumes) taking Easter Eggs and Donations for the Children in the hospital. Started in 1988 with just 200 motorcycles, the event now attracts bikers from all over the UK and upwards of 9,000 bikes (in 2009). This year there is a restriction to only 3,000 bikes (officially) attending due to policing and health and safety reasons.
This year, on 24th April, I will be riding along with a friend for Mobile Motorcycle Services, one of the event sponsors, from Kelvin Way to Yorkhill where we will be greeted with music from Rock Radio DJs and Radio Lollipop.
With Yorkhill Children's Foundation celebrating its tenth anniversary, the aim is to top £30,000 in donations!
Not got a bike, but don't want to miss this spectacular event? Why line the streets along the new route for 2011. The old traditional start point of Kelvin Way being resurrected, followed by a 6.5 mile run will wind through the west end of Glasgow, up Great Western Road and down Crow Road towards Yorkhill Hospital. Route map: http://www.independentphoto.co.uk/yeer/2011%20route.pdf
Tuesday, 22 March 2011
Use Cases and User Stories
I have been reading a number of articles on the comparison between User Cases and User Stories
The conclusions I have came to are as follows:
From the Business Users perspective:
The conclusions I have came to are as follows:
- User stories explain the need
- Use cases explain the behaviours involved
From the Business Users perspective:
- Without prior knowledge Use Cases are difficult to understand, and can be seen as too 'techie'.
- User Stories are easy to read, write and understand.
- User Stories do not give enough detail on what the system needs to do and how it should behave.
- Use Cases provide more information about the interactions, prerequisites, outcomes etc.
Subscribe to:
Posts (Atom)