Introduction Project management is the science (and art) of organizing the components of a project, whether the project is development

of a new product, the launch of a new service, a marketing campaign, or a wedding. A project isn't something that's part of normal business operations. It's typically created once, it's temporary, and it's specific. As one expert notes, "It has a beginning and an end." A project consumes resources (whether people, cash, materials, or time), and it has funding limits. Project Management Basics No matter what the type of project, project management typically follows the same pattern: 1. 2. 3. 4. 5. Definition Planning Execution Control Closure

Defining the Project In this stage the project manager defines what the project is and what the users hope to achieve by undertaking the project. This phase also includes a list of project deliverables, the outcome of a specific set of activities. The project manager works with the business sponsor or manager who wants to have the project implemented and other stakeholders -- those who have a vested interest in the outcome of the project.

Planning the Project Define all project activities. In this stage, the project manager lists all activities or tasks, how the tasks are related, how long each task will take, and how each tasks is tied to a specific deadline. This phase also allows the project manager to define relationships between tasks, so that, for example, if one task is x number of days late, the project tasks related to it will also reflect a comparable delay. Likewise, the project manager can set milestones, dates by which important aspects of the project need to be met. Define requirements for completing the project. In this stage, the project manager identifies how many people (often referred to as "resources") and how much expense ("cost") is involved in the project, as well as any other requirements that are necessary for completing the project. The project manager will also need to manage assumptions and risks related to the project. The project manager will also want to identify project constraints. Constraints typically relate to schedule, resources, budget, and scope. A change in one constraint will typically affect the other constraints. For example, a budget constraint may affect the number of people who can work on the project, thereby imposing a resource constraint. Likewise, if additional features are added as part of project scope, that could affect scheduling, resources, and budget. Executing the Project Build the project team. In this phase, the project manager knows how many resources and how much budget he or she has to work with for the project. The project manager then assigns those resources and allocates budget to various tasks in the project. Now the work of the project begins.

Controlling the Project The project manager is in charge of updating the project plans to reflect actual time elapsed for each task. By keeping up with the details of progress, the project manager is able to understand how well the project is progressing overall. A product such as Microsoft Project facilitates the administrative aspects of project management. Closure of the Project In this stage, the project manager and business owner pull together the project team and those who have an interest in the outcome of the project (stakeholders) to analyze the final outcome of the project. Time, Money, Scope Frequently, people refer to project management as having three components: time, money, and scope. Reducing or increasing any one of the three will probably have an impact on the other two. If a company reduces the amount of time it can spend on a project, that will affect the scope (what can be included in the project) as well as the cost (since additional people or resources may be required to meet the abbreviated schedule). Project Portfolio Management Recent trends in project management include project portfolio management (PPM). PPM is a move by organizations to get control over numerous projects by evaluating how well each project aligns with strategic goals and quantifying its value. An organization will typically be working on multiple projects, each resulting in potentially differing amounts of return or value. The company or agency may decide to eliminate those projects with a lower return in order to dedicate greater resources to the remaining projects or in order to preserve the projects with the highest return or value

project management, tools, process, plans and project planning tips

While project management skills are obviously important for project managers, interestingly the methods and tools that project managers use can be helpful for everyone. A 'task' does not necessarily have to be called a 'project' in order for project management methods to be very useful in its planning and implementation. Even the smallest task can benefit from the use of a well-chosen project management technique or tool, especially in the planning stage. Any task that requires some preparation to achieve a successful outcome, will probably be done better by using a few project management methods somewhere in the process. Project management methods can help in the planning and managing of all sorts of tasks, especially complex activities. Project management is chiefly associated with planning and managing change in an organization, but a project can also be something unrelated to business - even a domestic situation, such as moving house, or planning a wedding. Project management methods and tools can therefore be useful far more widely than people assume.

Project management techniques and project planning tools are useful for any tasks in which different outcomes are possible where risks of problems and failures exist - and so require planning and assessing options, and organizing activities and resources to deliver a successful result. Projects can be various shapes and sizes, from the small and straightforward to extremely large and highly complex. In organizations and businesses, project management can be concerned with anything, particularly introducing or changing things, in any area or function, for example:

people, staffing and management products and services materials, manufacturing and production IT and communications plant, vehicles, equipment storage, distribution, logistics buildings and premises finance, administration, acquisition and divestment purchasing sales, selling, marketing human resources development and training customer service and relations

quality, health and safety, legal and professional technical, scientific, research and development new business development and anything else which needs planning and managing within organizations.

Successful project management, for projects large or small, tends to follow the process outlined below. The same principles, used selectively and appropriately, also apply to smaller tasks. Project management techniques are not just for project managers they are available for anyone to use.

project management process

1. Agree precise specification for the project - 'Terms of Reference' 2. Plan the project - time, team, activities, resources, financials - using suitable project management tools. 3. Communicate the project plan to your project team - and to any other interested people and groups. 4. Agree and delegate project actions.

5. Manage and motivate - inform, encourage, enable the project team. 6. Check, measure, monitor, review project progress - adjust project plans, and inform the project team and others. 7. Complete project - review and report on project performance; give praise and thanks to the project team. 1.8. Project follow-up - train, support, measure and report

results and benefits.

1 - agree precise specification (terms of reference) for the project

Often called the project 'terms of reference', the project specification should be an accurate description of what the project aims to achieve, and the criteria and flexibilities involved, its parameters, scope, range, outputs, sources, participants, budgets and timescales Usually the project manager must consult with others and then agree the project specification with superiors, or with relevant authorities. The specification may involve several drafts before it is agreed. A project specification is essential in that it creates a measurable accountability for anyone wishing at any time to assess how the project is going, or its success on completion. Project terms of reference also provide an essential discipline and framework to keep the project on track, and concerned with the original agreed aims and parameters. A properly formulated and agreed project specification also protects the project manager from being held to account for issues that are outside the original scope of the project or beyond the project manager's control. This is the stage to agree special conditions or exceptions with those in authority. Once you've published the terms of reference you have created a very firm set of expectations by which you will be judged. So if you have any concerns, or want to renegotiate, now's the time to do it.

The largest projects can require several weeks to produce and agree project terms of reference. Most normal business projects however require a few days thinking and consulting to produce a suitable project specification. Establishing and agreeing a project specification is an important process even if your task is simple one. A template for a project specification: 1. Describe purpose, aims and deliverables. 2. State parameters (timescales, budgets, range, scope, territory, authority). 3. State people involved and the way the team will work (frequency of meetings, decision-making process). 4. Establish 'break-points' at which to review and check progress, and how progress and results will be measured. Separately the acronym BOSCARDET provides a useful example structure for Terms of Reference headings/sections: Background, Objectives, Scope, Constraints, Assumptions, Reporting, Dependencies, Estimates, Timescales. This structure contains no specific heading for costs/budgets - these considerations can be included within 'Constraints' or 'Estimates'.

Since projects (and other activities requiring Terms of Reference) vary considerably there is no standard universal structure for a Terms of Reference document. The responsibility lies with the project manager or leader to ensure all relevant and necessary issues are included, and this local interpretation tends to imply TOR headings and document structure. Brainstorming can be a helpful process by which all relevant Terms of Reference criteria can be indentified and structured. Organizations may have standard TOR structures, such as the BOSCARDET example, which it is sensible to use where applicable, mindful of risks of omission or over-complication that can arise when following standard practice. See also Terms of Reference in the business dictionary section. 2 - plan the project

Plan the various stages and activities of the project. Where possible (and certainly where necessary) involve your team in the planning. A useful tip is to work backwards from the end aim, identifying all the things that need to be put in place and done, in reverse order. Additionally, from the bare beginnings of the project, use brainstorming (noting ideas and points at random typically with a project team), to help gather points and issues and to explore innovations and ideas. Fishbone diagrams are also useful for brainstorming and identifying causal factors which might otherwise be forgotten. For complex projects, or when you lack experience of the issues, involve others in the brainstorming process. Thereafter it's a question of putting the issues in the right order, and establishing relationships and links between each issue. Complex projects will have a number of activities running in parallel. Some parts of the project will need other parts of the project to be completed before they can begin or progress. Such 'interdependent' parts of a project need particularly careful consideration and planning. Some projects will require a feasibility stage before the completion of a detailed plan. Gantt Charts and Critical Path Analysis Flow Diagrams are two commonly used tools for detailed project management planning, enabling scheduling, costing and budgeting and other financials, and project management and reporting. project timescales and costs

Most projects come in late - that's just the way it is - so don't plan a timescale that is over-ambitious. Ideally plan for some slippage. If you have been given an fixed deadline, plan to meet it earlier, and work back from that earlier date. Build some slippage or leeway into each phase of the project. Err on the side of caution where you can. Projects which slip back and are delivered late, or which run over budget or fail to meet other financial requirements often cause significant problems. Many planners are put under pressure to deliver projects sooner and more costeffectively than is realistic. Ambition and aiming high are good attitudes, but planning without proper prudence and responsibility is daft. Investors and executives tend rarely to question an overambitious plan, but they will quickly make very ruthless decisions when any overly ambitious project starts to fail. Exercising a little realism at the outset of a project regarding financials and timescales can save an enormous amount of trouble later. the project team

Another important part of the planning stage is picking your team. Selecting and gaining commitment from the best team members whether directly employed, freelance, contractors, suppliers, consultants or other partners - is crucial to the quality of the project, and the ease with which you are able to manage it. Identifying or appointing one or two people even during the terms of reference stage is possible sometimes. Appointing the team early maximises their ownership and buy-in to the project, and maximises what they can contribute. But be very wary of appointing people before you are sure how good they are, and not until they have committed themselves to the project upon terms that are clearly understood and acceptable.. Some of the most valuable team members are informal advisors, mentors, helpers, who want nothing other than to be involved and a few words of thanks. Project management on a tight budget can be a lonely business - get some help from good people you can trust, whatever the budget. To plan and manage large complex projects with various parallel and dependent activities you will need to put together a 'Critical Path Analysis' and a spreadsheet on MS Excel or equivalent. Critical Path Analysis will show you the order in which tasks must be performed, and the relative importance of tasks. Some tasks can appear small and insignificant when they might actually be hugely influential in enabling much bigger activities to proceed or give best results. A Gantt chart is a useful way of showing blocks of activities over time and at a given cost and for managing the project and its costs along the way. project management tools

Here are examples and explanations of four commonly used tools in project planning and project management, namely: Brainstorming, Fishbone Diagrams, Critical Path Analysis Flow Diagrams Gantt Charts. The tools here each have their strengths and particular purposes, summarised as a basic guide in the matrix below.

Matrix key: B = Brainstorming F = Fishbone/Ishikawa Diagrams C = Critical Path Analysis Flow Diagrams G = Gantt Charts *** - main tool ** - optional/secondary tool * - sometimes useful

B Project brainstorming and initial concepts, ideas, structures, aims, etc Gathering and identifying all elements, especially causal and hidden factors Scheduling and timescales Identifying and sequencing parallel and interdependent activities and stages Financials - costings, budgets, revenues, profits, variances, etc Monitoring, forecasting, reporting Troubleshooting, problem identification, diagnosis and solutions 'Snapshot' or 'map' overview - nonsequential, non-scheduled Format for communications, presentations, updates, progress reports, etc ** *

*** **

*** ** ** ***

*** *

* *

** **

*** *** *

*** **

**

***

***

Brainstorming
Brainstorming is usually the first crucial creative stage of the project management and project planning process. See the brainstorming method in detail and explained separately, because it many other useful applications outside of project management. Unlike most project management skills and methods, the first stages of the brainstorming process is ideally a free-thinking and random technique. Consequently it can be overlooked or underutilized because it not a natural approach for many people whose mains strengths are in systems and processes. Consequently this stage of the project planning process can benefit from being facilitated by a team member able to manage such a session, specifically to help very organised people to think randomly and creatively. fishbone diagrams Fishbone diagrams are chiefly used in quality management faultdetection, and in business process improvement, especially in manufacturing and production, but the model is also very useful in project management planning and task management generally. Within project management fishbone diagrams are useful for early planning, notably when gathering and organising factors, for example during brainstorming.

Fishbone diagrams are very good for identifying hidden factors which can be significant in enabling larger activities, resources areas, or parts of a process. Fishbone diagrams are not good for scheduling or showing interdependent time-critical factors. Fishbone diagrams are also called 'cause and effect diagrams' and Ishikawa diagrams, after Kaoru Ishikawa (1915-89), a Japanese professor specialising in industrial quality management and engineering who devised the technique in the 1960s. Ishikawa's diagram became known as a fishbone diagram, obviously, because it looks like a fishbone: A fishbone diagram has a central spine running left to right, around which is built a map of factors which contribute to the final result (or problem). For each project the main categories of factors are

identified and shown as the main 'bones' leading to the spine. Into each category can be drawn 'primary' elements or factors (shown as P in the diagram), and into these can be drawn secondary elements or factors (shown as S). This is done for every category, and can be extended to third or fourth level factors if necessary. The diagram above is a very simple one. Typically fishbone diagrams have six or more main bones feeding into the spine. Other main category factors can include Environment, Management, Systems, Training, Legal, etc.

The categories used in a fishbone diagram should be whatever makes sense for the project. Various standard category sets exist for different industrial applications, however it is important that your chosen structure is right for your own situation, rather than taking a standard set of category headings and hoping that it fits. At a simple level the fishbone diagram is a very effective planning model and tool - especially for 'mapping' an entire operation. Where a fishbone diagram is used for project planning of course the 'Effect' is shown as an aim or outcome or result, not a problem. The 'Problem' term is used in fault diagnosis and in quality management problem-solving. Some fishbone diagrams can become very complex indeed, which is common in specialised quality management areas, especially where systems are computerised. This model, and the critical path analysis diagram are similar to the even more complex diagrams used on business process modelling within areas of business planning and and business process improvement.

Project critical path analysis (flow diagram or chart)

'Critical Path Analysis' sounds very complicated, but it's a very logical and effective method for planning and managing complex projects. A critical path analysis is normally shown as a flow diagram, whose format is linear (organised in a line), and specifically a time-line. Critical Path Analysis is also called Critical Path Method - it's the same thing - and the terms are commonly abbreviated, to CPA and CPM. A commonly used tool within Critical Path Analysis is PERT (Program/Programme/Project Evaluation and Review Technique) which is a specialised method for identifying related and interdependent activities and events, especially where a big project may contain hundreds or thousands of connected elements. PERT is not normally relevant in simple projects, but any project of considerable size and complexity, particularly when timings and interdependency issues are crucial, can benefit from the detailed analysis enabled by PERT methods. PERT analysis commonly feeds into Critical Path Analysis and to other broader project management systems, such as those mentioned here.

Critical Path Analysis flow diagrams are very good for showing interdependent factors whose timings overlap or coincide. They also enable a plan to be scheduled according to a timescale. Critical Path Analysis flow diagrams also enable costings and budgeting, although not quite as easily as Gantt charts (below), and they also help planners to identify causal elements, although not quite so easily as fishbone diagrams (below). This is how to create a Critical Path Analysis. As an example, the project is a simple one - making a fried breakfast. First note down all the issues (resources and activities in a rough order), again for example: Assemble crockery and utensils, assemble ingredients, prepare equipment, make toast, fry sausages and eggs, grill bacon and tomatoes, lay table, warm plates, serve. Note that some of these activities must happen in parallel - and crucially they are interdependent. That is to say, if you tried to make a fried breakfast by doing one task at a time, and one after the other, things would go wrong. Certain tasks must be started before others, and certain tasks must be completed in order for others to begin. The plates need to be warming while other activities are going on. The toast needs to be toasting while the sausages are frying, and at the same time the bacon and sausages are under the grill. The eggs need to be fried last. A Critical Path Analysis is a diagrammatical representation of what needs done and when. Timescales and costs can be applied to each activity and resource. Here's the Critical Path Analysis for making a fried breakfast:

This Critical Path Analysis example below shows just a few activities over a few minutes. Normal business projects would see the analysis extending several times wider than this example, and the time line would be based on weeks or months. It is possible to use MS Excel or a similar spreadsheet to create a Critical Path Analysis, which allows financial totals and time totals to be planned and tracked. Various specialised project management software enable the same thing. Beware however of spending weeks on the intricacies of computer modelling, when in the early stages especially, a carefully hand drawn diagram - which requires no computer training at all - can put 90% of the thinking and structure in place. (See the details about the most incredible planning and communications tool ever invented, and available for just a tiny fraction of the price of all the alternatives.)

project critical path analysis flow diagram example

gantt charts Gantt Charts (commonly wrongly called gant charts) are extremely useful project management tools. The Gantt Chart is named after US engineer and consultant Henry Gantt (1861-1919) who devised the technique in the 1910s. Gantt charts are excellent models for scheduling and for budgeting, and for reporting and presenting and communicating project plans and progress easily and quickly, but as a rule Gantt Charts are not as good as a Critical Path Analysis Flow Diagram for identifying and showing interdependent factors, or for 'mapping' a plan from and/or into all of its detailed causal or contributing elements.You can construct a Gantt Chart using MSExcel or a similar spreadsheet. Every activity has a separate line. Create a time-line for the duration of the project (the breakfast example shows minutes, but normally you would use weeks, or for very big longterm projects, months). You can colour code the time blocks to denote type of activity (for example, intense, watching brief, directly managed, delegated and left-to-run, etc.) You can schedule review and insert break points. At the end of each line you can show as many cost columns for the activities as you need. The breakfast example shows just the capital cost of the consumable items and a revenue cost for labour and fuel.

A Gantt chart like this can be used to keep track of progress for each activity and how the costs are running. You can move the time blocks around to report on actuals versus planned, and to reschedule, and to create new plan updates. Costs columns can show plan and actuals and variances, and calculate whatever totals, averages, ratios, etc., that you need. Gantt Charts are the most flexible and useful of all project management tools show the importance and inter-dependence of related parallel activities, and the necessity to complete one task before another can begin, as a Critical Path Analysis will do, so you may need both tools, especially at the planning stage, and almost certainly for large complex projects. gantt chart example

A wide range of computerised systems/software now exists for project management and planning, and new methods continue to be developed. It is an area of high innovation, with lots of scope for improvement and development. I welcome suggestions of particularly good systems, especially if inexpensive or free. Many organizations develop or specify particular computerised tools, so it's a good idea to seek local relevant advice and examples of best practice before deciding the best computerised project management system(s) for your own situation. Project planning tools naturally become used also for subsequent project reporting, presentations, etc., and you will make life easier for everyone if you use formats that people recognize and find familiar.

project financial planning and reporting For projects involving more than petty cash you'll probably need a spreadsheet to plan and report planned and actual expenditure. Use MSExcel or similar. Financial accounting for small projects can sometimes be managed using the project's Gantt Chart. Large projects are likely to require some sort of require dedicated accounting system, although conceivably Gantt Charts and financial management accounts can easily be administered within a spreadsheet system given sufficient expertise. If you don't know how to put together a basic financial plan, get some help from someone who does, and make sure you bring a good friendly, flexible financial person into team - it's a key function of project management, The spreadsheet must enable you to plan, administer and report the detailed finances of your project. Create a cost line for main expenditure activity, and break this down into individual elements. Create a system for allocating incoming invoices to the correct activities (your bought-ledger people won't know unless you tell them), and showing when the costs hit the project account. Establish clear payment terms with all suppliers and stick to them. Projects develop problems when team members get dissatisfied; rest assured, non- or late-payment is a primary cause of dissatisfaction. Remember to set some budget aside for 'contingencies' - you will almost certainly need it.

project contingency planning Planning for and anticipating the unforeseen, or the possibility that things may not go as expected, is called 'contingency planning'. Contingency planning is vital in any task when results and outcomes cannot be absolutely guaranteed. Often a contingency budget needs to be planned as there are usually costs associated. Contingency planning is about preparing fall-back actions, and making sure that leeway for time, activity and resource exists to rectify or replace first-choice plans. A simple contingency plan for the fried breakfast would be to plan for the possibility of breaking the yolk of an egg, in which case spare resource (eggs) should be budgeted for and available if needed. Another might be to prepare some hash-browns and mushrooms in the event that any of the diners are vegetarian. It may be difficult to anticipate precisely what contingency to plan for in complex long-term projects, in which case simply a contingency budget is provided, to be allocated later when and if required. 3 - communicate the project plan to your team This serves two purposes: it informs people what's happening, and it obtains essential support, agreement and commitment. If your project is complex and involves a team, then you should involve the team in the planning process to maximise buy-in, ownership, and thereby accountability. Your project will also benefit from input and consultation from relevant people at an early stage. Also consider how best to communicate the aims and approach of your project to others in your organization and wider network.

Your project 'team' can extend more widely than you might first imagine. Consider all the possible 'stakeholders' - those who have an interest in your project and the areas it touches and needs to attract support or tolerance. Involvement and communication are vital for cooperation and support. Failing to communicate to people (who might have no great input, but whose cooperation is crucial) is a common reason for arousing suspicion and objections, defensiveness or resistance. 4 - agree and delegate project actions

Your plan will have identified those responsible for each activity. Activities need to be very clearly described, including all relevant parameters, timescales, costs, and deliverables. Use the SMART acronym to help you delegate tasks properly. See the delegation tips and processes. Using proper delegation methods is vital for successful project management involving teams. When delegated tasks fail this is typically because they have not been explained clearly, agreed with the other person, or supported and checked while in progress. So publish the full plan to all in the team, and consider carefully how to delegate medium-to-long-term tasks in light of team members' forward-planning capabilities. Long-term complex projects need to be planned in more detail, and great care must be taken in delegating and supporting them. Only delegate tasks which pass the SMART test. Other useful materials to help understand team delegation are the Tannenbaum and Schmidt Continuum, and Tuckman's group forming/performing model. The Johari Window model is also an excellent review framework for quickly checking or reminding about mutual awareness among team members in large complex projects, where there is often a risk of project fragmentation and people 'doing their own thing' in blissful isolation - which seriously undermines even the best planned projects.

5 - manage, motivate, inform, encourage, enable the project team Manage the team and activities in meetings, communicating, supporting, and helping with decisions (but not making them for people who can make them for themselves). 'Praise loudly; blame softly.' (a wonderful maxim attributed to Catherine the Great). One of the big challenges for a project manager is deciding how much freedom to give for each delegated activity. Tight parameters and lots of checking are necessary for inexperienced people who like clear instructions, but this approach is the kiss of death to experienced, entrepreneurial and creative people. They need a wider brief, more freedom, and less checking. Manage these people by the results they get - not how they get them. Look out for differences in personality and working styles in your team. Misunderstanding personal styles can get in the way of team cooperation. Your role here is to enable and translate. Face to face meetings, when you can bring team members together, are generally the best way to avoid issues and relationships becoming personalised and emotional. Communicate progress and successes regularly to everyone. Give the people in your team the plaudits, particularly when someone high up expresses satisfaction - never, never accept plaudits yourself. Conversely - you must take the blame for anything that goes wrong - never 'dump' (your problems or stresses) on anyone in your team. As project manager any problem is always ultimately down to you anyway. Use empathy and conflict handling techniques, and look out for signs of stress and manage it accordingly. A happy positive team with a basic plan will outperform a miserable team with a brilliant plan, every time.

6 - check, measure, and review project performance; adjust project plans; inform project team and others Check the progress of activities against the plan. Review performance regularly and at the stipulated review points, and confirm the validity and relevance of the remainder of the plan. Adjust the plan if necessary in light of performance, changing circumstances, and new information, but remain on track and within the original terms of reference. Be sure to use transparent, preagreed measurements when judging performance. (Which shows how essential it is to have these measures in place and clearly agreed before the task begins.) Identify, agree and delegate new actions as appropriate. Inform team members and those in authority about developments, clearly, concisely and in writing. Plan team review meetings. Stick to the monitoring systems you established. Probe the apparent situations to get at the real facts and figures. Analyse causes and learn from mistakes. Identify reliable advisors and experts in the team and use them. Keep talking to people, and make yourself available to all. 7 - complete project; review and report on project; give praise and thanks to the project team At the end of your successful project hold a review with the team. Ensure you understand what happened and why. Reflect on any failures and mistakes positively, objectively, and without allocating personal blame. Reflect on successes gratefully and realistically. Write a review report, and make observations and recommendations about follow up issues and priorities - there will be plenty.

8 - follow up - train, support, measure and report project results and benefits Traditionally this stage would be considered part of the project completion, but increasingly an emphasised additional stage of project follow-up is appropriate. This is particularly so in very political environments, and/or where projects benefits have relatively low visibility and meaning to stakeholders (staff, customers, investors, etc), especially if the project also has very high costs, as ICT projects tend to do. ICT (information and communications technology) projects often are like this - low visibility of benefits but very high costs, and also very high stress and risk levels too. Project management almost always involves change management too, within which it's very important to consider the effects of the project on people who have to adapt to the change. There is often atraining or education need. There will almost certainly be an explanation need, in which for example methods like team briefing have prove very useful. Whatever, when you are focused on project management it is easy to forget or ignore that many people are affected in some way by the results of the project. Change is difficult, even when it is good and for right reasons. Remembering this during and at the end of your project will help you achieve a project that is well received, as well as successful purely in project management terms.

PERT chart (Program Evaluation Review Technique) Reprints A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either circles or rectangles) representing events, or milestones in the project linked by labelled vectors (directional lines) representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks. In the diagram, for example, the tasks between nodes 1, 2, 4, 8, and 10 must be completed in sequence. These are called dependent or serial tasks. The tasks between nodes 1 and 2, and nodes 1 and 3 are not dependent on the completion of one to start the other and can be undertaken simultaneously. These tasks LEARN MORE

Software Test Design Project Tracking Project Management Process are called parallel or concurrent tasks. Tasks that must be completed in sequence but that don't require resources or completion time are considered to have event dependency. These are represented by dotted lines with arrows and are called dummy activities. For example, the dashed arrow linking nodes 6 and 9 indicates that the system files must be converted before the user test can take place, but that the resources and time required to prepare for the user test (writing the user manual and user training) are on another path. Numbers on the opposite sides of the vectors indicate the time allotted for the task. The PERT chart is sometimes preferred over the Gantt chart, another popular project management charting method, because it clearly illustrates task dependencies. On the other hand, the PERT chart can be much more difficult to interpret, especially on complex projects. Frequently, project managers use both techniques. Getting started with PERT charts

Here are some additional resources for learning about how PERT charts and other project management tools are used in the enterprise: Project management tools and strategies: The Gantt chart and the PERT chart are probably the two best known charts in project management. Each of these can be used for scheduling, but because Gantt charts don't illustrate task dependencies and PERT charts can be confusing, PMs often use both. Project management charts: Beyond Gantt: Gantt charts are good for certain purposes, explains project management expert David Christiansen, but there are other charts PMs have at their disposal.

Project Management Templates Feasibility Study Undertake a Feasibility Study using Project Management Templates During the creation of a Business Case for your project, decide that you need to undertake a Feasibility Study to determine the likelihood of the alternative solutions actually meeting the customers requirements. A Feasibility Study adds depth to a Business Case by researching the business problem in more detail, identifying the requirements for a solution, and determining whether the alternative solutions are likely to meet the requirements stated. You should always start a Feasibility Study using Project Management Templatesby researching the business problem or opportunity that the project addresses. You should then document the customers requirements for a solution and complete a Feasibility Assessment to measure the likelihood of each alternative solution actually meeting those requirements. By ranking the results of the Feasibility Study, you can then recommend a preferred solution for implementation, based on the overall feasibility rating.

Although you may conduct a Feasibility Study Project Management Templatesexercise before, during or after you complete the Business Case for your project, it is usual to complete it as part of the Business Case process to add rigor to the alternative solutions identified. Once the Feasibility Study is complete, it is presented to an identified Project Sponsor for approval. Research the Problem Add depth to the Business Case by researching the root cause of the problem which the project hopes to address by implementing a suitable solution. Complete a Root Cause Analysis exercise to identify the underlying cause of the problem by performing the following steps:

Data Collection. Gather all of the information required to gain a thorough understanding of the problem Data Analysis. Analyze the information gathered and identify any gaps and deficiencies in knowledge Identify Contributing Factors. Then identify the events which led to the problem, and identify the possible contributing factors for those events Identify the Root Cause. After all of the contributing factors have been identified, describe the reasons for them occurring. These reasons form the root cause of the problem. Research the Opportunity Although projects are often initiated to solve a business problem, you may also initiate a project to realize (i.e. take up on) a business opportunity. Complete the following research to identify the underlying basis for the opportunity, by performing the following steps: - Data Collection. Gather all of the information required to gain a thorough understanding of the opportunity

- Data Analysis. Analyze the information gathered and identify any gaps and deficiencies in knowledge - Identify Contributing Factors. Then identify the events which led to the opportunity and identify the possible contributing factors for those events - Identify the Underlying Reason. After all of the contributing factors have been identified, describe the reasons for them occurring. These reasons form the underlying basis for the opportunity Identify the Requirements Now that you have a detailed understanding of the root cause of the problem or the underlying basis of the opportunity, you should identify the business drivers and requirements for a solution to that problem or opportunity in your online project management templates. For example, it may be required that a project delivers: - A new technology for the business with a central source of data - A set of new processes and procedures for staff to implement - A suite of new products and services to release to the market place - A new business premise with greater staff capacity and improved facilities - A physical asset for a customer, such as a construction, infrastructure or telecommunications asset Assess the Feasibility You have now completed all the background research required to gain a detailed understanding of the business problem, drivers and requirements. You are now ready to undertake a feasibility assessment,

by identifying the alternative solutions available and rating the likelihood of each solution meeting the requirements of the customer. You will also list the risks, issues and assumptions associated with each alternative solution. Then assess the likelihood (or feasibility) of each alternative solution meeting the requirements of the project. To determine the level of feasibility of each solution, you need to identify a range of appropriate assessment methods. Once you have completed the feasibility assessment, you should document the results by specifying the level to which the solution addresses the requirements of the customer. If you dont have the time, or it is not possible to complete a formal assessment of the feasibility of each solution, then a best guess based on the research of other similar projects undertaken may be the only method available to you. RISK ANALYSIS

Understanding Risk Analysis and Risk Management Risk Management The goal of risk management is to measure and assess risk, with the ultimate goal of managing that risk. Risk management falls into the arena of Project Planning. Over time, specific standards and methods have been developed with respect to risk management. These methods

of analysis help those that practice risk management to use

established ways of identifying risk. It also helps them manage risk by either avoiding it, transferring it, reducing the impact of the risk, or by various other alternative solutions that will be discussed later in this article. Risk management should be thoroughly understood by project managers. They should be familiar with the principles of risk management from the earliest days of their training in project management and project management principles. What is Risk? You may ask yourself, what is risk? Risk can be found in almost anything that we set out to do or accomplish in life. Think of risk as anything that can potentially have a negative impact on something that is of value to you. Risk can be caused by any number of factors. To understand the severity of a risk, risk is often analyzed for probability; the higher the chance that it will happen the higher the risk. Probability is then assessed in combination with loss. When it comes to project management, all types of risk can occur: knowledge risk, relationship risk or process-engagement risk. Unfortunately, each of these can have a huge impact on the productivity of your team and ultimately on the success of the project at hand. Having said that, all risk can not be avoided nor should it else nothing would ever be accomplished in your projects as risk exists in every single task. Identifying Risk Risk management requires you to identify potential risks; risk being anything that can possibly harm or have a negative impact on the project. Risk managers generally approach the search for potential risk from two distinct angles: source analysis and problem analysis. Source analysis seeks to look at the potential sources of risk whereas problem analysis looks at specific individual problems that could arise.

Risk Management Methods Risk management uses formulas and templates to narrow in on and to identify risk. Which formulas and templates are used is often determined by the industry that they are being practiced in. Some common methods of risk identification are: Scenario-Based Risk

Identification, Objectives-Based Risk Identification, Taxonomy-Based Risk Identification and Common Risk Checking.
Risk Assessment Once risks have been identified, the next logical step in risk management is assessment. Risk assessment, as mentioned earlier, measures the probability of an identified risk actually taking place, as well as the amount of loss that would be suffered were the risk to actually occur. Loss and probability are usually placed in a prioritized list, with those risks that are most probable and that stand to generate the most loss given the most attention. In reality, a lot of guess work goes into this phase of risk management as at times it is almost impossible to evaluate and know the true likelihood as to whether a potential risk will occur or not. Prioritizing Risk Once risk has been identified and prioritized according to probability and loss, those issues that are at the top of the prioritized list (those of highest risk) can be addressed. Of course, you would logically want to completely eliminate anything that is of high risk. Although ideal, this is not usually possible as eliminating all risk would also eliminate most of your opportunities. Managing Risk Risk can be and is usually managed by a variety of approaches: Risk transfer, risk avoidance, risk reduction and risk acceptance.

Risk Transfer Risk transfer involves transferring the weight or the consequence of a risk on to some other party. There are many ways that risk transfer can take place. Insurance is a commonly used method of risk transfer; the insurance company accepts the risk of another. Another form of risk transfer can happen in the way that a contract is laid out. Risk Avoidance Risk avoidance is exactly as it sounds. It generally involves not doing an activity in order to avoid the risk involved. The downfall of using avoidance as your main form of risk management is that by avoiding all risk, you will avoid all opportunities to earn or accomplish as well. Risk Reduction Risk reduction involves measures that are thrown at a risk in order to reduce the potential loss associated with that risk. A very easy to understand example of this is the installation of sprinklers in a building. Sprinklers can not prevent a fire but are aimed at reducing the loss caused by the fire should one break out. Risk Acceptance Risk acceptance is also known by the name of risk retention. Risk acceptance is simply accepting the identified risk without taking any measures to prevent loss or the probability of the risk happening. This approach is ideal for those risks that will not create a high amount of loss if they occur. These risks in fact would be considered more costly to manage than to allow.

Golden rules of risk management

The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner. The result will be that you minimise the impact of project

threats and seize the opportunities that occur. This allows you to deliver your project on time, on budget and with the quality results your project sponsor demands. Also your team members will be much happier if they do not enter a "fire fighting" mode needed to repair the failures that could have been prevented. This article gives you the 10 golden rules to apply risk management successfully in your project. They are based on personal experiences of the author who has been involved in projects for over 15 years. Also the big pile of literature available on the subject has been condensed in this article. Rule 1: Make Risk Management Part of Your Project The first rule is essential to the success of project risk management. If you don't truly embed risk management in your project, you can not reap the full benefits of this approach. You can encounter a number of faulty approaches in companies. Some projects use no approach whatsoever to risk management. They are either ignorant, running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). Some people blindly trust the project manager, especially if he (usually it is a man) looks like a battered army veteran who has been in the trenches for the last two decades. Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff. Rule 2: Identify Risks Early in Your Project The first step in project risk management is to identify the risks that are present in your project. This requires an open mind set that focuses on future scenarios that may occur. Two main sources exist to identify risks, people and paper. People are your team members that each bring along their personal experiences and expertise. Other people to talk to are experts outside your project that have a track record with the type of project or work you are facing. They can reveal

some booby traps you will encounter or some golden opportunities that may not have crossed your mind. Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. Paper is a different story. Projects tend to generate a significant number of (electronic) documents that contain project risks. They may not always have that name, but someone who reads carefully (between the lines) will find them. The project plan, business case and resource planning are good starters. Another categories are old project plans, your company Intranet and specialised websites. Are you able to identify all project risks before they occur? Probably not. However if you combine a number of different identification methods, you are likely to find the large majority. If you deal with them properly, you have enough time left for the unexpected risks that take place. Rule 3: Communicate About Risks Failed projects show that project managers in such projects were frequently unaware of the big hammer that was about to hit them. The frightening finding was that frequently someone of the project organisation actually did see that hammer, but didn't inform the project manager of its existence. If you don't want this to happen in your project, you better pay attention to risk communication. A good approach is to consistently include risk communication in the tasks you carry out. If you have a team meeting, make project risks part of the default agenda (and not the final item on the list!). This shows risks are important to the project manager and gives team members a "natural moment" to discuss them and report new ones. Another important line of communication is that of the project manager and project sponsor or principal. Focus your communication efforts on the big risks here and make sure you don't surprise the boss or the customer! Also take care that the sponsor makes decisions

on the top risks, because usually some of them exceed the mandate of the project manager. Rule 4: Consider Both Threats and Opportunities Project risks have a negative connotation: they are the "bad guys" that can harm your project. However modern risk approaches also focus on positive risks, the project opportunities. These are the uncertain events that beneficial to your project and organisation. These "good guys" make your project faster, better and more profitable. Unfortunately, lots of project teams struggle to cross the finish line, being overloaded with work that needs to be done quickly. This creates project dynamics where only negative risks matter (if the team considers any risks at all). Make sure you create some time to deal with the opportunities in your project, even if it is only half an hour. Chances are that you see a couple of opportunities with a high pay-off that don't require a big investment in time or resources. Rule 5: Clarify Ownership Issues Some project managers think they are done once they have created a list with risks. However this is only a starting point. The next step is to make clear who is responsible for what risk! Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign a risk owner for each risk that you have found. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. The effects are really positive. At first people usually feel uncomfortable that they are actually responsible for certain risks, but as time passes they will act and carry out tasks to decrease threats and enhance opportunities. Ownership also exists on another level. If a project threat occurs, someone has to pay the bill. This sounds logical, but it is an issue you have to address before a risk occurs. Especially if different business units, departments and suppliers are involved in your project, it becomes important who bears the consequences and has to empty his

wallet. An important side effect of clarifying the ownership of risk effects, is that line managers start to pay attention to a project, especially when a lot of money is at stake. The ownership issue is equally important with project opportunities. Fights over (unexpected) revenues can become a long-term pastime of management. Rule 6: Prioritise Risks A project manager once told me "I treat all risks equally." This makes project life really simple. However, it doesn't deliver the best results possible. Some risks have a higher impact than others. Therefore, you better spend your time on the risks that can cause the biggest losses and gains. Check if you have any showstoppers in your project that could derail your project. If so, these are your number 1 priority. The other risks can be prioritised on gut feeling or, more objectively, on a set of criteria. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. Whatever prioritisation measure you use, use it consistently and focus on the big risks. Rule 7: Analyse Risks Understanding the nature of a risk is a precondition for a good response. Therefore take some time to have a closer look at individual risks and don't jump to conclusions without knowing what a risk is about. Risk analysis occurs at different levels. If you want to understand a risk at an individual level it is most fruitful to think about the effects that it has and the causes that can make it happen. Looking at the effects, you can describe what effects take place immediately after a risk occurs and what effects happen as a result of the primary effects or because time elapses. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs, lead time or product quality. Another angle to look at risks, is to focus on the events that precede a risk occurrence, the risk causes. List the

different causes and the circumstances that decrease or increase the likelihood. Another level of risk analysis is investigate the entire project. Each project manager needs to answer the usual questions about the total budget needed or the date the project will finish. If you take risks into account, you can do a simulation to show your project sponsor how likely it is that you finish on a given date or within a certain time frame. A similar exercise can be done for project costs. The information you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimise the risks. Rule 8: Plan and Implement Risk Responses Implementing a risk response is the activity that actually adds value to your project. You prevent a threat occurring or minimise negative effects. Execution is key here. The other rules have helped you to map, prioritise and understand risks. This will help you to make a sound risk response plan that focuses on the big wins. If you deal with threats you basically have three options, risk avoidance, risk minimisation and risk acceptance. Avoiding risks means you organise your project in such a way that you don't encounter a risk anymore. This could mean changing supplier or adopting a different technology or, if you deal with a fatal risk, terminating a project. Spending more money on a doomed project is a bad investment. The biggest category of responses are the ones to minimise risks. You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. A final response is to accept a risk. This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult, time consuming or relatively

expensive. Just make sure that it is a conscious choice to accept a certain risk. Responses for risk opportunities are the reverse of the ones for threats. They will focus on seeking risks, maximising them or ignoring them (if opportunities prove to be too small). Rule 9: Register Project Risks This rule is about bookkeeping (however don't stop reading). Maintaining a risk log enables you to view progress and make sure that you won't forget a risk or two. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3). A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). Most project managers aren't really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off, especially if the number of risks is large. Some project managers don't want to record risks, because they feel this makes it easier to blame them in case things go wrong. However the reverse is true. If you record project risks and the effective responses you have implemented, you create a track record that no one can deny. Even if a risk happens that derails the project. Doing projects is taking risks. Rule 10: Track Risks and Associated Tasks The risk register you have created as a result of rule 9, will help you to track risks and their associated tasks. Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks or to generate, select and implement responses. Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which risks are more likely to happen? Has the

relative importance of risks changed? Answering this questions will help to pay attention to the risks that matter most for your project value