Search This Blog


21 March 2008

More on Solution Assessment and Validation (A post script to the Carnival of Business Analysts #7)

I felt that the last edition of the Carnival of Business Analysts missed the mark a little. Here is some extra information I want to add to the Carnival of Business Analysts #7: Solution Assessment and Validation.

For a start you can get to the IIBA’s BABOK from here. Chapter 7 addresses Solution assessment and validation. Read the chapter sub-headings and you’ll see topics such as Developing alternate solutions, evaluating technology solutions, useability, quality assurance, and implementation.

Having read a draft of the Enterprise Analysis chapter of v2.0 I think some of this content may move into the EA chapter, but we aren’t there yet so we’ll take a quick look at them all here.

Developing alternate solutions
When coming up with a solution you should typically look at more than one approach.

Many projects come up with the deluxe, budget and middle road proposals to contrast the strengths and weaknesses of different approaches, but there are more options available to you also; for example build, buy or buy and customise. Another dimension is do you enhance the existing infrastructure or do you build on a new platform? See some case studies on this topic at Chief Architect.)

There are many ways of approaching solutions and each one of them will address the project goals to varying degrees and have particular impacts on the organisation. Your jobs as the project BA is to assess these solution in terms of how well they’ll meet the business requirements. One tool you may use is a requirements traceability matrix. Another is validation by business stakeholders, for example by demoing a prototype. And there are more including Alpha Testing, Field Testing and Market testing.

Evaluating technology
A Traditional and process heavy approach to selecting and developing a solution idea goes like this;

That represents a traditional waterfall approach. In these modern freewheeling times, solutions may not follow this process, stages may overlap, or the process may be fast tracked, bundling two or more phases together. Anything goes these days. Regardless of the development approach each stage that is applied needs to be assessed and validated.

Is this solution the best one for the business? Does it find the right balance between cost, time and quality? Does it align to strategy and standards? Does it address the project goals? You are the judge.

Personally I am no expert but I know what I like.

I have some views that are supported by others including that UI for applications used by back-office people don’t need special attention; they get paid to come to work and will learn the system regardless of the UI. Of course there are some issues with training and ramping up to expert users, but these are more relevant to the tools presented to sales staff and customers.

Other people disagree with this view, so you'll need to form your own opinion.

Another thing I think is that you should do some sort of task analysis to work out how to lay out features in relation to each other, but there is a whole world of UI stuff out there and I say go and explore that if it’s your thing.

One thing we all agree is that you can’t leave user interfaces, and especially design to programmers. At least not usually: but there are always exceptions.

Quality Assurance
The QA work that a BA may undertake, or participate in, includes developing a test strategy, a test plan, and test cases. A BA may also procure and manage users for UAT, or participate in it themselves. During this phase a BA may have to find workaround for system shortcomings and communicate what’s going on to various stakeholders.

Of course one of the main things with testing is that the test cases are mapped back to the requirements statements, and for testing to be easy he requirements have to be written in a way that they are testable. Requirements statements like “The UI must be easy to use” don’t make for easy test cases. What does easy to use mean? Instead try for statements that can be tested; e.g. “The UI will be brand compliant.”

Another thing to remember is that BA's are not professional testers, and as such we can learn from others. Don't just jump in. Prepare yourself.

There are two aspects to implementation; the physical deployment of new systems to IT infrastructure and the deployment of new processes, rules and behaviours to the business environment. Depending on the role of the BA they may be arranging or participating in on, the other, or both.

Some techniques to help you through the business side stage of the project include Business transition plans, a review of your stakeholder impact matrix, change management plans, and changes to business process, policy and rules.
Change management is a big topic and could easiliy be expanded into another post, or even series of posts. Or even a blog of it's own.

(I’ll keep adding links to each topic for a few days. Put up a link in the comments if you know a good one.)