Change, scope creep, expectations etc can be managed while a project is in-flight by implementing good process.   A problem with poor requirements however is different.  There are always ways to improve how requirements are elicited and how they are written, others have mentioned this and I’ve talked about how to do this on my blog, but if you inherit poor requirements on an in-flight project, you options are limited and the impact is potentially catastrophic.

You face three big issues when you inherit poor requirements on a project:

1. The business has already invested the time in creating the requirements that currently exist.  You won’t get that sort of quality time with them again; in truth they thought the analysis phase was a waste of time anyway.

2. You risk alienating both the development teams and the business if you start raising the number of change requests that are actually required to fix situations like this.

3. A strange sense of inertia will descend upon the team when you start pointing out how deficient the requirements are.  It’s amazing how many people would rather deliver rubbish than what the business actually need.

So, faced with inertia, disgruntled stakeholders and a skeptical business, what is a conscientious Business Analyst to do?  Let’s face it, at this stage the odds are stacked against you and you should probably be looking for a new project anyway, but if you fancy a challenge, you could try turning to an old friend, the test team.

Yes testers.  This might seem a bit strange when you consider that in a traditional waterfall diagram, testing comes somewhere at the end of the development cycle especially being that the longer a bug goes identified the more expensive it is to fix.  Don’t forget though that testers test requirements, not code.

This gives you license to let the testers loose on the requirements that do exist and challenge them to come up with suitable test cases.  Once this happens, things are going to get very painful for everyone, but you will have found yourself a very potent ally.

A developer won’t be so keen on moving forwards with coding once he or she has a sense that their code will never get out of FAT testing.  Likewise the business should be in test case review meetings and be faced with a barrage of questions, that will, hopefully, open up doubts in their mind that this requirements phase is as closed as they initially thought it was.

Like I said, it’s going to be a painful process, no one is going to be happy, but this is your last chance to salvage something from the project.  I’ve only been in this position once myself and it will take all of your skills just to deal with the political fall out from this approach.

How did it work out for me?  We de-scoped a lot of work and concentrated on what little we could safely say was required.  While this was a success, it also resulted in timelines being slashed to allow the start of the new development cycle to begin, only this time with proper requirements.  Definitely a victory, but a very painful one.

I’d be very interested in hearing how other Business Analysts have dealt with this challenge?

If you’re interested in seeing more articles related to the role of a Business Analyst, then why not subscribe via the RSS feed.

This article originally appeared as a comment on Linkedin in the IIBA discussion group.

“Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information on it” – Samuel Johnson

Happy 2010! It’s my first post of 2010 and I’d like to use it to address the question of what it takes to be a Business Analyst and what skills should you expect a BA to exhibit?

This is a question that I imagine vexes employers, particularly those, that understand what a BA does and now want to employ one of the best. The question is also relevant for those looking to pursue a career as a BA.

Below I’ve compiled a list of the 5 key skills that I look for in a Business Analyst, I’m sure the list is not exhaustive and that you can add to the list, in fact, feel free to leave your suggestions below.

1. Technical Knowledge

While the first priority of any BA should always be the business and their requirements, a BA still needs technical knowledge.

Most BAs have a technical background, I started out coding in VBA and SQL. I was never very good at either of them and was always far more interested in the planning and analysis phases of any project, rather than the actual coding itself.

As useless as I was at actually coding, the exposure to different types of technologies has allowed me to a much better Business Analyst, primarily because of how that knowledge allows me to interact with two of the key stakeholders in any project; the technical teams and the business.

Knowledge of relevant technologies allows a BA to have informed discussions with the technical teams. A BA may not understand the ins and outs of Java, for instance, and probably can’t even code in it, but they should understand the principles of development, be able to relate to issues faced by a development team and their knowledge of technology should allow them translate that knowledge into a language that will be understandable by the business.

This ability allows a BA to build trust with the business. Often the technicalities of a project will be confusing and complex for the business, a BA that can be the bridge between the technical and business worlds and can explain technology to the business in language that the business can understand will give the business confidence both in the development process and the BA.

Technology should never be the main focus of a Business Analyst, but they should understand enough that they can build trust, understanding and vital relationships with both IT and the business.

2. Thirst for Knowledge

A BA has to have a thirst for knowledge. At every stage during a project people are going to bring questions to the BAs door, be it the business, development, testing, project mangers or any one of a number of stakeholders. Not only will people bring the BA these questions, they’ll expect them to have answers as well.

Right from the start of a project, a BA has to be a detective, think of all the questions have to be resolved:

- What’s the problem?
- Why is it a problem?
- How will fixing the problem help?
- Is this the most important problem to fix? Why?
- What’s the solution?
- Why will the solution be a success?

There is a lot of pressure in any project to answer these questions, and many others, immediately and the BA has to be up to the challenge. The best BAs will feel exposed if they can’t answer a question, they have to understand, they need to know, it’s something biological in them.

This need that BAs have to understand and to learn leads to massive benefits for projects. For instance a BA that has taken the time to understand, not just the businesses’ requirements, but also the context in which the requirements exist, will be able to talk authoritatively about the business in discussions with technical teams, helping them to understand the background to a project and the importance of what they are doing to the business.

Likewise, a BA that has taken the time to understand why technical solutions were chosen or how technical issues will impact a project, can save a massive amount of hours when explaining these issues to the business as they won’t need to have technical teams attend crisis meetings, allowing them to concentrate on actually fixing the issues rather than discussing them.

This thirst for knowledge and the need that BAs have to understand, is the main reason why I believe that domain knowledge should not necessarily be a prerequisite for a BA when starting a new project.

3. People Person

A BA has to be interested in people, they spend all of their working lives surrounded by them, immersed in their issues, their problems and their needs. The role of the Business Analyst involves documenting their requirements and designing systems that address and alleviate their problems. Without a degree of empathy for and interest in people, it does not seem possible that a BA would be able to do any of these things effectively.

Additionally, the Business Analyst is often the face of change on a project, which is possibly one of scariest things that any of us experience, either in life or in our careers. Change is always frightening to someone. People are always afraid of the unknown, yet it’s the very currency in which a BA trades. It’s therefore important that people trust and like the Business Analyst that they are working with. Change may well be scary, but it’s inevitable, when it’s introduced by someone we like, respect and trust, it becomes easier to accept.

4. Creative

BAs appear to be a very conservative bunch, wearing suits, working for very serious organisations, such as banks and spending most of their days documenting something or other, they don’t at first glance strike you as being very creative. Many believe that it’s the long haired, jeans wearing, young people from the development teams that are the creative types. I don’t want to detract from what they do, but they’re not the only creatives on a development project.

More often than not, despite the conservative image, it’s the BA that will throw out the template in an attempt to present information relevant to a stakeholder in an effective manner. When a project is at a road block, with two or more stakeholders unable to agree on the best way forward, it’s the BA that will put them in a room, propose different ways of working and get their brains working to resolve the issue.

And given the fact that a BA is neither technical nor the business, it’s the BA that has the freedom from the expectation that they are the expert, allowing the BA to claim ignorance and ask the so called “stupid questions”, the seemingly obvious questions, like “Why do you do that?” that once asked, demonstrate a lack of understanding amongst the experts and open up avenues in peoples brains that allows them to re-frame problems and to look at things in different ways.

5. Communicator

A BA must be able to communicate and be clearly understood by their audience. As BAs we derive an awful lot of knowledge on any given project. None of it is worth anything though if it’s not accurately communicated to the people that need the information to complete the project.

A more fundamental communication skill for a BA than simply being able to convey information accurately to others is their ability to listen. Listening is often the most under estimated of all the skills involved in communicating, however, for a BA it’s the most important.

Before a BA can communicate accurately with people, they must first have listened to and understood other stakeholders. A BA cannot explain a requirement to a developer unless they were able to listen to the business convey that requirement in the first place.

A BA should never be afraid to just go quiet in a meeting and listen, it’s surprising what you’ll hear that no one else did.

Well, those are my thoughts on what it takes to make a great Business Analyst, I hope this helps you either in choosing to be become a BA or indeed in choosing your next BA. If you have your own ideas as to what it takes to be an excellent BA, then please feel free to let me know by leaving a comment below.

If you’re interested in seeing more articles related to the role of a Business Analyst, then why not subscribe via the RSS feed.

Since then I’ve relayed this story many times, only to discover that it wasn’t just my erstwhile interviewer that was unsure of what a Business Analyst actually does. Very often it’s not until a BA has delivered on a piece of work that the business that they are working for appreciates exactly what it was that the BA did for them, even then I suspect they would find it difficult to define exactly what it was that the BA did.

In a cold economic climate when IT budgets are being cut, it’s important that BAs answer the question of what we actually do, after all, our livelihoods depend on it! While our documentation skills and communication style will prove invaluable during the development phase of a project, when fingers are being pointed and vendors are demanding more cash, this will be no good to us if we haven’t won the business in the first place.

We have a very positive story to tell about what we do, but what exactly is it that we do?

Other IT professions don’t suffer from this sort of ambiguity, a project manager, for instance, has several very clear definitions of what they do, my favourite being:

A project manager has overall responsibility for the planning and successful execution of a project.

That’s it, it’s to the point and everyone knows exactly what to expect from a Project Manager and how they are going to benefit a project. On the other hand, we have the definition as stated by the International Institute of Business Analysis (The IIBA®) in version 2 of it’s Business Analyst Body of Knowledge®:

Business Analysts must analyze and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The Business Analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. In many cases, the Business Analyst will also work to facilitate communication between organizational units. In particular, Business Analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a “translator” between those groups.

It does describe what we do, but it’s not quite as easy to digest as the definition of a Project Manager and you can see why there may be confusion about what the role actually entails. I can hear the business now, ‘Where is the value add?’. It’s a fair question, how does analysing and synthesizing all this information actually help an organisation to meet it’s goals?

To try to understand more about what Business Analyst actually does, I want to look at each phase of a typical project and examine what is required of a Business Analyst during the life cycle of a typical project:

Initiation

The initiation phase is the period during which the business is feeling some kind of pain and is looking to alleviate the stress that this pain is causing, usually by implementing some form of technology or process based solution.

It’s the role of the BA to clearly identify the problem that the business is experiencing and to map out what a possible solution would look like.

This map is then used to create a business case which shows why a problem is being tackled, how much it will cost to resolve the problem and what benefits the organisation can expect to see once the problem has been resolved.

It is the business case which a Business Analyst will constantly refer back to as the need for changes occur during the course of a project, constantly checking to ensure that a change is in-line with the expected business benefits and to ensure that the business case is still relevant and that something still needs to be change within the organisation.

Analysis

The analysis phase is the period during which the Business Analyst defines the requirements in detail, stating clearly and unambiguously what the business needs in order to resolve it’s problem.

During this phase the BA will also work with the development team and in particular an Architect to create the design and define exactly what the solution should look like.

Taken together the design and the requirements will guide the rest of the project, with the testers looking to ensure that the requirements have been met and the developers trying to deliver against the design. It’s the responsibility of the BA to ensure that the design meets the requirements and that the testers are testing the requirements.

During this early phase of the project the BA will expend a lot of energy ensuring that any possible changes that can be identified are identified, while they are easily, and often more importantly, inexpensively corrected. Once the initial requirements are documented they need to be tested to destruction by the BA to ensure that they will actually deliver a solution to the problems that the business are facing.

Development

The development phase is possibly the most challenging phase for a BA. It’s quite normal after the pressure of the analysis phase to sit back a little, safe in the knowledge that both quality requirements and design have been delivered. However, it’s during this phase that a BA needs to step up their meetings with the development team, attending daily meetings and generally being the eyes and ears of the business, constantly looking for deviations in course that would otherwise go undetected.

Testing

The testing phase sees the Business Analyst back on firmer footing. There is a process to follow as the testing team go through the process of testing and identifying bugs and the BA can work with the business to set defect fix priorities.

Disputes between the business and development concerning what is and what is not an off spec defect will often be resolved by the BA using documentation created in earlier phases. The mere existence of this documentation is often enough for one side of the other to admit a mistake and for the issue to be resolved amicably.

Implementation

The implementation phase is not the end for the Business Analyst. It’s the last chance for things to go awry and for goals to be missed.

It’s during this phase that a BA should be conscious of how users are using the system. Are they actually seeing the benefits envisaged in the business case? Do the training materials even support the business case?

Looking at each of these phases in this way, a common theme of discovery, validation and verification appears throughout a project life cycle. Given the opportunity to answer the question again, I would define the role of a Business Analyst using the following statement which clearly shows what a Business Analyst adds to a project, a business or an organisation:

A Business Analyst is responsible for knowing what the goal of a project is, how to achieve it, managing any changes to the goal and ensuring that all deliverables are aligned with the goal.

In essence, a Business Analyst is a navigator, responsible for reaching the end destination, in our case that destination is the successful resolution of a business problem. The BA always knows what the end destination is, how to get there and is capable of handling course adjustments as they arise.

In the future, when pitching for work, I’ll be better prepared to answer the question and will have a great story to tell.

I hope you found this article useful. If you have a definition of what a BA does, then please feel free to let me know by leaving a comment below. If you’re interested in seeing more articles related to the role of a Business Analyst, then why not subscribe via the RSS feed.