Tag: Business

Critical Chain Project Management

Critical chain project management (CCPM) is a method of planning and managing projects that emphasizes the resources (people, equipment, physical space) required to execute project tasks. It was developed by Eliyahu M. Goldratt. It differs from more traditional methods that derive from critical path and PERT algorithms, which emphasize task order and rigid scheduling. A critical chain project network strives to keep resources levelled, and requires that they be flexible in start times.

Critical chain project management is based on methods and algorithms derived from Theory of Constraints. The idea of CCPM was introduced in 1997 in Eliyahu M. Goldratt’s book, Critical Chain. Application of CCPM has been credited with achieving projects 10% to 50% faster and/or cheaper than the traditional methods (i.e., CPM, PERT, Gantt, etc.) developed from 1910 to 1950s.

According to studies of traditional project management methods by Standish Group and others as of 1998, only 44% of projects typically finish on time. Projects typically complete at 222% of the duration originally planned, 189% of the original budgeted cost, 70% of projects fall short of their planned scope (technical content delivered), and 30% are cancelled before completion. CCPM tries to improve performance relative to these traditional statistics.

With traditional project management methods, 30% of lost time and resources are typically consumed by wasteful techniques such as bad multitasking (in particular task switching), student syndrome, Parkinson’s law, in-box delays, and lack of prioritization.

In a project plan, the critical chain is the sequence of both precedence- and resource-dependent tasks that prevents a project from being completed in a shorter time, given finite resources. If resources are always available in unlimited quantities, then a project’s critical chain is identical to its critical path method.

Critical chain is an alternative to critical path analysis. Main features that distinguish critical chain from critical path are:

CCPM planning aggregates the large amounts of safety time added to tasks within a project into the buffers—to protect due-date performance and avoid wasting this safety time through bad multitasking, student syndrome, Parkinson’s Law, and poorly synchronized integration.

Critical chain project management uses buffer management instead of earned value management to assess the performance of a project. Some project managers feel that the earned value management technique is misleading, because it does not distinguish progress on the project constraint (i.e., on the critical chain) from progress on non-constraints (i.e., on other paths). Event chain methodology can determine a size of project, feeding, and resource buffers.

A project plan or work breakdown structure (WBS) is created in much the same fashion as with critical path. The plan is worked backward from a completion date with each task starting as late as possible.

A duration is assigned to each task. Some software implementations add a second duration: one a “best guess,” or 50% probability duration, and a second “safe” duration, which should have higher probability of completion (perhaps 90% or 95%, depending on the amount of risk that the organization can accept). Other software implementations go through the duration estimate of every task and remove a fixed percentage to be aggregated into the buffers.

Resources are assigned to each task, and the plan is resource leveled, using the aggressive durations. The longest sequence of resource-leveled tasks that lead from beginning to end of the project is then identified as the critical chain. The justification for using the 50% estimates is that half of the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero.

Recognizing that tasks are more likely to take more time than less time due to Parkinson’s law, Student syndrome, or other reasons, CCPM uses “buffers” to monitor project schedule and financial performance. The “extra” duration of each task on the critical chain—the difference between the “safe” durations and the 50% durations—is gathered in a buffer at the end of the project. In the same way, buffers are gathered at the end of each sequence of tasks that feed into the critical chain. The date at the end of the project buffer is given to external stakeholders as the delivery date. Finally, a baseline is established, which enables financial monitoring of the project.

An alternate duration-estimation methodology uses probability-based quantification of duration using Monte Carlo simulation. In 1999, a researcher[who?] applied simulation to assess the impact of risks associated with each component of project work breakdown structure on project duration, cost and performance. Using Monte Carlo simulation, the project manager can apply different probabilities for various risk factors that affect a project component. The probability of occurrence can vary from 0% to 100% chance of occurrence. The impact of risk is entered into the simulation model along with the probability of occurrence. The number of iterations of Monte Carlo simulation depend on the tolerance level of error and provide a density graph illustrating the overall probability of risk impact on project outcome.

When the plan is complete and the project is ready to start, the project network is fixed and the buffers’ sizes are “locked” (i.e., their planned duration may not be altered during the project), because they are used to monitor project schedule and financial performance.

With no slack in the duration of individual tasks, resources are encouraged to focus on the task at hand to complete it and hand it off to the next person or group. The objective here is to eliminate bad multitasking. This is done by providing priority information to all resources. The literature draws an analogy with a relay race. Each element on the project is encouraged to move as quickly as they can: when they are running their “leg” of the project, they should be focused on completing the assigned task as quickly as possible, with minimization of distractions and multitasking. In some case studies, actual batons are reportedly hung by the desks of people when they are working on critical chain tasks so that others know not to interrupt. The goal, here, is to overcome the tendency to delay work or to do extra work when there seems to be time. The CCPM literature contrasts this with “traditional” project management that monitors task start and completion dates. CCPM encourages people to move as quickly as possible, regardless of dates.

Because task duration has been planned at the 50% probability duration, there is pressure on resources to complete critical chain tasks as quickly as possible, overcoming student’s syndrome and Parkinson’s Law.

According to proponents, monitoring is, in some ways, the greatest advantage of the Critical Chain method. Because individual tasks vary in duration from the 50% estimate, there is no point in trying to force every task to complete “on time;” estimates can never be perfect. Instead, we monitor the buffers created during the planning stage. A fever chart or similar graph can be created and posted to show the consumption of buffer as a function of project completion. If the rate of buffer consumption is low, the project is on target. If the rate of consumption is such that there is likely to be little or no buffer at the end of the project, then corrective actions or recovery plans must be developed to recover the loss. When the buffer consumption rate exceeds some critical value (roughly: the rate where all of the buffer may be expected to be consumed before the end of the project, resulting in late completion), then those alternative plans need to be implemented.

Critical sequence was originally identified in the 1960s.

Tzvi Raz, Robert Barnes and Dov Dvir, Project Management Journal, December 2003.

Get More PRINCE2 Information by Clicking HERE

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 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

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 Interoperability (BPI)

Business process interoperability (BPI) is a property referring to the ability of diverse business processes to work together, to so called “inter-operate”. It is a state that exists when a business process can meet a specific objective automatically utilizing essential human labor only. Typically, BPI is present when a process conforms to standards that enable it to achieve its objective regardless of ownership, location, make, version or design of the computer systems used.

The main attraction of BPI is that a business process can start and finish at any point worldwide regardless of the types of hardware and software required to automate it. Because of its capacity to offload human “mind” labor, BPI is considered by many as the final stage in the evolution of business computing. BPI’s twin criteria of specific objective and essential human labor are both subjective.

The objectives of BPI vary, but tend to fall into the following categories:

Business process interoperability is limited to enterprise software systems in which functions are designed to work together, such as a payroll module and a general ledger module that are part of the same program suite, and in controlled software environments that use EDI. Interoperability is also present between incompatible systems where middleware has been applied. In each of these cases, however, the processes seldom meet the test of BPI because they are constrained by information silos and the systems’ inability to freely communicate among each other.

The term “Business process interoperability” (BPI) was coined in the late 1990s, mostly in connection with the value chain in electronic commerce. BPI has been utilized in promotional materials by various companies, and appears as a subject of research at organizations concerned with computer science ontologies.

Despite the attention it has received, business process interoperability has not been applied outside of limited information system environments. A possible reason is that BPI requires universal conformance to standards so that a business process can start and finish at any point worldwide. The standards themselves are fairly straightforward—organizations use a finite set of shared processes to manage most of their operations. Bringing enterprises together to create and adopt the standards is another matter entirely. The world of management systems is, after all, characterized by information silos. Moving away from silos requires organizations to deal with cultural issues such as ownership and sharing of processes and data, competitive forces and security, not to mention the effect of automation on their work forces.

While the timetable or adoption of BPI cannot be predicted, it remains a subject of interest in organizations and think tanks alike.

To test for BPI, an organization analyzes a business process to determine if it can meet its specific objective utilizing essential human labor only.

The specific objective must be clearly defined from start to finish. Start and finish are highly subjective, however. In one organization, a process may start when a customer orders a product and finish when the product is delivered to the customer. In another organization, the same process may be preceded with product manufacture and distribution, and may be followed by management of after-sale warranty and repairs.

Essential human labor includes:

To qualify for BPI, every process task must be taken into account from start to finish, including the labor that falls between the cracks created by incompatible software applications, such as gathering data from one system and re-inputting it in another, and preparing reports that include data from disparate systems. The process must flow uninterrupted regardless of the underlying computerized systems used. If non-essential human labor exists at any point, the process fails the test of BPI.

To assure that business processes can meet their specific objectives automatically utilizing essential human labor only, BPI takes a “service-oriented architecture“ (SOA) approach, which focuses on the processes rather than on the technologies required to automate them. A widely used SOA is an effective way to address the problems caused by any disparate system that is the heart of each information silo.

SOA makes practical sense because organizations cannot be expected to replace or modify their current enterprise software to achieve BPI, regardless of the benefits involved. Many workers’ jobs are built around the applications they use, and most organizations have sizable investments in their current information infrastructures which are so complex that even the smallest modification can be very costly, time-consuming and disruptive. Even if software makers were to unite and conform their products to a single set of standards, the problem would not be solved. Besides software from well-known manufacturers, organizations use a great many legacy software systems, custom applications, manual procedures and paper forms. Without SOA, streamlining such a huge number of disparate internal processes so that they interoperate across the entire global enterprise spectrum is simply out of the question.

To create an SOA for widespread use, BPI relies on a centralized database repository containing shared data and procedures common to applications in every industry and geographical area. In essence, the repository serves as a top application layer, enabling organizations to export their data to its distributed database and obtain the programs they need by simply logging on via a portal. To assure security and commercial neutrality, the repository conforms to standards promulgated by the community of BPI stakeholders.

Organizations and interest groups that wish to achieve business process interoperability begin by establishing one or more BPI initiatives.

Project Portfolio Management (PPM)

Prince2 Certification
Image by/from Kokcharov

Project Portfolio Management (PPM) is the centralized management of the processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals, while honouring constraints imposed by customers, strategic objectives, or external real-world factors. The International standard defines the framework of the Project Portfolio Management

PPM provides program and project managers in large, program/project-driven organizations with the capabilities needed to manage the time, resources, skills, and budgets necessary to accomplish all interrelated tasks. It provides a framework for issue resolution and risk mitigation, as well as the centralized visibility to help planning and scheduling teams to identify the fastest, cheapest, or most suitable approach to deliver projects and programs. Portfolio Managers define Key Performance Indicators and the strategy for their portfolio .

Pipeline management involves steps to ensure that an adequate number of project proposals are generated and evaluated to determine whether (and how) a set of projects in the portfolio can be executed with finite development resources in a specified time. There are three major sub-components to pipeline management: ideation, work intake processes, and Phase-Gate reviews. Fundamental to pipeline management is the ability to align the decision-making process for estimating and selecting new capital investment projects with the strategic plan.

The focus on the efficient and effective deployment of an organization’s resources where and when they are needed. These can include financial resources, inventory, human resources, technical skills, production, and design. In addition to project-level resource allocation, users can also model ‘what-if’ resource scenarios, and extend this view across the portfolio.

The capture and prioritization of change requests that can include new requirements, features, functions, operational constraints, regulatory demands, and technical enhancements. PPM provides a central repository for these change requests and the ability to match available resources to evolving demand within the financial and operational constraints of individual projects.

With PPM, the Office of Finance can improve their accuracy for estimating and managing the financial resources of a project or group of projects. In addition, the value of projects can be demonstrated in relation to the strategic objectives and priorities of the organization through financial controls and to assess progress through earned value and other project financial techniques.

An analysis of the risk sensitivities residing within each project, as the basis for determining confidence levels across the portfolio. The integration of cost and schedule risk management with techniques for determining contingency and risk response plans, enable organizations to gain an objective view of project uncertainties.

In the early 2000s, many PPM vendors realized that project portfolio reporting services only addressed part of a wider need for PPM in the marketplace. Another more senior audience had emerged, sitting at management and executive levels above detailed work execution and schedule management, who required a greater focus on process improvement and ensuring the viability of the portfolio in line with overall strategic objectives. In addition, as the size, scope, complexity, and geographical spread of organizations’ project portfolios continued to grow, greater visibility was needed of project work across the enterprise, allied to improved resource utilization and capacity planning.

Enterprise Project Portfolio Management (EPPM) is a top-down approach to managing all project-intensive work and resources across the enterprise. This contrasts with the traditional approach of combining manual processes, desktop project tools, and PPM applications for each project portfolio environment.

The PPM landscape is evolving rapidly as a result of the growing preference for managing multiple capital investment initiatives from a single, enterprise-wide system. This more centralized approach, and resulting ‘single version of the truth’ for project and project portfolio information, provides the transparency of performance needed by management to monitor progress versus the strategic plan.

The key aims of EPPM can be summarized as follows:

A key result of PPM is to decide which projects to fund in an optimal manner. Project Portfolio Optimization (PPO) is the effort to make the best decisions possible under these conditions.

Management Process

Management process is a process of setting goals, planning and/or controlling the organizing and leading the execution of any type of activity, such as:

An organization’s senior management is responsible for carrying out its management process. However, this is not always the case for all management processes, for example, it is the responsibility of the project manager to carry out a project management process.

Planning, it determines the objectives, evaluate the different alternatives and choose the best

Organizing, define group’s functions, establish relationships and defining authority and responsibility

Staffing, recruitment or placement and selection or training takes place for the development of members in the firm

directing, is to give the Direction to the employees.

Acquisition Initiation Within the Information Services Procurement Library (ISPL)

Uncategorized
Image by/from User:Mcalukin of the English Wikipedia

Acquisition Initiation is the initial process within the Information Services Procurement Library (ISPL) and is executed by a customer organization intending to procure Information Services. The process is composed of two main activities: the making of the acquisition goal definition and the making of the acquisition planning. During the acquisition initiation, an iterative process arises in which questions about the goal of the acquisition are usually asked. In response to these questions the Library provides details of the requirements, covering areas such as cost, feasibility and timelines. An example of such requirements is the “planning of the acquisition”, a component that may also lead to more questions about the acquisition goal (thus, it is reasonable to state that a relationship exists between the acquisition goal and the acquisition planning).

The process-data model shown in the following section displays the acquisition initiation stages. It shows both the process and the data ensuing from the process, and parts of the image will also be used as references in the body of this article. The concepts and data found in the model are explained in separate tables which can be found in the section immediately following the model. A textual, and more thorough, explanation of the activities and concepts that make up the Acquisition Initiation process can be found in the remainder of this article.

The draft acquisition goal is the description of the global goal that is to be achieved by starting procurement. It is inspired by the business needs or business strategy. It is similar, though simpler, to the concept of the project brief in PRINCE2. It is the first draft of the acquisition goal, containing at least a (short) problem definition and a (short) goal definition. The draft acquisition goal is meant to give the main reasons and the main goals to those people who will have to make the decision to actually start of the acquisition or not. It may thus also encapsulate items like a cost-benefit analysis, stakes & stakeholders and other items that will be further refined during the actual Acquisition Initiation.

It is, in this sense, not an activity of the acquisition initiation process, but it is the input for starting the process.

The problem definition is a statement about the problem that could be resolved by starting the acquisition process.

The goal definition is a statement about the goal that will have to be reached when the acquisition is executed:

The draft acquisition goal can be made as short or as long as is needed by the organization, as long as it serves to be a good basis to make the initial decision to start of an acquisition process.

When the decision is made to start an acquisition process, the first activity of the acquisition initiation is to define the acquisition goal.

The acquisition goal is the whole of defined systems and services requirements, attributed by costs & benefits and stakes & stakeholders, with a defined target domain serving as the boundary. The acquisition goal is the basis of the acquisition process and for formulating the acquisition strategy during the acquisition planning. Input can be the draft acquisition goal and the business needs (of the target domain). The business needs can be derived from strategic business plans or information system plans.

The target domain is that part of the customer organization that is involved in, or influenced by an information service. It is defined in terms of business processes, business actors, business information, business technology and the relations between these four aspects. The target domain is identified to ensure a fitting acquisition goal with fitting requirements for the systems and services to be acquired.

A limited description of a target domain can thus be, for example:The part of customer organization that uses the software program MarketingUnlimited (fictional), involving the marketing-process, several types of information related to the marketing-department of the customer organization, the employees working in the marketing department and the production platform for MarketingUnlimited consisting of an application server, several workstations, and tools related to MarketingUnlimited.

The acquisition goal is then described by system descriptions and service descriptions:

Other information on how ISPL defines the deliverables of the acquisition can be found in the general ISPL entry.

Cost-benefit analysis concerns the analysis of:

to successfully evaluate the investment issues of the acquisition.

It is important to identify all actors affected, and in what way they are affected (their stake), because a negative attitude of actors may negatively influence the success of the acquisition. ISPL proposes to perform a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats) for the actors involved to properly and thoroughly identify the stakes of the actors. The results of this analysis can serve as input for the situation & risk analysis.

The information contained within the Acquisition Goal is used to produce the acquisition plan. The acquisition plan is the master plan of the entire acquisition. In this plan, delivery scenarios are determined and the situation and risks are evaluated. Based on the scenarios, situations, and risks, a strategy is formed to manage the acquisition. Furthermore, the acquisition plan will hold the main decision points, in which decisions are made about the deliverables within the acquisition and the acquisition organization (similar to a project organization) is formed.

On the basis of the acquisition goal, which contains among others the systems and services requirements and descriptions, scenarios can be formed for the deliveries of the information services to be acquired. Multiple scenarios may be built, which will then be evaluated and used in the design of the acquisition strategy. The scenarios are built with the priorities and interdependence of the deliverables in mind.

Priorities are related to the importance of each delivery: which delivery has time-preference over another.

Some deliveries may be dependent on each other, requiring one services to be delivered before the next one can be.

Example:

During a project to make ISPL more specific for generic product software implementations, a number of scenario’s were made. One of these was for an approach of a one-shot implementation. The below picture shows a diagram of the scenario that was made. An example of a scenario for the implementation of software is shown in the thumbnail on the right.

In this example, the general deliverables within an implementation of software are mentioned, executed and delivered differently as time goes by, mainly because of dependencies between deliverables. For instance, the actual go for the delivery of the software and the other related deliverables are dependent on the outcome of the deliverable “Proeftuin”. “Proeftuin” is an agreed period in which the software is extensively tested by the customer organization, provided and supported by the supplier. The customer organization can get a feel for the use of the software in the target domain, to guarantee that the software is a “fit” within the organization.

ISPL adheres to a situational approach to manage an acquisition. The situational approach takes into account properties of the problem situation, which are called situational factors. ISPL provides a number of these situational factors. Some of these situational factors affect events that have adverse consequences: the risks. Thus, the situational factors and risks within ISPL are related to each other. This makes it possible to provide a number of heuristics on which factors have an influence on certain risks.
First the situation is analysed, then ISPL proposes a number of risks which may arise from the situation at hand. With this information, an acquisition strategy can be formed to mitigate both the situation and risks in a number of areas.
Other information of the situation & risk analysis of ISPL can be found in the ISPL entry.

The acquisition strategy within ISPL acts as the design of a risk management strategy. The risk management strategy provides choices for options that reduce the probability and/or effect of risks. ISPL provides several options, divided over four classes:

Options are chosen based on their efficiency, costs and the related delay for delivery.

Based upon all the previous activities, the decision points planning is made. This is a time-set planning of decision points.

A decision point is described by:

An example of a decision points planning can be found through the thumbnail on the right. In this planning the decisions points are planned through time (top to bottom, left to right). This planning was taken from a study to make ISPL more specific for product software implementations. The decision points planning is thus aimed at a part of the process of a software implementation.

A shortened example of a decision point description can be found in the image below. This description was taken from the same study to make ISPL more specific for product software implementations.

The acquisition organization is set, which is similar to a project organization. Although the acquisition organization is more focused on the (legal) relationship that it has to maintain with the supplier organization.