BPM Methods: A Change in Software LifeCycle

As in business, BPM projects either produce or fail. And, in varying degrees, BPM honestly tries. Maintaining net-value is an effort of direct participation. To remain relevant… one must keep up with the pack – speed counts. This demands agile, quick development iterations and, consequently, a serious weaning from project fat.  Cutting corners gets us ahead of the game. Knowing when, how, and which ballast to cut throughout keeps us in the game.

Evolution

Focus on the relationship between software development methodology and business success.

The catalyst behind change is our drive towards increasing efficiency. The tools and methods behind process management effectively short-circuits communication channels and re-wires the organization. Brought into focus are traditional gaps in execution between business leaders and software development. Otherwise impeding the flow of evolutionary progress, and spotlighted for what they are, progress forces its way around unnecessary bureaucracy.

Obvious like highway congestion and air-travel delays – we need change. It’s our impatience. It’s nearby, within reach, and forces itself as matter-of-fact: keep up or be left-behind.

A Spotlight on Bureaucracy: Tradition

“There are protocols that must be followed, regardless of their cost or waste.”

Let’s take a look at a more traditional methodology.

The Business Owner communicates values to our Requirement Analyst who, in turn, produces documentation which is then, in turn, handed over to the Process Architect.

Process models flow into software which then become rooted within operations via services (SOA) and general integration architecture.

The “playback”, or software demo’, provides a theater where our Business Owner communicates direction back into the next cycle. Iterations repeat until we find usability.

In theory we have a fairly good working methodology. In practice we do not.

Short-circuit Communication and Evolve

No barriers. No handoffs. One team.

Our new model has the Business Owner working directly with the Process Architect.

Reasons:

• Direct communication between Business Owner and Process Architect is simply more efficient. This efficiency produces working, executable process in a fraction of the amount of time that would have otherwise been spent on traditional, time intensive, requirements documentation and review cycles.
• As business feedback (aka requirements) now flow directly into development there’s neither room nor slack for misunderstanding.
• Reduction in administrative overhead (requirements documentation) allows shorter iteration cycles and early delivery.

Business Value

Work occurs with the immediacy of market conditions.

Value-driven methods and purpose force efficiency. From the Business Owner’s perspective, “value” is executing process:

• Strong User Interface
• Valued Process Outputs
• Supporting Services
• Shows Strategic Direction while supporting tactical agility

We now understand the nature of process development. BPM projects DO NOT build systems because “systems” lack context – technology isn’t the point. The effort behind building “systems” is as irrelevant as attempting to build a house before its blueprint… more so even before understanding the intended home owner’s perspective. The best approach then is to isolate our system builders – take them out of the picture.

Irrelevance

Those who once lead must now follow

Removing system builders removes distraction. Without this distraction we’re able to maintain business alignment and, consequently, remain focused on business process development.

So what does a roomful of system builders do when left on their own? They build an irrelevant system.  Frequent the result of specialized teams is competing effort – things created, with good intent (we hope), that offer much less support as interference.

We’re left with a dichotomy.

Our goal still focused on business process and yet diplomacy plays in as a key strategic requirement? Though completely outside the scope of process development, “change management” (politically correct term) is none-the-less required.

Rebuild The Team

NEXT WEEK’S PREVIEW…  (to be continued)

The best solution here is to break these specialized teams apart and reassemble as cross-functional units (aka “pods”). We keep our specialized skills, such as QA and integration, while maintaining orientation on process development.

As a BPM effort we have “process” goals on our plan. Competing milestones no longer receive management’s attention. Goals become aligned and focused on process development iterations.