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.