From Project to Program: Expanding Across the Organization

In the first two parts of the “From Project to Program” series, I covered how to do a post-implementation review of your first process automation project, and how to pick the next process automation project after you had the first one under your belt.

In this third and final part of the series, I’ll look at how to expand what you’ve done in the first couple of projects to an organization-wide program of process automation and improvement. There are a lot of pointers in here that I’ve written about in greater depth in earlier posts, so I’ll be referring back to those as I go.

There are a number of keys to success once you get beyond those first couple of projects:

• Aligning processes vertically and horizontally
• Measuring success (and failure)
• Sharing ideas and knowledge
• Sharing code and technology
• Sharing costs and efforts
• Spreading the word

Alignment

The first projects are often a bit of a learning experience, where you’re learning about how to use the tools and techniques of improving and automating processes. Often these can be departmental in nature, and you may not have had a chance to look at them in the large context of your business architecture and corporate goals. If you go back to the posts that I did on goal alignment and end-to-end processes, this will get you started on with vertical alignment between corporate goals and departmental KPIs, and horizontal alignment with end-to-end processes across business units to ensure customer satisfaction.

Start to align the KPIs of the processes that you’ve already automated with the corporate goals in your business architecture: are you performing activities or rewarding workers that don’t align with the top-level objectives? Reconsider what you’re doing in those processes based on that alignment, and adjust accordingly. Similarly, position the process that you’ve automated in the end-to-end process model for your entire value chain: does it serve the needs of the end-to-end process, or is it just locally optimized? Even if the other parts of the process aren’t automated yet, you want to be prepared to optimize the entire chain, not just your first projects’ processes. Keep in mind that you may be eventually designing and implementing loosely-coupled processes rather than a single end-to-end orchestration.

Measurement

The post-implementation review is a great place to get started with measuring the success (and failure) of your first process automation projects. To expand these concepts across the organization, you need to move from a one-time review of a project to ongoing monitoring and measurement of your processes. In the past, this was often done by just monitoring what was happening in your process automation system, but there can be an entire alphabet soup of different systems involved in your projects: business process management (BPMS), decision management (DM), case management (CM), custom/legacy systems, enterprise resource planning (ERP), customer relationship management (CRM) and more. Measuring your entire process automation will require gathering data from all of the systems involved into a common visualization: an enterprise process dashboard. Both vertical and horizontal alignment are important here, since you need to show the direct vertical alignment from measured KPIs to corporate goals, and show the performance of end-to-end processes.

Beyond the ongoing measurement of the process automation performance, you also need to consider the impacts to the organization on a larger scale. For example, how is automation and improved productivity changing your workforce, both in terms of skills and management? How is a more efficient end-to-end process shortening your time to market? Many of these measurements will need to be considered only have your have had your processes automated for some period of time and can look back on weeks or months of data.

Sharing Knowledge

Sharing ideas and technology are where a center of excellence (CoE) comes in, and I’ve previously written about the need for a business automation CoE rather than a separate CoE for each discipline or product. Implementing a CoE helps improve your organization’s process maturity, which in turn improves productivity, flexibility and innovation. I won’t go into everything that you want to include in your CoE, but in short it should include the following:

• A repository of best practices, training/referend materials, and code
• A skills-sharing marketplace for knowledge, mentoring and training
• Governance of process automation projects through vision, methodologies and project reviews
• Community involvement to share problem-solving techniques and coordinate end-to-end process automation efforts

The point in time when you’re moving from your initial projects to an organization-wide program is the best time to start building your CoE using the resources from those projects.

As your first project matures and some of the earlier resources (such as designers/architects) are not required full-time on the project, you can bootstrap create the CoE using those resources. They should document what they have learned in the first project so far, particularly tool usage, best practices and methodologies. As a second project starts, it can use some of the same people resources as well as the content that they have created to get that project off to a faster start. As the first project ends, more resources can contribute material and knowledge to the CoE, and can be move through to the second project. By the time that you’ve completed two projects you will have the core of your CoE repository in place, as well as some of your governance procedures and resources for skills development.

Sharing Costs

Knowledge isn’t the only thing that will be shared as you roll out a process automation program across the enterprise: you also need to consider how to share costs of the technology and resources. Some people will remain in the CoE for a longer period of time, but provide services to individual projects: this resources usage needs to be measured and accounted for in some way, so that the cost of the CoE is spread across the enterprise rather than just the first two projects that bootstrapped it.

Sharing technology costs used to be a complex calculation with on-premise systems, since you would have to consider costs for hardware, software and data center resources. This is now much easier with cloud-based systems that can measure usage by each project/department, although there will still be overhead for some amount of administration. There may also be on-premise costs for bridging components that work between the cloud-based systems and your legacy systems.

Evangelizing Success

Once you’ve experienced some degree of success with your first projects, you might think that everyone else in the organization will be knocking at your door to work with them next. That’s probably an optimistic view: most organizations have a certain amount of inertia that resists change, with barriers ranging from regulations to technology to culture. In order to roll out process automation across the enterprise, you will need to evangelize to gain new “converts”. This is essentially an internal marketing role, where you communicate the successes of the early projects, and help other parts of the organization to understand what they can expect in terms of benefits as well as roadblocks along the way.

A good evangelist is someone who benefited the most from the initial projects, for example, an operational manager who has a view of both individual team member metrics as well as the departmental overview. Recruiting an internal resource like this to “sell” the concept across the organization is essential, because they will speak from a position of deep understanding: not just an all-positive sales spin, but what they achieved and what had to happen to make it work. They will have negative things to say about the technology and the change management, but if they saw an overall success, then it will be a compelling story.

Documenting an internal case study will be an important tool in communicating success to other parts of the organization. This may be something that one of the product vendors would assist with in exchange for being able to use it publicly, or it could be purely internal. Be sure to include the vertical and horizontal alignment factors, what you learned from your post-implementation review, the continuous improvement benefits of the enterprise process dashboard, and the resources available in the CoE.

Once you have an evangelist (or two) who want to share the information, and a documented case study, you can spread the word across the organization using a road show (virtual or in-person) or open house.

In summary, moving from your initial projects to an organization-wide program of process automation is more than just doing more of the same: you need to consider how to leverage what you’ve already learned to build something that is greater than the sum of the parts.

Follow Sandy on her personal blog Column 2.