Sandy Kemsley's Blog - From Project to Program: Picking-Your-Next-Project
Sandy Kemsley

From Project to Program: Picking Your Next Project

By Sandy Kemsley

Read Time: 7 Minutes

In my last post, I went through the details of what to look for in a post-implementation review (PIR) after your first intelligent automation project:

  • Identify good and bad uses of the technology in the context of your project.
  • Determine what organizational changes still need to be made, and how to manage resistance to the project.
  • Align the project implementation with your end-to-end processes and organizational capabilities.
  • Identify reusable methodologies and components.

Basically, your PIR helps you to figure out what worked and what didn’t work, both in a technology and organizational sense, and provide input into determining your path forward. No one expects your first project to be 100% successful, but you are definitely expected to learn from your mistakes and correct those on subsequent projects.

Next up is to figure out where to go from here.

You may want to build on your first project’s success, or use those best practices for a different business area. But how do you decide?

A good place to start is with the third outcome from your PIR, namely, the alignment of the first project with your core processes and capabilities. This will highlight some of the areas that can also benefit from a similar treatment, and help you identify your second project; usually this falls into one of three categories:

Add functionality to the first project.

When you were able to avoid scope creep in the first project and implement a somewhat limited “minimum viable product” – big enough to be relevant, but small enough to be manageable – you probably have some work that you want to do on that first implementation. This almost always includes integration with other systems, and some degree of automation of manual steps.

Let’s say, for example, that your first project automated the general process within a department and linked to one or two of the more modern systems. Although this would reduce some of the non-value-added manual steps, as well as providing better oversight and analytics about the business area, there are older legacy systems that you did not integrate in the first project. Workers will receive their assigned tasks via the new system, but still need to copy and paste information between that system and the legacy system. The goal is not to eliminate workers from a process if they are adding value, but to reduce the amount of error-prone “swivel-chair integration” that they are doing by automating the integration with all of the systems involved. This leaves the workers free to focus on solving the problems at hand, not on whether they copied and pasted the current information.

Survey the actual users of the system to figure out the best candidates for integration and automation, based on what’s taking them the most time without adding a lot of value. Management may also have some new ideas on what metrics that they need in the new processes. Don’t get caught in the trap of just implementing what was specified before you started implementing the first project, since new ways of working and new ideas will emerge. It’s also important not to try to do everything at once: your goal should be to have ever-evolving processes across your organization, not a one-and-done implementation.

Often the additional integration requires input from resources that were not used on the first project, such as having the mainframe developers or third-party service providers create an API that you can use for automating those interfaces, or adding robotic process automation (RPA) to the technology mix. This can add costs and complexity, so you want to be sure that you are prioritizing the integrations that will add the most value overall.

Expand the reach of the first project to cover your end-to-end process.

If your first project took on a small portion of a larger end-to-end process, consider leaving the first implementation as it is, and extend the same capabilities to other participants in the overall process.

In the previous scenario, your first project automated a general departmental process and provided some integration and automation. However, handoffs to related departments were still done manually by emailing spreadsheets. In this case, the greater benefit for the second project may be to extend the automated process to the other departments so that the work is moved between departments in a standardized fashion. Most of the work being done at each step will still be done in the same way, but the work assignment, delivery and management is now automated. This provides improvements in compliance and control, and also provides the infrastructure for adding more functionality to the individual departments in later stages.

The users of the first project can provide input into where you should be expanding the implementation, but also consider input from management, process analysts, the other departments to be impacted, and even customers to identify which expansions could most improve the customer experience.

One of the often-overlooked benefits of this approach is that process analytics from this expanded implementation provide valuable insights into the operation of the end-to-end process. This can help to identify more radical improvements, such as reorganizing work between (not just within) departments, and highlight areas for increased automation.

Take on a completely unrelated business area that is in need of improvement.

If there are other areas in your organization that are under stress, you can shift gears and apply the learning from the first project to a completely different area. The first project needs to be in a stable state, providing sufficient improvement to the business area that there will be little resistance to continuing in the current state until (possibly) much later.

Moving to a different business area for the second project can be a bit of a fire-fighting approach, and you need to be careful that you’re not just chasing after the department head who is yelling the loudest. Taking a step back and looking at the potential projects in the context of your core end-to-end processes often helps to see which are really the most important for the near term, and which can wait until you have increased the resources available.

In this case, you need to leverage as much as possible from what you learned in the first project: designing with your goals in mind, best practices and design patterns for using the technology, and how to manage change. These can be difficult to achieve without at least the start of a center of excellence (CoE) to collect your best practices and related information.

In general, I would recommend one of the first two approaches before taking on a different business area as your second project, since you really need at least two projects to fully understand the new technology and how it is best applied to your business. However, by increasing your resources at the same time and supporting them with a fledgling CoE, you can start to work on projects for different business areas soon after you start that second project.

That brings me to the topic for my next post: how to use what you learned in that first project, and the beginning of subsequent projects, to bootstrap a CoE. A CoE doesn’t initially need to be a project or department in itself, and the creation of it should not delay projects, but it can start simply with a collection of information that supports growing project teams. Next time, I’ll discuss how to get your CoE kicked off, and how to grow it to support all of your intelligent automation projects.

Follow Sandy on her personal blog Column 2.

Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ blog

View all

Learn how it works

Request Demo

Confirm your budget

Request Pricing

Discuss your project

Request Meeting