Whether developing and updating processes as an improvement initiative, in support of a software upgrade, as part of an automation effort or introduction of a new line business, it is important to identify the required work and to estimate the time, cost and resources required to achieve the desired goals. When the purpose of the project is to develop or improve a process, it is easy to see why a project plan to identify the tasks, milestones, resources and timelines is required.
However, when the processes are not the primary focus of the work, they may be given a lower priority and relegated to the role of documentation. When this happens it often becomes difficult to justify the time and effort required to manage the process work in the same way as other key deliverables. For example, when an application is replaced or upgraded, there can be an assumption made that the actual work performed will not change.
Documentation of system functionality is identified as a deliverable but the perceived impact to the business is limited to increased processing speed, system reliability, new system functionality and improved access to information to name a few.
It is important for the business owner and project manager to ensure that sufficient effort is spent on researching and addressing the impact of the change to the way the business operates. At the same time, it is often an automatic but unwritten expectation of the business that introduction of a new application or technology provides an opportunity to improve the business processes. Unfortunately, while the business may assume this as a deliverable, if these expectations are not clearly defined, communicated and agreed to, the work effort to accomplish it will not be identified as part of the scope. This may occur when key business users are not brought into the project when the scope is being defined or when the business fails to communicate its expectations. This oversight leads to changes in scope, project delays and cost overruns.
The Process Development Life Cycle is made up of the following phases: Define, Develop, Deploy, Execute, Monitor/Measure and Revise/Improve. The work effort for each phase should be estimated and tracked. This includes estimating the cost of deployment, executing the process including ongoing support, monitoring, capturing metrics, obtaining customer feedback and performing periodic audits. Let’s take a look at what’s involved in the Development Phase as an example. This phase is made up of four main activities as shown in the diagram below.
The Analyze activity is comprised of three primary tasks. The first is documenting the current state, also known as the As-is. This task includes validating the current process flow, definitions, enablers, controls, and metrics. The second is identifying gaps in the current process and known constraints and the third is identifying key issues. During this activity potential process automation opportunities may be identified and should be evaluated as part of the Design activity.
The first task in the Design activity is documenting the future state, also known as the To-be. This task includes updating the process definitions, identifying expected changes to the process metrics, enablers and controls. Next is resolving gaps and constraints, both known and newly identified. The third task is identifying and resolving issues. The Design activity also includes evaluating potential process automation opportunities, changes to equipment and existing applications. It may also include recommendation of organizational changes,
The Build activity has four key tasks. These are developing and/or upgrading software/hardware if the process is automated; developing and documenting work procedures; designing a distribution method for communicating the processes and procedures; and, developing the training plan, materials and delivery methods.
The final activity of the Development Phase is Test. This includes performing walkthroughs with the business users and developers; running simulations to verify the process flow, projected metrics and to identify bottlenecks and/or gaps that may not be caught by the walkthroughs; and, developing and executing test plans and use cases to verify the new system functionality for automated processes. Another key task is testing the work procedures. This is a critical complement to system and user acceptance testing. These tests are not focused on how well the new system functionality works but rather on whether the associated work procedure meets the business requirements and validates its efficiency and effectiveness. How well the new system enables and supports the work procedure is also evaluated.
Once the tasks for each activity have been identified, the next step is to estimate the work effort. One method of estimating is to create a worksheet that lists the steps required to complete each task. For each step, identify the resource type, number of hours needed and the cost per hour for each. For example, the Analyze activity worksheet could be broken out by time for workshop planning, holding the workshops, compiling and documenting workshop results, verifying/updating workshop results, presenting results and obtaining signoffs. Estimating the effort involved with developing the work procedures in the Build activity could include time to research existing documentation, develop and validate content outline, write the draft, review, revise, obtain approval and sign off. Once all the steps have been identified and estimated, a tool such as Microsoft Project can be used to develop the dependencies, time lines, do resource leveling and track the progress of the work effort.
Determining the effort required can be done in different ways such as using historical statistics, estimating formulas or relying on past experience. By actively recognizing the process work as a key deliverable that must be planned, estimated, scheduled and tracked, the risk to the business will be significantly reduced when the system changes are deployed.
