From Project to Program: Picking Your Next Project

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.