In the past, large IT projects would deploy new applications or upgrades and be considered failures not because the technology failed but because the impact to the business wasn't fully understood or even considered as a criteria for the success of the project. Similarly, many process improvement initiatives would meet the same fate because they focused on the execution of business tasks and, if technology was considered at all, it was identified for a potential and separate future IT project. Unfortunately by the time the project was approved and the funds allocated the original process improvement deliverables would be outdated or overshadowed by the technology deliverables. With the increased interest in Business Process Management, the relationship between project management and process management methodologies has become a topic for serious consideration when organizations consider launching new projects and/or process improvement initiatives. This relationship when treated as a partnership of equals can improve the success of both the technical and the process improvement interests. Understanding how the Project Life Cycle (PLC) and the Process Life Cycle (PrLC) interact is a beginning to exploring this relationship. Let's start with a basic definition for Business Process.

A Business Process is uniquely definable; has a defined set of activities that break down into increasingly more granular steps and an agreed to set of sequences; is enabled and/or constrained by culture, skills, policies and rules, laws, measurement/reward systems, workflow design, information systems and facilities; often crosses organizational boundaries; and follows a formal life cycle.

To better show the relationship to the Project Life Cycle, the Develop phase of the Process Life Cycle is expanded to the next level of detail made up of four sub-phases: Analyze, Design, Build and Test. Analyze documents the current state including capturing metrics; validates and updates process flows and definitions with the Stakeholders; identifies current enablers, controls, and constraints; and identifies gaps and issues. Design develops and documents the future state; creates/updates process flows and definitions; identifies new enablers, controls and constraints; and resolves gaps and issues. The third sub-phase is Build and includes coding, configuration, acquiring hardware, and software for processes that will be automated. For manual processes, it includes equipment, tools, and other supplies needed to execute the process. Work procedure documentation is another key deliverable for both automated and non-automated processes. This documentation includes both training materials and user guides. Testing is the final sub-phase and includes walkthroughs, simulations, and field tests. Whether the process is automated or manual, testing the process and its integration into the end-to-end workflow is a critical activity.

For this discussion, the Project Life Cycle for a technology project is made up of the following phases: Initiate, Define Scope, Define Requirements, Build, System Test, User Acceptance, Deploy and Close.

The first phase of the PrLC, the Define phase, begins in parallel to the Define Scope phase of the PLC. During this phase of the PLC new processes needed and existing processes that will be impacted are identified and are input to the Define phase of the PrLC. The Define phase delivers a high-level statement outlining: what the process is (Purpose); what it will do, what it will not do (Process Scope); expected impact to the organization (Impact); who will be responsible for its success (Owner); and what other groups have a vested interest (Stakeholders).

Next the Define Requirements phase of the PLC and the Analyze phase of the PrLC are started. The current state of existing processes are documented, definitions agreed to, current enablers, controls and constraints validated, and outstanding issues and gaps identified. These PrLC deliverables are used in the development of both business and system requirements and become part of the project's requirements documentation.

During the next two phases of the PLC, Develop Detail Specifications and Build, the PrLC phases of Design and Build are executed. This includes changes to existing processes as well as development of new. In the Design phase the future state is documented, definitions updated, new enablers, controls and constraints identified, gaps and issues are resolved. The Build phase will vary depending on whether this is an automated or manual process. As noted above, the Build phase may include coding, configuration, acquiring hardware and software, equipment, tools, and other supplies needed to execute the process. This includes the development of work procedure documentation which is input to the Training Life Cycle. Building the application and building the process together as two inter-dependent deliverables improves the odds that both will meet the business requirement defined in the previous phases.

In conjunction with the System Test and User Acceptance Test phases of the PLC, the business process is also tested and deployed. The Test phase of the PrLC includes walkthroughs, simulations, and field tests. Testing the business process is often forgotten during System and User Acceptance Tests. Following the PrLC in parallel to the PLC will help avoid this omission. The Testing Life Cycle plays a key role here as well.

Although it may seem strange to have the Deploy phase of the PrLC before the Deploy phase of the PLC, it is actually a prerequisite for the latter. This phase of the PrLC deals with staffing issues such as hiring, redeployment, and reduction of staff as well as addressing potential impacts to Bargaining Unit agreements. It also includes Training plans which will tie to the Training Life Cycle. Training is a key deliverable for both the PLC and the PrLC and these deliverables need to be integrated to ensure completeness and avoid redundancy.

Once the system is deployed, the Process becomes part of the business routine. The Deploy phase of the PLC kicks off the Execute phase of the PrLC.

Since a project by definition is finite and therefore has an ending, the Project Life Cycle ends with the Close phase. However, the Process Life Cycle by its nature is continuous and, therefore, the Monitor/Measure and Revise/Improve phases do not correspond to any phase within the PLC.
While the coordination of these two Life Cycles takes planning and dedication, the benefits to both the success of the project and the effectiveness of the business process make it worthwhile. As previously mentioned, the Process Life Cycle also interacts with the Testing and Training Life Cycles. However, that discussion will need to be left for another time.

Sandra Lusk has over twenty years experience in system and process design and development working with utility, transportation, logistics, insurance and banking organizations in the US, Canada, Australia, New Zealand and Wales, UK. She has taught at Algonquin College in Ontario and at the Saskatchewan Institute of Applied Science and Technology. As a Senior Business Process Management Consultant, her responsibilities included development of a BPM Governance, training, mentoring and support of business improvement initiatives. A graduate in Computer Science from the University of Regina, she is a certified Project Management Professional (PMP) and is currently President of the Association for Business Process Management Professionals, Portland Chapter.
http://www.bpminstitute.org