The real problem? Many people simply don’t understand improvement projects

How to reduce the risk of failure in your BPM project

The bottom line is that I have learned a lot. As a result I know quite a bit about what works and what will cause problems. I understand what will reduce risk and what will likely fail.

The simple fact is that I have seen project failures and I have been engaged to turn them around. I have also been engaged to help pick up the pieces and start over. All of this has proven to me that the real issue is not simply a matter of following a project management methodology (although that can be a factor).

Among the key issues that I have encountered is a problem with project foundation – what is needed to succeed? - and the flip side of that, which is what are the things that will likely cause a BPM or BPMS project to fail? I have also seen the BPMS tools evolve and the approaches used in BPM projects mature. The result is that I personally believe that there is no reason for a BPM or BPMS project to fail any longer.

Doomed from the start

Any BPM or BPMS project, and really any project in any area, must have a firm foundation if it is to succeed.

I have learned this lesson well from many project turn-arounds that I have led. Design problems can be easily fixed. Skill deficiency can be remedied quickly. Even project management problems can be fixed without too much trouble. But, if the project’s foundation is weak, unrealistic, or missing components, the project will have a hard time succeeding – it will be almost impossible to reset expectations and budget. But, this foundation goes beyond project management or project management methods.

Foundation

The project must be reasonable, it must have formal goals and it must have a realistic budget. If it doesn’t it cannot succeed. Common sense? Yes, but it is very often not done. The creation of this foundation is a responsibility of the BPM CoE or the project requestor. The project manager should be "safety valve" for the project requestor and sponsor, and advise them when the project is not set up to succeed.

Foundational success factors include:

• Consensus on formal goals
• Consensus on formal expectation definition
• Understanding of the activities that must be performed – e.g. business modeling, redesign, etc.
• Formal BPM/BPMS/IT/production standards, approaches, techniques and methods
• An agreed upon estimating formula
• Understanding of the problem and the desired outcome
• Understanding of the deliverables and how they will be used
• Agreement on the way success will be measured
• Commitment by all affected to be part of the project – collaboration
• Understanding of the limitations of the business, IT and others in creating the solution
• Realistic estimate of time and budget

If any of these success factors are missing, the project will be at risk. The degree of risk is dependent on the project and the company, but it will definitely increase with the number of missing success factors.

Part of the real test of the ability of a project to succeed is simply common sense. Experienced BPM/BPMS project managers will know when a project simply doesn’t seem right – just as experienced PMP certified project managers know when a project is not set up properly. The fact is that if a project doesn’t seem to be set up properly to an experienced project manager, it probably isn’t set up to succeed.

The following are real examples of projects that simply didn’t have a firm foundation and were doomed from the start.

Example #1:

A large bank wanted to redesign a part of its operation. When asked if they had standards that they wanted followed I was given a rather basic workflow model. It showed flow but not much more. I told them that the model was a nice example but it was not a set of standards as it didn’t address a great many situations that the project team would encounter. The response was that they defined it as their standards.

The team also asked what information they wanted to support the models and what level of detail they wanted in the models. They said they would know it when they saw it. We next went to the two groups that would be recipient of the deliverables. The business user wanted to solve operational issues, the Enterprise Architects wanted 12 different deliverables – they had examples of format, but they couldn’t define what they wanted the content to show or what they would do with them – their purpose. We recommended to the project sponsor - as well as the managers in the business and IT - that the project be put on hold until it could be better defined. As I am certain you will agree, it was clear that the project could not succeed.

Example #2:

In another company, a project was defined as having a mix of14 separate deliverables for the business operation and IT. These included "as is" business models and a redesign with "to be" models along with data architecture and a solution roadmap. The team asked what the goals of the redesign were so the new design would have targets. There weren’t any – just improve the operation. We then found out that the company wanted 7 different business areas involved and the company wanted the project completed in 4 weeks. This clearly indicated that the company simply didn’t understand business improvement. Company management was told that the number of business areas and deliverables were not realistic and the project could not succeed.

The problem is that a great many people simply don’t understand improvement projects. They don’t know what is involved and often believe that this work is no big deal – even though they have no experience with business improvement. This is true of both internal managers and many technology focused consulting firms. Many give/accept unrealistic goals or estimates and set the stage for failure.

The fact is that you cannot manage your way out of something that was set up to fail. It is also true that a project that is not set up to succeed if done in house (assuming the right skills are available), will not succeed if a consulting firm is contracted to do it. Success is clearly based on knowledge, skill, and creativity, but a poor foundation with unrealistic expectations simply cannot succeed.

This is where risk control begins for BPM and BPMS projects.

The road to success

Any consideration of improvement will need to start with a determination of what projects should be considered. A business partner, Dr. Mathias Kirchmer, Co-Founder of BPM-D,says: "a Value-driven BPM agenda is the starting point for realizing the full potential of the BPM-Discipline – enabling the next generation enterprise".

Creating this type of BPM based improvement agenda provides a framework for focusing on real value. It is thus one of the first steps in moving toward consistent project success.

The simple fact is that there is only so much money to go around in any budget and it must be divided somehow. By focusing on a value driven agenda, the company can begin to define value targets. These include competitive advantage, setting the framework for rapid opportunity response, cost reduction, and quality improvement. The components of a value driven agenda will vary, as will the target metrics, but this agenda is an important foundation element for determining the projects that should be funded and supported through time and talent commitment.

The real benefit of this value-driven approach is that any project that is selected through this approach will be both needed and justified. Cost will always be an issue, but the benefit will be known and agreed upon.

Also, "project goals" will be defined (and agreed upon) if a value-driven approach has been used to identify accepted projects. The fact is that projects can only succeed if there are measurable goals or at least clearly defined goals. Without clear goals, success will be determined by opinion. That is a tough road to walk down.

Obviously, estimates can only be reasonable once the project is defined and the goals are clear. However, there is a trap. This involves how projects are estimated. I have often seen projects knowingly underestimated to help ensure approval. I have also seen them padded for contingencies and overestimated. Both cases are dangerous and can be avoided by building a formal BPM/BPMS estimation tool that is based on standards related to time and cost. While this type of tool will need to evolve to adjust to the realities of each company, it will provide estimates that can be believed – and backed up.

Of course, any project estimate is simply that – an estimate. Experience should be used to feed back into the standards (time and cost estimates) in the estimation tool. In this way the estimates will become more accurate with each project.

[inlinead]

In moving forward, managers must recognize that BPM and BPMS are not about creating an IT solution to a business problem. These projects are all about creating a business solution to a business problem and enabling the solution with improved IT support, better collaboration, and better links to strategic support requirements, improved production capabilities and improved staff skills.

IT can and does set the limitations of the solution but it should not dictate the solution. This support role should not be seen as minimizing the value of IT. For most business improvement projects and all business transformation projects, IT will play a critical role in defining the solution and in building it. The issue is simply about perspective and focus. Business improvement must be driven by business SMEs

This concern about perspective is often overlooked, but it is critical. Ideally, the project team will have input from Business Architecture, Process Architecture/Management, IT (Enterprise Architecture), compliance management, and production. Project leadership should be from the business operation side and the other expertise engaged as needed. Each of these groups brings the perspective of their area and different professional disciplines to the table. It is the melding of these perspectives that form the foundation for innovation and a solution that is realistic, while meeting the goals of the project.

Once the project plan is completed, commitment of resources from these different groups needs to be formalized. I cannot overstress the need for a commitment of time and budget from the business areas that will be affected by the solution.

The simple fact is that no one outside a business can really have a final say on what is best for the area – and have it accepted. To be successful a new operating solution should not be imposed on the people it will affect. It should be designed with their input and, if possible, their formal acceptance.

The actual project should start with good "as is" models. However, few companies claim to have adequate "as is" business models. From experience, if you have comprehensive "as is" business models, they are probably out of date and will need to be updated. If they don’t exist, they must be built first and have rules and performance monitoring points laid out, with bottlenecks and problems linked to the operation activity. These models are the foundation for problem analysis, improvement analysis and an analysis of how the business area can become more aligned to delivering rapid response and competitive advantage.

Based on the business analysis the team can begin to consider the goals of the project and come up with a set of changes that should be made. These changes become the basis of the business redesign. This is where the different discipline and business area perspectives come into play to create a comprehensive, holistic solution.

Using a BPMS, the new business models map out all legacy interfaces and include data, data use, and data presentation. With the new optimized design the team will now need to determine the ripple effect of the solution and discuss the potential impact with the affected business managers. Depending on these reviews the team will need to either eliminate these impacts or gain agreement on how the probable impacts will be dealt with. This eliminates unforeseen upstream and downstream problems caused by the new solution.

If you have a BPMS you can now generate applications and tie them to interfaces. If you do not have a BPMS, you will need to work with IT and create appropriate application specs.

Creation of the application support needed for the solution, should be done in a controlled test environment. All legacy application data and interfaces can be anticipated from the detailed new solution design. It is then a matter of building small programs to feed data or take data from the applications generated by the BPMS or in a more traditional approach to application development, the small program modules created through an approach such as Agile.

Most of the better BPMS tools let you run the solution in a simulated environment and find the strengths and weaknesses – working with the business user. This simulation will be formal in some tools with a simulation modeler and "forced" in other tools by treating a "live" test as a simulation.

The solution can then be iterated and re-simulated until the performance measurement goals are met and the user likes the solution. The result is a virtual elimination of risk from a failure to meet goals and expectations.

Regardless of whether you build applications or generate them using a BPMS, once built, you can move the solution to a "production lab" and try it in a separate live environment - again fixing any problems. This will help to minimize the risk that the solution will not be acceptable or not work the way the business participants want it to.

At that point you can go into data load and cutover – but as you do that, always be ready to "back out the change" if there is a problem. If you do this, risk can be virtually eliminated.

This approach is not necessarily the fastest or least expensive approach, but it is the safest and the least disruptive. In addition, it helps eliminate the infamous "change orders" that can have a real impact on the budget and estimated time frame of the project. But, most of all, risk is minimal and the stage is set for rapid future evolution of the business and its support.

But what do you think? As always, I welcome any comments on this article or drop me a line on Daniel.morris@wendan-consulting.com.