Corporate Performance Management: Process Improvement

We know these two concepts relate to one another, but how? 

First, some definitions...

Business process improvement (BPI) is defined as a systematic approach that helps organizations optimize its underlying processes in an effort to achieve better results.   BPI works by:

• Defining the organization's strategic goals and purposes (Who are we, what do we do, and why do we do it?)
• Determining the organization's customers (or stakeholders) (Who do we serve?)
• Aligning the business processes to realize the organization's goals (How do we do it better?)

Corporate performance management (CPM) is defined as the monitoring and analysis of a company’s performance goals.  CPM works by:

• Defining the goals of a company or business unit (strategic planning)
• Gathering the relevant data to measure those goals (benchmarking)
• Consolidating and reporting on that data (financial reporting)
• Comparing and contrasting the actual performance vs. performance goals (the budgeting process)
• Making operational and strategic decisions in light of that information (The Balanced Scorecard)

So if the goal of CPM is to analyze and monitor a company's results, and the goal of BPI is to improve processes to achieve better results, then clearly these two concepts go hand-in-hand.  In fact, they share a lot of common characteristics: 

• An organization's strategic goals should provide the key direction for any Business Process Improvement exercise. This alignment can be brought about by integrating programs like Balanced Scorecard to the BPI initiative
• BPI tools place a lot of emphasis on "measurable results". Accordingly, benchmarks assume an important role in any BPI initiative. Benchmarks may be internal (within the organization), external (from other competing / noncompeting organizations) or dictated by the senior management of the organization

A BPI initiative could come about after a company has implemented its CPM solution and realized that they are not meeting one or more of their strategic goals.  Let's say that the organization realizes it needs to reduce expenses by 5% in order to achieve its profit margin goal.  One way to reduce expenses is to optimize its business process such that redundancies and inefficiencies are removed.  This is where a business process improvement initiative comes into play. 

• The first step in BPI is to define the existing structure and process at play (AS-IS). 
• Then, the organization must determine what outcomes would add value to the organization's objectives and how best to align its processes to achieve those outcomes (TO-BE). 
• Then a full scale BPI project is initiated to achieve those outcomes

The Business Analyst Role in the Agile World

Facilitating risk discovery and assisting the team in retaining focus on effective risk mitigation is central to the analyst’s role on an agile team.  Iterative development processes provide opportunities for increased efficiencies in the work of business analysis. In non-agile projects (i.e. waterfall projects), requirements are developed in their entirety prior to the development phase. As risk elements are uncovered and business needs evolve, certain requirements may change or be eliminated outright; making the work effort put into those requirements wasted. By providing just-in-time requirements via agile development, there is less rework of requirements because only the requirements required for the current release are defined in detail and developed.

The techniques of business analysis do not change dramatically in the agile environment. However, the timing and how they are used do change. Artifacts such as personas, data models, story maps, and business rules continue to be employed, but are kept as lightweight as possible. Low-fidelity artifacts, such as diagrams, maps, and lists, provide more value to an agile project than long, textual requirement descriptions or specifications. Low-fidelity artifacts are developed for the sole purpose of building the software for a specific iteration and only need to be intelligible to the team during the course of the iteration. Long-lived artifacts, on the other hand, are intended to be utilized beyond the scope of development. Long-lived artifacts may include the business case, charter, and documentation that is used to communicate what the software does and why it does it.

Agile offers the opportunity for the business analysis to benefit from the frequent feedback provided by the business. By reviewing the results of successive iterations with the business stakeholders, analysts have the opportunity to

• refine the product’s requirements to ensure they maintain cohesion with the business needs for the product
• identify and mitigate risk early in the project

 

There are a variety of ways a business analyst can be engaged on an Agile project:

• In more complex environments the analyst might be the facilitator, bringing divergent business stakeholders together and helping them speak with a single voice so the project team are not confused by contradictory and conflicting perspectives.
• The analyst might act as the product owner/customer representative where they are empowered by the business to make decisions on product features and priority.
• The analyst could act as a surrogate product owner, in situations where the business product owner not available.
• The analyst might act as the second in command to a business product owner with limited availability.
• An analyst could take the role of business coach in an environment where the business product owner is competent and committed, but has limited IT project experience and the rest of the development team are lacking in domain knowledge.

Irrespective of job titles, business analysis is about ensuring the project is able to deliver the maximum value for customers and adapting to the evolving business needs.

The 5 Reasons Why Projects Fail

Do your projects suffer from these undesirable effects?

• delivery date is well past due date
• your resources are overloaded
• your resources are not available when needed (even when promised)
• your scope suffers from excessive changes (due to long project timelines)
• there are changing priorities & constant rework

There are five main reasons why your projects struggle with these problems:

1. Bad multi-tasking - do you or your team constantly face shifting priorities that cause reources to stop one task and work on another? Is someone waiting for the output of your task before they can do their work? This is the definition of bad multitasking.  Often the culprit is poor prioritization. We are asked to start several tasks simultaneously and each of them has a "customer" waiting for the output. Each customer wants progress to be made on their task and constantly asks - "is it done yet?" - forcing us to repeatedly switch to their task to get something done and report progress. While working on this task other customers request status on their respective tasks. This cycle forces us to task switch repeatedly.
2. Student syndrome - this is also known as procrastination.  Student syndrome is a natural defense mechanism. It means to put off the work until the last possible moment not because we are lazy, in fact we are working very hard, but because urgent tasks will take precedence over important tasks.  Due to competing demands we delay the start of tasks until we absolutely must start.
3. Parkinson's law - this is defined as "work expands so as to fill the time available for its completion." In a project sense, Parkinson's law rears it's ugly head when team members embed greater safety in task estimates because they feel like their estimates will not be "estimates", but rather committments.  In order to make sure they deliver on their "committments", team members add in slack to allow for the uncertainty.
4. Task dependency - if you have a task that was estimated to take 5 days and you started immediately, and completed the task “early,” is the person that receives your output ready to use it immediately? Not usually. Therefore, if you deliver the results in 3 days the next person will not touch it for 2 additional days because they are not scheduled to start their task until that time. To overcome this problem you must have a project system that ensures all tasks begin, not when they are scheduled to begin, but when the required inputs are available.
5. PM math where 2+2=5 - each of the above scenarios contribute to the final reasons why projets struggle..."project math". 

Each of these problems not only drain the company of valuable resources, it also causes a delay in the potential cash flow that results from a finished project.  Remember, if you keep doing what you have always done you will keep getting what you've always got -- late projects. 

To remove these obstacles you will need to stop bad multitasking, develop a system that allows early and late tasks to cancel each other out, account for the probability of dependent events, stop the effects of Parkinson's Law, ensure that when one task completes the results appear almost instantaneously to the next task in line, and stop the practice of adding safety to each task.

Interviewing

Project managers and business analysts can spend hours running through SWOT and decision analysis, reviewing system documentation, analyzing various use cases and scenarios, and setting up focus groups and survey questionaires, but ultimately all these techniques may not yield the types of information gleaned from simply interviewing project stakeholders.

An interview is a systematic approach designed to elicit information from a person or group of people in an informal or formal setting by talking to an interviewee, asking relevant questions and documenting the responses.

For the purpose of eliciting requirements, interviews are of two basic types:

• Structured Interview - where the interviewer has a pre-defined set of questions and is looking for answers
• Unstructured Interview - where, without any pre-defined questions, the interviewer and the interviewee discuss topics of interest in an open-ended way

Successful interviewing depends on several factors including, but not limited to:

• Level of understanding of the domain by the interviewer
• Experience of the interviewer in conducting interviews
• Skill of the interviewer in documenting the discussions
• Readiness of interviewee to provide the relevant information
• Degree of clarity in interviewee’s mind about what the business requires of the target system
• Rapport of the interviewer with the interviewee
• Rapport of the interviewer with the interviewee

In relation to other solicitation techniques, the advantages and disadvantages in using interviews are:

1) Advantages:

• Encourages participation and establishes rapport with the stakeholder
• Simple, direct technique that can be used in varying situations
• Allows the interviewer and participant to have full discussions and explanations of the questions and answers.
• Enables observations of non-verbal behavior
• The interviewer can ask follow-up and probing questions to confirm their own understanding
• Allows interviewees to express opinions in private that they may be reluctant to express in public

2) Disadvantages:

• Interviews are not an ideal means of reaching consensus across a group of stakeholders
• Requires considerable commitment and involvement of the participants
• Training is required to conduct effective interviews. In particular, unstructured interviews require special skills including facilitation/virtual facilitation and active listening
• Depth of follow-on questions may be dependent on the interviewer’s knowledge of the business domain
• Transcription and analysis of interview data can be complex and expensive
• Based on the level of clarity provided during the interview, the resulting documentation may be subject to interviewer’s interpretation
• There is a risk of unintentionally leading the interviewee

Decision Analysis

Decision analysis is an approach to decision-making that examines and models the possible consequences of different decisions. Decision analysis assists in making an optimal decision under conditions of uncertainty.

Effective decision analysis requires that the business analyst/project manager understand:

• The values, goals and objectives that are relevant to the decision problem
• The nature of the decision that must be made
• The areas of uncertainty that affect the decision
• And the consequences of each possible decision

Uncertainty may exist because of:

• Unknown factors that are relevant to the decision problem
• There are too many possible interrelated factors to consider
• Conflicting perspectives on a situation
• Tradeoffs between the different available options

A common method of dealing with uncertainty in decision problems is to calculate the expected value of outcomes. This involves estimating the percentage chance of each outcome occurring and them multiplying the numeric value associated with that outcome by that percentage.

Decision analysis generally requires that the business analyst/project manager to use some form of mathematical model to assess possible financial outcomes.  Commonly used financial valuation techniques include:

• Discounted Cash Flow: future value on a specific data
• Net Present Value: future view of costs and benefits converted to today’s value
• Internal Rate of Return: the interest rate (or discount) when the net present value is equal to zero
• Average Rate of Return: estimate of rate of return on an investment
• Pay Back Period: the amount of time it takes for an investment to pay for itself 
• Cost-Benefit Analysis: quantification of costs and benefits for a proposed new solution

Not all decision outcomes can be expressed in financial terms. However, effective decision analysis still requires that outcomes be directly comparable. In some cases, there will be a metric that is applicable (defects per thousand, percentage uptime, customer satisfaction rating). When there is not, a relative scoring of possible outcomes will have to be determined.