Active Business Involvement - Recipe for BPM Success

	Bookmark This Page Email This Page Format for Printing Submit an Article Read More Articles
	Related Tools & Articles BPM Solution Brings Big Changes through Small Processes Defining an Enterprise Business Process Architecture 4 BPM Success Stories
	Discussion Forum "I'm leading a team to look at options to revamp an existing process in which we have identified people-tasks which may be able to be done using technology and data reports..." Contribute to this Discussion

By Chandra Sekhar Ramaraju and Venugopal Juturu

Many organizations outsource their IT projects due to a lack of required expertise and time internally, and in order to minimize internal project costs and delivery times. Business process management (BPM) projects are no exception to outsourcing. Something not well understood in outsourcing planning is the engagement model, which defines the required level of active involvement, roles and responsibilities of the external consultants, internal business and IT teams, and other stakeholders.

Unlike typical IT projects, BPM projects need a higher level of active participation from the business team in order to successfully realize the project goals, mainly due to the very nature of activities involved in BPM projects.

Traditional IT Projects Vs. BPM Projects

Sometimes an organization ends up being not as involved as they need be when outsourcing. Thinking about a BPM project as any other IT project, lack of proper co-ordination between project teams and missing vital inputs from internal business team are common problems that can be avoided by early, active participation. One fundamental difference between a traditional IT project and a BPM project is that for a traditional IT project, the focus is automating the process, thereby reducing cycle time. On the other hand, a BPM project’s focus is to bring a change in the process first and then implement a solution in such a way that it reduces cycle time, brings transparency to the process and contains enough process controls for continuous improvement. Typically in BPM projects, more than half of the necessary work involves understanding the current processes and their issues in order to find a suitable solution.

Key Roles in Outsourced Projects

Numerous actors are involved in outsourced projects. Depending on the complexity of an organization, engagement models vary but Figure 1 shows a typical group.

Figure 1: Team Composition in  Typical Outsourced Projects

Customer/Buyer/Outsourcer Organization

1. Internal business team (SMEs): These are the key resources from the customer organization – also known as business process owners. Most of the projects are geared toward addressing the issues faced by these people due to the limitations in the existing systems/solutions. These internal business SMEs provide key inputs such as an "as-is" state of the current process, business issues faced, etc. These SMEs also define their expectations from the proposed solution. In general, these business SMEs are busy and their time is limited. Project success generally depends upon their active involvement.
2. Internal IT team (optional): These are the resources from the customer organization. They support the supplier IT team during the development and maintenance of IT applications.

Service Provider/Supplier Organization

1. External business/process consultants: As internal business SMEs are often already occupied, service provider organizations bring in process consultants to perform the same role as internal business SMEs. These external business consultants typically possess domain knowledge and have exposure toward BPM technologies. These people act as a bridge between the IT teams and internal business SMEs.
2. External IT team: These are the resources from the service provider organization. They are responsible for building the IT solution.

In addition to the above roles, other important roles (such as project management, quality and testing) are taken up by either the customer or supplier organization depending on the engagement model defined between the two.

Though it is an indisputable fact that external consultants can provide benefits, the internal process stakeholders (both business SMEs and the IT team) do need to be involved at appropriate level at various stages of a BPM lifecycle, mainly because they are the ones involved in the day-to-day activities and are familiar with real problem areas and issues. These internal process stakeholders are better able to verify the viability of suggested improvements from external consultants and to derive best out of them.

Traditional Software Development Lifecycle Vs. BPM Lifecycle

Traditional Software Projects

The traditional software development lifecycle typically involves these four phases:

1. Planning and requirements
2. Design
3. Build
4. Deploy and sustain

Figure 2 shows the extent of involvement of business team and the IT team. In this example, the business team is process owners from the organization. The IT team consists of both an internal IT team and an outsourced vendor IT team.

Figure 2: Traditional Application Lifecycle

Except for the initial planning and requirements collection phase, the extent of involvement of the business team is low. After the collection phase, the IT team typically works in isolation until the end of the project. Table 1 shows the typical activities at various stages of traditional IT projects.

Table 1: Activities in Traditional IT Projects
Project Phase	Business Team	IT Team
Planning and Requirements Collection	• Review and approve business case • Provide business requirements	• Develop business case • Participate in business requirements and validate • Develop system requirements and use cases • Develop acceptance criteria
Design	• Review and accept prototype	• Develop prototype • Validate and demonstrate prototype to business team • Develop application architecture • Develop IT bill of materials (hardware) • Develop application design • Develop detailed design • Develop test plans and test cases
Build	• Review and approve end-user acceptance test plans	• Application coding • Review and approve integration test plans and test cases • Perform testing and QA activities • Sample verification of application coding • Develop application documentation
Deploy and Sustain	• Perform user acceptance testing	• Perform functional testing • Perform Integration testing • Routine IT maintenance and monitoring • Deploy application into staging and production • Transition to IT operations

BPM Projects

BPM projects typically involve four phases:

1. Model
2. Analyze
3. Implement
4. Monitor

Figure 3 shows the extent of involvement required from both the business and IT teams.

Figure 3: BPM Lifecycle

The extent of involvement required from the business team is high during the most of the lifecycle. Business teams do need to actively participate during the modeling and analysis phases to provide the necessary information as well as validate the deliverables. Their involvement lessens during the implement phase and again increases during the business activity monitoring phase.

Most often, business team consists of both internal business team members and process consultants from an outsourced vendor. Figure 5 shows the extent of involvement of both groups.

Figure 4: Internal and External Business Teams’ Involvement in Lifecycle

During the model phase, the internal business team plays a major role while the external business team gradually picks up on the processes, constraints and opportunities. During the analyze phase, the involvement of external process consultants is more about proposing alternate solutions to the problem, freeing internal process owners for their busy regular jobs’ both the teams, however, collaboratively work to develop the best suitable solution for the organization. During the implement phase, there is little participation from both the business teams – the external process consultants will provide any required support for IT team. Finally, during the monitor phase, the internal business team starts taking an active role – toward the end of the lifecycle, they get full control of the overall BPM solution. Table 2 shows the activities involved in BPM projects.

Table 2: Activities in BPM Projects
Project Phase	Internal Business Team (SMEs)	External Business/Process Consultants	Internal IT Team
Model	• Develop project governance structure • Process prioritization • Provide necessary information on as-is processes to model • Provide information on known problem areas • Review and approval of as-is process models	• Develop organization’s modeling standards and BPA/BPM product selection • Identify the necessary process attributes to be captured during process discovery • Conduct workshops and extract as-is business processes and all attributes for modeling	• Provide existing application details for mapping to process steps
Analyze	• Thorough review of the analysis work carried out • Review and approval of process change recommendations • Review and approval of business case	• Static and dynamic analysis of processes (Six Sigma, Lean, simulation, etc.) • Identify process improvement • Design the "to-be" processes • Develop business case for implementing to-be processes • Conduct change impact analysis	• Review and provide inputs to business team on BPM implementation risks (if any)
Implement	• Participate in change management and governance activities as needed	• Act as single point of contact for IT staff on business related gaps • Perform functional and end-user testing • Prepare end-user documentation • Provide end-user training	• Re-factor the existing applications as needed • Implement the desired functionality • Perform testing and QA activities • Review test plans and test cases • Develop application documentation
Monitor	• Monitor process performance • Provide necessary feedback to the IT teams for any further changes	• Transition knowledge to internal business	• Provide routine IT maintenance and monitoring • Deploy the new processes onto the staging and production environments • Transition to sustenance team

Conclusion

Unlike traditional IT projects, BPM projects are more demanding. In order to be successful in BPM initiatives, it is important to have a clearly defined strategy toward teaming, roles and responsibilities. Considering the strategic nature of BPM initiative, organizations have to think upfront and develop checks and balances to be able to effectively deal with teaming issues.

Before embarking on a BPM journey, organizations have to have top level management buy-in to actively engage the business teams on the projects. The probability of success of BPM initiatives are enhanced by ensuring that there is adequate business team participation in every phase of a BPM lifecycle.

Acknowledgment

We would like to thank Dr. Udaya Bhaskar Vemulapati, general manager at Wipro Technologies, for giving us encouragement and support in creating this article.

About the Authors: