The good, the bad, and the…"Wagile"?!?

So, clearly, something needs to change. But what?

Investigating this problem with several BPMS/BPM colleagues I have come to believe that the underlying issue is related to the approach that guides the execution of the projects. While the technology side of the equation can be controlled through a variety of methodologies, the approach taken on the business side (operational redesign, rules definition, data use, performance management, compliance reporting, etc.) is often either not formally controlled or is inadequately controlled.

Weaknesses in approaches today generally include:

• lack of a clear understanding of project outcome targets and approaches
• lack of clarity in operational visioning
• failure to agree on measures of success
• project plans that are too high level and too rigid
• insufficient and/or unreliable detail - missing the reality of current processes, tasks, and steps
• incomplete "as is" foundation information – failure to align work to applications, metrics, problems, and standards
• incomplete definitions of "to be" tasks and steps
• unclear definitions of the ways business and IT will interact at each touch point as well as poor coordination of the different groups and disciplines that will be involved

Part of the result is that without a formal approach that addresses how to proceed given issues such as these, you cannot achieve consistency. You cannot reduce risk.

However, too much of a good thing is also bad. In addition to direction and governance you need flexibility in the way you apply BPMS/BPM and an ability to simulate, iterate, and improve.

So, something new is needed.

A little innovation here will go a long way. What about mixing approaches? Could there be a way of combining the best of Waterfall and Agile technical project management?

The technical world has used the term WAGILE to describe a hybrid technical project management approach that blends waterfall and agile methodology. But Jim Sinur, Rod Moyer, Tony Benedict and I also started to look at further changing the resulting method with new techniques that are specifically focused on removing obstacles and eliminating the underlying cause of problems.

"Wagile as a House

There is a parallel between business oriented BPM and constructing a house. Both must begin with a clear vision of the end result – the outcome. Next, the project team must decide how they will actually build the house. The Waterfall approach encompasses the detailed plans and punch list which require careful design and close management. The Agile approach exploits the speed and efficiency of pre-fabricating wall sections complete with wiring and rough plumbing. Each section must fit the overall plans and sequence to end up with a whole house and the overall plans and sequence must specify the details of each section. Simulation and iteration address onsite adjustments. Acceptance is the final action and it is based on an evaluation of the ability of the house to meet the needs of the family."

Analogy supplied by Rod Moyer, Managing Principal BTDT

The first question for us was – "Is a Technical Perspective Too Limiting for BPMS/BPM based change?"

The short answer is YES it is. We took a close look at various technology perspectives since most improvement and all transformation projects involve technology. We found that the choice of any specific technology methodology was basically irrelevant (a variety will work) except as a constraint (the company’s technology environment) and that a technical approach failed to provide the business view that we felt was needed.

We recognized that this would be controversial – many technical professionals believe they have the same perspective as business analysts, process designers, or business architects. My experience, however, is that they generally don’t, any more than people with business disciplines have the right perspective in defining application support and interfaces. These are all really specialized skills.

To improve the chance of success, we first felt that we had to establish, as a foundation, that BPMS/BPM is about the business and the redesign of the activities and tasks. We further said that we needed to look at technology as an enabler. It exists to support the business operation. Period!

While features, strengths, and weaknesses may vary, the core of BPMS technology is the same. It creates a new technical environment for business operations and was created to enable rapid business change with an equally rapid application response. This environment is where we build models, define rules, and define context for the business solutions.

The models and information the BPMS provides are also the embodiment of our business and applications specs. However, this environment is a tool and it exists to support the business, not define it or constrain it.

Wagile applied to BPMS/BPM requires changes beyond combining of Waterfall and Agile tasks

First, as stated above, business must drive business redesign. Second, the new business design must be proven to deliver both the envisioned business operation outcome and the performance metrics that were used to justify the project. Third, this redesign must provide everything that is needed to generate applications (thus it must be customized to the BPMS environment used by a company) and it must be detailed enough to define the applications, data, legacy interfaces, social media, web services, and website needs that are external to the BPMS generated applications, so they can be built by IT professionals.

Then comes support for new concepts like break point analysis, outcome focused lean, simulation, iteration, performance management, advanced Business Intelligence with inference and Evolutive Management to drive innovation. This together creates an enhanced BPMS/BPM Wagile environment that can provide the right information to IT on what it needs to build.

Successful Business Transformation and Improvement

A serious problem that has arisen over the years results from the need to specialize skills. As business and technology have grown in complexity we have created specialists.

For example, take application programming. In the early days (yep, I was there and programming in the 70’s), we did everything from business analysis, requirements definition, program design, database design, and user interface design, to actual programming, testing, and implementation.

Today this is divided among specialists and each will apply their own twist on basic philosophies, approaches and techniques. Unfortunately, the result is that many look at the world only through the lens of their specialty—they were trained that way.

However, experience has shown me that no single perspective, approach, method, or technique has all the answers. But, as noted above, most have some good components. So, why not take the best that each has to offer and mix it?

When you do this from a business and BPMS perspective what emerges is a new form of Wagile.

Wagile

Given the inconsistent project results, it is clear that business transformation and business improvement can both benefit from the formality of a business oriented BPMS/BPM methodology. It is also clear that the basic concepts of Waterfall and Agile approaches offer a lot and can be morphed from a technology focus and applied to the business operation. But we also need to put a business "spin" on all the concepts and approaches to avoid known technology traps.

From a business perspective, the concerns of the application developers become secondary to the concerns of the business managers and staff. It is this difference and the new focus on business operational changes that are the key advantages of Wagile in BPM.

This refocusing also moves from a traditional requirements based approach to an approach of defining support based on the business model. It also helps eliminate ambiguity and mistakes in defining IT support by aligning the application/data/interface services directly to the business – at the task level.

In addition, experience shows that projects need structure and governance. Project managers need to be assured that everyone (managers and staff in both business and IT) performs all needed tasks, in the same way, applying the same BPMS/BPM techniques and using the same standards.

This is critical if the design and construction of a solution will be divided among teams or specialists. It allows all the parts of the solution to fit together to form an optimal whole and allows managers to predict work and manage delivery quality. Unarguable truths!

But, experience also shows that business improvement and transformation need flexibility. We need the flexibility to be innovative and to iterate designs, simulate operational results and then iterate again. We also need to do this quickly and reduce risk. So, we need each iterated component to be built fast and to fit into the bigger picture solution – seamlessly.

To gain the speed needed in improvement today many are now realizing that BPMS/BPM is a concept and tool set that creates a different environment than what we have dealt with in the past.

The approaches, concepts, methods, or disciplines of the past really don’t fit BPM when expanded into a business operations model. It requires a new form of control and flexibility. This recognition is critical – it is also hard for some practitioners of these various approaches, techniques, and disciplines to accept.

So while our past IT focused methodologies have proven to help, they all simply offer a part of the broader BPM picture and need to be re-evaluated for the selection of components to blend – thus creating Wagile.

Benefits of Wagile in a BPMS/BPM World

Both the business and IT sides of the transformation or improvement project benefit from Wagile. The benefits relate to the problems we are experiencing with current "traditional" approaches. For BPMS/BPM projects, these problems involve project failure, outcome inconsistency, inability for solution information created by different teams to fit together, requirement/spec quality, information reuse and more. The results of these problems are higher risk, longer solution change times, and benefit realization inconsistency.

We now need to look objectively at the lessons of the past and learn. If the rate of project failure were really low, we could declare that we had all gotten it right and just "keep on trucking". But, that is not the case.

So, what can we expect if we are able to correct these problems?

The most immediate set of benefits:

• Control over the project and what is being done
• Operational design flexibility through rapid iteration
• Assurance of meeting targets through simulation and performance measurement
• Consistency and risk reduction through a common approach
• Cost reduction – a solid foundation where everyone agrees on the outcome objectives and how that outcome will be delivered (including their roles and priorities)

And, although Wagile provides a compelling benefit to BPMS/BPM projects, possibly the greatest benefit is to the IT side. Arguably, the biggest IT problem with improvement or transformation is building the right support for a solution to really deliver optimization. Wagile addresses this issue by tying the applications, interfaces, etc., that will need to be built, directly to the business design. The business design thus becomes the foundation for both business and technical requirements. Technical requirements are then an extension of the business design that provides the information specified in the IT standards for requirements.

Implementing a Business Wagile Approach to BPM

The first step in implementing a Wagile approach is to work with the technical community and obtain their acceptance of a business focused BPM/change methodology that defines and delivers controlled change from a business perspective.

However, I believe that to be acceptable to IT, the methodology must not force the replacement of the way the technical staff wants to work – it must rather augment and tie to it.

Once accepted in concept by both business and IT managers, the Wagile method for the business redesign (BPMS/BPM) should be aligned to and linked with the current company IT methods, company performance standards and more. This will allow all of the methods to work together, providing the right perspective (business, technical, performance, production, etc.) at the right times.

To gain experience in the company with the modified (company specific) version of Wagile, a series of short pilots will be needed. These pilots will need to be critically evaluated and the company specific version of the Wagile methodology improved based on the results.

This evaluation and improvement process should become part of the project close procedure to allow the project teams to continue learning what works best given the company’s constraints and capabilities. This is also where innovation and creativity should be encouraged.

BPMS/BPM Centers of Excellence

A formal business/IT hybrid methodology will likely become a key part of BPM/BPMS, Business Architecture, and Enterprise Architecture Centers of Excellences (CoEs).

Why? Because it is needed.

BPMS/BPM use in many companies has progressed to the point where it is leaving the experimentation stage of its lifecycle and moving into broad use. As it does so, individual interpretation of how transformation and improvement should be done should be discouraged and a consistent methodology adopted.

Centers of Excellence (regardless of their names) need to provide standardization and control over each of the projects. They also need a consistent formal way to monitor progress and measure improvement. This requires a formal methodology.

The Wagile methodology will serve as the hub of control for the involvement of all the players in a business transformation or improvement project. In this way, the Wagile methodology will also provide a link to specialized tools, techniques, and concepts used in the various disciplines that are needed at different points in a BPMS/BPM project such as Lean, Six Sigma, Agile, etc. In this way the Wagile method orchestrates but does not impose in these areas.

Wagile represents an approach to business transformation and business improvement that I believe is a critical breakthrough. It does, however, move beyond the traditional place for methodologies – the technical world. This movement of a BPMS/BPM methodology into the business side of operational optimization is a recognition that IT methods are fine for IT, but business requires methodologies that deal with its perspective and concerns.

The key word in business transformation or business improvement is "business". While almost every business improvement or transformation requires IT support, business must be the driver in defining how the business operates. And, just as formal methods and approaches helped stabilize IT projects, they can be extremely useful in delivering consistent business change outcomes.

I would like to give a special thanks to Rod Moyer of BTDT Consulting for his thoughts on Wagile.

As always, thank you for reading my column. Please let me know what you think.

For additional information on Wagile, sign up for the PEX Webinar "Reduce the Risk of BPM Project Failure with a New Approach to Project Management" on May 22^ndat 11:00 a.m. EST. Also check out Jim Sinur’s new book, Business Process Management: The New Wave.