31 July 2007

A Carnival of Business Analysts #1

Welcome to the July 31, 2007 and first edition of the Carnival of Business Analysts.

I have decided to present this issue around conversations on the role of a business analyst, and what the role is about. The posts also include a couple of examples of what a BA is not. Read on, and I hope you find this series of articles useful.

The role of the Business Analyst

CraigBrown presents What "Architecture" Is Notposted at Technology Architecture & Projects, saying, "Robert McIlree has a post on what an Enterprise Architect is not – and his list includes the business analyst."

CraigBrown presents Who owns Business Analysts? posted at Competitive Excellence through Business Process Management, saying, "Vinayak Khadye asks "Who should own these Business Analysts - Business Functions or IT?"

CraigBrown presents Business Analyst Profit Center posted at Tyner Blain, saying, "Scott Sehlhorst writes about some of the challenges that face business analysts while they remain characterised as a cost centre."

CraigBrown presents Defining the BA Role posted at BA Insight, saying, "An article by Kevin Brennan of the IIBA commenting on the BABOK’s definition of a business analyst."

CraigBrown presents Business Analyst Job Description posted at Jonathan Babock, saying, "Jonathan Babcock addresses the question “What is a business analyst” in a post about BA job descriptions."

CraigBrown presents What is a Business Analyst? posted at Portrait of a Business Analyst, saying, "Rajeev Singh has written his view of what a business analyst is."

CraigBrown presents Business Analyst Definition posted at Marios Alexandrou, saying, "Marios Alexandrou provides a definition of a business analyst at his site. His site also has an example BA job description if you are interested in digging deeper"

CraigBrown presents The BA Career – A Multi Faceted Opportunity accidental business analyst posted at The accidental business analyst, saying, "Opinions about the opportunities a career as a BA presents"

CraigBrown presents How to Plan a Career posted at Software Project Management, saying, "Some insight into career planning from a while ago. While not specifically on the analyst role, it does address the need to plan your career."

CraigBrown presents A framework for defining competencies for business systems analysts posted at Modern Analyst, saying, "A managers view of the skill and competencies you need to be a BA from a manager’s point of view"

CraigBrown presents “So, you want to be a BA?” posted at B2B Training, saying, "A blog post on getting your first BA role, called “So, you want to be a BA?”

-New-

Scott Sehlhorst introduced me to an article at RQNG on the topic of What is a Business Analyst with some solid tips on how to present to a recruiter. If you are in the market, take a look at this article. You might also want to read the discussion thread attached.

That concludes this edition. Submit your blog article to the next edition of the Carnival of business analysts using our carnival submission form.

Next month the theme will be: The Business Analyst and Quality.

Past posts and future hosts can be found on our blog carnival index page.

*********
As you can see, most - well, okay, all - of these posts are presented by me from blogs that I regularly read.

It turned out that most of the contributors were people promoting home based business, or using their financial modelling tool for your investment plan. Just more examples of people not reading the guidelines (and learning the requirements.)

I’ll host another Carnival of Business Analysts at the last weekend of August, and I have also propose a theme to help you bloggers pick an old post to dust off.


,

29 July 2007

Cost saving calculator

Cutting costs? Running a Six Sigma project?

I put together a calculator to help work out the value of process improvements based upon average handle time, transaction volumes and FTE (full time employee) costs.

You can enter the before and after values and see the forecast value of your process improvement project.

How to use it
The grey "Resource Costs" box shows the cost per minute/annum of work time. It is derived from a number of factors which can be changed depending on the workforce.

The Blue"As Is" box calculates the current cost of transactions based upon the established cost per work time, the number of transactions and the average handle time (AHT.) It also shows whether there are sufficient FTE allocated to the work.

The Green"Savings Calculator" box assesses the value of process improvement initiatives by capturing the aggregate value of improvements to handle time and volume of work.

If you do have a look at this tool and even use it I would appreciate feedback on whether you found value in it and whether you had any troubles using it.

Modern Analyst; a community for business analysts


Want to read more about the role and skills of business analysts? Visit Modern Analyst where Adrian Marchis has put together a community site of blogs, articles and other resources.

(You may have noticed Modern Analyst is in my RSS feeds at the bottom of this page. )


The Product Design Era

This picture is from Lost Garden. There is a whole dinner party story that goes with this picture which is quite entertaining. It’s well worth a read.

It’s a story of how the user interface specialist helps customers adopt and use software products, and happily. Read the story and you see how the UA specialist could easiliy be swapped for the business analyst.

I found this article courtesy of Scott’s Nexus site. And I present it mainly because I like the graphic.

28 July 2007

What skills do business analysts need?

I surveyed about 100 job postings for business analysts in Australia, the US and UK and came up with this spread of requirements posted.
I have aggregated some things and where jobs asked for technical skills such as oracle, SAP, dot.net and so on I have listed it under "understanding the technical domain." All of these advertisements were under the title of "business analyst" and not systems analyst, analyst/programmer or anything else.

I provide this graph for your information in case you are thinking of applying for a job as a business analyst.

The resulst align with many writers on the topic of what is a business analyst - the focus is on communications, consulting and requirements management. It also highlights the common idea that a BA should have some sort of technical background, often that they have pogramming or DBA skills.

Any comments?

24 July 2007

A carnival of business analysts - call for submissions

Hi readers,

This is a call out for submissions for the


I hope to publish next week, so if you have any articles to offer please do so via this link this week.

Thanks
Craig

Triple Bottom Lining your business case

Most business cases are simply a matter of cost and new revenue. Corporations apply Net Present Value to discount cash over the product lifecycle. Smaller businesses need a quick payback and so have less need for NPV.

Project business cases may also consider other aspects of business strategy including growth through new markets, taking customers from competitors or defending their position in the marketplace. Some projects are justified through regulatory compliance.

It is also feasible to factor the benefits projects can bring to the triple bottom line.

The triple bottom line is about incorporating the social responsibility aspects to accounting; people, planet and profitability. I guess the idea is that it is often hard to capture the true lifecycle costs of projects and of business itself but there are legitimate costs (and benefits) that can be assessed and measured: Sure we can dump that nuclear waste now, but what will it cost (us, tax payers, somebody else?) to clean it up in 30, 50 or 100 years?

So next time you are writing up a business case, you might want to consider the social costs and benefits of your project.

If you want to read more about the triple bottom line and how it can be applied to financial estimating you can read the Australian Governement's guidelines here . There are also UN and various other government policies and guielines out there.



22 July 2007

Project Sociology

Bas is back with a new video promoting his book.

It's as entertaining as the first series. Take a look;


Project Sociology, Part 1




Project Sociology, Part 2







20 July 2007

BusinessAnalystWorld: Symposium Series

BusinessAnalystWorld: Symposium Series is a new series of events design to deliver education and networking opportunities to communities of business analysts not currently being served by the current line-up of BusinessAnalystWorld events. Each event will also host two sittings of the new IIBA certification exam.

Each event is one day long featuring a keynote speaker, 6 track session presentations, a lunch and a networking reception at the end of the day. The cost is $545 for the day so I expect it's aimed at employers more than practitioners.

Download the brochure here.
  • Sydney - August 7, 2007
  • Sheraton on the Park 161 Elizabeth Street on Hyde Park, Sydney
  • Melbourne - August 8, 2007
  • Sofitel Melbourne, 25 Collins Street, Melbourne

Implementing the BA role

Alan S. Koch writes an article at Project Connections talking about introducing a BA to a workforce.

The potential problem he identifies is in role clarity. The IIBA and BABOK clarify the BA role, but what about other people who are doing these activities already?

He proposes the answer is understanding who is doing the work already and what are their feelings on handing the work over to a BA.

If you are planning to introduce BA's to your workforce or redefine the role, have a read of the article.



18 July 2007

Business Analysts are not Technicians

Projects@work has an article called Enter the Business Analyst.


It talks about how a good business analyst makes for better requirements management which mankes for better project outcomes. We all belive that, don't we?

As the article progresses the author goes to quote her case study BA in saying business analysts must have good competencies in IT;

That’s a lesson Phull took to heart more than a decade ago, when she started working with stakeholders doing business analysis. She had started out with a background in technology.

“You have to have done IT or engineering in order to be a good business analyst, because you have to understand the technical details. The best business analysts have had experience both on the business and on the technical side,” she says.

Well, I'm not so sure.

And if it's true that I.T. is on its way to commoditisation then it's definitely not true. My opinion is that an understanding of business is the key knowledge area, and technical literacy, while useful is not a critical success factor.

In fact, with good requirements management and communication skills avoiding IT or technical aspects ot a business problem may well be a strength.

17 July 2007

A carnival of business analysts


I have started to submit articles to the Carnival of Project Management at A Girl's Guide to Project Management. It's a monthly round-up of on-topic articles by various bloggers posted at the one spot.

This blog covers project management and business analysis, and so I thought I might start a Carnival of Business Analysts. I'll try to keep this going on a monthly basis.

If you are one of the many insightful bloggers on business analysis why not click through and offer up an article.

Submit an article to the Carnival of Business Analysts.

Here are some guidelines for submisions, lifted pretty muich right out of The Girl's Guide blog.
  • Be relevant to the topic of business analysis; the focus is on the type of business anlaysis associated with projects and change management, not so much on pure financial analsis
  • One post per author per edition; If you have lots of good posts you can spread them over multiple editions.
  • Add a short introduction to your article when submitting; This will appear on the carnival as the intro to your article.





16 July 2007

A Handy Heuristic

I was reading an article on problem solving and came across an idea I believe came from Charles Handy. It could well be labelled as a Handy heuristic. Especially for us project workers. It goes like this;

There are two types of problems;

When things are done wrong, and

When things are not done right.


See the difference? I'll give a McDonald's analogy (as it seems to be the flavour of the month.)

1. You order a Big Mac and the burger arrives but is overcooked and inedible. The thing was done wrong. The burger was cooked incorrectly.

2. You order a Big Mac and the staff have made a local modification that makes it the best Big Mac you have ever had. You are very happy with the burger. BUT next time your burger doesn't live up to expectations and so you are disappointed. The thing was not done right. It was cooked well, but not according to guidelines.

Project management implications
In the project context this idea has a number of implications. If you have some ideas or examples I’d be glad to hear them. Here is an example around setting scope and designing solutions.

Doing the wrong thing
An example of this is when a project team defines the wrong scope or picks the wrong solution so that the business problem is not solved.

A lot of corporate projects have made this mistake in recent years and there is more than one company out there that is full of disappointed execs and stakeholders after a series of underwhelming projects that have had budget over-runs and functions de-scoped.

Doing the thing wrong
A typical example of this type of problem is where a project is running full steam ahead, but the scope has not yet been defined. Eventually this sort of project is bound to run into trouble. Projects need to know what heir problem is before they solve it.

Another common example is when a solution is picked when requirements are not fully understood. Think about projects where the project manager is told to solve business problem X with IT system Y.


Reference: Handy C 1999 The New Alchemists, Random House, London




15 July 2007

Service oriented architecture for organisational design

SOA is a term developed for IT architecture. It's an equally valid concept for organisational architecture.

High level it's about creating a number of service oriented components that can be called upon to deliver services. It goes nicely with business process management systems.

Think of a system that takes an applications for a loan, calls out to a credit checking tool, get a result and move to the next step, calls out to a document generator and produces a letter of offer, gets a result and then proceeds to the next step. That's service orientation.

Now transfer this idea to business process design and organisational design - business architecture.

Tom Peters wrote a piece called The PSF is Everything! a few years ago calling on departments and teams everywhere to become service oriented in order to support an organisation's quest to be excellent. I recommend reading it for a bit of TP style inspiration, but also to get the idea around the importance of taking on a service oriented approach to teams and departments in order to do well at the big picture level.

The same principles apply to business as in IT: Loosely coupled, easy interface business units that provide a reliable and high quality service make for a more agile and efficient business. These feature provide for less rework, less errors and waste, and more working together as a team to face whatever monster we are up against this month/quarter/year.

Let me list out these key points for you;
  • Loosely coupled
  • Easy interface
  • High quality
When you look around at the corporations you find that most businesses don't work like this. Instead high performing individuals (often boundary spanners) are the ones that oil the machine into working.

When you are designing the future state of your organisation, what, as an analyst or change agent, can you do to improve things?

14 July 2007

Contruction video: Constructing the Merivale Bridge

The main focus of this website is on software and business process projects.

The engineering and construction industries have a lot to offer in terms of case studies and knowledge. In that spirit I present some clips on engineering project management that you might find interesting.

And the video has a retro 70's (maybe 80's) style that is interesting to watch also.

Enjoy the Construction of the Merivale Bridge (in Brisbane)

Part 1




Part 2





13 July 2007

5 challenges in delivering quality for projects

When you work on projects you are in the service industry.

For the most part you deal in intangibles. This makes it more difficult to manage people's perceptions of the quality of your work.

If you were selling used cars people would be able to assess the quality of the vehicles in the lot or on a test drive. With a project, especially an I.T. or business process project, it is difficult to know what the quality of the work being done until it is completed, and even then; sometimes not for many months.

In the past I have written about the RATER framework for managing service quality. Today I present an extension to that view. Academics Ritsema and Broekuis* list 5 challenges in delivering quality to clients in service industries.
  • The limited opportunities to delivery tangibles to clients
  • The uniqueness of each service
  • Measuring quality in quantitative way
  • Limited opportunities for standardisation
  • The provision of technically good work
As a project worker you should be aware of them and take active steps to manage these challenges. I'll take a few minutes to expand each of these points with examples relevant to project work.

1. Tangibles
I have written about tangibles before in the RATER articles. The bottom line is that you should make sure people get physical things that help them esteem the work you and your team do. Real estate agents use glossy brochures. Advertising agencies give out media packs. This is your chance to be creative.

2. Uniqueness
Your project is unique and your client will have a hard time assessing the work you do against a comparable piece. Larger corporations often have frameworks and measurements to monitor projects with, but at the end of the day, how often do they implement data warehouses, or offshore a back office department?

You can help by defining the comparisons. If your team have experience on similar projects you can get them to tell their stories and use them as baselines for comparison. If not you can research case studies, and failing those options there are always the consultants who have a broad range of industry experience they can share for a price.)

3. Measuring quality in quantitative way
Sometimes it is a leap to transport qualitative things to hard numbers, but at the end of the day you can usually do it; it just takes planning. The Six Sigma framework for example requires the project team to make sure they can measure the problem before they apply a solution. The RATER approach also provides a model for measuring quality in a systematic and quantitative way.

If the numbers aren’t apparent maybe you need to undertake a piece of work to capture them. At the very least surveys of customers, key stakeholders or process participants, can be used. Then, at the end of (or after) the project you can measure again and see the improvement.

4. Standardisation
In the planning phase of the project consider your opportunities to standardise your work packages. You can also consider calling in experts for particular parcels of work. Your project may only need to test software development once, but if you call in a specialist to manage and execute software testing you are on the way to higher quality (and lower risk) work.

5. Doing/getting good work
Many studies of project performance come up with the same recommendation; make sure you have a skilled, proficient and trained team.

Sometimes it’s tough to fill a team quickly with the right people. Every experienced and successful project worker I have spoken to agrees: Wait for the right people and don’t hire the wrong ones. You can read more about recruiting here.

Bottom line: Make sure your team is a good one and that they are up to the job.

* Source: HP Ritsema and M Broekuis "Problem of quality management in professional service"International Journal of Quality and Reliability" Vol 9 no 7 1999 pp23-26



12 July 2007

3 Journeys to a successful project

Further to my post on Top Down/Bottom Up analysis post:

I have read a nice article by Shawn Callahan at Australian firm Anecdote. It's called Knowledge Strategy - 3 Journeys.

The article is written in the context of implementing knowledge management strategies and it talks about and demonstrates a quality approach to project execution and requirements management. This includes the importance of reconciling the details with the strategic direction when documentaing and managing corporate knowledge.

Take a minute and read the article.

10 July 2007

Urgent/Important Prioritisation

Busy? Always busy? Are you working on the right things right now?

From Stephen R Covey's 7 Habits of Highly Successful People comes this model for prioriting your work:
  • Rate what is most important to least important to you
  • Then rate these things in terms of urgency. Which ones need to be dealt with no and which ones can wait.
  • Place them on ths Grid and now thing again about what work you need to do today, this week, this month.

If this mode of thinking is new to you try this as a weekly activity, until it becomes second nature.

You could also do worse things than buy his book.

Top Down, Bottom Up Analysis

Taking a top down and bottom up approach to business analysis is a useful method, especially when working with business processes.

I recommend it to analysts who are mapping a whole business or large departments. It helps check whether the purpose of a business process is actually being met by the myriad details below it; a reconciliation.

It also helps analyse whether activities are aligned with the strategic objective of the process. If not it's a trigger to investigate and challenge the activity a bit more rigorously.

The assumption is when you investigate the top level process with senior execs, they are most closely aligned with the business strategy, and that as you drill into the detail front line workers are much less likely to be aligned with strategy and more likely to be focused on their local turf, which may be based on things such as customer experience, timeliness or cost.

While front line activities may seem sensible and good, they may not be aligned with business strategy. Or short term satisfaction may be gained at the cost of the overall customer experience. (Jonathan Babcock presents a hypothetical example of this in his blog.)

Whether you are analysing the current state or designing the future , make sure you include the top down part of the analysis and don't just go work shopping and interviewing your way through front line workers activities. It may eem like extra effort today, but it will mean your work will be of a higher quality and of more business value.


Image Details: View of Manhattan from Empire State Building
Author: Luigi Scarantino
URL: http://www.infoturisti.com

9 July 2007

Making a Gantt Chart with Excel

Making a gantt chart is a basic technical skill for project managers. It helps you work out who will be doing what and when. It also helps you identify dependencies; for example you need to know your requirements before you design your solutions.

There are plenty of purpose specific tools out there, Microsoft project being the most ubiquitous, but they are also notoriously complex once you start getting into the more advanced features.

I am also a fan of scaling your tools to the project you are on, and of learning the basics of the technique before you defer it to technology. So, in that vein, here is a tutorial I found at Youtube on how to create a project gannt chart in Excel.



7 July 2007

The V-Model: Table of Contents

I have written about the V-Model across several posts. The V model is a testing focused expansion of the software development lifecycle. In fact, it's a testing paradigm.

The posts are listed here in order.





6 July 2007

Extending the V-Model; The project tick of success

Imagine extending the V model into a tick shape.

Think about the V-model as is: sloping down during the planning and development phase, the right side of the V rising up during the testing nd validation excercises, and then; the organisational and change management leg of the project extending up and beyond the technical work.

The things on the right should, according to the framework, be test an validate activities.

They could be activities such as a business transition agreement, or handover from the project team to operations or the implementation of new performance indicators in the new mode of operations. This acknowledges the steps that help migrate the project's deliverables into the business' future state.

Any thoughts or comments on this extension?


(Project tick of success. I crack myself up.)

The V-Model: Test and Verify on the way out

Once the actual development has been done you want to test it to make sure it meets specifications. Again the maths of picking up defects early applies. The earlier you find an error the easier it is to fix.

It seems to me that this is one of the strengths of an agile development approach; you are putting functional components into production or at least a test space as early as you can so you can pick up problems. Regardless of the method the principle still applies.

The phases in the V-model cycle are listed below, but there are other labels and other types of testing. The nice thing about the V-model is that each level of testing can be reconciled back to a design stage. So, for example user acceptance testing becomes a way of checking off whether business requirements have been met, just as interface testing can test whether the system design got things right.


V-Model Testing phases

  • Component testing
  • Interface testing
  • System testing
  • User acceptance testing
  • Release testing
I am not going to break down test activities and their details here. If you want that level of information I recommend you Craig Borysowich’s blog at IT Toolbox for a very detailed run down on test activities. Instead let me focus on the ways a business analyst would interact with each of these test activities.

The business analysts role in this phase of the development lifecycle is to act as an assessor and communicator. Your role is to understand what the testers are doing, what results they get and to be able to clearly explain what that means to business stakeholders.

Things to consider include;
  • When you don’t understand what is in the test plan; ask the test manager or developer to explain it.
  • When you think you see gaps in the planning; raise the issue until you are satisfied; these are your requirements that are being serviced after all.
  • When there are bugs or problems; understand them in the context of the full solution before raising the alarm, but if things are really not working, let people know.

You can manage bugs like you manage project issues and risks; they should be clearly articulated and have an owner, an action plan and a deadline. If you don’t time box a problem it can have an impact n the whole project schedule. If problems aren’t resolved by a deadline it’s a flag to escalate the problem to a new level.

Many business analysts are also heavily involved in user acceptance testing (UAT). Business analysts (and other types of requirements managers) should be involved in UAT so that they have a detailed and thorough understanding of both the validation process and the useability of new systems and processes. By participating fully in this activity you can identify poorly built aspects of the system and areas where the business processes need to be enhanced.

You also deepen your subject matter expertise in the solution, which is useful for the change management work that comes at the implementation phase of the project.



4 July 2007

The V-Model: Verify on the way into development

This may be extending the V model beyond it’s original design, but I think it’s a worthwhile concept. During the planning, analysis and design phases of projects there is the opportunity to validate the design points along the way.

The most common method is for formal approval of milestone documents such as requirements specifications, solution design documents and so on. As each of these documents are produced they are circulated, socialised and assessed by the relevant subject matter experts.

Business analysts have a lot to contribute at this phase as they maintain a huge amount of subject matter expertise around the business requirements and further business processes. As such they are uniquely able to participate in the review and assessment work throughout the project lifecycle.

The business analyst can then liaise with stakeholders and offer recommendations for approval or rejection of design documents, and help identify or develop non-technical solutions to gaps in the solution design.

The project manager should also be plan to have full and frank discussions with the business analyst about the suitability of the solution. Are there non technical cheaper or better ways of solving the problem? After all technologists will focus on providing a technology based solution, but they are not always the best ones. For example an activity may be outsourced for a better return on investment.

At the end of the analyse and design phases the requirements and solution should have been validated by the project manager, business analyst and sponsor.

Stakeholders views should have been heard and understood in the context of the projects objectives and the project team should feel that there is a good chance of the project being ble to deliver what it is committing to.

The next post will consider the V-model on the way out of the development phase.


3 July 2007

the V-Model: the Development Process

The V model as designed is built for traditional waterfall project development processes.

The validation process is aligned to the governance and planning artefacts like requirements documents and solution designs.

The testing processes are also aligned but less tightly to the waterfall development process and can be applied whatever development framework is used. For example; if you use Agile you could apply the V-model tests for each iteration of your development.

The typical stages of a waterfall SLDC are:

  • Business Case
  • Business Requirements
  • Solution Architecture or System Specification
  • System Design
  • Component Design
  • Component Construction

For each of these stages there is a validation exercise that can be done on the way through the development process, and a testing activity than can be done on the way out of development on the way to production.

For now here is the model as a diagram. You can click the image to get a larger view.



The next posts will expand on the validation and testing steps.





2 July 2007

The V-Model; The value of quality and testing

Why test? Why validate? The value of testing could also be described as the cost of quality.

Many of the process and quality gurus written about on this site wrote about this topic years ago and when you look at the model below it should, if not be familiar, at least be intuitively right.

The earlier you address problems the cheaper they are to fix.

Here is a construction example; When building a house the builder stops and checks the concrete slab before constructing the rest of the building. If he didn’t, and rushed into the building of the walls and roof he may find there are problems with the foundations and have to rip the building down and start again, wasting a lot of work and materials.

The same can be applied to any almost any type of project, and especially large complex software projects.



There is also the idea of managing quality in, rather than managing defects out.

Pulling defects out of a production line is one way of increasing quality for customers, but these days it’s generally accepted that you want to pull out the defects of the production process itself, so that it doesn't create defects and so you can get the highest yield out of your production line.

In software development this is done by two streams of activities; validation of the requirements and solution design, usually by document reviews, and also by ensuring that the system is functional, robust and meets customer requirements before releasing it into production.

That way, once the users have logged on for the first time the system is likely to be doing as expected, and process workarounds will not be required to perform smoke and mirror tricks so the customers experience a quality experience.

The next post will talk about the software development process and how the V-model fits into it.