BPM Library

The blog includes information from the materials that I meet during my career. It is a collection of information about methods and library sources for professionals in the IT Business Analysis sector.


Depending on the context upon which your project is founded will depend on who sets your objectives. This said, it is the responsibility of the Project Manager to ensure that the objectives are workable and “S.M.A.R.T.”. If the PM has to set them or has had them handed down from senior management or programme management, the PM needs to review the projects objectives and redraft them if necessary to ensure that they are exact and achievable. Don’t forget to re-communicate them – they are no good in the bottom of your drawer.

Evaluate the project objectives using the following considerations.

Specific - A specific objective has a much greater chance of being accomplished than a general objective. To set a specific objective you must answer the six "W" questions:

* Who: Who is involved?
* What: What do we want to accomplish?
* Where: Identify a location.
* When: Establish a time frame.
* Which: Identify requirements and constraints.
* Why: Specific reasons, purpose or benefits of accomplishing the objective.

Measurable - Establish concrete criteria for measuring progress toward the attainment of each objective you set. To determine if your objective is measurable, ask questions such as......How much? How many? How will I know when it is accomplished?

Agreed - it is crucial that agreement is reached between all stakeholders on what the project’s goals should be.

Realistic - To be realistic, an objective must be something your project and your organisation are both willing and able to work. To you have the right resources and funding? Has your organisation taken ownership of the project?

Time-based - A objective should be grounded within a time frame. With no time frame tied to it there's no sense of urgency.

For example, a business unit’s goal maybe “Keep our department’s web page up to date.”

A more effective goal would be, “To… solicit updates and new material from our department’s managers for the web page on the first Friday of every month in order to… publish this new material no later than the following Friday.


Time, quality and cost are a function of scope. Therefore if you get scope wrong, the time, quality and costs will be wrong.

The project scope relationship

In determining scope the project manager must develop common understanding as to what is included in, or excluded from, a project. Only then, once your have defined the scope, you can calculate cost, quality and time.

There are numerous ways to define. Ideally several ways should be used. Each looks at the situation from a different perspective and will elicit different information. We look at three main ways are:

* Define Deliverables

- What training is required?

- What documentation is required?

* Define Functionality and Information

- What business procedures are required?

- What operations procedures are required?

- What are the critical requirements?

- Will Systems Analysis be required, if so what’s needed?

* Define Technical Structure

- Will an Acceptance Test Plan and testing be required?

Scope definition deals with "What" and Why" and is a function of Quality, Cost and Time.

* What is the main or overall goal

* What is the background

* What opportunity/problem is to be solved

* What is the "fit" with corporate strategic goals?

* What other related projects are in process?

* What changes will come about as a result of the project?

* What are the Go/No-go criteria for implementation?

* What are the specific objectives? efficiency? ROI?

* What are the measureable outcomes? or specific deliverables?

* What are the priorities?

* What is included? or not included? limits to your authority?

* What are the options?

* What are the assumptions?

* What are the Key Performance Indicators?

* Why is this a project in the first place? why is it needed?

* Why are the limits set as they are? who is setting them?

* Why are there politics involved? and who are the stakeholders?

* Why are some stakeholders against the project? who are they? how might they influence the outcome?

Outline project deliverables

At this early stage of the project, list the expected project deliverables and try to be as specific as possible. Consider the following:

* The deliverables within the scope considered.

* The opportunities that would be lost/missed if the project did not happen.


What activities have been excluded from the project?

The scope of the project can be defined by what will not be implemented as much as by what will be included. This may be due to budgetary constraints, the overlapping with another project or be part of a future phase. This is a very important section as it will define and communicate which deliverables the reader might have expected to be part of the project but are considered outside the projects current scope.


This section can expressed the constraints in terms of project, operational, technical, business and external constraints. However at a minimum the following should be addressed:

* Resources – What is the resource availability of skilled team members?

* Time - What is the latest project completion date?

* Quality – What is the basic minimum standard of delivery?

* Cost - What is the maximum cost of the project?


Projects do not exist within a vacuum. What organisations, both internal and external, does the project interface with? What are the job titles of the primary and secondary contacts? Names of people should be avoided as people can change jobs during the course of the project.

Power / Interest Grid for Stakeholder Prioritization

To see where an stakeholder is positioning, use the scale from 1 to 10 and make this graphic.
Who has interest/ impact on the horizontal scale and who has influence / power on the vertical

  • High power, interested people: Manage Closely - these are the people you must fully engage with, and make the greatest efforts to satisfy. Most critical stakeholder group: collaborate with closely.

  • High power, less interested people: Keep Satisfied - put enough work in with these people to keep them satisfied, but not so much that they become bored with your message. Useful for decision and opinion formulation, brokering: mitigate impacts.

  • Low power, interested people: Keep Informed – keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very helpful with the detail of your project. Important stakeholder group, in need of empowerment: involve, build capacity and secure interests.

  • Low power, less interested people: Monitor (minimal effort) - again, monitor these people, but do not bore them with excessive communication. Least priority stakeholder group: monitor or ignore.

Use Case is a detailed description of a users interaction with a system

It can be applied to a business process, a software system or event organization of events.

The only requirements are an actor and an object to be acted on.

A Use Case consist of seven components:

1. Name - the identifier for the use case in question. It should be represented in a form of an action.

2. Description - expands of the name and provides additional information and details regarding the user and the system interaction.

3. Preconditions - criteria that must first be met prior to the execution of the scenario. They can be sucsessful execution of other use cases or assumptions.

4. Scenario - the anticipated series of actions and responses. Depending of the complexity of the use case the scenario maybe is simple as a couple of lines or spend several pages but length should be taken in the consideration. If the scenario is too long maybe it will be better to define other use cases from that use case

5. Results - the final results of the actor system interaction. Reflex the successful compleition of the use case.

6. Alternate paths - variations on the anticipated scenario and represent failiors of the actor system interaction.

7. Additional business rules - rules that govern the use case. They should be presented within the scenario or within the alternate paths which are relevant. It is a place for additional business rules that govern the entire use case and do not have a location for inclusions whithin the context.

Download a template from here

A very Good Business Process Definition - A business process is a flow of decision-coordinated activities, conducted by participants and acting on data, information and knowledge то reach a goal.

Business Rules Approach, the four C's:

o Classify - classify the type of employee or customer or contract, the type of entity that we are dealing with, to narrow down where that rule applies to.
o Compute - for example how many purchases or orders we have for the past three months, it could be a database look up or a data that is provided within in the process
o Compare - compare all data with predefined lines. To put in action the rule.
o Control - whether or not the discount apply to the customer or particular fact are true and hence that control back to the business process.

"The Old Seven."

"The First Seven."

"The Basic Seven."

Quality pros have many names for these seven basic tools of quality, first emphasized by Kaoru Ishikawa, a professor of engineering at Tokyo University and the father of “quality circles.”

1. Cause-and-effect diagram (also called Ishikawa or fishbone chart): Identifies many possible causes for an effect or problem and sorts ideas into useful categories.

2. Check sheet: A structured, prepared form for collecting and analyzing data; a generic tool that can be adapted for a wide variety of purposes.

3. Control charts: Graphs used to study how a process changes over time.

4. Histogram: The most commonly used graph for showing frequency distributions, or how often each different value in a set of data occurs.

5. Pareto chart: Shows on a bar graph which factors are more significant.

6. Scatter diagram: Graphs pairs of numerical data, one variable on each axis, to look for a relationship.

7. Stratification: A technique that separates data gathered from a variety of sources so that patterns can be seen (some lists replace "stratification" with "flowchart" or "run chart").

Excerpted from Nancy R. Tague’s The Quality Toolbox, Second Edition, ASQ Quality Press, 2004, page 15.


The name "Pareto" is derived from the name of founder of the theory "Vilfredo Pareto" on which Pareto chart works. Vilfredo Pareto was an economist who gave the theory that in certain economies the majority of the wealth is held disproportionately by a small segment of the population.

The Pareto principle was brought in Quality by Joseph M. Juran. The Pareto chart is a quality tool that is mainly used to graphically segregate out the "Vital few from Trivial many". The Pareto principle is based on 80/20 rule which states that 80% of the problem are due to 20% of the causes.

The figure given below represents the Pareto diagram/Chart. The first three defects represent the vital defects as they constitute 80% of the total defects.


Step 1 - Categorize the data (e.g. by defect type)
Step 2 - Determine the way to compare relative importance (e.g. it can be on financial basis, frequency basis)
Step 3 - Rank the categories from most important to least important
Step 4 - Find the percentage frequency for each category.
Step 5 - Compute the cumulative frequency in the order they are ranked
Step 6 - Plot bar graph showing the relative importance of each category in descending order.
Step 7 - Identify the vital few by the 80 - 20 rule.

Ground Rules?

Percentage: In the bar graph percentage and not the actual value has to be plotted
Cumulative: The 80% has to be considered for the cumulative percentage. It is not that accurately 80% has to be taken, something less or graeter can also be taken


It helps in prioritizing the problem and help management identify the problems that require immediate attention
Pareto chart can also be used to compare the condition before and after the implementation of solution for improvement
"After" improvement Pareto chart can be used to see the impact of the remaining problems
Pareto Chart helps the management in allocating the limited resources to problem solving


If categorization is not done correctly than the Pareto can be misleading in the way that resource being spent on trivial problem instead of vital.

Ishikawa diagrams (also called fishbone diagrams or cause-and-effect diagrams) are diagrams that show the causes of a certain event.

A common use of the Ishikawa diagram is in product design, to identify potential factors causing an overall effect.

For more info see here

The role of the BA facilitator is to guide activities on developing both the vision and software solution. The key word here is guide.

The BA facilitator role provides process to group settings and avoids participating in content. Typically, the BA facilitator role serves as the liaison between stakeholders, and the stakeholders and software development team respectively. As the liaison, the BA facilitator role uses various techniques and emotional intelligence skills to assist project sponsors and/or team leaders in accomplishing group meeting goals:

• Facilitation Techniques for identifying solution features

o Creating a Solution Vision and Scope

  • Brainstorming – discussing of ideas
  • Brainwriting – submitting written ideas for discussion
o Eliciting Features and Associated Business Rules
  • Focus Group Meetings – soliciting opinions
  • Joint Application Design – resolving conflicts
o Analyzing Features – Assumptions, Constraints, Risks, and Issues
  • Root Cause – 5 whys, Ishikawa Diagrams
  • Force-Field – listing negative and positive influences
  • As-Is and To-Be Gap
o Making Decisions on Features and Priorities
  • Multi-voting – subjective paring down a long feature list
  • Criteria-Based Grid – weighting feature value criteria
  • Impact/Effort Grid – comparing feature benefits versus effort

• Emotional Intelligence Skills for interfacing with stakeholders

o Active Listening and Paraphrasing
o Generating Participation
o Neutrality – focus on meeting process instead of solution content
o Questioning – seeking answers rather than posing solutions
o Maintaining Focus – use a parking lot and issue log for off agenda topics
o Obtaining Stakeholder Feedback
o Summarizing and Synthesizing Ideas
o Conflict Intervention

From The Need for the Business Analyst Facilitator Role
in an Agile Software Development Team
By Mark Monteleone, CBAP

This scheme provides information for the desired skills from recruiters about the role

The requirements gathering is a major part of the Business Analyst responsibilities.
As a first step of every project the requirements are crucial for the next phases of the project. They have to be complete and useful.

Here is a list of the characteristics of the requirements

  • Cohesive - The requirement addresses one and only one thing.
  • Complete - The requirement is fully stated in one place with no missing information.
  • Consistent - The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
  • Correct - The requirement meets all or part of a business need as authoritatively stated by stakeholders.
  • Current - The requirement has not been made obsolete by the passage of time.
  • Externally Observable - The requirement specifies a characteristic of the product that is externally observable or experienced by the user. "Requirements" that specify internal architecture, design, implementation, or testing decisions are properly constraints, and should be clearly articulated in the Constraints section of the Requirements document.
  • Feasible - The requirement can be implemented within the constraints of the project.
  • Unambiguous - The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited.
  • Mandatory - The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated.
  • Verifiable - The implementation of the requirement can be determined through one of four possible methods: inspection, analysis, demonstration, or test. The expected methods are usually test or demonstration. The inspection or analysis are done just in special cases.

For more information see here

FMEA, RPN, and Process Sigma

FMEA: How To Perform a Failure Mode and Effects Analysis Tutorial

FMEA (Failure mode and effects analysis) is a part of DMAIC in Six Sigma

Is a step after C&E Matrix ant it is used for analysis of potential failure modes within a system

Every defect is measured by Severity, Occurrence and Detection. The multiplication of these elements gives the Risk prioritization (Risk Priority Number RPN) for every case.

Uses of FMEA

  • Development of system requirements that minimize the likelihood of failures.
  • Development of methods to design and test systems to ensure that the failures have been eliminated.
  • Evaluation of the requirements of the customer to ensure that those do not give rise to potential failures.
  • Identification of certain design characteristics that contribute to failures, and minimize or eliminate those effects.
  • Tracking and managing potential risks in the design. This helps avoid the same failures in future projects.
  • Ensuring that any failure that could occur will not injure the customer or seriously impact a system.
  • To produce world class quality products


  • Improve the quality, reliability and safety of a product/process
  • Improve company image and competitiveness
  • Increase user satisfaction
  • Reduce system development timing and cost
  • Collect information to reduce future failures, capture engineering knowledge
  • Reduce the potential for warranty concerns
  • Early identification and elimination of potential failure modes
  • Emphasis problem prevention
  • Minimize late changes and associated cost
  • Catalyst for teamwork and idea exchange between functions
  • Reduce the possibility of same kind of failure in future
For more information see here

A very useful article about C&E Matrix

Need Help Making Decisions?
by Ron Pereira on June 11th, 2007

Posted using ShareThis

Here is a list of the main Process Analysis methods:

  • Cause and Effect - Fishbone
  • 5 Whys Analysis
  • Process Mapping
  • Value Stream Mapping
  • Mind Mapping
  • C&E Matrix
  • Value-Add Analysis
  • Waste Analysis
  • FMEA
  • Pair-wise Comparison

Lean Manufacturing

Continuous Improvement In Manufacturing

White Belt Program


Process Control