VIEWS: 4 PAGES: 46 POSTED ON: 1/11/2012
SLOVAK UNIVERSITY OF TECHNOLOGY Faculty of Material Science and Technology in Trnava PROJECT MANAGEMENT Colected and Processed by Pavol Tanuška TRNAVA 2007 Obsah: Project management............................................................................................ 3 History of project management ...................................................................... 3 Definitions ......................................................................................................... 4 Job description ................................................................................................. 4 The traditional triple constraints ................................................................... 5 Project management activities ........................................................................... 6 Project objectives ............................................................................................. 7 Project management artifacts ......................................................................... 7 Project control variables ................................................................................. 8 Approaches ....................................................................................................... 8 Project systems ............................................................................................... 11 Project management tools ................................................................................ 13 Project management associations ................................................................. 14 International standards .................................................................................... 14 PLANNING A PROJECT ................................................................................ 16 Gantt chart ......................................................................................................... 25 Historical development .................................................................................. 25 Advantages and limitations ........................................................................... 25 Program Evaluation and Review Technique .................................................. 27 Overview ......................................................................................................... 27 PERT terminology and conventions ............................................................ 28 Implementing PERT ...................................................................................... 29 Critical path method ......................................................................................... 35 Work breakdown structure .............................................................................. 37 History ............................................................................................................. 37 WBS design principles ................................................................................... 38 WBS construction example ........................................................................... 40 Common pitfalls and misconceptions .......................................................... 41 PRINCE2 Methodology .................................................................................... 42 Project management Project Management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives. A project is a finite endeavor—having specific start and completion dates—undertaken to create a unique product or service which brings about beneficial change or added value. This finite characteristic of projects stands in sharp contrast to processes, or operations, which are permanent or semi-permanent functional work to repetitively produce the same product or service. In practice, the management of these two systems is often found to be quite different, and as such requires the development of distinct technical skills and the adoption of separate management philosophy, which is the subject of this article. The primary challenge of project management is to achieve all of the project goals and objectives while adhering to classic project constraints—usually scope, quality, time and budget. The secondary—and more ambitious—challenge is to optimize the allocation and integration of inputs necessary to meet pre-defined objectives. A project is a carefully defined set of activities that use resources (money, people, materials, energy, space, provisions, communication, motivation, etc.) to achieve the project goals and objectives. History of project management As a discipline, project management developed from different fields of application including construction, engineering, and defense. In the United States, the forefather of project management is Henry Gantt, called the father of planning and control techniques, who is famously known for his use of the Gantt chart as a project management tool, for being an associate of Frederick Winslow Taylor's theories of scientific management, and for his study of the work and management of Navy ship building. His work is the forerunner to many modern project management tools including the work breakdown structure (WBS) and resource allocation. The 1950s marked the beginning of the modern project management era. Again, in the United States, prior to the 1950s, projects were managed on an ad hoc basis using mostly Gantt Charts, and informal techniques and tools. At that time, two mathematical project scheduling models were developed: (1) the "Program Evaluation and Review Technique" or PERT, developed by Booz-Allen & Hamilton as part of the United States Navy's (in conjunction with the Lockheed Corporation) Polaris missile submarine program; and the "Critical Path Method" (CPM) developed in a joint venture by both DuPont Corporation and Remington Rand Corporation for managing plant maintenance projects. These mathematical techniques quickly spread into many private enterprises. At the same time, technology for project cost estimating, cost management, and engineering economics was evolving, with pioneering work by Hans Lang and others. In 1956, the American Association of Cost Engineers (now AACE International; the Association for the Advancement of Cost Engineering) was formed by early practitioners of project management and the associated specialties of planning and scheduling, cost estimating, and cost/schedule control (project control). AACE has continued its pioneering work and in 2006 released the first ever integrated process for portfolio, program and project management(Total Cost Management Framework). In 1969, the Project Management Institute (PMI) was formed to serve the interest of the project management industry. The premise of PMI is that the tools and techniques of project management are common even among the widespread application of projects from the software industry to the construction industry. In 1981, the PMI Board of Directors authorized the development of what has become A Guide to the Project Management Body of Knowledge (PMBOK Guide), containing the standards and guidelines of practice that are widely used throughout the profession. The International Project Management Association (IPMA), founded in Europe in 1967, has undergone a similar development and instituted the IPMA Competence Baseline (ICB). The focus of the ICB also begins with knowledge as a foundation, and adds considerations about relevant experience, interpersonal skills, and competence. Both organizations are now participating in the development of an ISO project management standard. Definitions PMBOK (Project Management -- Body of Knowledge as defined by the Project Management Institute — PMI):"Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements." PRINCE2 project management methodology: "The planning, monitoring and control of all aspects of the project and the motivation of all those involved in it to achieve the project objectives on time and to the specified cost, quality and performance." PROJECT: A temporary endeavor with a finite completion date undertaken to create a unique product or service. Projects bring form or function to ideas or needs. DIN 69901 (Deutsches Institut für Normung - German Organization for Standardization): "Project management is the complete set of tasks, techniques, tools applied during project execution" Job description Project management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and productive mutual interaction of various parties in such a way that overall risk of failure is reduced. A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality, and above all, client satisfaction, can be realized. In whatever field, a successful project manager must be able to envision the entire project from start to finish and to have the ability to ensure that this vision is realized. Any type of product or service —buildings, vehicles, electronics, computer software, financial services, etc.— may have its implementation overseen by a project manager and its operations by a product manager. The traditional triple constraints Like any human undertaking, projects need to be performed and delivered under certain constraints. Traditionally, these constraints have been listed as scope, time, and cost . These are also referred to as the Project Management Triangle, where each side represents a constraint. One side of the triangle cannot be changed without impacting the others. A further refinement of the constraints separates product 'quality' or 'performance' from scope, and turns quality into a fourth constraint. The Project Management Triangle The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope. The discipline of project management is about providing the tools and techniques that enable the project team (not just the project manager) to organize their work to meet these constraints. Another approach to project management is to consider the three constraints as finance, time and human resources. If you need to finish a job in a shorter time, you can throw more people at the problem, which in turn will raise the cost of the project, unless by doing this task quicker we will reduce costs elsewhere in the project by an equal amount. Time For analytical purposes, the time required to produce a deliverable is estimated using several techniques. One method is to identify tasks needed to produce the deliverables documented in a work breakdown structure or WBS. The work effort for each task is estimated and those estimates are rolled up into the final deliverable estimate. The tasks are also prioritized, dependencies between tasks are identified, and this information is documented in a project schedule. The dependencies between the tasks can affect the length of the overall project (dependency constrained), as can the availability of resources (resource constrained). Time is not considered a cost nor a resource since the project manager cannot control the rate at which it is expended. This makes it different from all other resources and cost categories. It should be remembered that no effort expended will have any higher quality than that of the effort- expenders. Cost Cost to develop a project depends on several variables including (chiefly): resource quantities, labor rates, material rates, risk management (i.e.cost contingency), Earned value management, plant (buildings, machines, etc.), equipment, cost escalation, indirect costs, and profit. Scope Requirements specified for the end result. The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish. A major component of scope is the quality of the final product. The amount of time put into individual tasks determines the overall quality of the project. Some tasks may require a given amount of time to complete adequately, but given more time could be completed exceptionally. Over the course of a large project, quality can have a significant impact on time and cost (or vice versa). Together, these three constraints have given rise to the phrase "On Time, On Spec, On Budget". In this case, the term "scope" is substituted with "spec(ification)". Project management activities Project management is composed of several different types of activities such as: 1. Analysis & design of objectives and events 2. Planning the work according to the objectives 3. Assessing and controlling risk (or Risk Management) 4. Estimating resources 5. Allocation of resources 6. Organizing the work 7. Acquiring human and material resources 8. Assigning tasks 9. Directing activities 10. Controlling project execution 11. Tracking and reporting progress (Management information system) 12. Analyzing the results based on the facts achieved 13. Defining the products of the project 14. Forecasting future trends in the project 15. Quality Management 16. Issues management 17. Issue solving 18. Defect prevention 19. Identifying, managing & controlling changes 20. Project closure (and project debrief) 21. Communicating to stakeholders 22. Increasing/ decreasing a company's workers Project objectives Project objectives define target status at the end of the project, reaching of which is considered necessary for the achievement of planned benefits. They can be formulated as S.M.A.R.T. Specific, Measurable (or at least evaluable) achievement, Achievable (recently Acceptable is used regularly as well), Relevant and Time terminated (bounded). The evaluation (measurement) occurs at the project closure. However a continuous guard on the project progress should be kept by monitoring and evaluating. Project management artifacts The following documents serve to clarify objectives and deliverables and to align sponsors, clients, and project team's expectations. 1. Project Charter 2. Preliminary Scope Statement / Statement of work 3. Business case / Feasibility Study 4. Scope Statement / Terms of reference 5. Project management plan / Project Initiation Document 6. Work Breakdown Structure 7. Change Control Plan 8. Risk Management Plan 9. Risk Breakdown Structure 10. Communications Plan 11. Governance Model 12. Risk Register 13. Issue Log 14. Action Item List 15. Resource Management Plan 16. Project Schedule 17. Status Report 18. Responsibility assignment matrix 19. Database of lessons learned 20. Stakeholder Analysis These documents are normally hosted on a shared resource (i.e., intranet web page) and are available for review by the project's stakeholders (except for the Stakeholder Analysis, since this document comprises personal information regarding certain stakeholders. Only the Project Manager has access to this analysis). Changes or updates to these documents are explicitly outlined in the project's configuration management (or change control plan). Project control variables Project Management tries to gain control over variables such as risk: Risk Potential points of failure: Most negative risks (or potential failures) can be overcome or resolved, given enough planning capabilities, time, and resources. According to some definitions (including PMBOK Third Edition) risk can also be categorized as "positive--" meaning that there is a potential opportunity, e.g., complete the project faster than expected. Customers (either internal or external project sponsors) and external organizations (such as government agencies and regulators) can dictate the extent of three variables: time, cost, and scope. The remaining variable (risk) is managed by the project team, ideally based on solid estimation and response planning techniques. Through a negotiation process among project stakeholders, an agreement defines the final objectives, in terms of time, cost, scope, and risk, usually in the form of a charter or contract. To properly control these variables a good project manager has a depth of knowledge and experience in these four areas (time, cost, scope, and risk), and in six other areas as well: integration, communication, human resources, quality assurance, schedule development, and procurement. Approaches There are several approaches that can be taken to managing project activities including agile, interactive, incremental, and phased approaches. Regardless of the approach employed, careful consideration needs to be given to clarify surrounding project objectives, goals, and importantly, the roles and responsibilities of all participants and stakeholders. The traditional approach A traditional phased approach identifies a sequence of steps to be completed. In the traditional approach, we can distinguish 5 components of a project (4 stages plus control) in the development of a project: 1. project initiation stage; 2. project planning or design stage; 3. project execution or production stage; 4. project monitoring and controlling systems; 5. project completion stage. Not all the projects will visit every stage as projects can be terminated before they reach completion. Some projects probably don't have the planning and/or the monitoring. Some projects will go through steps 2, 3 and 4 multiple times. Many industries utilize variations on these stages. For example, in bricks and mortar architectural design, projects typically progress through stages like Pre-Planning, Conceptual Design, Schematic Design, Design Development, Construction Drawings (or Contract Documents), and Construction Administration. In software development, this approach is often known as 'waterfall development' i.e. one series of tasks after another in linear sequence. In software development many organizations have adapted the Rational Unified Process (RUP) to fit this methodology, although RUP does not require or explicitly recommend this practice. Waterfall development can work for small tightly defined projects, but for larger projects of undefined or unknowable scope, it is less suited. The Cone of Uncertainty explains some of this as the planning made on the initial phase of the project suffers from a high degree of uncertainty. This becomes specially true as software development is often the realization of a new or novel product, this method has been widely accepted as ineffective for software projects where requirements are largely unknowable up front and susceptible to change. While the names may differ from industry to industry, the actual stages typically follow common steps to problem solving--defining the problem, weighing options, choosing a path, implementation and evaluation. Rational Unified Process 1. Inception - Identify the initial scope of the project, a potential architecture for the system, and obtain initial project funding and stakeholder acceptance. 2. Elaboration - Prove the architecture of the system. 3. Construction - Build working software on a regular, incremental basis which meets the highest-priority needs of project stakeholders. 4. Transition - Validate and deploy the system into the production environment Temporary organization sequencing concepts 1. Action-based entrepreneurship 2. Fragmentation for commitment-building 3. Planned isolation 4. Institutionalised termination Critical Chain Critical chain is the application of the Theory of Constraints (TOC) to projects. The goal is to increase the rate of throughput (or completion rates) of projects in an organization. Applying the first three of the five focusing steps of TOC, the system constraint for all projects is identified as resources. To exploit the constraint, tasks on the critical chain are given priority over all other activities. Finally, projects are planned and managed to ensure that the critical chain tasks are ready to start as soon as the needed resources are available, subordinating all other resources to the critical chain. For specific projects, the project plan is resource-leveled, and the longest sequence of resource-constrained tasks is identified as the critical chain. In multi-project environments, resource leveling should be performed across projects. However, it is often enough to identify (or simply select) a single "drum" resource—a resource that acts as a constraint across projects—and stagger projects based on the availability of that single resource. Extreme Project Management In critical studies of project management, it has been noted that several of these fundamentally PERT-based models are not well suited for the multi-project company environment of today. Most of them are aimed at very large-scale, one-time, non-routine projects, and nowadays all kinds of management are expressed in terms of projects. Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven to cause unnecessary costs and low maneuverability in several cases. Instead, project management experts try to identify different "lightweight" models, such as Extreme Programming for software development and Scrum techniques. The generalization of Extreme Programming to other kinds of projects is extreme project management, which may be used in combination with the process modeling and management principles of human interaction management. Event chain methodology Event chain methodology is the next advance beyond critical path method and critical chain project management. Event chain methodology is an uncertainty modeling and schedule network analysis technique that is focused on identifying and managing events and event chains that affect project schedules. Event chain methodology helps to mitigate the negative impact of psychological heuristics and biases, as well as to allow for easy modeling of uncertainties in the project schedules. Event chain methodology is based on the following major principles. Probabilistic moment of risk: An activity (task) in most real life processes is not a continuous uniform process. Tasks are affected by external events, which can occur at some point in the middle of the task. Event chains: Events can cause other events, which will create event chains. These event chains can significantly affect the course of the project. Quantitative analysis is used to determine a cumulative effect of these event chains on the project schedule. Critical events or event chains: The single events or the event chains that have the most potential to affect the projects are the ―critical events‖ or ―critical chains of events.‖ They can be determined by the analysis. Project tracking with events: If a project is partially completed and data about the project duration, cost, and events occurred is available, it is possible to refine information about future potential events and helps to forecast future project performance. Event chain visualization: Events and event chains can be visualized using event chain diagrams on a Gantt chart. Process-based management Also furthering the concept of project control is the incorporation of process-based management. This area has been driven by the use of Maturity models such as the CMMI (Capability Maturity Model Integration) and ISO/IEC15504 (SPICE - Software Process Improvement and Capability Determination), which have been far more successful. Agile project management approaches based on the principles of human interaction management are founded on a process view of human collaboration. This contrasts sharply with traditional approach. In the agile software development or flexible product development approach, the project is seen as a series of relatively small tasks conceived and executed as the situation demands in an adaptive manner, rather than as a completely pre-planned process. Project systems As mentioned above, traditionally, project development includes five elements: control systems and four stages. Project control systems Project control is that element of a project that keeps it on-track, on-time, and within budget. Project control begins early in the project with planning and ends late in the project with post- implementation review, having a thorough involvement of each step in the process. Each project should be assessed for the appropriate level of control needed: too much control is too time consuming, too little control is very risky. If project control is not implemented correctly, the cost to the business should be clarified in terms of errors, fixes, and additional audit fees. Control systems are needed for cost, risk, quality, communication, time, change, procurement, and human resources. In addition, auditors should consider how important the projects are to the financial statements, how reliant the stakeholders are on controls, and how many controls exist. Auditors should review the development process and procedures for how they are implemented. The process of development and the quality of the final product may also be assessed if needed or requested. A business may want the auditing firm to be involved throughout the process to catch problems earlier on so that they can be fixed more easily. An auditor can serve as a controls consultant as part of the development team or as an independent auditor as part of an audit. Businesses sometimes use formal systems development processes. These help assure that systems are developed successfully. A formal process is more effective in creating strong controls, and auditors should review this process to confirm that it is well designed and is followed in practice. A good formal systems development plan outlines: A strategy to align development with the organization‘s broader objectives Standards for new systems Project management policies for timing and budgeting Procedures describing the process Project development stages Regardless of the methodology used, the project development process will have the same major stages: initiation, planning or development, production or execution, maintenance and controlling, and closing. Initiation The initiation stage determines the nature and scope of the development. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business‘s needs. The key project controls needed here are an understanding of the business environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them. The initiation stage should include a cohesive plan that encompasses the following areas: Study analyzing the business needs in measurable goals. Review of the current operations. Conceptual design of the operation of the final product. Equipment requirement. Financial analysis of the costs and benefits including a budget. Select stake holders, including users, and support personnel for the project. Project charter including costs, tasks, deliverables, and schedule. Planning and design After the initiation stage, the system is designed. Occasionally, a small prototype of the final product is built and tested. Testing is generally performed by a combination of testers and end users, and can occur after the prototype is built or concurrently. Controls should be in place that ensure that the final product will meet the specifications of the project charter. The results of the design stage should include a product design that: Satisfies the project sponsor, end user, and business requirements. Functions as it was intended. Can be produced within quality standards. Can be produced within time and budget constraints. Executing Executing consists of the processes used to complete the work defined in the project management plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan. Monitoring and Controlling Monitoring and Controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan. Monitoring and Controlling includes: Monitoring the ongoing project activities against the project management plan and the project performance baseline Influencing the factors that could circumvent integrated change control so only approved changes are implemented In multi-phase projects, the Monitoring and Controlling process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan. Project Maintenance is an ongoing process, and it includes: Continuing support of end users Correction of errors Updates of the software over time In this stage, auditors should pay attention to how effectively and quickly user problems are resolved. Over the course of any construction project, the work scope changes. Change is a normal and expected part of the construction process. Changes can be the result of necessary design modifications, differing site conditions, material availability, contractor-requested changes, value engineering and impacts from third parties, to name a few. Beyond executing the change in the field, the change normally needs to be documented to show what was actually constructed. Hence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. The record is made on the contract documents – usually, but not necessarily limited to, the design drawings. The end product of this effort is what the industry terms as-built drawings, or more simply, ―asbuilts.‖ The requirement for providing them is a norm in construction contracts. Closing Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. Closing phase consist of two parts: Close project: to finalize all activities across all of the process groups to formally close the project or a project phase Contract closure: necessary for completing and settling each contract, including the resolution of any open items, and closing each contract applicable to the project or a project phase. Project management tools Project management tools include Financial tools Cause and effect charts PERT charts Gantt charts Event Chain Diagrams RACI diagram Run charts Project Cycle Optimisation List of project management software Participatory Impact Pathways Analysis (An approach for developing common understanding and consensus amongst project partcipants and stakeholders as to how the project will achieve its goal) Project management associations Several national and professional associations exist which have as their aim the promotion and development of project management and the project management profession. The most prominent associations include: The Project Management Institute (PMI) The American Academy of Project Management (AAPM) The Agile Project Leadership Network (APLN) The Association for Project Management (UK) (APM) The Australian Institute of Project Management (AIPM) The International Project Management Association (IPMA) The Brazilian Association for Project Management (ABGP) The International Association of Project and Program Management (IAPPM) International standards There have been several attempts to develop project management standards, such as: A Framework for Performance Based Competency Standards for Global Level 1 and Level 2 Project Managers (Global Alliance for Project Performance Standards) A Guide to the Project Management Body of Knowledge (PMBOK Guide) The Standard for Program Management The Standard for Portfolio Management APM Body of Knowledge 5th ed. (APM — Association for Project Management (UK)) ICB v3 (IPMA Competence Baseline) RBC v1.1 (ABGP Competence Baseline) PRINCE2 (PRojects IN a Controlled Environment) P2M (A guidebook of Project & Program Management for Enterprise Innovation, Japanese third-generation project management method) (Download page for P2M and related products) V-Modell (German project management method) HERMES method (The Swiss general project management method, selected for use in Luxembourg and international organisations) Organizational Project Management Maturity Model (OPM3) International Organisation for Standardisation Founded 1947 o ISO 9000: a family of standards for quality management systems. o ISO 10006:2003, Quality management systems — Guidelines for quality management in projects JPACE (Justify, Plan, Activate, Control, and End - The James Martin Method for Managing Projects (1981–present)) Software Engineering Institute: Capability Maturity Model Total Cost Management Framework (AACE International's process for Portfolio, Program and Project Management) (ref:Cost Engineering) Professional certifications CompTIA Project+, ([Computer Technology Industry Association]) CPM (The International Association of Project & Program Management) IPMA (Levels of Certification: IPMA-A, IPMA-B, IPMA-C and IPMA-D) PMP (Project Management Professional), CAPM (Certified Associate in Project Management). PMI certifications Master Project Manager, Certified International Project Manager. AAPM certifications Certified Portfolio, Program & Project Manager (C3PM)- AACE International. Master's Certificate in Project Management — The George Washington University and ESI International Master of Science in Project Management PLANNING A PROJECT THE SPECIFICATION Before describing the role and creation of a specification, we need to introduce and explain a fairly technical term: a numbty is a person whose brain is totally numb. In this context, numb means "deprived of feeling or the power of unassisted activity"; in general, a numbty needs the stimulation of an electric cattle prod to even get to the right office in the morning. Communication with numbties is severely hampered by the fact that although they think they know what they mean (which they do not), they seldom actually say it, and they never write it down. And the main employment of numbties world-wide is in creating project specifications. You must know this - and protect your team accordingly. A specification is the definition of your project: a statement of the problem, not the solution. Normally, the specification contains errors, ambiguities, misunderstandings and enough rope to hang you and your entire team. Thus before you embark upon the the next six months of activity working on the wrong project, you must assume that a numbty was the chief author of the specification you received and you must read, worry, revise and ensure that everyone concerned with the project (from originator, through the workers, to the end-customer) is working with the same understanding. The outcome of this deliberation should be a written definition of what is required, by when; and this must be agreed by all involved. There are no short-cuts to this; if you fail to spend the time initially, it will cost you far more later on. The agreement upon a written specification has several benefits: the clarity will reveal misunderstandings the completeness will remove contradictory assumptions the rigour of the analysis will expose technical and practical details which numbties normally gloss over through ignorance or fear the agreement forces all concerned to actually read and think about the details The work on the specification can seen as the first stage of Quality Assurance since you are looking for and countering problems in the very foundation of the project - from this perspective the creation of the specification clearly merits a large investment of time. From a purely defensive point of view, the agreed specification also affords you protection against the numbties who have second thoughts, or new ideas, half way through the project. Once the project is underway, changes cost time (and money). The existence of a demonstrably-agreed specification enables you to resist or to charge for (possibly in terms of extra time) such changes. Further, people tend to forget what they originally thought; you may need proof that you have been working as instructed. The places to look for errors in a specification are: the global context: numbties often focus too narrowly on the work of one team and fail to consider how it fits into the larger picture. Some of the work given to you may actually be undone or duplicated by others. Some of the proposed work may be incompatible with that of others; it might be just plain barmy in the larger context. the interfaces: between your team and both its customers and suppliers, there are interfaces. At these points something gets transferred. Exactly what, how and when should be discussed and agreed from the very beginning. Never assume a common understanding, because you will be wrong. All it takes for your habitual understandings to evaporate is the arrival of one new member, in either of the teams. Define and agree your interfaces and maintain a friendly contact throughout the project. time-scales: numbties always underestimate the time involved for work. If there are no time-scales in the specification, you can assume that one will be imposed upon you (which will be impossible). You must add realistic dates. The detail should include a precise understanding of the extent of any intermediate stages of the task, particularly those which have to be delivered. external dependencies: your work may depend upon that of others. Make this very clear so that these people too will receive warning of your needs. Highlight the effect that problems with these would have upon your project so that everyone is quite clear about their importance. To be sure, contact these people yourself and ask if they are able to fulfil the assumptions in your specification. resources: the numbty tends to ignore resources. The specification should identify the materials, equipment and manpower which are needed for the project. The agreement should include a commitment by your managers to allocate or to fund them. You should check that the actual numbers are practical and/or correct. If they are omitted, add them - there is bound to be differences in their assumed values. This seems to make the specification sound like a long document. It should not be. Each of the above could be a simple sub-heading followed by either bullet points or a table - you are not writing a brochure, you are stating the definition of the project in clear, concise and unambiguous glory. Of course, the specification may change. If circumstances, or simply your knowledge, change then the specification will be out of date. You should not regard it as cast in stone but rather as a display board where everyone involved can see the current, common understanding of the project. If you change the content everyone must know, but do not hesitate to change it as necessary. PROVIDING STRUCTURE Having decide what the specification intends, your next problem is to decide what you and your team actually need to do, and how to do it. As a manager, you have to provide some form of framework both to plan and to communicate what needs doing. Without a structure, the work is a series of unrelated tasks which provides little sense of achievement and no feeling of advancement. If the team has no grasp of how individual tasks fit together towards an understood goal, then the work will seem pointless and they will feel only frustration. To take the planning forward, therefore, you need to turn the specification into a complete set of tasks with a linking structure. Fortunately, these two requirements are met at the same time since the derivation of such a structure is the simplest method of arriving at a list of tasks. Work Breakdown Structure Once you have a clear understanding of the project, and have eliminated the vagaries of the numbties, you then describe it as a set of simpler separate activities. If any of these are still too complex for you to easily organise, you break them down also into another level of simpler descriptions, and so on until you can manage everything. Thus your one complex project is organised as a set of simple tasks which together achieve the desired result. The reasoning behind this is that the human brain (even yours) can only take in and process so much information at one time. To get a real grasp of the project, you have to think about it in pieces rather than trying to process the complexity of its entire details all at once. Thus each level of the project can be understood as the amalgamation of a few simply described smaller units. In planning any project, you follow the same simple steps: if an item is too complicated to manage, it becomes a list of simpler items. People call this producing a work breakdown structure to make it sound more formal and impressive. Without following this formal approach you are unlikely to remember all the niggling little details; with this procedure, the details are simply displayed on the final lists. One common fault is to produce too much detail at the initial planning stage. You should be stop when you have a sufficient description of the activity to provide a clear instruction for the person who will actually do the work, and to have a reasonable estimate for the total time/effort involved. You need the former to allocate (or delegate) the task; you need the latter to finish the planning. Task Allocation The next stage is a little complicated. You now have to allocate the tasks to different people in the team and, at the same time, order these tasks so that they are performed in a sensible sequence. Task allocation is not simply a case of handing out the various tasks on your final lists to the people you have available; it is far more subtle (and powerful) than that. As a manager you have to look far beyond the single project; indeed any individual project can be seen as merely a single step in your team's development. The allocation of tasks should thus be seen as a means of increasing the skills and experience of your team - when the project is done, the team should have gained. In simple terms, consider what each member of your team is capable of and allocate sufficient complexity of tasks to match that (and to slightly stretch). The tasks you allocate are not the ones on your finals lists, they are adapted to better suit the needs of your team's development; tasks are moulded to fit people, which is far more effective than the other way around. For example, if Arthur is to learn something new, the task may be simplified with responsibility given to another to guide and check the work; if Brenda is to develop, sufficient tasks are combined so that her responsibility increases beyond what she has held before; if Colin lacks confidence, the tasks are broken into smaller units which can be completed (and commended) frequently. Sometimes tasks can be grouped and allocated together. For instance, some tasks which are seemingly independent may benefit from being done together since they use common ideas, information, talents. One person doing them both removes the start-up time for one of them; two people (one on each) will be able to help each other. The ordering of the tasks is really quite simple, although you may find that sketching a sequence diagram helps you to think it through (and to communicate the result). Pert charts are the accepted outcome, but sketches will suffice. Getting the details exactly right, however, can be a long and painful process, and often it can be futile. The degree to which you can predict the future is limited, so too should be the detail of your planning. You must have the broad outlines by which to monitor progress, and sufficient detail to assign each task when it needs to be started, but beyond that - stop and do something useful instead. Guesstimation At the initial planning stage the main objective is to get a realistic estimate of the time involved in the project. You must establish this not only to assist higher management with their planning, but also to protect your team from being expected to do the impossible. The most important technique for achieving this is known as: guesstimation. Guesstimating schedules is notoriously difficult but it is helped by two approaches: make your guesstimates of the simple tasks at the bottom of the work break down structure and look for the longest path through the sequence diagram use the experience from previous projects to improve your guesstimating skills The corollary to this is that you should keep records in an easily accessible form of all projects as you do them. Part of your final project review should be to update your personal data base of how long various activities take. Managing this planning phase is vital to your success as a manager. Some people find guesstimating a difficult concept in that if you have no experience of an activity, how can you make a worthwhile estimate? Let us consider such a problem: how long would it take you to walk all the way to the top of the Eiffel Tower or the Statue of Liberty? Presuming you have never actually tried this (most people take the elevator part of the way), you really have very little to go on. Indeed if you have actually seen one (and only one) of these buildings, think about the other. Your job depends upon this, so think carefully. One idea is to start with the number of steps - guess that if you can. Notice, you do not have to be right, merely reasonable. Next, consider the sort of pace you could maintain while climbing a flight of steps for a long time. Now imagine yourself at the base of a flight of steps you do know, and estimate a) how many steps there are, and b) how long it takes you to climb them (at that steady pace). To complete, apply a little mathematics. Now examine how confident you are with this estimate. If you won a free flight to Paris or New York and tried it, you would probably (need your head examined) be mildly surprised if you climbed to the top in less than half the estimated time and if it took you more than double you would be mildly annoyed. If it took you less than a tenth the time, or ten times as long, you would extremely surprised/annoyed. In fact, you do not currently believe that that would happen (no really, do you?). The point is that from very little experience of the given problem, you can actually come up with a working estimate - and one which is far better than no estimate at all when it comes to deriving a schedule. Guesstimating does take a little practice, but it is a very useful skill to develop. There are two practical problems in guesstimation. First, you are simply too optimistic. It is human nature at the beginning of a new project to ignore the difficulties and assume best case scenarii - in producing your estimates (and using those of others) you must inject a little realism. In practice, you should also build-in a little slack to allow yourself some tolerance against mistakes. This is known as defensive scheduling. Also, if you eventually deliver ahead of the agreed schedule, you will be loved. Second, you will be under pressure from senior management to deliver quickly, especially if the project is being sold competitively. Resist the temptation to rely upon speed as the only selling point. You might, for instance, suggest the criteria of: fewer errors, history of adherence to initial schedules, previous customer satisfaction, "this is how long it takes, so how can you trust the other quotes". ESTABLISHING CONTROLS When the planning phase is over (and agreed), the "doing" phase begins. Once it is in motion, a project acquires a direction and momentum which is totally independent of anything you predicted. If you come to terms with that from the start, you can then enjoy the roller-coaster which follows. To gain some hope, however, you need to establish at the start (within the plan) the means to monitor and to influence the project's progress. There are two key elements to the control of a project milestones (clear, unambiguous targets of what, by when) established means of communication For you, the milestones are a mechanism to monitor progress; for your team, they are short- term goals which are far more tangible than the foggy, distant completion of the entire project. The milestones maintain the momentum and encourage effort; they allow the team to judge their own progress and to celebrate achievement throughout the project rather than just at its end. The simplest way to construct milestones is to take the timing information from the work breakdown structure and sequence diagram. When you have guesstimated how long each sub- task will take and have strung them together, you can identify by when each of these tasks will actually be completed. This is simple and effective; however, it lacks creativity. A second method is to construct more significant milestones. These can be found by identify stages in the development of a project which are recognisable as steps towards the final product. Sometimes these are simply the higher levels of your structure; for instance, the completion of a market-evaluation phase. Sometimes, they cut across many parallel activities; for instance, a prototype of the eventual product or a mock-up of the new brochure format. If you are running parallel activities, this type of milestone is particularly useful since it provides a means of pulling together the people on disparate activities, and so: they all have a shared goal (the common milestone) their responsibility to (and dependence upon) each other is emphasised each can provide a new (but informed) viewpoint on the others' work the problems to do with combining the different activities are highlighted and discussed early in the implementation phase you have something tangible which senior management (and numbties) can recognise as progress you have something tangible which your team can celebrate and which constitutes a short-term goal in a possibly long-term project it provides an excellent opportunity for quality checking and for review Of course, there are milestones and there are mill-stones. You will have to be sensitive to any belief that working for some specific milestone is hindering rather than helping the work forward. If this arises then either you have chosen the wrong milestone, or you have failed to communicate how it fits into the broader structure. Communication is your everything. To monitor progress, to receive early warning of danger, to promote cooperation, to motivate through team involvement, all of these rely upon communication. Regular reports are invaluable - if you clearly define what information is needed and if teach your team how to provided it in a rapidly accessible form. Often these reports merely say "progressing according to schedule". These you send back, for while the message is desired the evidence is missing: you need to insist that your team monitor their own progress with concrete, tangible, measurements and if this is done, the figures should be included in the report. However, the real value of this practice comes when progress is not according to schedule - then your communication system is worth all the effort you invested in its planning. THE ARTISTRY IN PLANNING At the planning stage, you can deal with far more than the mere project at hand. You can also shape the overall pattern of your team's working using the division and type of activities you assign. Who know best? Ask your team. They too must be involved in the planning of projects, especially in the lower levels of the work breakdown structure. Not only will they provide information and ideas, but also they will feel ownership in the final plan. This does not mean that your projects should be planned by committee - rather that you, as manager, plan the project based upon all the available experience and creative ideas. As an initial approach, you could attempt the first level(s) of the work breakdown structure to help you communicate the project to the team and then ask for comments. Then, using these, the final levels could be refined by the people to whom the tasks will be allocated. However, since the specification is so vital, all the team should vet the penultimate draft. Dangers in review There are two pitfalls to avoid in project reviews: they can be too frequent they can be too drastic The constant trickle of new information can lead to a vicious cycle of planning and revising which shakes the team's confidence in any particular version of the plan and which destroys the very stability which the structure was designed to provide. You must decide the balance. Pick a point on the horizon and walk confidently towards it. Decide objectively, and explain beforehand, when the review phases will occur and make this a scheduled milestone in itself. Even though the situation may have changed since the last review, it is important to recognise the work which has been accomplished during the interim. Firstly, you do not want to abandon it since the team will be demotivated feeling that they have achieved nothing. Secondly, this work itself is part of the new situation: it has been done, it should provide a foundation for the next step or at least the basis of a lesson well learnt. Always try to build upon the existing achievements of your team. Testing and Quality No plan is complete without explicit provision for testing and quality. As a wise manager, you will know that this should be part of each individual phase of the project. This means that no activity is completed until it has passed the (objectively) defined criteria which establishes its quality, and these are best defined (objectively) at the beginning as part of the planning. When devising the schedule therefore you must include allocated time for this part of each activity. Thus your question is not only: "how long will it take", but also: "how long will the testing take". By asking both questions together you raise the issue of "how do we know we have done it right" at the very beginning and so the testing is more likely to be done in parallel with the implementation. You establish this philosophy for your team by include testing as a justified (required) cost. Fitness for purpose Another reason for stating the testing criteria at the beginning is that you can avoid futile quests for perfection. If you have motivated your team well, they will each take pride in their work and want to do the best job possible. Often this means polishing their work until is shines; often this wastes time. If it clear at the onset exactly what is needed, then they are more likely to stop when that has been achieved. You need to avoid generalities and to stipulate boundaries; not easy, but essential. The same is also true when choosing the tools or building-blocks of your project. While it might be nice to have use of the most modern versions, or to develop an exact match to your needs; often there is an old/existing version which will serve almost as well (sufficient for the purpose), and the difference is not worth the time you would need to invest in obtaining or developing the new one. Use what is available whenever possible unless the difference in the new version is worth the time, money and the initial, teething pains. A related idea is that you should discourage too much effort on aspects of the project which are idiosyncratic to that one job. In the specification phase, you might try to eliminate these through negotiation with the customer; in the implementation phase you might leave these parts until last. The reason for this advice is that a general piece of work can be tailored to many specific instances; thus, if the work is in a general form, you will be able to rapidly re- use it for other projects. On the other hand, if you produce something which is cut to fit exactly one specific case, you may have to repeat the work entirely even though the next project is fairly similar. At the planning phase, a manager should bare in mind the future and the long-term development of the team as well as the requirements of the current project. Fighting for time As a manager, you have to regulate the pressure and work load which is imposed upon your team; you must protect them from the unreasonable demands of the rest of the company. Once you have arrived at what you consider to be a realistic schedule, fight for it. Never let the outside world deflect you from what you know to be practical. If they impose a deadline upon you which is impossible, clearly state this and give your reasons. You will need to give some room for compromise, however, since a flat NO will be seen as obstructive. Since you want to help the company, you should look for alternative positions. You could offer a prototype service or product at an earlier date. This might, in some cases, be sufficient for the customer to start the next stage of his/her own project on the understanding that your project would be completed at a later date and the final version would then replace the prototype. The complexity of the product, or the total number of units, might be reduced. This might, in some cases, be sufficient for the customer's immediate needs. Future enhancements or more units would then be the subject of a subsequent negotiation which, you feel, would be likely to succeed since you will have already demonstrate your ability to deliver on time. You can show on an alternative schedule that the project could be delivered by the deadline if certain (specified) resources are given to you or if other projects are rescheduled. Thus, you provide a clear picture of the situation and a possible solution; it is up to your manager then how he/she proceeds. Planning for error The most common error in planning is to assume that there will be no errors in the implementation: in effect, the schedule is derived on the basis of "if nothing goes wrong, this will take ...". Of course, recognising that errors will occur is the reason for implementing a monitoring strategy on the project. Thus when the inevitable does happen, you can react and adapt the plan to compensate. However, by carefully considering errors in advance you can make changes to the original plan to enhance its tolerance. Quite simply, your planning should include time where you stand back from the design and ask: "what can go wrong?"; indeed, this is an excellent way of asking your team for their analysis of your plan. You can try to predict where the errors will occur. By examining the activities' list you can usually pinpoint some activities which are risky (for instance, those involving new equipment) and those which are quite secure (for instance, those your team has done often before). The risky areas might then be given a less stringent time-scale - actually planning-in time for the mistakes. Another possibility is to apply a different strategy, or more resources, to such activities to minimise the disruption. For instance, you could include training or consultancy for new equipment, or you might parallel the work with the foundation of a fall-back position. Post-mortem At the end of any project, you should allocate time to reviewing the lessons and information on both the work itself and the management of that work: an open meeting, with open discussion, with the whole team and all customers and suppliers. If you think that this might be thought a waste of time by your own manager, think of the effect it will have on future communications with your customers and suppliers. PLANNING FOR THE FUTURE With all these considerations in merely the "planning" stage of a project, it is perhaps surprising that projects get done at all. In fact projects do get done, but seldom in the predicted manner and often as much by brute force as by careful planning. The point, however, is that this method is non-optimal. Customers feel let down by late delivery, staff are demotivated by constant pressure for impossible goals, corners get cut which harm your reputation, and each project has to overcome the same problems as the last. With planning, projects can run on time and interact effectively with both customers and suppliers. Everyone involved understands what is wanted and emerging problems are seen (and dealt with) long before they cause damage. If you want your projects to run this way - then you must invest time in planning. Gantt chart A Gantt chart showing three kinds of schedule dependencies (in red) and percent complete indications. A Gantt chart is a popular type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e., precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical "TODAY" line as shown here. Historical development The first Gantt Chart was developed by Karol Adamiecki, who called it a Harmonogram. Because Adamiecki did not publish his chart until 1931, this famous chart bears Gantt's name. Henry Gantt (1861–1919) designed his chart in 1910. In the 1980s, personal computers eased the creation and editing of elaborate Gantt charts. These desktop applications were intended mainly for project managers and project schedulers. In the late 1990s and early 2000s, Gantt charts became a common feature of web-based applications, including collaborative groupware. Although now considered a common charting technique, Gantt charts were considered quite revolutionary when they were introduced. In recognition of Henry Gantt's contributions, the Henry Laurence Gantt Medal is awarded for distinguished achievement in management and in community service. Advantages and limitations Gantt charts have become a common technique for representing the phases and activities of a project work breakdown structure (WBS), so they can be understood by a wide audience. A common error made by those who equate Gantt chart design with project design is that they attempt to define the project work breakdown structure at the same time that they define schedule activities. This practice makes it very difficult to follow the 100% Rule. Instead the WBS should be fully defined to follow the 100% Rule, then the project schedule can be designed. Although a Gantt chart is easily comprehended for small projects that fit on a single sheet or screen, they can become quite unwieldy for projects with more than about 30 activities. Larger Gantt charts may not be suitable for most computer displays. A related criticism is that Gantt charts communicate relatively little information per unit area of display. That is, projects are often considerably more complex than can be communicated effectively with a Gantt chart. Gantt charts only represent part of the triple constraints of projects, because they focus primarily on schedule management. Moreover, Gantt charts do not represent the size of a project or the relative size of work elements, therefore the magnitude of a behind-schedule condition is easily miscommunicated. If two projects are the same number of days behind schedule, the larger project has a larger impact on resource utilization, yet the Gantt does not represent this difference. Although project management software can show schedule dependencies as lines between activities, displaying a large number of dependencies may result in a cluttered or unreadable chart. Because the horizontal bars of a Gantt chart have a fixed height, they can misrepresent the time-phased workload (resource requirements) of a project. In the example shown in this article, Activities E and G appear to be the same size, but in reality they may be orders of magnitude different. A related criticism is that all activities of a Gantt chart show planned workload as constant. In practice, many activities (especially summary elements) have front- loaded or back-loaded work plans, so a Gantt chart with percent-complete shading may actually miscommunicate the true schedule performance status. Program Evaluation and Review Technique PERT network chart for a seven-month project with five milestones (10 through 50) and six activities (A through F). The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is a model for project management designed to analyze and represent the tasks involved in completing a given project. Overview PERT is a method to analyze the tasks involved in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project. This model was invented by Booz Allen Hamilton, Inc. under contract to the United States Department of Defense's US Navy Special Projects Office in 1958 as part of the Polaris mobile submarine-launched ballistic missile project. This project was a direct response to the Sputnik crisis. Some US government contracts required that PERT be used as part of management supervision. PERT was developed primarily to simplify the planning and scheduling of large and complex projects. It was able to incorporate uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities. It is more of an event-oriented technique rather than start- and completion-oriented, and is used more in R&D-type projects where time, rather than cost, is the major factor. This project model was the first of its kind, a revival for scientific management, founded in Fordism and Taylorism. Though most companies now have their own project model, they all resemble PERT in some respect. Only DuPont corporation's critical path method was invented at roughly the same time as PERT. The most recognizable feature of PERT is the "PERT Networks", a chart of interconnecting timelines. PERT is intended for very large-scale, one-time, complex, non-routine projects. PERT terminology and conventions Conventions A PERT chart is a tool that facilitates decision making; The first draft of a PERT chart will number its events sequentially in 10s (10, 20, 30, etc.) to allow the later insertion of additional events. Two consecutive events in a PERT chart are linked by activities, which are conventionally represented as arrows in the diagram above. The events are presented in a logical sequence and no activity can commence until its immediately preceding event is completed. The planner decides which milestones should be PERT events and also decides their ―proper‖ sequence. A PERT chart may have multiple pages with many sub-tasks. Terminology A PERT event: is a point that marks the start or completion of one or more tasks. It consumes no time, and uses no resources. It marks the completion of one or more tasks, and is not ―reached‖ until all of the activities leading to that event have been completed. A predecessor event: an event (or events) that immediately precedes some other event without any other events intervening. It may be the consequence of more than one activity. A successor event: an event (or events) that immediately follows some other event without any other events intervening. It may be the consequence of more than one activity. A PERT activity: is the actual performance of a task. It consumes time, it requires resources (such as labour, materials, space, machinery), and it can be understood as representing the time, effort, and resources required to move from one event to another. A PERT activity cannot be completed until the event preceding it has occurred. Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes). Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal. Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time). TE = (O + 4M + P) ÷ 6 Critical Path: the longest possible continuous pathway taken from the initial event to the terminal event. It determines the total calendar time required for the project; and, therefore, any time delays along the critical path will delay the reaching of the terminal event by at least the same amount. Critical Activity: A activity that has total float equal to zero. Activity with zero float does not mean it is on critical path. Lead time (rhymes with "feed", not "fed"): the time by which a predecessor event must be completed in order to allow sufficient time for the activities that must elapse before a specific PERT event is reached to be completed. Lag time: the earliest time by which a successor event can follow a specific PERT event. Slack: the slack of an event is a measure of the excess time and resources available in achieving this event. Positive slack(+) would indicate ahead of schedule; negative slack would indicate behind schedule; and zero slack would indicate on schedule. Fast tracking: performing more critical activities in parallel Crashing critical path: Shortening duration of critical activities Float or Slack is the amount of time that a task in a project network can be delayed without causing a delay - Subsequent tasks – (free float) or Project Completion – (total float) Implementing PERT The first step to scheduling the project is to determine the tasks that the project requires and the order in which they must be completed. The order may be easy to record for some tasks (e.g. When building a house, the land must be graded before the foundation can be laid) while difficult for others (There are two areas that need to be graded, but there are only enough bulldozers to do one). Additionally, the time estimates usually reflect the normal, non-rushed time. Many times, the time required to execute the task can be reduced for an additional cost or a reduction in the quality. In the following example there are seven tasks, labeled a through g. Some tasks can be done concurrently (a & b) while others cannot be done until their predecessor task is complete (c cannot begin until a is complete). Additionally, each task has three time estimates: the optimistic time estimate (a), the most likely or normal time estimate (m), and the pessimistic time estimate (b). The expected time (TE) is computed using the formula (a + 4m + b) /6. Opt. Norm. Pess. TE Activity Predecessor a m b (a + 4m + b) /6 a -- 2 4 6 4.00 b -- 3 5 9 5.33 c a 4 5 7 5.17 d a 4 6 10 6.33 e b, c 4 5 7 5.17 f d 3 4 8 4.50 g e 3 5 8 5.17 Note: All times listed are in work days (Mon - Fri, 8 A.M. to 5 P.M. with a one hour lunch break). Once this step is complete, one can draw a Gantt chart or a network diagram. A Gantt chart created using Microsoft Project (MSP). Note (1) the critical path is in red, (2) the slack is the black lines connected to non-critical activities, (3) when using MSP, you must use the task ID when labeling predecessor activities, and (4) since Saturday and Sunday are not work days (as described above) some bars on the Gantt chart are longer if they cut through a weekend. A Gantt chart created using OmniPlan. Note (1) the critical path is highlighted, (2) the slack is not specifically indicated on task 5 (d), though it can be observed on tasks 3 and 7 (b and f), (3) when using OmniPlan, you may use the GUI to easily link dependencies, or you may enter them by reference to task ID, and (4) since weekends are indicated by a thin vertical line, and take up no additional space on the work calendar, bars on the Gantt chart are not longer or shorter when they do or don't carry over a weekend. A network diagram can be created by hand or by using a diagram software. There are two types of network diagrams, activity on arrow (AOA) and activity on node (AON). Activity on node diagrams are generally easier to create and interpret. To create an AON diagram, it is recommended (but not necessary) to start with a node named start. This "activity" has a duration of zero (0). Then you draw each activity that does not have a predecessor activity (a and b in this example) and connect them with an arrow from start to each node. Next, since both c and d list a as a predecessor activity, their nodes are drawn with arrows coming from a. Activity e is listed with b and c as predecessor activities, so node e is drawn with arrows coming from both b and c, signifying that e cannot begin until both b and c have been completed. Activity f has d as a predecessor activity, so an arrow is drawn connecting the activities. Likewise, an arrow is drawn from e to g. Since there are no activities that come after f or g, it is recommended (but again not necessary) to connect them to a node labeled finish. A network diagram created using Microsoft Project (MSP). Note the critical path is in red. A node like this one (from Microsoft Visio) can be used to display the activity name, duration, ES, EF, LS, LF, and slack. By itself, the network diagram pictured above does not give much more information than a Gantt chart; however, it can be expanded to display more information. The most common information shown is: 1. The activity name 2. The normal duration time 3. The early start time (ES) 4. The early finish time (EF) 5. The late start time (LS) 6. The late finish time (LF) 7. The slack In order to determine this information it is assumed that the activities and normal duration times are given. The first step is to determine the ES and EF. The ES is defined as the maximum EF of all predecessor activities, unless the activity in question is the first activity, which the ES is zero (0). The EF is the ES plus the task duration (EF = ES + duration). The ES for start is zero since it is the first activity. Since the duration is zero, the EF is also zero. This EF is used as the ES for a and b. The ES for a is zero. The duration (4 work days) is added to the ES to get an EF of four. This EF is used as the ES for c and d. The ES for b is zero. The duration (5.33 work days) is added to the ES to get an EF of 5.33. The ES for c is four. The duration (5.17 work days) is added to the ES to get an EF of 9.17. The ES for d is four. The duration (6.33 work days) is added to the ES to get an EF of 10.33. This EF is used as the ES for f. The ES for e is the greatest EF of its predecessor activities (b and c). Since b has an EF of 5.33 and c has an EF of 9.17, the ES of e is 9.17. The duration (5.17 work days) is added to the ES to get an EF of 14.34. This EF is used as the ES for g. The ES for f is 10.33. The duration (4.5 work days) is added to the ES to get an EF of 14.83. The ES for g is 14.34. The duration (5.17 work days) is added to the ES to get an EF of 19.51. The ES for finish is the greatest EF of its predecessor activities (f and g). Since f has an EF of 14.83 and g has an EF of 19.51, the ES of finish is 19.51. Finish is a milestone (and therefore has a duration of zero), so the EF is also 19.51. Barring any unforeseen events, the project should take 19.51 work days to complete. The next step is to determine the late start (LS) and late finish (LF) of each activity. This will eventually show if there are activities that have slack. The LF is defined as the minimum LS of all successor activities, unless the activity is the last activity, for which the LF equals the EF. The LS is the LF minus the task duration (LS = LF - duration). The LF for finish is equal to the EF (19.51 work days) since it is the last activity in the project. Since the duration is zero, the LS is also 19.51 work days. This will be used as the LF for f and g. The LF for g is 19.51 work days. The duration (5.17 work days) is subtracted from the LF to get an LS of 14.34 work days. This will be used as the LF for e. The LF for f is 19.51 work days. The duration (4.5 work days) is subtracted from the LF to get an LS of 15.01 work days. This will be used as the LF for d. The LF for e is 14.34 work days. The duration (5.17 work days) is subtracted from the LF to get an LS of 9.17 work days. This will be used as the LF for b and c. The LF for d is 15.01 work days. The duration (6.33 work days) is subtracted from the LF to get an LS of 8.68 work days. The LF for c is 9.17 work days. The duration (5.17 work days) is subtracted from the LF to get an LS of 4 work days. The LF for b is 9.17 work days. The duration (5.33 work days) is subtracted from the LF to get an LS of 3.84 work days. The LF for a is the minimum LS of its successor activities. Since c has an LS of 4 work days and d has an LS of 8.68 work days, the LF for a is 4 work days. The duration (4 work days) is subtracted from the LF to get an LS of 0 work days. The LF for start is the minimum LS of its successor activities. Since a has an LS of 0 work days and b has an LS of 3.84 work days, the LS is 0 work days. The next step is to determine the critical path and if any activities have slack. The critical path is the path that takes the longest to complete. To determine the path times, add the task durations for all available paths. Activities that have slack can be delayed without changing the overall time of the project. Slack is computed in one of two ways, slack = LF - EF or slack = LS - ES. Activities that are on the critical path have a slack of zero (0). The duration of path adf is 14.83 work days. The duration of path aceg is 19.51 work days. The duration of path beg is 15.67 work days. The critical path is aceg and the critical time is 19.51 work days. It is important to note that there can be more than one critical path (in a project more complex than this example) or the critical path can change. For example, let's say that activities d and f take their pessimistic (b) times to complete instead of their expected (TE) times. The critical path is now adf and the critical time is 22 work days. On the other hand, if activity c can be crashed to one work day, the path time for aceg is reduced to 15.34 work days, which is slightly less than the time of the new critical path, beg (15.67 work days). Assuming these scenarios do not happen, the slack for each activity can now be determined. Start and finish are milestones and by definition have no duration, therefore they can have no slack (0 work days). The activities on the critical path by definition have a slack of zero; however, it is always a good idea to check the math anyway when drawing by hand. o LFa - EFa = 4 - 4 = 0 o LFc - EFc = 9.17 - 9.17 = 0 o LFe - EFe = 14.34 - 14.34 = 0 o LFg - EFg = 19.51 - 19.51 = 0 Activity b has an LF of 9.17 and an EF of 5.33, so the slack is 3.84 work days. Activity d has an LF of 15.01 and an EF of 10.33, so the slack is 4.68 work days. Activity f has an LF of 19.51 and an EF of 14.83, so the slack is 3.84 work days. Therefore, activity b can be delayed almost 4 work days without delaying the project. Likewise, activity d or activity f can be delayed 4.68 work days without delaying the project (alternatively, d and f can be delayed 2.34 work days each). A completed network diagram created using Microsoft Visio. Note the critical path is in red. Critical path method The Critical Path Method, abbreviated CPM, or critical path analysis, is a mathematically based algorithm for scheduling a set of project activities. It is an important tool for effective project management. It was developed in the 1950s in a joint venture between DuPont Corporation and Remington Rand Corporation for managing plant maintenance projects. Today, it is commonly used with all forms of projects, including construction, software development, research projects, product development, engineering, and plant maintenance, among others. Any project with interdependent activities can apply this method of scheduling. The essential technique for using CPM is to construct a model of the project that includes the following: 1. A list of all activities required to complete the project (also known as Work breakdown structure), 2. The time (duration) that each activity will take to completion, and 3. The dependencies between the activities. Using these values, CPM calculates the longest path of planned activities to the end of the project, and the earliest and latest that each activity can start and finish without making the project longer. This process determines which activities are "critical" (i.e., on the longest path) and which have "total float" (i.e., can be delayed without making the project longer). In project management, a critical path is the sequence of project network activities which add up to the longest overall duration. This determines the shortest time possible to complete the project. Any delay of an activity on the critical path directly impacts the planned project completion date (i.e. there is no float on the critical path). A project can have several, parallel, near critical paths. An additional parallel path through the network with the total durations shorter than the critical path is called a sub-critical or non-critical path. These results allow managers to prioritize activities for the effective management of project completion, and to shorten the planned critical path of a project by pruning critical path activities, by "fast tracking" (i.e., performing more activities in parallel), and/or by "crashing the critical path" (i.e., shortening the durations of critical path activities by adding resources). Originally, the critical path method considered only logical dependencies between terminal elements. Since then, it has been expanded to allow for the inclusion of resources related to each activity, through processes called "activity-based resource assignments" and "resource leveling". A resource-leveled schedule may include delays due to resource bottlenecks (i.e., unavailability of a resource at the required time), and may cause a previously shorter path to become the longest or "resource critical" path. A related concept is called the critical chain, which attempts to protect activity and project durations from unforeseen delays due to resource constraints. Since project schedules change on a regular basis, CPM allows continuous monitoring of the schedule, allows the project manager to track the critical activities, and alerts the project manager to the possibility that non-critical activities may be delayed beyond their total float, thus creating a new critical path and delaying project completion. In addition, the method can easily incorporate the concepts of stochastic predictions, using the Program Evaluation and Review Technique (PERT) and event chain methodology. Currently, there are several software solutions available in industry that use the CPM method of scheduling, see list of project management software. However, the method was developed and used without the aid of computers. A schedule generated using critical path techniques often is not realized precisely, as estimations are used to calculate times: if one mistake is made, the results of the analysis may change. This could cause an upset in the implementation of a project if the estimates are blindly believed, and if changes are not addressed promptly. However, the structure of critical path analysis is such that the variance from the original schedule caused by any change can be measured, and its impact either ameliorated or adjusted for. Indeed, an important element of project postmortem analysis is the As Built Critical Path (ABCP), which analyzes the specific causes and impacts of changes between the planned schedule and eventual schedule as actually implemented. Work breakdown structure A (WBS) is a fundamental project management technique for defining and organizing the total scope of a project, using a hierarchical tree structure. The first two levels of the WBS (the root node and Level 2) define a set of planned outcomes that collectively and exclusively represent 100% of the project scope. At each subsequent level, the children of a parent node collectively and exclusively represent 100% of the scope of their parent node. A well- designed WBS describes planned outcomes instead of planned actions. Outcomes are the desired ends of the project, and can be predicted accurately; actions comprise the project plan and may be difficult to predict accurately. A well-designed WBS makes it easy to assign any project activity to one and only one terminal element of the WBS. History The concept of the WBS developed with the Program Evaluation and Review Technique (PERT) in the United States Department of Defense (DoD). PERT was introduced by the U.S. Navy in 1957 to support the development of its Polaris missile program. While the term "work breakdown structure" was not used, this first implementation of PERT did organize the tasks into product oriented categories. By June of 1962, DoD, NASA and the aerospace industry published a guidance document for the PERT Cost system which included an extensive description of the WBS approach. This guide was endorsed by the Secretary of Defense for adoption by all services. In 1968, the DoD issued "Work Breakdown Structures for Defense Materiel Items" (MIL- STD-881), a military standard mandating the use of work breakdown structures across the DoD.  This standard established top-level templates for common defense materiel items along with associated descriptions (WBS dictionary) for their elements. The document has been revised several times, most recently in 2005. The current version of this guidance can be found in "Work Breakdown Structures for Defense Materiel Items" (MIL-HDBK-881A). It includes guidance for preparing work breakdown structures, templates for the top three levels of typical systems (Appendices A through H), and a set of "common elements" that are applicable to all major systems and subsystems (Appendix I) Defense Materiel Item categories from MIL-HDBK-881A: Aircraft Systems Electronic/Automated Software Systems Missile Systems Ordnance Systems Sea Systems Space Systems Surface Vehicle Systems Unmanned Air Vehicle Systems Common Elements The Common Elements identified in MIL-HDBK-881A, Appendix I are: Integration, assembly, test, and checkout; Systems engineering; Program management; Training; Data; System test and evaluation; Peculiar support equipment; Common support equipment; Operational and site activation; Industrial facilities; and Initial spares and repair parts In 1987, the Project Management Institute (PMI) documented the expanion of these techniques across non-defense organizations. The Project Management Body of Knowledge (PMBOK) Guide provides an overview of the WBS concept, while the "Practice Standard for Work Breakdown Structures" is comparable to the DoD handbook, but is intended for more general application. WBS design principles The 100% Rule One of the most important WBS design principles is called the 100% Rule. The Practice Standard for Work Breakdown Structures (Second Edition), published by the Project Management Institute (PMI) defines the 100% Rule as follows: The 100% Rule...states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management. The 100% rule is one of the most important principles guiding the development, decomposition and evaluation of the WBS. The rule applies at all levels within the hierarchy: the sum of the work at the ―child‖ level must equal 100% of the work represented by the ―parent‖ and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work… It is important to remember that the 100% rule also applies to the activity level. The work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package. (p. 8) Planned outcomes, not planned actions If the WBS designer attempts to capture any action-oriented details in the WBS, he/she will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results. This also ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and creative thinking on the part of the project participants. For new product development projects, the most common technique to ensure an outcome-oriented WBS is to use a product breakdown structure. Feature-driven software projects may use a similar technique which is to employ a feature breakdown structure. When a project provides professional services, a common technique is to capture all planned deliverables to create a deliverable-oriented WBS. Work breakdown structures that subdivide work by project phases (e.g. Preliminary Design Phase, Critical Design Phase) must ensure that phases are clearly separated by a deliverable also used in defining Entry and Exit Criteria (e.g. an approved Preliminary Design Review document, or an approved Critical Design Review document). Mutually exclusive elements In addition to the 100% Rule, it is important that there is no overlap in scope definition between two elements of a WBS. This ambiguity could result in duplicated work or miscommunications about responsibility and authority. Likewise, such overlap is likely to cause confusion regarding project cost accounting. If the WBS element names are ambiguous, a WBS dictionary can help clarify the distinctions between WBS elements. The WBS Dictionary describes each component of the WBS with milestones, deliverables, activities, scope, and sometimes dates, resources, costs, quality, etc. Level of detail A question to be answered in the design of any WBS is when to stop dividing work into smaller elements. A common way of deciding the detailing level is the time between status reports/meetings. If the team reports bi-weekly the largest work package should be 80 hours. Then at reporting time a package is either not started, in progress, finished or late. This way makes it easy catching delays. A work package is a piece that: can be realistically and confidently estimated cannot be logically subdivided further can be completed quickly have a meaningful conclusion and deliverable can be completed without interruption (without the need for more information) will be outsourced or contracted out Decomposition Considerations (Breadth vs. Depth) A WBS will tend to be most useful for project management when its breadth and depth are thoughtfully balanced. A common pitfall is to inadequately group related elements, resulting in one or more nodes of the WBS becoming "too wide" to support effective management. This can make it difficult for management to find risk-relevant roll-up points within the WBS, requiring manual subtotaling of nodes or eventual restructuring of the WBS in order to make useful cost data more readily accessible. While no concrete standard exists for optimal depth or breadth, a common rule-of-thumb is to avoid having more than 7 immediate sub-elements below any given node of the WBS. This rule-of-thumb appears to be derived from psychological studies indicating that an average human brain is only capable of processing about 7 to 9 considerations simultaneously. The relevance of that psychological consideration to any particular WBS elaboration is left to the discretion of the WBS designer. At a minimum, the existence of more than 7 sister-nodes at any point in the WBS should prompt the designer to carefully consider whether those sub-elements might not best be expressed (and tracked) in more logical sub-groupings. WBS coding scheme It is common for WBS elements to be numbered sequentially to reveal the hierarchical structure. For example 1.3.2 Rear Wheel identifies this item as a Level 3 WBS element, since there are three numbers separated by a decimal point. A coding scheme also helps WBS elements to be recognized in any written context. WBS construction example Figure 1: WBS Construction Technique. This exemplary WBS is from PMI's Practice Standard for Work Breakdown Structures (2nd Edition). This image illustrates an objective method of employing the 100% Rule during WBS construction. Figure 1 shows a WBS construction technique that demonstrates the 100% Rule quantitatively. At the beginning of the design process, the project manager has assigned 100 points to the total scope of this project, which is designing and building a custom bicycle. At WBS Level 2, the 100 total points are subdivided into seven comprehensive elements. The number of points allocated to each is a judgment based on the relative effort involved; it is NOT an estimate of duration. The three largest elements of WBS Level 2 are further subdivided at Level 3, and so forth. The largest terminal elements at Level 3 represent only 17% of the total scope of work. These larger elements may be further subdivided using the progressive elaboration technique described above. In this example, the WBS coding scheme includes a trailing "underscore" character ("_") to identify terminal elements. This is a useful coding scheme because planned activities (e.g. "Install inner tube and tire") will be assigned to terminal elements instead of parent elements. Incidentally, this quantitiative method is related to the Earned Value Management technique. It is recommended that WBS design be initiated with interactive software (i.e. a spreadsheet) that allows automatic rolling up of point values. Another recommended practice is to discuss the point estimations with project team members. This collaborative technique builds greater insight into scope definitions, underlying assumptions, and consensus regarding the level of granularity required to manage the project. Common pitfalls and misconceptions A WBS is not an exhaustive list of work. It is instead a comprehensive classification of project scope. A WBS is not a project plan or a project schedule and it is not a chronological listing. It is considered poor practice to construct a project schedule (e.g. using project management software) before designing a proper WBS. This would be similar to scheduling the activities of home construction before completing the house design. Without concentrating on planned outcomes, it is very difficult to follow the 100% Rule at all levels of the WBS hierarchy. A WBS is not an organizational hierarchy. Some practitioners make the mistake of creating a WBS that shadows the organizational chart. While it is common for responsibility to be assigned to organizational elements, a WBS that shadows the organizational structure is not descriptive of the project scope and is not outcome-oriented. See also: responsibility assignment matrix (also called a Staffing Matrix). WBS updates, other than progressive elaboration of details, require formal change control. This is another reason why a WBS should be outcome-oriented and not be prescriptive of methods. Methods can, and do, change frequently, but changes in planned outcomes require a higher degree of formality. If outcomes and actions are blended, change control may be too rigid for actions and too informal for outcomes. PRINCE2 Methodology PRINCE2 (PRojects IN Controlled Environments) is a structured method for effective project management. PRINCE2 is based on the experiences of scores of projects, project managers and project teams, who have contributed, some from their mistakes or omissions, others from their successes. PRINCE2 is a de facto standard used extensively by the UK government and is widely recognised and used in the private sector, both in the UK and internationally. PRINCE2 is in the public domain. PBS - Product Breakdown Structure This is the first step in product-based planning. Breaking down a product into its constituent sub-products helps clarify and identify all necessary work for its creation. The objectives of the step are: • Identify the products required by the customers • Identify additional products needed to build and support the customer products • Build a consensus on the best product groupings that should be used to generate ideas on what products have to be created or obtained A PRINCE2 project has two types of product: 1. The specialist products whose development is the subject of the plan 2. The management ‗products‘ that will be required as part of managing the project (e.g. Highlight Reports, End Stage Reports, Project Issues) and as part of establishing and maintaining quality. All the products of the project need to be drawn up in a hierarchical structure. Practitioner Exam Tips: • There must be no one-to-one product relationships • There must not be any arrows • There must be at least three levels not including the top level product i.e. a multiple level • There must be at least two intermediate products: one integration product and one collective group • The project‘s final product should be at the top • There must be at least one simple, external product • Ask ‗Does this product consist of these products?‘. PD - Product Description A description of a product‘s purpose, composition, derivation and quality criteria. It is produced at planning time, as soon as the need for the product is identified. Product Descriptions may need to be updated if a change to a product is agreed. Once approved, a Product Description should not be changed without passing through Change Control. PFD - Product Flow Diagram A diagram showing the sequence of production and interdependencies of the products listed in a Product Breakdown Structure. PID - Project Initiation Document A logical document which brings together the key information needed to start the project on a sound basis and to convey that information to all concerned with the project. Once approved at the end of the Initiation Stage, the Project Initiation Document is ‗frozen‘ and used as a ‗baseline‘ to make key decisions upon during the project. The most dynamic parts of the PID are: Project Plan, Business Case and Risk Log. They will be updated at least at the end of each stage. PL - Planning Planning is a repeatable process and plays an important role in other processes, the main ones being: • Planning an Initiation Stage (SU6) • Planning a Project (IP2) • Planning a Stage (SB1) • Updating a Project Plan (SB2) • Accepting a Work Package (MP1) • Producing an Exception Plan (SB6). Apart from a plan, the process produces: • A Product Checklist, which is a table of the products to be produced by the work planned, with space for planned and actual dates for delivery of draft, quality-checked and approved products • The Risk Log, updated with any risk situation changes made as a result of the planning activity. Peer Review Specific reviews of a project or any of its products where personnel from within the organisation and/or from other organisations carry out an independent assessment of the project. Peer reviews can be done at any point within a project but are often used at stage-end points. Phase A part, section or segment of a project, similar in meaning to a PRINCE2 stage. The key meaning of stage in PRINCE2 terms is the use of management stages, i.e. sections of the project to which the Project Board only commits one at a time. A phase might be more connected to a time slice, change of skills required or change of emphasis. Planning Network A flow diagram showing the activities of a plan and their interdependencies. The network shows each activity‘s duration, earliest start and finish times, latest start and finish times and float. Planning Quality (IP1) This process builds on the Project Approach defined in SU5 and describes how quality will be achieved in the subsequent planning processes. The Project Quality Plan will contain the results of Planning Quality (IP1) and will be an element of the Project Initiation Document output from Assembling a PID (IP6). Planning a Project (IP2) The process uses the common Planning (PL) process to produce the Project Plan. The Project Plan becomes a major element of the Project Initiation Document. Planning a Stage (SB1) The approaching end of the current stage triggers the process. The main objective is to prepare a plan for the next stage of the project. The high-level summary of the next stage is expanded from the Project Plan into sufficient detail that the Project Manager will be able to control progress against it ona day-to-day basis. The Planning (PL) process is used to develop the plan. The Stage Plan will need to be prepared in parallel with any relevant team plans. Planning an Initiation Stage (SU6) The Project Board needs to know what effort is required to create the PID. The common Planning (PL) process will be used to create the initiation Stage Plan. Plans PRINCE2 offers a series of plan levels that can be tailored to the size and needs of a project and an approach to planning based on products rather than activities. A plan is a document, framed in accordance with a predefined scheme or method, describing how, when and by whom a specific target or set of targets is to be achieved. A plan is a design of how identified targets for deliverables; timescales, costs and quality can be met. Plans are the backbone of the management information system required for any project. PRINCE2 proposes 3 levels of Plan: Project (mandatory); Stage (mandatory); and Team (optional). This is to reflect the different levels of management involved in the project. All plans follow the same structure and format. Exception plans should also follow the same format as other plans. An Exception plan picks up from the current plan actuals to the end of that current plan. PRINCE2 has a Product-based approach to planning and also includes activity planning. The Project Board approve the Project Plan, Stage Plan and any Exception Plans. The Project Manager approves all Team Plans. The Project Plan is updated at the end of every stage to reflect progress already made and to show the impact of the next stage. Re-planning is needed at Stage Boundaries and when Exceptions arise. The last task when creating a plan is to add its narrative to explain the plan, any constraints on it, external dependencies, assumptions made and the risks identified. Post-Project Review - One or more reviews held after project closure to determine if the expected benefits have been obtained. Also known as post-implementation review. Post-Project Review Plan The purpose of the Post-Project Review Plan is to define for the Executive how and when a measurement of the achievement of the project benefits can be made. The plan is presented to the Executive at the end of the project. The plan has to cover the effort to find out: - Whether the expected benefits of the product(s) have been realised - Whether the product(s) has caused any problems in use. Each expected benefit has to be assessed for the level of its achievement so far or any additional time needed for the benefit to materialise. Use of the product may have brought unexpected side effects, either beneficial or adverse. Time and effort have to be allowed to document explanations of why these side effects were not foreseen. The plan must include time for recommendations on how to realise or improve benefits or counter problems. The post-project review is planned as part of Identifying Follow-on Actions (CP2), but the Executive is responsible for ensuring that the review happens after the project has finished. Practitioner Examination Typical Topics for Preparation and individual practical work: • Product-Based Planning • Risk Analysis • Business Case • Controls • Configuration Management & Change Control • Quality Practitioner Level This level is aiming to measure whether a candidate would be able to apply PRINCE2 to the running and managing of a project within an environment supporting PRINCE2. To this end they need to exhibit the competence required for the Foundation qualification, and show that they can apply and tune PRINCE2 to address the needs and problems of a specific project scenario. Preparing a Project Brief (SU4) The project needs to start with a reliable statement of requirements and expectation, to ensure it is based on consistent and adequate information. Keep the Project Brief as small and high level as is consistent with the decisions that need to be taken in Authorising Initiation (DP1). Process That which must be done to bring about a particular outcome, in terms of information to be gathered, decisions to be made and results that must be achieved. Producer This role represents the creator(s) of a product that is the subject of a quality review. Typically, it will be filled by the person who has produced the product or who has led the team responsible. Producing an Exception Plan (SB6) The deviation should have been recognised during Controlling a Stage (CS). The Project Manager will have brought the situation to the attention of the Project Board through an Exception Report. The Project Board will have requested the Project Manager to produce an Exception Plan. The Exception Plan will then be presented to the Project Board at an Exception Assessment. Product Checklist To list the products to be produced within a Stage Plan, together with key status dates. Used by the Project Board to monitor progress. Extracted from the Product Breakdown Structure. Produced as an output from Defining and Analysing Products (PL2) and finalised in Completing a Plan (PL7). Product Status Account Information about the state of products within defined limits. The limits can vary. For example, the report could cover the entire project, a particular stage or a particular area of the project. Product-based Planning This PRINCE2 technique enables the project to define the standard of quality to which each product must conform. • Define what the project has to deliver • Provide descriptions of the required products, the skills needed to develop the products, plus measurable statements of the quality required and how the presence of that quality is to be tested • Objectively monitor and control progress. The sequence in which each product should be produced and any dependencies. The Planning (PL) process is where the technique of product-based planning is used. There are three steps to the product-based planning technique: 1. Producing a Product Breakdown Structure 2. Writing Product Descriptions 3. Producing a Product Flow Diagram. Practitioner Exam Tips: • Use product-based planning for Exception, Project, Stage and Team Plans • Do not use product-based planning for the Project Quality Plan, Configuration Management Plan, Post-Project Review Plan or Communication Plan • Only include management products if requested • External products (i.e. those outside the scope of the project) should be shown in ellipses • Identify at least 20 simple products, not activities, for a 50 mark question. Products A product maybe a tangible one such as a machine, a document or a piece of software, or it may be intangible, such as a culture change or a different organisational structure. Within PRINCE2 these are all called products. A product may itself be a collection of other products. PRINCE2 distinguishes between management products (which are produced as part of the management or quality processes of the project) and specialist products (which are those products that make up the final deliverable). Programme A portfolio of projects selected, planned and managed in a co-ordinated way. Project • A management environment that is created for the purpose of delivering one or more business products according to a specified Business Case • A temporary organisation that is needed to produce a unique and predefined outcome or result at a prespecified time using predetermined resources Project Approach To define the type of solution to be developed by the project and/or the method of delivering that solution. It should also identify any environment into which the solution must fit. Project Assurance The Project Board are responsible for Project Assurance. They may choose to delegate it but they will remain responsible. If Project Assurance is delegated, it has to be independent of the Project Manager. One Project Assurance responsibility is to ensure the right people are being involved, for example in product creation and quality checking. Project Board There are three project interests that need to be represented on the Project Board at all times, which are: Business, User and Supplier. The Project Board are the owners of the project. The Project Board is the project‘s voice to the outside world. The Project Board is not a democracy ruled by votes; the Executive is the key decision maker, with advice and support from the Senior User and Senior Supplier. The Project Board must also monitor the environment outside the project and bring to the notice of those concerned, such as the Project Manager, any changes that affect the project. Major Controls of the Project Board are: Project Initiation, End Stage Assessments, Highlight Reports, Stage Level Tolerance, Exception Reports, Exception Assessments and Project Closure. Project Brief A description of what the project is to do; a refined and extended version of the Project Mandate, which has been agreed by the Project Board and which is input to project initiation. Project Closure Notification Advice from the Project Board to inform the host location that the project resources can be disbanded and support services, such as space, equipment and access, demobilised. Project Closure Recommendation Notification prepared by the Project Manager for the Project Board to send (when the board is satisfied that the project can be closed) to any organisation that has supplied facilities to the project. Project Document Management Three main files are suggested by PRINCE2 – Project, Stage and Quality With sensible design,computerised support can avoid the need for multiple copies and ensure that staff have access to only the latest version of information. Remember that ‗files‘do not necessarily mean paper. The project files will cover a wide range of media, all of which need to be considered. Project File Filing under the Project file will include: The PID, Project Plan, Risk Log, Business Case, Organisation Structure, Controls, Communications Plan. Project Issue Project Issues can be about anything to do with the project. PRINCE2 uses the same approach – (Change Control) to capture all Change Requests, Off-Specifications and any general issues, new risks, questions, concerns, good ideas etc. All such things are treated and captured as Project Issues. Issues can impact existing risks and create new risks, therefore the Risk Log should be examined along side project issues and updated where necessary. Project Management The planning, monitoring and control of all aspects of the project and the motivation of all those involved in it to achieve the project objectives on time and to the specified cost, quality and performance. Project Management Team A term to represent the entire management structure of Project Board, Project Manager, plus any Team Manager, Project Assurance and Project Support roles. Project Manager The person given the authority and responsibility to manage the project on a day-to-day basis to deliver the required products within the constraints agreed with the Project Board. The Project Manager is responsible for producing a result that is capable of achieving the benefits defined in the Project Initiation Document. Project Mandate The Project Mandate contains information created externally to the project, which forms the terms of reference and is used to start up the PRINCE2 project. The Project Mandate should contain at least some basic elements of the Business Case. It will be used to create the Project Brief. The Project Mandate may take a variety of forms. Essentially any ―trigger‖ will suffice - the concept of the Project Mandate recognises that there has to be some stimulus to get the project ―into play‖! Project Plan A high-level plan showing the major products of the project, when they will be delivered and at what cost. An initial Project Plan is presented as part of the Project Initiation Document. This is revised as information on actual progress appears. It is a major control document for the Project Board to measure actual progress against expectations. It is used by the Project Board as a baseline against which to monitor project progress and cost stage by stage. Project Quality Plan A plan defining the key quality criteria, quality control and audit processes to be applied to project management and specialist work in the PRINCE2 project. It will be part of the text in the PID. The planning function includes the creation of the Configuration Management Plan, which forms part of the Project Quality Plan. It is produced as an output from Planning Quality (IP1). Project Records A collection of all approved management, specialist and quality products and other material, which is necessary to provide an auditable record of the project. NB This does not include working files. Project Start-up Notification Advice to the host location that the project is about to start and requesting any required Project Support services. Project Support Office A group set up to provide certain administrative services to the Project Manager. Often the group provides its services to many projects in parallel.