Business Process Analysis for Project Life Cycles

The forty-two PMI processes are referred to as the Project Management Life Cycle. There are probably thousands of project life cycles, depending on the type of project, the enterprise needs, and the industry needs. Project life cycles are divided into phases that can be defined by specific processes.

The processes used in these phases may be repeated for future projects that will employ this same life cycle. It is natural, therefore, to use BPA to improve these processes also. For example:

• Requirements Development – Requirements are foundational to a successful software project, yet many enterprises pay inadequate attention to this key process.
• Testing – Any project life cycle that involves testing should have thorough and efficient processes.
• Transition to Operations – Most IT projects require a period of transition from the project state to the operational state.

The project life cycle example above would be described as a waterfall life cycle. That is, each phase is executed and completed prior to beginning the next phase. This traditional approach, while safe, can be ponderous for software development projects. Agile project life cycles have been developed to address this problem. Agile is a development technique that uses iterative cycles to build software in releases. It is called agile because the technique allows a dedicated co-located team to respond rapidly to change.

BPA for Project-Specific Processes

Change control can require project-specific processes. Although PMI identifies integrated change control as a standard process, the implementation must be customized for each project. Change management may vary depending on the sponsor or project scope. A PM should document the change control process including modeling with a flow chart. This process should be examined for efficiency and effectiveness throughout the project using BPA techniques.

Management of Projects Proposed Through BPA

Another reason for PMs to understand BPA is that many projects involve implementation of recommendations developed from BPA. Business Process Analysis is traditionally considered a BA responsibility. Enterprise analysis includes the activities that lead to project proposals that, if approved, become part of the enterprise project portfolio. Approved projects go through the PMI Initiating process group that includes assignment of the PM and the development of the project charter.

PMs who inherit a project of this kind have a vested interest in the BPA process. There are a number of factors to consider.

• Leadership Transition. Up to this point all work on the project has been led by a BA. It is imperative that there is a good transition from BA to PM.
• Stakeholder Information can be reused. One of the important jobs of the PM is to manage stakeholder expectations during the project. If the BA has done a thorough job of BPA then there has already been some stakeholder analysis and participation.
• Risks can be identified from BPA stakeholders
  • Are there stakeholders who have a negative view of the project?
  • Is it difficult to get on their schedules and do they cancel meetings frequently?
  • Are politics particularly difficult between business units?
  • Are there critical stakeholders that exhibit passive/aggressive/resistance attitudes?
  • Have some stakeholders reluctantly agreed to the project?
  • Are the users fearful of or dread this change?
  • Risks can be identified from the quality of the BPA effort – This can be a sensitive question but it is in the best interest of the PM and project to consider this.
    • Has the BA ever done this kind of analysis before?
    • Has the BA done an analysis of this scale before?
    • Did the BA work alone or were SMEs involved?
    • Was the team skilled in elicitation?
    • How thorough was elicitation? Were all business units consulted? Were end-users and managers consulted?
    • Were models, identified problems, and proposed solutions vetted and validated with the proper stakeholders?
    • If the business case included project costs and timing are these feasible?

The implementation of a BPA recommendation can have some specific deliverables, and PMs must make sure the appropriate deliverables are created. The project may make many changes to the processes themselves, tools used in the process, development of new roles, and training. Deliverables for process improvement implementations can include:

• Formalized process documentation
• Process guidelines and policies
• Tools such as checklists, templates, worksheets, forms
• Training materials
• Organization changes
• New or changed role and responsibility definitions
• Metrics definition and processes to collect metrics

Changes to processes often involve changes to manual activities as well as automation. Roles and responsibility changes can create discomfort which has to be anticipated and managed. The PM must understand this and include tasks in the project to smooth this transition. Again, BAs can be immensely helpful in this area because of their role as business advocates.

Managing a BPA Project

Up to this point the improvement implementation resulted from BPA performed by BAs prior to project approval. Sometimes however, the BPA is significant enough that the effort must be managed as formal project in its own right. Therefore the PM needs to have a thorough understanding how BPA works and how this can affect the project.

• Discovery – A BPA project involves a significant amount of discovery. This would include stakeholder identification from the elicitation perspective.
• Elicitation – Elicitation is discovery. Events must be planned to elicit from all stakeholders. This elicitation includes discovering the as-is situation, identifying problems, and identifying potential solutions.
• Analysis and Validation – Analysis involves sifting through elicited information, modeling processes, and documenting problems.
• Proposal – A proposal or recommendation is usually created as a project deliverable. The PM should make sure proposals are properly vetted with key stakeholders.
• Elicitation timing can be difficult to pinpoint – Many PMs are used to planning activities to happen at a certain time and riding herd on resources to get the work done. But elicitation can be difficult to plan and execute. Elicitation is one of the easiest BA disciplines to discuss but the hardest to implement.
• Elicitation is a skill – The PM should ensure that team members participating in elicitation or suited to the task by skill, discipline, and disposition. People oriented elicitation events require a level of skill in communications and facilitation.
• Stakeholders may change their mind – It is not uncommon in BPA for stakeholders to change their minds. In fact, they may not realize it or claim they have not. Here are some recommendations to handle this.
  • Elicitation results should be documented and sent to appropriate stakeholders for validation
  • Archive elicitation results, on a Sharepoint site for example, and use as backup for analysis and the proposal
  • Meet frequently with stakeholders to validate the findings. If they do change their mind the sooner that is discovered the better
  • It is more than automated tools – Many PMs have managed IT projects that create or modify tools or infrastructure.

Business Process Analysis is an important discipline for project managers. They should employ it to improve their own project management processes whether they are general project management processes, repeatable life cycle processes, or processes developed for a specific project.

Excerpted and available for download from Global Knowledge White Paper: What a Project Manager Needs to Know About Business Process Analysis

Related Courses
Business Analysis Essentials
Business Process Analysis
Requirements Development, Documentation, and Management