Have we missed some? Let us know by leaving a blog comment.

BA Acronyms

BABOK - Business Analysis Body of Knowledge (reflects current generally accepted practices)

CBAP – Certified Business Analysis Professional (professional certification for BAs with at least 7500 hours of hands-on BA experience)

CCBA – Certification of Competency in Business Analysis (professional certification for BAs with at least 3750 hours of hands-on BA experience)

IIBA – International Institute of Business Analysis (independent non-profit professional association for BAs)

BA – Business Analyst

BI – Business Intelligence (business information and business analysis that lead to decisions and actions and that result in improved business performance)

BPMN – Business Process Modelling Notation (an international standard for drawing process maps and building models)

CM – Change Manager

COTS – Commercial Off The Shelf (typically software)

DFD – Data-flow diagram (dynamic modelling technique that shows how data is shared among the various activities and entities in a system)

PIV – Post Implementation Verification – testing conducted after implementation to ensure that the changes have been accepted into the production environment

PM – Project Manager

RACI – Responsible, Accountable, Consulted, Informed (a framework for assigning stakeholder responsibilities)

RFI/RFP – Request For Information/Request For Proposal (standard business process to collect written information about the capabilities of various suppliers)

RMP – Requirements Management Plan – a document that defines how a project’s requirements will be managed. This includes requirements change controls and traceability.

ROI – Return On Investment (performance measure used to evaluate the efficiency of an investment)

RUP - Rational Unified Process (iterative software development process framework)

SDLC – Software Development Life Cycle (process of creating or altering an information system)

SME – Subject Matter Expert (a person who provides many important requirements, and in certain situations, may need to approve requirements)

SWOT – Strengths, Weaknesses, Opportunities, Threats (SWOT analysis is an extremely useful tool for understanding and decision-making for all sorts of situations in business and organisations)

UAT – User Acceptance Tests – tests executed by a select group of end users to ensure that the delivered system is acceptable.

UML – Unified Modelling Language (general-purpose modelling language in the field of object-oriented software engineering)

WBS – Work Breakdown Schedule (deliverable-oriented, hierarchical decomposition of project elements that defines the total work scope of the project)

BA common terms

Baseline requirements – a list of requirements that have been approved at a specific point in time, they are often used as the basis for future requirements.

Business architecture - part of the enterprise architecture that shows the structure of the enterprise (that is, divisions, locations, etc.) and its product or service strategy.

Business case – a document that captures the benefits and costs of the proposed project.

Business process mapping – pictorial presentation of a process.

Business process modelling – usually attaching numbers/flow information to a map at a most basic level.

Business process management – an enterprise view and governance of the approach and results.

Business requirements - stated from the viewpoint of the business function and using that terminology (also known as a High Level Requirement).

Business risk – eventualities that could threaten the project; positive (opportunities) or negative impacts the project could have on the business.

Business rules – static modelling technique that looks at the rules governing business processes and decisions (regulation, company policy, etc.).

Cause-and-effect diagram – combines brainstorming and concept mapping to identify and consider a range of causes and impacts relative to a problem; also referred to as a fishbone diagram or an Ishikawa diagram.

Critical path – the longest path through the project network; the sequence of activities that defines the minimum time required to complete the project.

Cost/benefit analysis – technique focused on the identification of the associated costs and the related benefits.

Defect – an error in requirements caused by incorrect, incomplete, missing or conflicting requirements (also known as a software bug).

Document analysis – requirement elicitation method that studies available documentation to leverage existing material; can be time-consuming and often information may be out of date.

Domain – the area or business unit that you are working in.

Elicitation – techniques used to extract requirements information from people, as well as from other sources.

Enterprise analysis – one of six knowledge areas identified by the BABOK; analysing needs and opportunities from the overall organisational perspective and recommending projects to improve specific business processes and systems.

Functional design – observable behaviours of the solution; as opposed to technical design.

Functional requirements – define what the system must be able to do; describe both the systems behaviour in detail and the information the system will manage.

Interface – a point in which a system or systems interact and communicate with a user.

Gap analysis – understanding the differences between two or more states of play, two or more applications, two or more sets of data etc, and making recommendations based on this understanding.

Modelling – representations of a business or solution that often include a graphic component along with supporting text and relationships to other components.

Non-functional requirements – a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours.

Prototype – a mock up of the proposed solution which can be used to demonstrate the flow of screens, it can range from a paper prototype through to a working mock up. Often used to verify requirements prior to development.

Scope –  identifies the boundaries for a piece of work and sets the expectations for the project team and stakeholders as to what will be delivered.

Scope creep - changes that occur during a project that are neither recognised, evaluated, nor approved.

Sponsor – the stakeholder(s) responsible for funding the project, they often make the final decision when stakeholders can’t agree.

Stakeholder - people or organisations that are actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project, or who can exert influence in project decisions.

Traceability – information that shows stakeholders the relationships between individual requirements and their sources; allows a BA to manage scope creep and ensure all requirements have been met.

Use-case - a list of steps, typically defining interactions between a role (known in UML as an “actor”) and a system, to achieve a goal. The actor can be a human or an external system.

User story – usage-modelling technique that is similar to use case descriptions, but with much less detail.

Validation – checking requirements to be sure that they are correct, complete, and feasible.

Verification – checking requirements to ensure that they have been written and specified well; should be done before validation.

Workflow models – dynamic modelling technique that diagrams the flow of activities among responsible parties.

References

1. A Guide to the Business Analysis Body of Knowledge, Version 2.0
2. www.en.wikipedia.org
3. Global Knowledge Training LLC – “A Business Analyst’s Glossary for Project Management Terminology”

In the current financial climate, business analysis tasks and timelines are already being squeezed to minimise costs. Businesses are looking for individuals who can hit the ground running, with little to no on-boarding, who know their domain, who don’t need a couple of days to familiarise themselves with the environment they are in and consume valuable SME time by asking the basic questions.

Let’s flip this scenario around for a moment though. Is there any benefit in taking on an individual who has no prior industry knowledge, hasn’t got a clue as to how your business works, and who needs to be prepared to ask the basic questions?

Is there any hidden value in asking the simplest of questions in the quest to understand the underlying issues and the real objectives that remain unstated, simply because nobody has asked?

The crux of it all being: having no previous knowledge in certain domain areas encourages our minds to be more curious, always keen to know more, gain a better understanding and to analyse the situation with a fresh set of eyes.

Here are some benefits that I can see:

•  Not constrained by past thinking (but why can’t it be done?)
• No perception of what a dumb question is (did he just ask that?)
• BAs are a resourceful lot and can use this learning curve as relationship building.

Granted there is one big challenge to overcome: How to convince the person doing the hiring that you’ll be able to keep up?

• It goes without saying that showing initiative by researching the domain, understanding the language, the terminology and environment is a good start (Google is your friend)
• Perhaps relate it to past experiences which at a stretch falls within the borders of the domain in question (in the past I’ve used being a bank customer when being interviewed for a banking industry assignment)
• Drive home the point that being a BA means possessing a skillset that is transferable.

Have you got any experiences to share of the time you overcame the no-domain-experience barrier by achieving results on the back of great business analysis skills?

The language of truth is unadorned and always simple.
Marcellinus Ammianus (fourth-century Roman historian)

The primary job of the business analyst is to facilitate communication: Usually between people who share a common natural language, but still find it difficult to achieve a common understanding.

Often this is simply because natural language has a tendency to be ambiguous with common words having multiple meanings, and this lack of precision leads to differences of interpretation especially after some time has passed. For the most part projects also require communication between people who inhabit different worlds (such as business and technical) which have specialised vocabularies, idioms and jargon. To effectively communicate between them requires an understanding
of both worlds to accurately interpret and translate what is being said, and a common language in which to
document it.

“You should say what you mean,” the March Hare told Alice.
“I do,” Alice replied, “at least I mean what I say – that’s the same thing, you know.”
“Not the same thing a bit!” said the Hatter, “You might as well say that ‘I see what I eat’ is the same thing as ‘I eat what I see.’”
– Lewis Carroll

Unfortunately, there is often a tendency to try to solve a complex problem by choosing a tool that has the (unintended) consequence of hindering communication rather than improving it. In business analysis this can be the result of selecting inappropriate languages for documentation.

Over-complicated document templates and impressive sounding, but ultimately meaningless language, are common faults. Complicated modelling methodologies such as Unified Modelling Language (UML) and Business Process Model and Notation (BPMN) are not effective communication tools for a general audience when used in an unrestricted fashion.

Everything must be made as simple as possible, but not simpler.
Albert Einstein (attributed)

On the contrary, by continuously seeking to remove ambiguity, jargon and buzzwords from the language used (and clearly defining any required domain-specific terms), an experienced BA aims to document using plain English using simple diagrams. Standard modelling languages are used but using a carefully restricted subset of symbols which are all clearly explained. Complicated document templates filled with boilerplate are avoided.

Every sentence or diagram whose meaning is unclear is a potential cost to the project. They can’t all be eliminated, but by keeping things simple there will be more time to tackle the intrinsic complexity of the business problem and less time wasted on misunderstanding and rework.

“Numquam ponenda est pluralitas sine necessitate.”
[“Plurality must never be posited without necessity.”]
— William of Ockham

Business owners demand it. Project Managers utter it. Architects revere it.

Unfortunately IT seldom delivers it.

How can Business Analysts contribute to the goal of simplification? Let us begin with the definition.

What is Simplifying?

Simplifying tends to get misunderstood. Project Managers and Business Owners often treat it at a superficial level. Business Analysts are encouraged by project stakeholders to ignore complexities and focus on simplistic situations. Simplifying is not about being reducing capability. It is about delivering more by choosing smart solutions.

Very often, people confuse simple with simplistic. The nuance is lost on most. Clement Mok

For instance, if there is a significant data integrity issue in a project striving for automation, the issue of data purification and reconciliation is often ignored. While the automation functionality may be delivered (often at a high cost), automation ratios continue to suffer.

Simplifying, in the actual sense, involves taking a complex process and re-engineering them to manageable entity. It requires delving deep rather than staying superficial. Simplifying necessitates focus on non functional requirements such as: Scalability, performance, reliability, security and inter-operability.

Techniques for simplifying

Simplicity is the ultimate sophistication Leonardo da Vinci

Some of the problem solving techniques that can be applied in various business analysis competencies are highlighted below:

Systems Thinking

One of the common problem-solving approaches, useful especially in the initial stage of the project, is to understand the eco-system of the problem domain. As part of enterprise analysis a holistic view of the components of the domain and their interactions needs to be mapped. Context diagram is a handy tool in documenting the results of the systems thinking. System thinking helps to simplify by focusing on:

•  Interdependencies (cause effect modelling)
• Goal alignment (ensuring all value streams work towards achieving common goals)
• Convergence (removing redundancies and improving system performance as whole)

Process patterns

At a business analysis level, identification of process patterns helps to standardize and improve consistency. All business domains over a period of time tend to exhibit entropy. Identifying the essential process patterns helps in implementing control mechanisms that will reduce process deviations.

For instance a campaign management process, irrespective of the channels that is used (direct marketing, phone, internet etc) would have a process pattern like:

Identify target market, contact target customer, promote concept\educate customer, provide offers and initiate fulfilment.

Process patterns help to maintain consistency, minimize and reuse design and improve throughput. It engenders focus and removes activities that do not contribute to the goal of the process.

Think Data

Data elements are the fundamental building blocks in any system. They tend to get more complicated and maintenance intensive, causing data attrition. In a study done by IBM, data quality even in best maintained system has an attrition value of 2%..

Business analysts can simplify the way in which data structures are defined, maintained, displayed to the users. Identifying core and meta-data relevant to business is an integral part of requirements analysis. Naming standards help reducing the profusion of multiple terminologies.

Organizing data structures smartly ensures that business processes operating to maintain the data can be simplified.

For instance, in a telco domain, if the fulfilment process does not define data structures for service level agreements consistently, service assurance processes will suffer.

And finally

Business Analysts can gain significant benefits by simplifying the way requirements are documented and communicated.

Using relevant diagrams, requirements management workflow tools, modelling data analysis and presenting them innovatively to stakeholders is a critical component of business analysis.

User stories, scenarios and narrative techniques can help the reader to engage and understand requirements better.

Taking a leaf out of Ernest Hemmingway’s book might perhaps help: “My aim is to put down on paper what I see and what I feel in the best and simplest way.”

So, the needs of the user. This certainly isn’t a new concept. One speaker at Webstock, Kathy Sierra, has been blogging about it since at least 2006. User centered design (UCD) has dozens, if not hundreds, of books and papers written about it. So I’m not going to focus on that – a quick Google Scholar search will get you all the information you need. I want to focus on something slightly different; not the product’s design and development, but rather the users of the products themselves.

Think for a moment about a successful or desirable product – where do the key attributes of this success and/or desire come from? Some people might say it’s the company; some people would say it’s the product itself. Whilst of course these things matter, they don’t have as much impact as you might think. If you take the time to step back and think about this rationally, key attributes of a successful product don’t come from either the company or the product. The key attributes of a successful product lie in the users themselves. User’s talk about themselves and what they personally gained from using your product: “Look what I did”, “Look what I made”, “Look how awesome I am”. If someone is using your product to create something, they want all the kudos that your product provides. They want the increase in productivity, the better reputation, or the enhanced skillset. If your product has a large positive impact on someone’s life in some way then, congratulations, you’re on the way to creating a passionate user. And passionate users are the cornerstone of any successful and desirable product.

For a case study, here’s a few testimonials from the (now offline) 37 signals testimonials page:
“Backpack is perfectly conceived and the most elegantly executed web app I’ve seen. Period. I’m excited again about keeping things organized at work and at home. I plan to be Backpack-ing a lot every day.”
“Genuinely a pleasure to use and interact with. We’ve just started using it, and the reaction from our clients and team has been singularly amazing.”
“Basecamp has already been key to winning a project, being the main thing that differentiated us from a very close competitor, and it’s had a massive, positive impact on our working practices, even after just a couple of weeks.”
“Backpack has changed the way I live.”

That’s inspiring stuff! Read through those quotes and think to yourself “What can I do with my product to get that kind of passion out of my users?” I’m not going to attempt to talk here about what you should specifically do, as everybody’s product and user types are different. But as long as you know that the job isn’t to create a better product, but rather a better user, then you’ll be away laughing.

Passionate users help generate sales of your product. If you’ve ever talked to a user of Apple products then you’ll know what I mean. These types of users enjoy telling other people about the products they love. They love telling stories about how these products have made their lives more enjoyable in some way. You can’t market that sort of enthusiasm; it can only come naturally from people who are genuinely passionate about your product. These users also always find a way to justify spending more money on their passion (“I need the new iPhone”, “I need feature x”). If you create a product that enables your users and they become genuinely passionate about it then you could, for example, utilise a tiered pricing model, paid upgrades, or offer paid workshops because your users won’t think twice about spending their money.

In summary, you shouldn’t be focusing on building a great product; you should be focusing on building a great user. People don’t buy products because they like you – they buy products because they like themselves. If you can offer something that has a positive impact impact on a users life then you’re on your way to creating a passionate user. And creating these types of users will, no doubt, have a huge impact on how successful your product is. Remember: it’s not about us. It’s about them.

Neil describes himself as an “average guy” with a typical 9-5 job in the burbs. Neil started blogging 1000 Awesome Things as a small reminder – in a world of rising sea levels, global conflict and troubled economy – of the free and easy little joys that make life sweet. What he didn’t anticipate was that his site would gain a readership of millions of people, win two webby awards, be named one of PC Magazine’s Top 100 Sites On the Internet or become a place where people from around the world would come to celebrate the simple pleasures of daily life.

In our BA world, how many times have you heard someone say or you have even said to yourself “I love being a BA because” or “this is why I chose to be a BA” or “this is what makes it all worthwhile”. I’m guessing maybe not as often as you should have. I love to chat with other BAs and in my travels, I’m constantly amazed by BAs that are doing the simple things really well. The flip side to this is that I’m also equally amazed by the humbleness shown by these BAs. For many, we’re just doing our jobs.

So I think it would be awesome to create a place where BAs from around the world can come to celebrate (or be reminded) of the simple joys of daily life as a Business Analyst. I would love nothing more than for everyone to hear your stories and for you to encourage your colleagues to share their stories (by leaving comments on this blog) so that we can help spread a little more optimism in our BA world.

So please share the love, leave your comments and spread the word. Let’s see how quick it takes to get to 500 comments.

Have fun and go wild.

Check out Warren’s presentation in the recorded video of the webinar. He is the 3^rd presenter. You may also want to access a PDF of the webinar inside the IIBA’s public webinar archive.

Starting off by defining what Business Analysis Practice Management means, and emphasising how important it is, we explore the types of agile tools that are out there for BAs, how The BA Kit works in parallel with those tools, and helps introduce some consistency into when other tools are used, by whom, and how well. The BA Kit can be considered theone source of truth for all the flavours of agile and non-agile methodologies and BA tasks.

We then presented a subjective graph (based on our experience and evaluations) that shows that there is a gap between what the evolving agile-specific tools offer, and the TOTALrole and actions of a BA. The BA Kit fulfils some of this gap, especially in planning and monitoring area, but across all body of knowledge areas.

A BA’s level of engagement on a project can fall into seven decreasing levels of involvement, and you may need a tool (such as The BA Kit) to cater for that variety that can eventuate in an individual agile project. We use the concept of a ‘stencil’ in The BA Kit to change-up the methodology being employed for a specific project depending on the level of specialist BA engagement in the agile project, as dictated by the business/product owner.

Agile projects tend to have a number of continuums that require balancing so that the role of the BA is clear and ratified. An Agile project team may contain a group of agile practitioners who are multi-skilled generalists (who can cover analysis, development and have the business product knowledge), or perhaps the Agile project team has more specialised roles, where a skilled BA is differentiated from other team members.

Natural tensions will exist for a BA who is both part of an Agile project team and also part of a pool of BA resources in an established practice inside an organisation. Regardless, the Product Owner in an Agile team and the BA Practice Manager will both require visibility of what activities the BA has been carrying out, to which time frames, and to what level of success.

The BA Kit facilitates the setting up of consistent processes and tasks for the BA to carry out, and then lets the Product Owner, Project Manager and BA Manager track and monitor progress in near real-time. The BA Kit caters for both ‘masters’ in managing the value of the BA.

Importantly, you don’t need to have separate systems for Agile and for non-Agile in terms of practice management if you are using The BA Kit, as a key is ‘flexibility’. You can start from scratch and create your own groupings of agile tasks, and create your own templates and details . . . or you can grab our inbuilt agile methodology and use that, including our take on what templates and worked examples will be of use . . . or you can do a bit of both – make a copy of our inbuilt methodology, change things, add new tasks, or perhaps even drag in a few other tasks from non-agile methodologies to make a hybrid. Maybe the governance on your projects requires typical waterfall-based business case planning, or the mandatory inclusion of use-cases for example.

Check out the 3^rd presentation inside the webinar and see what you think. We are keen to get your thoughts!

Despite the rapid growth in both the government and private sectors, I consider business analysis practice maturity to still be in its infancy and that there are few organisations in New Zealand that can lay claim to having achieved the ‘holy grail’ of a fully functioning Business Analysis Centre of Excellence (BACoE).  I liken the establishment of a BACoE to “Reaching for the Stars”. If, in your lifetime, you’re fortunate to have the opportunity to “Reach for the Stars” then please embrace the faith that someone has placed in you and absolutely go for it. If the BACoE is not quite within your reach, relax, there is hope. “Settling for the Moon” (establishing a mature Business Analysis Practice) is not necessarily a bad option (in fact I think it comes a close second), can be a lot of fun and if done well, hugely satisfying for all involved.

Attempting to define a BACoE without taking over the whole blog requires discipline, especially on my part. Given I appreciate the simple things done well, I gravitated to this definition:

A BACoE is a team of people that is established to promote collaboration and the application of best practices. There are 3 key characteristics of a BACoE that have a significant impact on its value and operation, these being its authority, role, and organisation placement/staffing within the organisation.

Whilst the idea might have popped up over-night, good BACoE’s don’t. Like any significant change effort, an effective team is needed to drive, develop and maintain a BACoE. To avoid frustration, disappointment and ultimately tears, a BACoE requires executive sponsorship, commitment, investment, good planning and execution, a champion to lead this effort and more often than not, a company culture that encourages want to be the best and embraces continuous improvement.  For me, a real point of differentiation between a BACoE and a good BA Practice is that a BACoE (or CoE) has an enterprise-wide flavour. By this, I mean an enterprise focus to business issues, e.g. alignment with the project management group, enterprise architecture, data integration, business and IT optimisation, and enterprise-wide access to information. A good Business Analysis Practice has a more local flavour, with the focus on developing a good Business Analysis framework and works lives by a simple idea – focus on the best and neglect all the rest. Whilst you never turn down executive sponsorship, support and investment if offered, you can achieve a good Business Analysis Practice by unleashing the talent that already exists in your BA team, getting comfortable with the idea of being a leader without a title, and allocating the team responsibility for making a positive difference whilst creating a work environment which make it easy for to get up in the morning and come to work.

It’s also of the view that before we even contemplate achieving Business Analysis nirvana (BACoE) we need to have first got our house in order and have established a good  Business Analysis Practice – the building blocks for a BACoE. If we are not afraid to be honest with ourselves and ask the hard questions (which we are trained to do), for many, a good business analyst practice will be all that is needed, all that is required and more importantly, will be a realistic and achievable goal that doesn’t kill the team in the process.

So which journey is the right one for you? The journey is likely to hurl you into the great unknown at warp speed but it will force you to embark on a serious of soul searching questions about yourself, your environment and your organisation which can only be good on all levels…right? I will cover this off in the following blogs but to help you get started, please consider the following four things you need to come to grips with and, may  ultimately help with the decision making process.

• What are the characteristics of your current business analysis workforce?
• What kind of business analysis workforce do you need?
• What is needed to build a mature analysis practice?
• How are you going to get there?

When coming to grips with these questions, the worst thing you can do is…..put them in the too hard basket and do nothing. According to the Forrester/IIBA September 2010 Global Business Analyst Online Survey, 28% of BAs responded have already made the decision, are involved in initiatives for creating a business analysis or requirements centre of excellence. This indicates that organisations are focusing more attention on business analysis skills and practices. I’ve also seen an emergence of organisations creating communities of practice, by this, bringing BAs together to share good practices, processes, templates, ideas and lessons learned (good BA Practice). Whilst you might have stakeholders that could benefit from understanding (at a high level) requirements management. Your executives might not care about repeatable processes, re-use, BABOK or the nitty-gritty details of functional (and non-functional) requirements, they all care about is delivering what was promised on time. This is requirements management,  it’s our zone and is why we should all care about “Reaching for the Stars” or Settling for the Moon”

In my next blog posting, I’ll dive deeper and share ideas for boldly going where others have already gone before. But for now, have fun, go wild and always remember “discipline at the core, creativity at the edge”.

Well, how often does one end up buying a car because a salesperson made a fabulous pitch? Never, or perhaps rare. Customers are growing smart enough to see beyond the impressive speech to check if they are buying a lemon.

Are we not told that in the mother of all metrics is how happy a customer is? But how often have we seen weekly status reports that end up looking like this?

Week 1 2 3 4 …after some weeks…Week n

So, what is the alternative to the soft-core business analysis approach?It’s time to define success of business analysis by intelligent metrics than rely on the emotional state of fickle customers. The blog proposes few metrics under four different categories that could help chart the health status of business analysis.

Requirements Elicitation Metrics

Requirements discovery rate: Number of new requirements (scenarios, processes, rules, use cases) elicited with stakeholders over a period of time. (say reporting time of a week)

Value of discovered requirements: What is the total business value of requirements discovered?

Priority of discovered requirements:  Is there a consensus of requirements priority and focus given to high priority requirements?

Pending scope issues: Number of scope issues pending at the end of requirements elicitation cycle.

Requirements Analysis Metrics

Requirements velocity: What is the time taken for requirements to move from draft to review and review to approved?

Requirements churn: How often does the requirements change before moving from draft to review status? (this could indicate requirements are unstable)

Traceability metrics:  A summary of traced and untraced requirements to scope and business drivers.

Requirements Quality: Metrics from requirements reviews including missed requirements, ambiguous requirements, incomplete requirements.

Requirements Management Metrics

Requirements change: Number of requirements change requests after the baselining of requirements was complete

Review process metrics: Number of review cycles, stakeholder response time, approvals received from stakeholders, response time to requirements reviews, root cause analysis of requirements defects.

Requirements plan metrics: Planned against actuals for requirements schedule, effort and resource, # of times requirements plan was changed, root cause analysis of plan changes.

Requirements management metrics: Issues identified and resolved, risks mitigated and requirements sizing in terms of Function Points, value analysis etc.

Stakeholder Metrics

Stakeholder analysis metrics: Number of stakeholders identified, stakeholders missed and churn in stakeholder analysis

Stakeholder availability metrics: Delays due to non-availability of stakeholders to requirements elicitation, requirements review and validation; average response time to review cycles and requirements clarification.

Stakeholder satisfaction metrics: Feedback survey of all stakeholders at the end (and possibly once in between in case of a large project) with metrics to measure intangibles such as leadership, innovation, risk management, process management, expectation and satisfaction etc.

The purpose of this blog is not to enumerate all possible metrics, but to highlight key numbers that would provide a glimpse into the state of business analysis activity in a project. Analysis is a primarily an engineering activity and requires quantitative approach to  manage and improve the process.

While the above numbers might look daunting to collect, it is quite easy to gather these numbers from a good requirements management tool. Modern requirements management tools are capable of generating excellent meta-data that provide excellent insight into evolution of requirements.

The above requirements metrics maps out the DNA of your business analysis practice. Unravel the world of business analysis … with numbers!

We’ve snuck in a few cool features too – as your business analysis partners, we wanted a dedicated area for useful bits and pieces for all business analysts – see for the BA. And if you want to see how we’ve evolved and some of our key achievements, we’ve got a nifty timeline so you can see what we’ve done at a glance. The revamp has been a great opportunity to showcase our software product The BA Kit, and some of our new service offerings – BA Capability Assessments and BA Maturity Assessments.

As well as better explaining what we do, we wanted to show you who does it! So, in the name of bringing our People to the People, here’s a quick rundown of who does what. And for those visitors who aren’t 100% sure of whether they actually need a BA – here’s all you need to know.

We were keen to make the site more relevant for potential employees too, so if you’re an ace BA looking to spread your wings, let us talk you through our job process. The website now gives you a better feel for the type of company we are and the way we value our staff.

We’d love to hear your thoughts – let us know if we’ve hit the mark, or if we need to make a few tweaks.

Cheers

Richard & Sarah Gibson
Redvespa Directors