Sie sind auf Seite 1von 23

Project Management Basics

Learning Objectives At the end of this Define topic, all learners will be able to:

define and describe elements of a project charter and develop a problem statement, including baseline and improvement goals. assist with the development of project definition/scope using Pareto charts, process maps, etc. assist with the development of primary and consequential metrics (e.g., quality, cycle time, cost) and establish key project metrics that relate to the voice of the customer. use project tools such as Gantt charts, critical path method (CPM) and program evaluation and review technique (PERT) charts, etc. provide input and select the proper vehicle for presenting project documentation (e.g., spreadsheet output, storyboards, etc.) at phase reviews, management reviews, and other presentations. describe the purpose and benefit of project risk analysis, including resources, financials, impact on customers and other stakeholders, etc. describe the objectives achieved and apply the lessons learned to identify additional opportunities.

Introduction Since a Six Sigma project is, after all, a project, understanding project management basics is essential to successfully communicating the multiple facets of this complex process. This topic covers the fundamental tools to execute a successful project. The foundation document is the project charter. The definition and scope of the project is established by the Black Belt or the Master Black Belt, using information from your previous activities. Project metrics will be established to determine what will be relevant to the client, as well as what will be the best ways to communicate the voice of the customer. Selecting project planning tools will be critical to keeping the project on track and communications flowing. In addition, selecting proper project documentation and diligently using documents to record meetings and various phases of the project will be critical to keeping the project on track. Throughout the project, risk analysis plays an important role in helping project leaders, owners and stakeholders make choices and understand the magnitude of certain decisions. Finally, properly closing out the project will help declare the project is done and provide lessons for future project efforts.

Project Charter
The project charter is a written commitment ideally approved by management stating the scope of authority for an improvement project. It is recognized by all parties involved in the project. The charter is not required in Six Sigma to be approved by management, but it is strongly recommended. Once published, it provides powerful communication about the project to the entire team. At the same time, a charter is a living document, constantly being reviewed and updated to reflect the addition of relevant data as it becomes known. Project Charter Purposes

Gives authority to act; gives permission to work Summarizes the project itself and its goals, boundaries, and deadlines Provides a source for reference to determine which new requirements are covered under the original agreement Serves as a living document which continues to evolve as more requirements are uncovered, but also provides a central source from which to manage these changes

Project Charter Elements include:


Business Case Problem Statement Project Scope Goal Statement Resources

Business Case The business case is a short summary of the strategic reasons for the project. The justification for a business case would typically involve at least one of the following:

Cost per unit Quality or defect rate Cycle time

Good business cases should:


Define one primary business metric. Focus on a process rather that a cost account. Quantify a financial impact.

Focus on the output (product/service) for the external customer. Provide details regarding the baseline performance of the primary business measure to ensure that this is really a problem, not an exception. Determine the gap between the baseline performance of the primary business measure and the business objective.

Problem Statement The problem statement will detail the issue that the project team wants to improve. From the perspective of owners and relevant stakeholders, a major cause of project failure is the lack of clarity in describing the problem. Develop the problem statement as thoroughly as possible with the information you have. The problem statement is a crucial part of the charter. Problem cases include:

historical data what areas of the business are affected how long the problem has existed any other symptoms of the problem The project description, along with the entire charter, should be reviewed by and with owners and appropriate stakeholders to ensure the right problem is being addressed and the anticipated solution will fix the real problem. Problem statements are discussed further in the Define lesson of this course.

Project Scope The project scope is the specific aspect of the problem that will be addressed, and serves to specify the boundaries of the project. The project scope is discussed further in the Define lesson of this course, along with tools that help determine the scope.

Goal Statement As discussed later in this lesson and in the Define lesson, the goal statement should specifically outline what you hope to achieve at the end of the project. Goals should:

Be carefully thought out and expressed.

Specify how completing the project will lead to improvements over the status quo. You should be able to clearly describe the outcomes, deliverables and benefits to stakeholders and customers. Provide the criteria you need to evaluate the success of the project in terms of time, costs, and resources. Be reviewed by the core team, which must reach consensus before moving to the next phase of the project. With Problem Statements and Goal Statements it should be noted that many projects have one or the other they tend to be the inverse of each other. A Goal Statement would be to make savings of one million dollars. A Problem Statement would be that we currently spend a million dollars more than we should.

Resources In terms of the project charter, resources are the people required to complete the project. In the Team Leadership topic of this lesson, you will read more about the creation of teams and the roles and responsibilities of team members

Problem Statement
A problem statement details the issue the project team wants to improve. The problem statement should be specific and based on data that describes the issues current state. The problem statement should not include the proposed solution. Problem Statement Purpose Problem statements focus the team on a process deficiency, thus controlling the scope of the project. Problem statements also communicates the significance of the process deficiency to others. Problem Statement Examples Poorly-Written Problem Statements

There are too many customer returns. The housewares department return rate is 17%. There are too many incorrect customer invoices. We must reduce incorrect invoices by 15%.

Well-Written Problem Statements


In 2005, the big ticket return rate was 17%, representing $15 million in returns. This was 7% higher than the target objective or goal for the division. In the 4th quarter, 20% of all customer invoices were incorrect. This was an increase of 5% from 3rd quarter.

Proj Sc ject cope


The Six Sigma practi S itioner uses various tools to develop the project scope and define the pro v s oject with data Green Belt will becom familiar with a wide variety of to during D a. ts me w ools Define and Measure. Two of th hose tools in nclude
1. processmappi ing 2. an ndParetocha arts.

Data glea aned by thes tools is uti se ilized to dev velop the proj scope. oject
Tools

Process Maps M A proces map uses a flowchart as a graphica means of d ss a al depicting pr rocess structu visually ure, y defining the separate steps of any process. St y teps are in se equential ord and typic der cally include e inputs an outputs, re nd equired decisions, the pe eople involv ed, time at e each step, an nd/or measurem ments. The process map might docum a comb p ment bination of looking at cu urrent operat ting procedur analysis on these, an developing new proce res, nd g esses. And if available, th should b f hey be mapped to current do t ocument procedures. The imag represents a simple pr ge s rocess map.

Process Maps and Flow Charts M F s Symbols are used to define certai types of steps in a flow in wchart: rectangles for m steps an most nd diamonds for decisio Move to the next pag for a list o flowchart symbols. ons. o ge of t A sample process flo e owchart is sh hown below. Each symbo on the ma can have a ol ap additional informati added to it such as in ion o nputs and ou utputs. To se an exampl of the inpu and outputs ee le uts of a step in the proce flowchart roll over th step indic ess t, he cated in the i image

Flow Chart Symbols Benefits of a Process Map A well-developed process map yields several benefits:

Visuallyrepresentshowtheprocessworks Supportstheidentificationofdisconnectsandnonvalueaddedsteps Helpstheteambetterunderstandtheprocess Enablesthediscoveryofproblemsormiscommunications Helpsdefinetheboundariesoftheprocess Identifiesprocessinputsandoutputs Assistsinrecognitionofprocessbottlenecksandopportunitiesforimprovement

Process maps also serve functions in other phases of DMAIC:


Improve:Defineandcommunicatetheproposedchangestotheprocess Control:Documenttherevisedprocess

Creating Process Maps Procedure Materials needed: yellow sticky notes, notepads or flipchart paper; marking pens
1. 2. 3. 4. 5. 6. Define(identify)theprocess. Brainstormtheactivitiesinvolvedintheprocess. Arrangetheactivitiesinpropersequence. Determineinputsandoutputs. Identifytimelagsandnonvalueaddedsteps. Oncethesequenceisagreedupon,drawarrowstoshowtheflow.

Use When

Developinganunderstandingofthestepsinaprocess. Studyingaprocessforimprovement. Communicatinghowtheprocessworks. Documentingaprocess.

User Tips

Focusonidentifyingtheprocessbeforeworryingaboutcorrectlydrawingtheprocessmap. Focusonthoseareasthatappearcomplexwithanexcessivenumberofpotentialdecisionpoints

ordelays. Lookforduplication,redundancy,complexityortoomanyhandoffsintheprocess. Askthefollowingtypesofquestions: o Whyareweperformingthetaskinthismanner? o Doesthecurrentprocessdeviatefromthedesignedprocess?Why? o Whatarethevalueaddedactivities? o Whatarethenonvalueaddedactivities? o Howmuchtime,moneyorworkhoursarerequiredforeachtask?Thesemaybethe outputs(Ys)ofthestepsintheprocess.

Pareto Chart Description ASQs Certified Quality Auditor learning series describes the Pareto chart as a vertical bar graph in which the bars are arranged in descending order of height, from left to right. Bars on the left have the highest significance or impact to an organization in terms of frequency, costs, time, etc. This means that categories represented by the tall bars on the left are relatively more important than those on the right. (An exception might be categories containing conglomeration of the fewest items or a miscellaneous category, which always appear at the far right.) A cumulative frequency line is sometimes added to a Pareto chart to indicate the cumulative contributions of items. In the example shown next, frequency counts are plotted on the left-most vertical axis and categories are spread out on the horizontal axis. The bars and cumulative percentages show the relative contribution of each category to the whole.

The Pare diagram in this examp shows th certificate errors and missing cer eto i ple hat e rtificates account for 68% of the total document co d omplaints, th indicating the greates opportunit for hus g st ties improvem ment.

Critical to Quality (CTQ) Tree ( e The purp pose of the cr ritical to qua ality (CTQ) tree is to con t nvert custom needs/wa to mer ants measurab requirem ble ments for the business to implement. This is the c critical transi ition step between define and measure. m

Metrics
Primary and Consequential Metrics Once the top-level process map or SIPOC has been completed, the next step is to determine the outputs or elements of the processes that are most important to the customer, and which would have the biggest impact if improved. At this stage, primary and consequential metrics should be defined and later calculated within the Measure phase. Primary metrics, also called process metrics, are the metrics Six Sigma practitioners can most influence. Primary metrics are: almost always a direct output characteristic of a process. a measure of a process outcome, but not a financial goal or business objective. frequently focused on quality, cycle time, and cost. derived from the project stakeholders, including internal customers, external customers, and suppliers. Consequential metrics, also called secondary metrics, can be either business or process metrics, and are derived from or are a result of a primary metric. In any given project, there may be one primary metric or multiple consequential metrics for improving one process. Where there is one primary metric, secondary or consequential metrics are needed to assure that improving the primary metric does not degrade other critical metrics (e.g., reducing a primary metric of cost but at the consequence of degrading secondary metrics of quality or cycle time). Project Metrics The fundamental key metrics for a typical project can include the following categories:

Quality Cycle Time Cost Value Labor

Manufacturing metric example: defects per million parts.

Non-manufacturing metric example: defects per unit (errors on a loan application the "unit" is the application). Other breakdowns within these categories will occur depending on the processes selected for improvement.

Plan nning Tools T


As the pr roject planni continues to develop the quality professiona may use a variety of to ing p, y al ools to aid in this process. Some of th project pla he anning tools to be famili with inclu iar ude: 1. 2. 3. 4.

Gantt chart G Critical path analysis C a PERT chart Precedence Diagram Met D thod

Gan Cha ntt art

The Gant chart was developed by Henry Ga in the 19 tt b antt 910s. Accord ding to The Q Quality Tool lbox, second ed dition, Nanc R. Tague states, A Gantt chart is a bar chart t shows t tasks of a cy G that the project, when each must take pla and how long each w take. As the project progresses, b w m ace, w will bars are shade to show which tasks have been co ed w h ompleted. Also look into: miles k stones chart, project bar chart Gantt Ch Procedur hart re 1. Identif the follow fy wing tasks ne eeded to com mplete the pr roject: a. Key milestones (im m mportant che points) eck

b. Time required for each task c. The sequence: i. Tasks to be finished before the next task can begin ii. Simultaneous tasks iii. Tasks to be completed before each milestone 2. Draw a horizontal time axis along the top or bottom of a page, and then mark off in an appropriate scale for the length of the tasks (days or weeks). 3. Down the left side of the page, write each project task and milestone in order: a. For each event happening at a point in time, draw a diamond (unfilled) under the time for that event. b. For activities occurring over a period of time, draw a bar (unfilled) spanning the appropriate times on the timeline i. Align the left end of the bar with the time the activity begins. ii. Align the right end with the time the activity concludes. iii. Ensure that every task of the project is on the chart. 4. As events and activities take place, shade the diamonds and bars to show completion. For tasks in-progress, estimate the percentage of completion and shade the appropriate amount. 5. Place a vertical marker to show the current date. When posting the chart on the wall, a heavy dark string hung vertically across the chart with two thumbtacks is an easy way to show the current time. Using Gantt Charts

Sometimes Gantt charts have additional columns for showing details, such as the amount of time the task is expected to take, resources, or skill level needed, or person responsible. Beware of identifying reviews or approvals as events unless they really will take place at a specific time, such as a meeting. Reviews and approvals often can take days or weeks It can be useful to indicate the critical points on the chart with bold or colored outlines of the bars.

Crit tical Path An nalysi (CPA is A)

h Develope by project managers in the 1950s, critical path analysis (C ed i CPA) also kn as critic now cal path meth (CPM) is one of sev hod i veral plannin tools for d ng demonstratin and viewi ng ing chronological tasks, identifying possible timi risks, an establishin the least a i p ing nd ng amount of tim me for the pr roject/proces ss. Benefits

Displays a graphical mod of the pro D del oject Predicts the shortest time required to complete th project he Emphasizes activities crit E a tical to main ntaining the s schedule Provides a tim ming referen point thro nce oughout the project Id dentifies inte errelationships between tasks t

t Three paths exist in the diagram next:


1-3-4-5-7 (8 weeks) (criti path; lon w ical ngest time) 1-3-5-7 (6 we eeks) 1-2-6-7 (7 we eeks)

CPA Pro ocedures 1. Use sticky no to indivi U otes idually list all tasks in th project. U he Underneath ea task, dra a ach aw horizontal arr pointing right. row g A s i priate sequen (from le to right). nce eft 2. Arrange the sticky notes in the approp 3. Between each pair of task draw circ to repres B h ks, cles sent events a to mark the beginnin or and ng en of a task. nd 4. Label all even in seque L nts, ence, with nu umbers. Labe all tasks, i sequence, with letters el in , s.

5. For each task, estimate the completion time. Write the time below the arrow for each task. 6. Draw the critical path by highlighting the longest path from the beginning to the end of the project.

Use When

Developing an optimal plan for the project Identifying the most critical issues/processes that would affect the overall project time Identifying the longest path through the process causing the most risk to miss the deadline (the critical path) Determining fixed time targets

User Tips

All activities begin and end at circles (nodes: a stage of completion). All activities with no predecessor branch from node 1. All activities with no successor point to the last node (the highest number).

PER RT

PERT Chart C First developed by th Navy in th 1950s to manage com he he m mplex project program evaluation a ts, and review te echnique (PE ERT) charts are powerfu tools for re ul educing the t time and cos for comple st eting a project. PERTs pla anning techn nique accoun for rando nts omness in tim requirem me ments. The term Critical Pat Method (C m th CPM) will al be used f a similar approach. A lso for r According to o Pyzdek in Quality En n ngineering Handbook, T most im H The mportant diffe ference betw ween PERT a and CPM is that originall the time estimates for the activitie were assum determi t ly e es med inistic in CP PM and were probabilisti in PERT. Today, PER and CPM actually com e ic RT M mprise one t technique an the nd differenc are mainl historical. ces ly . Time-dep pendent task diagrams al k llow for the plotting of e each task in relation to th other. CP he PM charts ad the dimension of norm (most lik dd mal kely) time to complete ta asks, and the critical path e h (longest timeline) thr t rough the pro oject. PERT Chart Examp C ple There are 5 processes that can be performed for the comp e s e pliance/audi process. Cr it reate the report10 and send it to electron storage 20, which w take 3 w 0 nic will weeks to be r received. A determin nation of criti icality is ma If it is cr ade. ritical then it must be delivered to au to be t udit validated for accurac by an indi d cy ividual 40 which takes one week. The validati process w s ion will occur and it will be sent to intern audit 50 in 3 weeks to be place in queue f quarterly d s nal s ed for audits. If the determination 20 is not critica then it is s in 2 wee to be pla f al sent eks aced in queue for quarterly audits by in y nternal audit50. If the report is sen to physica storage 30 it will tak 4 r nt al 0 ke weeks to be processe and a rand ed dom group is sent to inte s ernal audit 5 which w take 2 weeks. 50 will The quickest path to the audit qu ueue is the no critical, el ot lectronic rep that will take 5 week to port ks be moved into the int d ternal audit queue. The longest path is the electr q l ronic, critica reports wh al hich will take 7 weeks to be moved in the intern audit que b nto nal eue.

Use When:

Planning and controlling projects. Determining feasibility of meeting deadlines. Identifying possible bottlenecks in the project. Evaluating the effects of changes in the project requirements. Evaluating the effects of deviating from the schedule. Evaluating the effects of diverting resources from the project, or redirecting additional resources to the project. Constructing a chart showing start and finish times for each activity, as well as relationships to other activities in the project. Identifying critical activities to be completed on time. Gathering information for improving the project schedule.

Benefits

Provides a means of estimating the project completion time Demonstrates the probability for completing the project ahead of schedule Identifies start and end dates as well as critical path activities that affect completion time Organizes tasks in established time frames Acts as a decision-making tool Identifies where and when parallel activities occur Serves as an evaluation tool to determine the effect of changes

PERT Chart Procedure 1. Use Post-it notes to individually list all tasks in the project. Underneath each task, draw a horizontal arrow pointing right. 2. Arrange the notes in the appropriate sequence (from left to right). 3. Between each two tasks, draw circles to represent events, and to mark the beginning or end of a task. 4. Label all events, in sequence, with numbers. Label all tasks, in sequence, with letters. 5. For each activity, make three estimates regarding time requirements: the shortest possible time, the most likely time, and the longest time. 6. Determine the critical path. 7. Adjustments to the PERT Chart should be made to reflect any changes to the project along the way. PERT Chart Key Terms

The following terms are important to keep in mind when using PERT charts:

Critical path refers to the sequence of tasks (path) that takes the longest time and determines the projects completion date. Any delay of tasks on a critical path will delay the project completion time. Slack time refers to the time an activity can be delayed without delaying the entire project. Tasks on the critical path have a zero slack time. Slack time is the difference between the latest allowable date and the earliest expected date. It is represented by the following nomenclature: o T/E = The earliest time (date) on which an event can be expected to occur o T/L = The latest time (date) on which an event can occur without extending the completion date of the project o Slack time = T/L T/E An event is the starting or ending point for a group of tasks. Activity is the work required to proceed from one event or point in time to another.

PDM M

Preceden Diagram Method nce m Preceden diagram method (PD is a tech nce DM) hnique for diagramming a process ne etwork with individua activities displayed at the nodes (b al d boxes). Line link the ac es ctivity nodes to show dependen ncies and seq quence. Also call activity led: y-on-node (A AON), acti ivity-on-arc (AOA), an nd/or activit ty-on-line (AOL). Benefits

Logically disp L plays the act tivities Shows the rel lationships among activi a ities Able to add extra informa A e ation within the node Allows easy identification and calculation of the critical path A i n h

Procedure 1. 2. 3. 4. 5. Use Id dentify the sp pecific activ vities in the process. p Determine the proper acti D e ivity sequence. Create a node for each ac C e ctivity. Connect the nodes by line C n es. Enter addition informat E nal tion into each node. h

When planning and controlling projects When identifying projects with a critical schedule When identifying possible bottlenecks After knowing the steps of the process, their sequence, and the time each takes When identifying the critical path When you need to find out the effects of crashing activities

PDM User Tips


Activities are on the node. PDM does not require the use of dummy lines or activities as in CPM and PERT. Draw from left to right. Some add arrows to indicate flow direction. Additional information in the node may include: o Earliest start date (ES) o Duration (D) o Earliest finish date (EF) o Latest date start date (LS) o Latest finish date (LF) o Slack: ES minus LS

Project Documentation
Project documentation is an important part of measuring and ensuring the success of any project. Several tools and processes for documentation exist. Regardless of the tools or processes used, it is important that all information provided be accurate, specific, and detailed. Spreadsheets monitor the project in terms of status, deadlines, and budget through the use of spreadsheet applications such as MS Excel. Spreadsheets provide an excellent visual representation of information when project management software, such as MS Project, is not available. Status reports are written with a standardized format and formal tone, specific to each organization. The report is delivered periodically to the members of the project team. Status reports provide information, such as: Where the project is in relation to the planRisks or issues affecting the time, scope, or cost of the projectAction plan to address the risks or issuesRequests for management assistance or interventionStatus reports may even include other documentation, such as: Milestone chartsPerformance reportsBudget reportsProject storyboards are useful for depicting a sequence of events or explaining a process to someone not familiar with a workflow or procedure. Storyboards are also helpful when conveying project information involving changes that are more easily explained in a visual manner than with words. A common application for project storyboards is the use of before-and-after pictures. Beforeand-after-pictures are particularly helpful for facility or product redesign projects. Storyboards are frequently used when preparing a presentation to the executive team, and allow the team to collect their thoughts in a way conducive to soliciting support and obtaining buy-in from top management for a Six Sigma project. Phased reviews are also called milestone reviews or tollgates. Typically there are five reviews in a Six Sigma project, corresponding to the five phases of the Six Sigma DMAIC (Define-Measure-Analyze-Improve-Control) process, which will be discussed in upcoming lessons. Phased reviews offer an opportunity for the project team to assess the progress in relationship to the projects goals. They also allow the project team to regroup and make any necessary changes or modifications to the project. Management reviews are meetings between the project leader (typically the Black Belt) and the management team. They allow the project leader to update management on the status of the project in terms of financial progress. In some organizations, tollgates are both an opportunity to review the project with senior management, as well as an opportunity to update key stakeholders on the projects overall progress (i.e., its current phase).

Project Risk Analysis


Project risk analysis provides a framework to identify elements that help or hinder an organization. Purpose of Project Risk Analysis Focus efforts on risks that could effect the organization Risk factors include: 1. Risk event Precisely what might happen to the detriment of the project 2. Risk probability How likely is the event to occur 3. Amount at stake The extent of the loss or gain that could result Benefits of Project Risk Analysis Risk identificationRisk quantificationRisk response developmentRisk response controlRisk mitigation Impacts of Project Risk Analysis on Customers and Other Stakeholders

Identifies potential sources of risk (schedule, cost, technical, legal, etc.) Enables management to make informed decisions about the progress of the project Statistical independence o Expected monetary value o Decision tree analysis o Monte Carlo analysis o Impact analysis

ProjectClosure

Lessons Learned Remember: a Six Sigma project's scope is very focused, so some customer needs and requirements and/or processes had to be set aside. Now is the time to go back and look over those other opportunities. Review the other opportunities with the team to see if they still need to be addressed. If so, save all customer documentation, metrics, etc. for the next project team.Brainstorm with your team to flesh out:what worked well.what could have worked better.what the team would have liked to do differently.Look across. Where else we can apply to compound benefits. Then CELEBRATE! Have an end-of-project celebration!

Das könnte Ihnen auch gefallen