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.





A very useful online CV


In an Analysis, decision trees are used in a context of a identifying a strategy most likely to reach a goal.

software for decision tree - SmartDraw



A very useful pen for Business Analyst :)

It can be used for the Requirements gathering stage as well as for meeting minutes notes.

Livescribe 2GB Pulse Smartpen can be ordered from Amazon for $149.95

A very useful site for statistic analysis for several factors between all of the countries in the world


Gapminder world

Human Development Trends, 2005

CRoss Industry Standard Process for Data Mining

Process Model

Phases of the CRISP-DM Process Model

Shearer C., “The CRISP-DM model: the new blueprint for data mining”,
Journal of Data Warehousing 5 (2000) 13-22 (see also www.crisp-dm.org)

Definition - In information technology, gap analysis is an assessment tool to help identify differences between information systems or applications. A gap is sometimes called "the space between where we are and where we want to be." A gap analysis helps bridge that space by highlighting which requirements are being met and which are not.

In software development, for instance, a gap analysis can be used to document which services and/or functions have been accidentally left out, which ones have been deliberately eliminated and which still need to be developed. In compliance, a gap analysis can be used to compare what is required by law to what is currently being done.

Technique for determining the steps to be taken in moving from a current state to a desired future-state.

List of steps to be taken:

1. Listing of characteristic factors (such as attributes, competencies, performance levels) of the present situation ("what is")

2. Cross-lists factors required to achieve the future objectives ("what should be")

3. Highlights the 'gaps' that exist and need to be 'filled.' Also called need-gap analysis, needs analysis, and needs assessment.

Unfortunately the report includes only two companies from Bulgaria

In Small and Medium Scale Company Category
there are no any companies from Bulgaria

in Large Scale Company Category

Avendi, Bulgaria, Marketing and Distribution of FMCG


McDonald's Bulgaria, Bulgaria, Food Service Retailer / Quick Service Restaurants

the report for fast growing companies for the past five years in the technology sector

the Bulgarians companies and their positions in the report:

Ranking table: ‘Technology Fast 50’ category:

Rank Company Country Website Sector Growth

5 Telerik Corp. Bulgaria www.telerik.com Software 2,327%

6 Investor.BG AD Bulgaria www.ibg.bg Internet 2,130%

20 UNIVERSAL K Ltd. Bulgaria www.universal-k.com Telecommunications/Networking 664%

34 Interconsult Bulgaria OOD Bulgaria www.icb.bg Software 447%

• have annual revenue of at least EUR 50,000 in each of the last five years (2004-2008);
• be in business a minimum of 5 years;
• have an ownership structure that excludes majority owned subsidiaries of strategic entities; and
• have their headquarters in Central Europe.

After meeting these criteria, companies are ranked
according to revenue percentage growth, this is done by
comparing the base revenue of the fi rst out of the last
fi ve years (2004) and revenue of the last year (2008).

Ranking table: ‘Rising Stars’ category

Rank Company Country Website Sector Growth

9 HAND Ltd. Bulgaria www.sonicad.biz Software 315%

‘Rising Stars‘ category
This Technology Fast 50 category recognises ‘young’
technology companies that are quickly growing.
‘Rising Stars’ companies have to meet the same criteria
necessary for the Technology Fast 50 with the exception
of revenue, which must have exceeded EUR 30,000
each year for the past three years (2006-2008).
Additionally companies cannot be in business less
than three years and no longer than fi ve years.

BPM solution Goals

The BPM solution must meet the following goals:

* To provide users with electronic forms, whenever paper forms currently exist.

* To provide as many re-usable components as possible for future BPM solutions to take advantage of them (i.e. Prognosis).

* To allow for electronic notifications whenever applicable.

* To seamlessly integrate with other existing systems, therefore eliminating manual work.

* To provide a robust user interface that will provide custom capabilities to users and with the possibility to integrate with the existing portal.

The answers of the following questions have to be gathered before the process design.

• What action initiates the process?

• What tasks must be performed to complete the process? In what order must these tasks
be performed?

• Which individuals within the organization will be involved? What roles will they be
taking in the process?

• What information needs to be gathered during the course of the process? What
information should be shared among participants?

• What are the possible outcomes? Does the procedure flow in a step-by-step manner from
start to finish, or are there alternative paths to be taken into consideration? Are actions
taken sequentially or in parallel?


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

How to get detailed information for Business process:

People - who is involved?
- Roles
- Employees

Systems - is the task performed by a system?
- which one
- define inputs and outputs

Time - how long the task is performed?

Location - where is the task performed?

Documents - which documents are involved?

Decisions - where are the decisions set?

Information transformation - Are there any changes of the information?
- size
- format
- structure

Control - are there any possibilities for changing the KPIs or changing the rules

How to make a success checklist during the launch pad phase of a BPM project

Ask the stakeholders the flowing question and write the answers. They will be a very good success checklist.

It is six weeks after the completion of the project and you are sitting back at home in front of the fireplace having a red wine and reflecting on the project. You decide that it has been outstandingly successful. Why?

Conversation Blunders and How to Avoid Them
By Michael Lee

The major blunders in our conversations are, naturally, the violation of the general principles of communication. Such include talking about topics that are considered taboo, talking behind somebody else's back, and basing stories on exaggerations, or worse, lies.

However, these are not the only blocks we can stumble on when we engage in conversations with other people. There are so-called mechanical blunders, as well, which often result from not thinking seriously about what we are talking about, carelessness, or not keeping a close eye on our own conversation techniques.

Below are some of the most common technical conversation blunders.

Blunder 1: Using pet words regardless of their suitability to the topic or the situation

There are people who call everything they like 'fabulous', 'cute', or 'darling', and call things they don't like 'weird', 'dull', or 'lousy'. There are appropriate words to describe certain things. A building is not cute; a movie cannot be ghastly; a book cannot be weird; a restaurant cannot be a darling. Use words properly. Also, if you are one of these people who use pet words a lot, try to reduce their usage to a minimum. Be aware of the things that are coming out of your mouth. It can be very annoying.

Blunder 2: Using big words inappropriately

You've encountered people like this already - those who like using superfluous terms and phrases (probably to make a good impression). There also are those who seem to enjoy using words like 'basically', 'actually', 'so to speak', 'you know', etc. Get them out of your system. Not only are they unnecessary, they're also time and effort wasting.

Blunder 3: Exaggerating

A lot of us are guilty of this. We tend to introduce our stories with "Let me tell you about the weirdest thing I've ever experienced" or "This is the most amazing thing I've ever seen." While these kinds of statements are subjective and you are entitled to them, you should also think about the other person in the conversation. It might not be so for him or her, and by being so, the momentum you tried to create did not have the effect you were expecting. Get real.

Blunder 4: Getting too personal

You don't need to dish out all the dirt about your life just to get attention at a party. People will naturally listen to you if you make sense, not because you're giving fodder for gossip. Telling too much about yourself is like baring your soul to a group of strangers. It's okay to be real about your feelings, but it's awkward to get too revealing, because you don't know how other people will react to your stories. It could lead you to your undoing and you have no one to blame but yourself.

Blunder 5: Too much slang.

If you're conversing in English, use proper English. Don't bastardize the language and pepper it with slang. You can only use slang if the people around you speak the same way. But if you're in a group with people of diverse backgrounds and interests, slang is not appropriate. Speak in a manner that is understood by all to avoid possible conflict.

Proper style of communication can enhance your relationships, boost self-esteem, and help you achieve lifelong success. On the other hand, continuous use of conversation blunders may hinder you from attaining your goals; so be very careful and aware of every word coming out of your mouth.

About the Author:

Michael Lee is the author of the highly-acclaimed How To Be An Expert Persuader... In 20 Days or Less. This power-packed course reveals mind-altering persuasion secrets to turbocharge your earnings, win lots of friends, captivate the opposite sex, and make anyone subconsciously like and trust you. If you want to easily and quickly persuade anyone to eagerly do anything you want, go to http://www.20daypersuasion.com now!

How To Say No And Still Be Liked
By Michael Lee

We've all been in this situation. Somebody asks us to do him or her a favor and, though there are a gazillion other things we should do first, we find it difficult to turn the other person down because he or she has done us a favor in the past, or is a close friend or a family member. The concept of gratitude prevails and we find ourselves trapped in something we really didn't know why we committed to. We can sometimes be so worried at causing disappointment in other people, often at the expense of our own activities and interests.

Frankly, knowing how to say 'no' requires skill. Others might say that it shouldn't be hard to do. But, let's face it. We live as social beings and acceptance often occupies the number one spot in the list of virtues we want to achieve. Despite this, there are actually ways we can circumvent this difficulty. Subliminal persuasion is one way. Here are five more friendly, pain-free and reasonable ways to say 'no'.

1. Say 'no'; then show what the other person has to do to get a 'yes'

For example: An employee is asking you for a raise but you hesitate to do so because lately he's been skipping work and picking arguments with co-workers. Yet, he looks like he really needs it and has been working for your company for three years now. You want to give him a raise, but his recent behavior is a little disappointing. How do you say 'no'?

Tell him that you can't approve a raise right now, but will do so once you see an improvement in his work ethic. You can say, "I understand your need for a salary increase, but in order for me to implement that, we'll have to work on strengthening your work habits. Now, let's see how we can make that happen…"

2. Make it impersonal.

Make it sound like saying 'no' was a matter of circumstance, not of choice. An example of this is: "We've just paid our mortgage and my daughter is going off to college in two weeks. I won't be able to lend you money."

3. Say 'no' in a way that will make the other person say 'no' to himself or herself

Instead of saying 'no', teach the other person to say 'yes' to what you want. Do this subtly, of course. For instance, your fashion conscious sister wants to get a pink iPod while you want a blue one. You can tell her that while pink is a cute color, it's more difficult to match with her clothes. Once you level with her and link what you want with what interests her, she'll give in and agree with you.

4. Say you want to say 'yes', but…

Like tip number two, make it sound like you had no choice but to turn the other person down. This way, the relationship remains intact and no one gets hurt. Just don't involve other people, like blame your saying 'no' to somebody else, as this could result in conflict and ill feelings.

5. Say it nicely.

You're giving negative news, so you might as well do it nicely. Let the other person down easy to avoid misunderstandings. It's the least you can for the disappointed. People tend to be more accepting of bad news if it's brought in a polite and sympathetic manner.

About the Author:

Michael Lee is the author of the highly-acclaimed How To Be An Expert Persuader... In 20 Days or Less. This power-packed course reveals mind-altering persuasion secrets to turbocharge your earnings, win lots of friends, captivate the opposite sex, and make anyone subconsciously like and trust you. If you want to easily and quickly persuade anyone to eagerly do anything you want, go to http://www.20daypersuasion.com now! Special surprise gift awaits you.

Persuasion Tips To Help You Reach Your Goals
By Michael Lee

Having exceptional persuasion skills is one of the most essential abilities to possess in today's fast-paced society. We need the support and cooperation of other people to help us in our goal setting efforts. The saying "No man is an island" is an undeniable truth.

Here are some hot tips to effectively influence and persuade anyone you desire.

1) Be Nice and Friendly.

Smile to brighten up the day. Make a sincere compliment to encourage and raise their spirits. Simple little things like these count a lot.

Make them feel that whenever they need support or just someone who can give them guidance, you'll always be there to lend a hand. They would tend to be more receptive to people that they trust and respect.

If you want to ask your boss a favor, do everything you can to please him. Overdeliver and exceed his expectations. Soon, he will notice your efforts and can easily be receptive to your persuasion efforts.
expert persuader

"Discover the Most Powerful Insider Secrets to Easily Persuade Anyone.. Guaranteed!"

Click Here for Details

2) Enter their world.

You must understand the situation according to their point of view. Set aside your personal interests and focus on them.

Just pretend that if you are them, what would you do? What would be your suggestion? Then take the appropriate action that would be beneficial to them.

Copy them. Observe how they act, how they speak, and how they think. If they rub their hands while they talk to you, act like them. If they speak at a clear and slow pace, try to do the same thing. This is called mirroring.

In due time, the people you're mirroring will subconsciously feel more comfortable with you. It's as if they see themselves in you.

However, you must proceed with caution. Mirroring is different from mimicry. Do not let them be aware that you are copying them. They might interpret it as mockery and you'll just get into hot water.

3) Provide them with undeniable proof or evidence.

Explain to them how your ideas or opinions could be the most effective methods to implement. Show them undeniable proof that you have the best product by way of testimonials, before and after scenarios, and detailed comparisons against your competitors. Just make sure that all your claims are true and verifiable. Always maintain a good reputation.

4) Satisfy their existing needs and wants.

People are self-centered. They are initially concerned with their own well-being before others. If you can prove that your proposal will provide more advantages to them than to your own, then they will probably accept it.

If you could concentrate more on their interests, desires, needs, and expectations, then you would satisfy their cravings for attention. Moreover, it would show that you really care about them. Mutual trust and respect would be established.

This is the most important thing to remember when persuading anyone. No matter how close you are to becoming like them or how compelling your evidence is, if it does not satisfy the "What's In It For Me?" test, your persuasion endeavors will not produce satisfactory results. Always bear in mind how they will benefit from your actions.

About the Author:

Michael Lee is the author of the highly-acclaimed How To Be An Expert Persuader... In 20 Days or Less. This power-packed course reveals mind-altering persuasion secrets to turbocharge your earnings, win lots of friends, captivate the opposite sex, and make anyone subconsciously like and trust you. If you want to easily and quickly persuade anyone to eagerly do anything you want, go to http://www.20daypersuasion.com now! Special surprise gift awaits you.

1. Definability: It must have clearly defined boundaries, input and output.

2. Order: It must consist of activities that are ordered according to their position in time and space.

3. Customer: There must be a recipient of the process' outcome, a customer.

4. Value-adding: The transformation taking place within the process must add value to the recipient, either upstream or downstream.

5. Embeddedness: A process can not exist in itself, it must be embedded in an organizational structure.

6. Cross-functionality: A process regularly can, but not necessarily must, span several functions.

There are three types of BP:

Management processes - the processes that govern the operation of a system
- Corporate Governance
- Strategic management

Operational processes - processes that constitute the core business and create the primary value stream
- Purchasing
- Manufacturing
- Marketing
- Sales

Supporting processes - support the core processes
- Accounting
- Recruitment
- Technical support

Design Document - The document that describes the how of the project. The steps to make the project happen

Project Notebook - the document that records events that take place during the project

Functional Requirements Specification - The document that details the what of the project and describes the system

Business Requirements Specification
- The primary BA deliverable providing the why of the project

International Institute of Business Analysis
International Institute of Business Analysis (IIBA) is the leading international, professional association for business analysts and the business analysis profession, offering the Business Analysis Body of Knowledge (BABOK) and Certified Business Analysis Professional (CBAP) designation.

Online Testing FAQ

Business Certificate Programs – Boston University Corporate Education Center
Boston University offers seminars and certificate programs in management, supervisory skills, project management, information technology, and more.

B2T Training Exams : The B2T Training Catalog
The B2T Training Catalog : B2T Training Exams - Core Course Study Guides B2T Training Exams IIBA CBAP Prep Study Guide Requirements Template Roadmap ecommerce, open source, shop, online shopping

Certified Business Analyst Professional

Find out what is required to get the CBAP, a certification for business analysts.

Masters Certificate in Business Analysis University of Victoria

Certifications - Business Analysis - CBAP Business Analysis - BA Certification Ottawa
CBAP Business Analysis - BA Certification in Ottawa

All types of training page

PMCentersUSA - Online Education

University of California Irvine Extension BA Certificates

UBC Certificate in Business Analysis

Requirements Testing - An ambiguity check, a peer review, and an assumptions check are examples of this task

Ambiguity - When the communication of requirements lacks clarity or is not fully understood

Lack of Feasibility - When corporate resources will not support the scope or magnitude of the project

Questioning Technique - Asking open-ended questions and listening to the response.

Completeness Testing - Establishing agreement with the customer as to when the requirements process is finished.

Requirements Analysis - Evaluating what was learned during the information collection step and diagramming processes to assess requirements.

How versus What error - Attempting to describe the solution prematurely.