Category: Prince2 Certification

Project Sponsorship

Project sponsorship is the ownership of projects on behalf of the client organization.

There are two main differences between project sponsorship and project management. Firstly project sponsorship includes the identification and definition of the project whereas project management is concerned with delivering a project that is already defined, if only quite loosely.
Secondly the project sponsor is responsible for the project’s business case and should not hesitate to recommend cancellation of the project if the business case no longer justifies the project.

Project sponsors can encourage separation of decision making responsibilities between project manager and project sponsor, accountability for the realisation of project benefits, oversight of the project management function and can carry out senior stakeholder management.

The project sponsor or executive sponsor needs a range of skill sets, or at least access to skill sets which include appreciation of corporate strategy; ability to prepare a business case and profound knowledge of the organization’s operations. The project sponsor also needs to know his or her way around the organization and command respect within it. The project sponsor and project manager should form an effective partnership with the project manager orchestrating all players involved in delivering the project e.g. designers, manufacturers and contractors, whilst the project sponsor coordinates all departments of the client organization and associated stakeholders so as to integrate the delivered project into the client organization and take full benefits from it such that the business case is fulfilled.

Because the project sponsor is the ‘owner’ of the project from conception to commissioning and operation it is particularly important to achieve continuity of sponsor throughout the project yet correspondingly difficult to achieve because of the extended duration of sponsorship compared to project management.

Get More PRINCE2 Information by Clicking HERE

Change Control

15Change control within quality management systems (QMS) and information technology (IT) systems is a process—either formal or informal—used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change.

Change control is used in various industries, including in IT, software development, the pharmaceutical industry, the medical device industry, and other engineering/manufacturing industries. For the IT and software industries, change control is a major aspect of the broader discipline of change management. Typical examples from the computer and network environments are patches to software products, installation of new operating systems, upgrades to network routing tables, or changes to the electrical power systems supporting such infrastructure.

Certain portions of the Information Technology Infrastructure Library cover change control.

There is considerable overlap and confusion between change management, configuration management and change control. The definition below is not yet integrated with definitions of the others.

Change control can be described as a set of six steps:

Consider the primary and ancillary details of the proposed change. Should include aspects such as identifying the change, its owner(s), how it will be communicated and executed, how success will be verified, the change’s estimate of importance, its added value, its conformity to business and industry standards, and its target date for completion.

Impact and risk assessment is the next vital step. When executed, will the proposed plan cause something to go wrong? Will related systems be impacted by the proposed change? Even minor details should be considered during this phase. Afterwards, a risk category should ideally be assigned to the proposed change: high-, moderate-, or low-risk. High-risk change requires many additional steps such as management approval and stakeholder notification, whereas low-risk change may only require project manager approval and minimal documentation. If not addressed in the plan/scope, the desire for a backout plan should be expressed, particularly for high-risk changes that have significant worst-case scenarios.

Whether it’s a change controller, change control board, steering committee, or project manager, a review and approval process is typically required. The plan/scope and impact/risk assessments are considered in the context of business goals, requirements, and resources. If, for example, the change request is deemed to address a low severity, low impact issue that requires significant resources to correct, the request may be made low priority or shelved altogether. In cases where a high-impact change is requested but without a strong plan, the review/approval entity may request a full business case may be requested for further analysis.

If the change control request is approved to move forward, the delivery team will execute the solution through a small-scale development process in test or development environments. This allows the delivery team an opportunity to design and make incremental changes, with unit and/or regression testing. Little in the way of testing and validation may occur for low-risk changes, though major changes will require significant testing before implementation. They will then seek approval and request a time and date to carry out the implementation phase. In rare cases where the solution can’t be tested, special consideration should be made towards the change/implementation window.

In most cases a special implementation team with the technical expertise to quickly move a change along is used to implement the change. The team should also be implementing the change not only according to the approved plan but also according to organizational standards, industry standards, and quality management standards. The implementation process may also require additional staff responsibilities outside the implementation team, including stakeholders who may be asked to assist with troubleshooting. Following implementation, the team may also carry out a post-implementation review, which would take place at another stakeholder meeting or during project closing procedures.

The closing process can be one of the more difficult and important phases of change control. Three primary tasks at this end phase include determining that the project is actually complete, evaluating “the project plan in the context of project completion,” and providing tangible proof of project success. If despite best efforts something went wrong during the change control process, a post-mortem on what happened will need to be run, with the intent of applying lessons learned to future changes.

In a Good Manufacturing Practice regulated industry, the topic is frequently encountered by its users. Various industrial guidances and commentaries are available for people to comprehend this concept. As a common practice, the activity is usually directed by one or more SOPs. From the information technology perspective for clinical trials, it has been guided by another U.S. Food and Drug Administration document.

Get More PRINCE2 Information by Clicking HERE

Project Plan Document

The Project Management Plan Document also known as Project Plan Document or simply Project Plan is a document that contains the strategy for managing the project and the processes related to all areas of the project (scope, cost, schedule, quality, etc.) which are known as Knowledge Areas according to PMI. There are lots of project management processes mentioned in PMBOK® Guide, but determining what processes need to be used based on the needs of the project which is called Tailoring is part of developing the project management plan

The project plan document may include the following sections:

A High level overview of the project

The roles and authority of team members. It represents the executive summary of the Project Management Plan

The scope statement from the Project charter should be used as a starting point with more details about what the project includes and what it does not include (In-Scope and Out-Of-Scope)

A list of the project Milestones (the stop points that helps evaluating the progress of the project). This list includes the milestone name, a description about the milestone, and the date expected.

WBS which consists of Work Packages and WBS Dictionary, which defines these work packages, as well as Schedule Baseline, which is the reference point for managing project progress, are included here.

This section contains all management plans of all project aspects

Identify key resources needed for the project and their times and durations of need.

This section includes the budgeted total of each phase of the project and comments about the cost.

Acceptable levels of quality.

Some space for the project sponsor to sign off the document

Get More PRINCE2 Information by Clicking HERE

Work Project Management

Prince2 Certification
Image by/from WikiMedia Commons

Work more precise the “joint” or the “council” (3 in to 12 elements) for an “administration in project management” is the amount of effort applied to produce a deliverable or to accomplish a task (a terminal element) or a group of related tasks defined at the same level in the WBS.

Get More PRINCE2 Information by Clicking HERE

Project Risk Management

Prince2 Certification
Image by/from Kokcharov

Project risk management is an important aspect of project management. Project risk is defined by PMI as, “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”

Project risk management remains a relatively undeveloped discipline, distinct from the risk management used by Operational, Financial and Underwriters’ risk management. This gulf is due to several factors: Risk Aversion, especially public understanding and risk in social activities, confusion in the application of risk management to projects, and the additional sophistication of probability mechanics above those of accounting, finance and engineering.

With the above disciplines of Operational, Financial and Underwriting risk management, the concepts of risk, risk management and individual risks are nearly interchangeable; being either personnel or monetary impacts respectively. Impacts in project risk management are more diverse, overlapping monetary, schedule, capability, quality and engineering disciplines. For this reason, in project risk management, it is necessary to specify the differences (paraphrased from the “Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs”):

An improvement on the PMBOK definition of risk management is to add a future date to the definition of a risk. Mathematically, this is expressed as a probability multiplied by an impact, with the inclusion of a future impact date and critical dates. This addition of future dates allows predictive approaches.

Good Project Risk Management depends on supporting organizational factors, having clear roles and responsibilities, and technical analysis.

Chronologically, Project Risk Management may begin in recognizing a threat, or by examining an opportunity. For example, these may be competitor developments or novel products. Due to lack of definition, this is frequently performed qualitatively, or semi-quantitatively, using product or averaging models. This approach is used to prioritize possible solutions, where necessary.

In some instances it is possible to begin an analysis of alternatives, generating cost and development estimates for potential solutions.

Once an approach is selected, more familiar risk management tools and a general project risk management process may be used for the new projects:

Finally, risks must be integrated to provide a complete picture, so projects should be integrated into enterprise wide risk management, to seize opportunities related to the achievement of their objectives.

In order to make project management effective, the managers use risk management tools. It is necessary to assume the measures referring to the same risk of the project and accomplishing its objectives.

The project risk management (PRM) system should be based on the competences of the employees willing to use them to achieve the project’s goal. The system should track down all the processes and their exposure which occur in the project, as well as the circumstances that generate risk and determine their effects. Nowadays, the Big Data (BD) analysis appears an emerging method to create knowledge from the data being generated by different sources in production processes. According to Gorecki, the BD seems to be the adequate tool for PRM.

Get More PRINCE2 Information by Clicking HERE

Process Area Capability Maturity Model Integration (CMMI)

The Capability Maturity Model Integration (CMMI) defines a Process Area as, “A cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area.” Both CMMI for Development v1.3 and CMMI for Acquisition v1.3 identify 22 process areas, whereas CMMI for Services v1.3 identifies 24 process areas. Many of the process areas are the same in these three models.

In CMMI models, the process areas are organized in alphabetical order according to their acronym. However, process areas can be grouped according to maturity levels or process area categories.

There are Five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The process areas below and their maturity levels are listed for the CMMI for Development model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

The process areas below and their maturity levels are listed for the CMMI for Services model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined (this includes the process areas that make up the previous levels; Maturity Level 3 is made up of the process areas in Level 2 and Level 3)

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

The process areas below and their maturity levels are listed for the CMMI for Acquisition model:

Maturity Level 2 – Managed

Maturity Level 3 – Defined

Maturity Level 4 – Quantitatively Managed

Maturity Level 5 – Optimizing

There are two categories of goals and practices: generic and specific. Specific goals and practices are specific to a process area. Generic goals and practices are a part of every process area. A process area is satisfied when organizational processes cover all of the generic and specific goals and practices for that process area.

Generic goals and practices are a part of every process area.

Each process area is defined by a set of goals and practices. These goals and practices appear only in that process area.

CMMI for Development, Version 1.2 contains 22 process areas indicating the aspects of product and service development that are to be covered by organizational processes. For a summary of process areas for each model, see these quick reference documents available on the SEI website:

Purpose

The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement.

Specific Practices by Goal

Purpose

The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and
ensure that resources are provided and used effectively to support service requirements.

Specific Practices by Goal

Purpose

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance.

Specific Practices by Goal

Purpose

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Specific Practices by Goal

Purpose

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

Specific Practices by Goal

Purpose

The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.

Specific Practices by Goal

Purpose

The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability used to support management information needs.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets.

Specific Practices by Goal

Purpose

The purpose of Organizational Performance Management (OPM) is to proactively manage the organization’s performance to meet its business objectives.

Specific Practices by Goal

Purpose

The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of selected processes in the organization’s set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects.

Specific Practices by Goal

Purpose

The purpose of Organizational Training (OT) is to develop skills and knowledge of people so they can perform their roles effectively and efficiently.

Specific Practices by Goal

Purpose

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, behaves properly (i.e., possesses the required functionality and quality attributes), and deliver the product.

Specific Practices by Goal

Purpose

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

Specific Practices by Goal

Purpose

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

Specific Practices by Goal

Purpose

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

Specific Practices by Goal

Purpose

The purpose of the Quantitative Project Management (QPM) process area is to quantitatively manage the project to achieve the project’s established quality and process performance objectives.

Specific Practices by Goal

Purpose

The purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements.

Specific Practices by Goal

Purpose

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

Specific Practices by Goal

Purpose

The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Specific Practices by Goal

Purpose

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers.

Specific Practices by Goal

Purpose

The purpose of Technical Solution (TS) is to select design and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related lifecycle processes either singly or in combination as appropriate.

Specific Practices by Goal

Purpose

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

Specific Practices by Goal

Purpose

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

Specific Practices by Goal

Only changes made to the set of Process Areas are considered here. For more information about the changes made to Version 1.2, see the Version 1.2 Release Notes or for the definitive list of changes, take the CMMI Version 1.2 Upgrade Training.

Some significant improvements in CMMI-DEV, V1.3 include the following:

For a more complete and detailed list of improvements, see http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/comparison.cfm. An overview of the changes is described in http://www.benlinders.com/2011/cmmi-v1-3-summing-up/.

Table: Process Areas, Categories, and Maturity Levels

Get More PRINCE2 Information by Clicking HERE

Project Stakeholder

According to the Project Management Institute (PMI), the term project stakeholder refers to, “an individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project” (Project Management Institute, 2013). ISO 21500 uses a similar definition.

Project stakeholders are entities that have an interest in a given project. These stakeholders may be inside or outside an organization which:

The following are examples of project stakeholders:

Rather than focusing on one subset of stakeholders, Lynda Bourne advocates prioritizing all stakeholders and focusing your attention on the “most important” at this point in time. Her view of importance encompasses an assessment of the power, proximity and urgency associated with each stakeholder. She calls her methodology a “Stakeholder Circle”.

The rationale for this emphasis on decision makers is part of project stakeholder management and a key component in affecting change in an organization. John Kotter describes stakeholder analysis and stakeholder management as essential components of change management.

Get More PRINCE2 Information by Clicking HERE

Change Management

Change management (sometimes abbreviated as CM) is a collective term for all approaches to prepare, support, and help individuals, teams, and organizations in making organizational change. The most common change drivers include: technological evolution, process reviews, crisis, and consumer habit changes; pressure from new business entrants, acquisitions, mergers, and organizational restructuring. It includes methods that redirect or redefine the use of resources, business process, budget allocations, or other modes of operation that significantly change a company or organization. Organizational change management (OCM) considers the full organization and what needs to change, while change management may be used solely to refer to how people and teams are affected by such organizational transition. It deals with many different disciplines, from behavioral and social sciences to information technology and business solutions.

In a project-management context, the term “change management” may be used as an alternative to change control processes wherein changes to the scope of a project are formally introduced and approved.

Many change management models and processes are based with their roots in grief studies. As consultants saw a correlation between grieving from health-related issues and grieving among employees in an organization due to loss of jobs and departments, many early change models captured the full range of human emotions as employees mourned job-related transitions.

In his work on diffusion of innovations, Everett Rogers posited that change must be understood in the context of time, communication channels, and its impact on all affected participants. Placing people at the core of change thinking was a fundamental contribution to developing the concept of change management. He proposed the descriptive Adopter groups of how people respond to change: Innovators, Early Adopters, Early Majority, Late Majority and Laggards.

McKinsey & Company consultant Julien Phillips published a change management model in 1982 in the journal Human Resource Management, though it took a decade for his change management peers to catch up with him.

Robert Marshak has since credited the big six accounting and consulting firms with adopting the work of early organizational change pioneers, such as Daryl Conner and Don Harrison, thereby contributing to the legitimization of a whole change management industry when they branded their reengineering services as change management in the 1980s.

In his 1993 book, Managing at the Speed of Change, Daryl Conner coined the term ‘burning platform’ based on the 1988 North Sea Piper Alpha oil rig fire. He went on to found Conner Partners in 1994, focusing on the human performance and adoption techniques that would help ensure technology innovations were absorbed and adopted as best as possible. The first State of the Change Management Industry report was published in the Consultants News in February 1995.

Linda Ackerman Anderson states in Beyond Change Management that in the late 1980s and early 1990s, top leaders, growing dissatisfied with the failures of creating and implementing changes in a top-down fashion, created the role of the change leader to take responsibility for the human side of change.

In Australia, change management is now recognised as a formal vocation through the work of Christina Dean with the Australian government in establishing national competency standards and academic programmes from diploma to masters level.

In response to continuing reports of the failure of large-scale top-down plan-driven change programmes, innovative change practitioners have been reporting success with applying Lean and Agile principles to the field of change management.

The Association of Change Management Professionals (ACMP) announced a new certification to enhance the profession: Certified Change Management Professional (CCMP) in 2016.

Organizational change management employs a structured approach to ensure that changes are implemented smoothly and successfully to achieve lasting benefits.

Globalization and constant innovation of technology result in a constantly evolving business environment. Phenomena such as social media and mobile adaptability have revolutionized business and the effect of this is an ever-increasing need for change, and therefore change management. The growth in technology also has a secondary effect of increasing the availability and therefore accountability of knowledge. Easily accessible information has resulted in unprecedented scrutiny from stockholders and the media and pressure on management. With the business environment experiencing so much change, organizations must then learn to become comfortable with change as well. Therefore, the ability to manage and adapt to organizational change is an essential ability required in the workplace today. Yet, major and rapid organizational change is profoundly difficult because the structure, culture, and routines of organizations often reflect a persistent and difficult-to-remove “imprint” of past periods, which are resistant to radical change even as the current environment of the organization changes rapidly.

Due to the growth of technology, modern organizational change is largely motivated by exterior innovations rather than internal factors. When these developments occur, the organizations that adapt quickest create a competitive advantage for themselves, while the companies that refuse to change get left behind. This can result in drastic profit and/or market share losses. Organizational change directly affects all departments and employees. The entire company must learn how to handle changes to the organization. The effectiveness of change management can have a strong positive or negative impact on employee morale.

There are several models of change management:

Dr. John P. Kotter, the Konosuke Matsushita Professor of Leadership, Emeritus, at the Harvard Business School, invented the 8-Step Process for Leading Change. It consists of eight stages:

The Change Management Foundation is shaped like a pyramid with project management managing technical aspects and people implementing change at the base and leadership setting the direction at the top. The Change Management Model consists of four stages:

The Plan-Do-Check-Act Cycle, created by W. Edwards Deming, is a management method to improve business method for control and continuous improvement of choosing which changes to implement. When determining which of the latest techniques or innovations to adopt, there are four major factors to be considered:

Although there are many types of organizational changes, the critical aspect is a company’s ability to win the buy-in of their organization’s employees on the change. Effectively managing organizational change is a four-step process:

As a multi-disciplinary practice that has evolved as a result of scholarly research, organizational change management should begin with a systematic diagnosis of the current situation in order to determine both the need for change and the capability to change. The objectives, content, and process of change should all be specified as part of a change management plan. Change management processes should include creative marketing to enable communication between changing audiences, as well as deep social understanding about leadership styles and group dynamics. As a visible track on transformation projects, organizational change management aligns groups’ expectations, integrates teams, and manages employee-training. It makes use of performance metrics, such as financial results, operational efficiency, leadership commitment, communication effectiveness, and the perceived need for change in order to design appropriate strategies, resolve troubled change projects, and avoid change failures.

Successful change management is more likely to occur if the following are included:

Change management is faced with the fundamental difficulties of integration and navigation, and human factors. Change management must also take into account the human aspect where emotions and how they are handled play a significant role in implementing change successfully.

Traditionally, organizational development (OD) departments overlooked the role of infrastructure and the possibility of carrying out change through technology. Now, managers almost exclusively focus on the structural and technical components of change. Alignment and integration between strategic, social, and technical components requires collaboration between people with different skill-sets.

Managing change over time, referred to as navigation, requires continuous adaptation. It requires managing projects over time against a changing context, from inter-organizational factors to marketplace volatility. It also requires a balance in bureaucratic organizations between top-down and bottom-up management, ensuring employee empowerment and flexibility.

One of the major factors which hinders the change management process is people’s natural tendency for inertia. Just as in Newton’s first law of motion, people are resistant to change in organizations because it can be uncomfortable. The notion of doing things this way, because ‘this is the way we have always done them’, can be particularly hard to overcome. Furthermore, in cases where a company has seen declining fortunes, for a manager or executive to view themselves as a key part of the problem can be very humbling. This issue can be exacerbated in countries where “saving face” plays a large role in inter-personal relations.

To assist with this, a number of models have been developed which help identify their readiness for change and then to recommend the steps through which they could move. A common example is ADKAR, an acronym which stands for Awareness, Desire, Knowledge, Ability and Reinforcement. This model was developed by researcher and entrepreneur Jeff Hiatt in 1996 and first published in a white paper entitled The Perfect Change in 1999. Hiatt explained that the process of becoming ready for change is sequential, starting from the current level of each individual, and none of the five steps could be avoided: “they cannot be skipped or reordered”.

As change management becomes more necessary in the business cycle of organizations, it is beginning to be taught as its own academic discipline at universities. There are a growing number of universities with research units dedicated to the study of organizational change.

Get More PRINCE2 Information by Clicking HERE

Task Management

Task management is the process of managing a task through its life cycle. It involves planning, testing, tracking, and reporting. Task management can help either individual achieve goals, or groups of individuals collaborate and share knowledge for the accomplishment of collective goals. Tasks are also differentiated by complexity, from low to high.

Effective task management requires managing all aspects of a task, including its status, priority, time, human and financial resources assignments, recurrence, dependency, notifications and so on. These can be lumped together broadly into the basic activities of task management.

Managing multiple individuals or team tasks may be assisted by specialized software, for example workflow or project management software. In fact, many people[who?] believe that task management should serve as a foundation for project management activities.

Task management may form part of project management and process management and can serve as the foundation for efficient workflow in an organization. Project managers adhering to task-oriented management have a detailed and up-to-date project schedule, and are usually good at directing team members and moving the project forward.

The status of tasks can be described by the following states:

The following state machine diagram describes different states of a task over its life cycle. This diagram is referenced from IBM. A more up to date task’s state machine diagram applicable to the new continuous delivery method could be found here.

As a discipline, task management embraces several key activities. Various conceptual breakdowns exist, and these, at a high-level, always include creative, functional, project, performance and service activities.

Task management software tools abound in the marketplace. Some are free; others intended for enterprise-wide deployment purposes. Some are simple to-do lists, while others boast enterprise-wide task creation, visualization, and notification capabilities – among others. Task management is used by small to Fortune 100 size companies. It does support simple individual projects to corporate task management activities.

Project management software, calendaring software and workflow software also often provide task management software with advanced support for task management activities and corresponding software environment dimensions, reciprocating the myriad project and performance activities built into most good enterprise-level task management software products.

Software dimensions crisscrossing nearly all lines of task management products include task creation, task visualization, notifications, assign resources, compatibility, configurability, scalability, and reporting.

Get More PRINCE2 Information by Clicking HERE

Business Process Management

Prince2 Certification
Image by/from nih.gov

Business process management (BPM) is a discipline in operations management in which people use various methods to discover, model, analyze, measure, improve, optimize, and automate business processes. Any combination of methods used to manage a company’s business processes is BPM. Processes can be structured and repeatable or unstructured and variable. Though not required, enabling technologies are often used with BPM.

It can be differentiated from program management in that program management is concerned with managing a group of inter-dependent projects. From another viewpoint, process management includes program management. In project management, process management is the use of a repeatable process to improve the outcome of the project.

Key distinctions between process management and project management are repeatability and predictability. If the structure and sequence of work is unique, then it is a project. In business process management, a sequence of work can vary from instance to instance: there are gateways, conditions; business rules etc. The key is predictability: no matter how many forks in the road, we know all of them in advance, and we understand the conditions for the process to take one route or another. If this condition is met, we are dealing with a process.

As an approach, BPM sees processes as important assets of an organization that must be understood, managed, and developed to announce and deliver value-added products and services to clients or customers. This approach closely resembles other total quality management or continual improvement process methodologies.

ISO 9000 promotes the process approach to managing an organization.

…promotes the adoption of a process approach when developing, implementing and
improving the effectiveness of a quality management system, to enhance customer satisfaction by meeting customer requirements.

BPM proponents also claim that this approach can be supported, or enabled, through technology. As such, many BPM articles and scholars frequently discuss BPM from one of two viewpoints: people and/or technology.

BPMInstitute defined Business process management as:

The Workflow Management Coalition, BPM.com and several other sources use the following definition:

The Association of Business Process Management Professionals defines BPM as:

Gartner defines business process management as:

It is common to confuse BPM with a BPM suite (BPMS). BPM is a professional discipline done by people, whereas a BPMS is a technological suite of tools designed to help the BPM professionals accomplish their goals. BPM should also not be confused with an application or solution developed to support a particular process. Suites and solutions represent ways of automating business processes, but automation is only one aspect of BPM.

The concept of business process may be as traditional as concepts of tasks, department, production, and outputs, arising from job shop scheduling problems in the early 20th Century. The management and improvement approach as of 2010[update], with formal definitions and technical modeling, has been around since the early 1990s (see business process modeling). Note that the term “business process” is sometimes used by IT practitioners as synonymous with the management of middleware processes or with integrating application software tasks.

Although BPM initially focused on the automation of business processes with the use of information technology, it has since been extended[by whom?] to integrate human-driven processes in which human interaction takes place in series or parallel with the use of technology. For example, workflow management systems can assign individual steps requiring deploying human intuition or judgment to relevant humans and other tasks in a workflow to a relevant automated system.

More recent variations such as “human interaction management” are concerned with the interaction between human workers performing a task.

As of 2010[update], technology has allowed the coupling of BPM with other methodologies, such as Six Sigma. Some BPM tools such as SIPOCs, process flows, RACIs, CTQs and histograms allow users to:

This brings with it the benefit of being able to simulate changes to business processes based on real-world data (not just on assumed knowledge). Also, the coupling of BPM to industry methodologies allows users to continually streamline and optimize the process to ensure that it is tuned to its market need.[full citation needed]

As of 2012[update] research on BPM has paid increasing attention to the compliance of business processes. Although a key aspect of business processes is flexibility, as business processes continuously need to adapt to changes in the environment, compliance with business strategy, policies, and government regulations should also be ensured.
The compliance aspect in BPM is highly important for governmental organizations. As of 2010[update] BPM approaches in a governmental context largely focus on operational processes and knowledge representation.
There have been many technical studies on operational business processes in the public and private sectors, but researchers rarely take legal compliance activities into account—for instance, the legal implementation processes in public-administration bodies.

Business process management activities can be arbitrarily grouped into categories such as design, modeling, execution, monitoring, and optimization.

Process design encompasses both the identification of existing processes and the design of “to-be” processes. Areas of focus include representation of the process flow, the factors within it, alerts and notifications, escalations, standard operating procedures, service level agreements, and task hand-over mechanisms. Whether or not existing processes are considered, the aim of this step is to ensure a correct and efficient new design.

The proposed improvement could be in human-to-human, human-to-system or system-to-system workflows, and might target regulatory, market, or competitive challenges faced by the businesses. Existing processes and design of a new process for various applications must synchronize and not cause a major outage or process interruption.

Modeling takes the theoretical design and introduces combinations of variables (e.g., changes in rent or materials costs, which determine how the process might operate under different circumstances).

It may also involve running “what-if analysis”(Conditions-when, if, else) on the processes: “What if I have 75% of resources to do the same task?” “What if I want to do the same job for 80% of the current cost?”.

Business process execution is broadly about enacting a discovered and modeled business process. Enacting a business process is done manually or automatically or with a combination of manual and automated business tasks. Manual business processes are human-driven. Automated business processes are software-driven. Business process automation encompasses methods and software deployed for automating business processes.

Business process automation is performed and orchestrated at the business process layer or the consumer presentation layer of SOA Reference Architecture. BPM software suites such as BPMS or iBPMS or low-code platforms are positioned at the business process layer. While the emerging robotic process automation software performs business process automation at the presentation layer, therefore is considered non-invasive to and de-coupled from existing application systems.

One of the ways to automate processes is to develop or purchase an application that executes the required steps of the process; however, in practice, these applications rarely execute all the steps of the process accurately or completely. Another approach is to use a combination of software and human intervention; however this approach is more complex, making the documentation process difficult.

In response to these problems, companies have developed software that defines the full business process (as developed in the process design activity) in a computer language that a computer can directly execute. Process models can be run through execution engines that automate the processes directly from the model (e.g., calculating a repayment plan for a loan) or, when a step is too complex to automate, Business Process Modeling Notation (BPMN) provides front-end capability for human input. Compared to either of the previous approaches, directly executing a process definition can be more straightforward and therefore easier to improve. However, automating a process definition requires flexible and comprehensive infrastructure, which typically rules out implementing these systems in a legacy IT environment.

Business rules have been used by systems to provide definitions for governing behavior, and a business rule engine can be used to drive process execution and resolution.

Monitoring encompasses the tracking of individual processes, so that information on their state can be easily seen, and statistics on the performance of one or more processes can be provided. An example of this tracking is being able to determine the state of a customer order (e.g. order arrived, awaiting delivery, invoice paid) so that problems in its operation can be identified and corrected.

In addition, this information can be used to work with customers and suppliers to improve their connected processes. Examples are the generation of measures on how quickly a customer order is processed or how many orders were processed in the last month. These measures tend to fit into three categories: cycle time, defect rate and productivity.

The degree of monitoring depends on what information the business wants to evaluate and analyze and how the business wants it monitored, in real-time, near real-time or ad hoc. Here, business activity monitoring (BAM) extends and expands the monitoring tools generally provided by BPMS.

Process mining is a collection of methods and tools related to process monitoring. The aim of process mining is to analyze event logs extracted through process monitoring and to compare them with an a priori process model. Process mining allows process analysts to detect discrepancies between the actual process execution and the a priori model as well as to analyze bottlenecks.

Predictive Business Process Monitoring concerns the application of data mining, machine learning, and other forecasting techniques to predict what is going to happen with running instances of a business process, allowing to make forecasts of future cycle time, compliance issues, etc. Techniques for predictive business process monitoring include Support Vector Machines, Deep Learning approaches, and Random Forest.

Process optimization includes retrieving process performance information from modeling or monitoring phase; identifying the potential or actual bottlenecks and the potential opportunities for cost savings or other improvements; and then, applying those enhancements in the design of the process. Process mining tools are able to discover critical activities and bottlenecks, creating greater business value.

When the process becomes too complex or inefficient, and optimization is not fetching the desired output, it is usually recommended by a company steering committee chaired by the president / CEO to re-engineer the entire process cycle. Business process reengineering (BPR) has been used by organizations to attempt to achieve efficiency and productivity at work.

A market has developed for enterprise software leveraging the business process management concepts to organize and automate processes. The recent convergence of this software from distinct pieces such as business rules engine, business process modelling, business activity monitoring and Human Workflow has given birth to integrated Business Process Management Suites.
Forrester Research, Inc recognize the BPM suite space through three different lenses:

However, standalone integration-centric and document-centric offerings have matured into separate, standalone markets.

Rapid application development using no-code/low-code principles is becoming an ever prevalent feature of BPMS platforms. RAD enables businesses to deploy applications more quickly and more cost effectively, while also offering improved change and version management. Gartner notes that as businesses embrace these systems, their budgets rely less on the maintenance of existing systems and show more investment in growing and transforming them.

While the steps can be viewed as a cycle, economic or time constraints are likely to limit the process to only a few iterations. This is often the case when an organization uses the approach for short to medium term objectives rather than trying to transform the organizational culture. True iterations are only possible through the collaborative efforts of process participants. In a majority of organizations, complexity requires enabling technology (see below) to support the process participants in these daily process management challenges.

To date, many organizations often start a BPM project or program with the objective of optimizing an area that has been identified as an area for improvement.

Currently, the international standards for the task have limited BPM to the application in the IT sector, and ISO/IEC 15944 covers the operational aspects of the business. However, some corporations with the culture of best practices do use standard operating procedures to regulate their operational process. Other standards are currently being worked upon to assist in BPM implementation (BPMN, enterprise architecture, Business Motivation Model).

BPM is now considered a critical component of operational intelligence (OI) solutions to deliver real-time, actionable information. This real-time information can be acted upon in a variety of ways – alerts can be sent or executive decisions can be made using real-time dashboards. OI solutions use real-time information to take automated action based on pre-defined rules so that security measures and or exception management processes can be initiated.
Because “the size and complexity of daily tasks often requires the use of technology to model efficiently” when resources in technology became increasingly widespread with general availability to businesses to provide to their staff, “Many thought BPM as the bridge between Information Technology (IT) and Business.”

There are four critical components of a BPM Suite:

BPM also addresses many of the critical IT issues underpinning these business drivers, including:

Validation of BPMS is another technical issue that vendors and users must be aware of, if regulatory compliance is mandatory. The validation task could be performed either by an authenticated third party or by the users themselves. Either way, validation documentation must be generated. The validation document usually can either be published officially or retained by users.

Cloud computing business process management is the use of (BPM) tools that are delivered as software services (SaaS) over a network. Cloud BPM business logic is deployed on an application server and the business data resides in cloud storage.

According to Gartner, 20% of all the “shadow business processes” are supported by BPM cloud platforms. Gartner refers to all the hidden organizational processes that are supported by IT departments as part of legacy business processes such as Excel spreadsheets, routing of emails using rules, phone calls routing, etc. These can, of course also be replaced by other technologies such as workflow and smart form software.

The benefits of using cloud BPM services include removing the need and cost of maintaining specialized technical skill sets in-house and reducing distractions from an enterprise’s main focus. It offers controlled IT budgeting and enables geographical mobility.[full citation needed].

The emerging Internet of things poses a significant challenge to control and manage the flow of information through large numbers of devices. To cope with this, a new direction known as BPM Everywhere shows promise as a way of blending traditional process techniques, with additional capabilities to automate the handling of all the independent devices.