BPM Library

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?

Objectives

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.


Scope

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.


Exclusions

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.


Constraints

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?


Interfaces

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.