Tag: PRINCE2 certification preparation

Tasks in Project Management

In project management, a task is an activity that needs to be accomplished within a defined period of time or by a deadline to work towards work-related goals. It is a small essential piece of a job that serves as a means to differentiate various components of a project. A task can be broken down into assignments which should also have a defined start and end date or a deadline for completion. One or more assignments on a task puts the task under execution. Completion of all assignments on a specific task normally renders the task completed. Tasks can be linked together to create dependencies.

Tasks completion generally requires the coordination of others. Coordinated human interaction takes on the role of combining the integration of time, energy, effort, ability, and resources of multiple individuals to meet a common goal. Coordination can also be thought of as the critical mechanism that links or ties together the efforts on the singular level to that of the larger task being completed by multiple members. Coordination allows for the successful completion of the otherwise larger tasks that one might encounter.

Get More PRINCE2 Information by Clicking HERE

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