2011: The Year of Professional Development

I decided this year that 2011 was the year of some professional development. Well, I decided at the end of last year and opted to renew my lapsed student BCS membership for 2011.

Having studied on a BCS approved degree in Manchester, I knew about the BCS’s work and acknowledged them as a group how act as a common forum for both academia and industry. It is the professional qualifications that I was particularly interested in, many in the areas of Business Analysis and Business Systems Development.

I liked the BCS’s definition of CPD, that focused on maintaining competencies:

Continuing Professional Development (CPD) is the organised continuation, improvement and broadening of knowledge, understanding and skills, as well as development of personal qualities necessary for an individual to maintain their competence in order to undertake their duties throughout their working life.

On graduation in 2009 I though I was set, that I had everything that I needed and knew all I needed to know for my career. I’ve since learnt that what I studied was both excellent and dated in equal measure. Some of the tools I studied are no longer in common use and others are no good unless adopted by the whole organisation. In short, it was time to do some more learning.

I hope that there will be some more posts to come on the topic of CPD this year as I look to keep the blog updated with lectures, courses and conferences I attend.

I’m also keen to get along to some of the BCS Manchester events this year. The weekly email I get from the branch is always packed full with some great events and opportunities to get along and meet more like minded professionals. No doubt more posts will follow on this.

Using The Right Tool For The Job

As a business analyst it’s important to know when to use the right tool for the right job. Although there is a wide range of tools available out there, some differ based on the methodology being employed, but often the end goal is the same. To assist in capturing valuable information and ensuring that it’s well communicated to all involved parties.

As I have mentioned in an earlier post, my background is in traditional waterfall projects. The tools of my trade were the lengthy functional specification documents, developed over time thanks to stakeholder interviews, document analysis and observation sessions. While these documents severed their purposes for the projects I was working on at the time, I have come to learn that they are not always the best tool for the job.

I have been faced recently with a number of scenarios where a long functional specification document is not beneficial and does not help to move the project on at all. Some examples of this include when:

Your client is not your end user

This is quite new to me but the firm I work for are often used as an outsourced technical partner. As a result the brief I get is often third hand and the answers I get during interviews are not accurate.Watch Full Movie Online Streaming Online and Download

Your client doesn’t realise the implications of changes

This can often happen for a number of reasons. In my experience it’s because either the project team have not helped set realistic expectations for the project, thus not limiting the scope. Another reason may be that the client is very technically unaware of software projects.

Your client does not know what they want

This is the client that says. “I’ll know what I want when I see it”. We’ve all worked with these sorts of clients, some are great because they allow you to be creative and innovative, and others can be just unrealistic.

The question is, how do you know which tools to use when projects and clients are so different? This will of course be a decision you make based on a number of factors, some of the things I think about at this stage are:

  • Is the PM on the project a good one and will they be concentrating their time on this project or will they be tied up with others?
  • Is there a fixed delivery date? What are the implications of missing it?
  • Am I going to get access to some stakeholders or just a 3rd party?
  • Have I done a similar project to this before? Do I know the domain?

The way that you are able to answer these may affect the tools you chose to use. For some projects it will be obvious which toolset you use, for others it may be a little trickier. In these cases I like to sit with the client and explain the possible approaches and the pros and cons for each. Offering a client the option between a formal document heavy process and an open collaborative process with lots of workshops could be the difference between having a nightmare client and having a champion within the clients organisation who believes in your team and the work you produce.

At the end of the day a BA’s role is to get alongside their clients, elicit requirements and communicate them in the most effective way possible. As long as you’re able to do this, it’s not really relevant the tools you used to do it.

Good Reasons Not to Follow the Process

This made me smile. We’re starting some new agile projects this week and there has been a lot of interest from people not on the project team. Most of this interest seems to be based on the belief that we’re throwing the rule book out and becoming ‘a bit relaxed’ with our development process. I don’t believe that’s the case but this comic strip sums it up pretty well!

Source: ModernAnalyst.com

Definition: Business Analyst

I thought I’d do some simple posts that just outline what I mean by certain terminologies. Some terminologies can get a little vague as we start to cross methodologies. The first on my list is

Business Analyst


A person who analyses the operations of a department in order to develop a solution to its problems.

I really like this definition. I’m sure there are those who will hit me over the head with definitions from the BCS or the IIBA, however I think its pretty good. I like it because firstly, its simple. Simple to understand amd simple to explain. I also like it because it doesn’t mention technology.

There are obviously variations on the BA role:

  • Systems Analysts
  • Process Analysts
  • etc..

While I have been known to undertake elements of these in my work, I’m proud to say I’m a Business Analyst.

Engaging A Business Analyst: For Web Projects

Recently I was asked to help define some guidelines to help my team engage a Business Analyst. Initially I was quite surprised, but then I realised what a great opportunity it was to highlight some of the many areas of a project a Business Analyst can engage with and what benefits they can bring.

Before I go into, what to many will seem obvious, it’s probably important for me to give overview of the team that I work with, its size and its culture. I’ve recently joined a team who is making the slow but sure steps from being just another web development agency to being a software house. Although they still make websites, there is a real shift towards bespoke web applications and information systems. It’s a really exciting opportunity, yet slightly daunting as many of the team have never worked with a full-time BA.

Capturing or eliciting requirements can be done by anyone, and when the projects aren’t complicated there is little that can go wrong. It’s only as the scale of the projects increase, the budgets grow and with it the clients expectation, that it becomes clear that things have to get a little more formal.

The following is a very rough guide to how a BA could be engaged throughout the life cycle of a traditional software project. While I’d like to formalise it, I’ve come to realise that every project is different and every project will require different tools.


At the Project Initiation process it’s the responsibility of the Business Analyst to cover the high level scope and objectives of the project and establish communication channels.

  • Help to write PID docs
  • Help to determine technologies used

Understanding the business processes for a section of an organisation or for the whole of the organisation.

  • On site visits
  • Investigations & Interviews

Clear Understanding and communication of Requirements is a very important aspect of a Business Analyst role as it ensures that there is minimum gap between the expectations of the end users and the final deliverable from the technical team.

  • Writing spec documents
  • Meetings & Interviews

During Development

Regular interactions by the Business Analyst with the developers and the technical leads is essential as the knowledge transfer of the user expectations should be ongoing.

  • Continual interaction and collaboration

Functional Testing during the testing phase to ensure that features and functions behave as per the users original requirements.

  • Writing test plans
  • Write automated test suites


After the implementation of the software system, the business analyst also may need to handle the change management process if there are any new requirements or changes proposed.

  • Training sessions
  • User Documentation

This is not an exhaustitive list of possible activities that could be undertaken throughout the life of a project, nor should it be seen as limiting. It’s merely a guide to developers and project managers who have not had the opportunity to work directly with BA’s on projects before, to help understand how you should engage your BA.

Launch: JamieClouting.co.uk

Its been a while in the making but it’s finally here! If you’re reading this then you’ve stumbled across my blog.

This is my personal blog about Business Analysis. It’s my intention to write about things that I find useful in my day to day job as BA, tools, books and methods. I’ll probably also aim to comment on some of the things I experience along the way.

Please have a look about and let me know what you think.