Brief Introduction to Project Management


Published on

A brief introduction to project management for college students covering basic information and topics.

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The preamble establishes the ground rules for this presentation. This is akin to a project charter. The introduction establishes common terminologies. The How to section flies through project management using PMBOK. The Quiz is QC for this project. The Survey is QC and customer acceptance criteria for this project.
  • Establishing ground rules for this presentation is part of the stakeholder expectation management. The stakeholders are Shri (sponsor), Students, RCC management, Self (PM).
  • PMBOK is the distilled knowledge of thousands of project management professionals from all kinds of industries and sectors.
  • Projects may range from writing an essay requiring a lot of research to painting your house, building a tree house to building a space ship. All of these projects require planning before staring the work, though the amount of planning and the level of formalism differs. The same applies to the rest of the PMBOK process groups and knowledge areas. This page is all about assumptions. No formal pm experience is an assumption. Constraints include: 1 hour presentation to college students. No money involved.
  • This slides talks about stakeholder expectations. This lecture will not provide a PDU to audience for PMI usage, nor does it provide contact project management training necessary for PM certification. You need practical experience (4500 to 7500 hours of work related experience) plus 35 hours of PM training by a certified provider to apply for any of the PMI certifications. There are different certifications by PMI and by other institutes world wide. PMI being the most known in North America. Intuitive insight is really a gut feeling of how a project is managed. Processes, tools, and techniques are given cursory treatment..
  • The quiz and survey is not only QC but also acceptance criteria for the presentation.
  • An example of operations work that is temporary and unique but not a project: Imagine an IT help desk department where they receive service calls from customers. The calls are on the phone or by web or email. Does not matter. The help desk technician will analyse the service call information, use the operations manual for procedures for obtaining additional information relating to the topic, possibly communicating with the customer for the additional information. Then, once all the required information are gathered the operations manual is consulted to obtain the solution to the service call. The operations manual may not include the correct answer, and some research and experimentation is required to obtain the correct answer which is then reported to the customer. The customer is now happy. The service call is closed. The operations manual is updated to add the new situation which will now be routine. This last scenario shows a temporary and unique work, But it is not a project. UNLESS the work needed to close the service call turned out to be large enough to be initiated explicitly as a project. Another example of operations work is the installation of software for specific users in the organization. Or it could be the installation of the same software for all users if the IT management infrastructure permits mass installation using an automated script. This becomes routine operational work unless the software has special requirements like new hardware, operating system upgrades, etc.
  • Small jobs, single person work, or work that sufficiently routine, artistic is probably not a good candidate for project management. Work that requires many people of different talents and skills, perhaps with different locations, and requiring time and materials should be project managed. Imagine Michael Angelo or Leonardo Di Vinci project managing the statue of David or the Mona Lisa. Both works are unique and the work to produce them is temporary. And they are projects in a certain sense but with very little or nonexistent formalism. On going work or operations may involve repetitive work and does not have beginning or end. Operations may have unique events happening but they these unique events are not projects. Projects may have repeated elements but the overall outcomes are still unique. The outcome of a project used by other projects: MS Word is the product of project A, and it is used to carry the work of Project B. MS Access Runtime distributable is the product of project A, and project B is a vertical application for market X that bundles the Access runtime. Or the project can package the results of subprojects.
  • Market demand: CNN mobile application. Organizational need: HR software. Customer request: Integrate Facebook with Skype. Need this feature on that software. Technological advance: IPAD. Improved encryption because computers became faster now and can crack existing algorithms. Legal requirement: collect certain information, create certain reports Ecological impact: forest fire monitoring, desertification monitoring. Use improved hardware that use less energy, use software that use less hardware. Social need: Software to improve healthcare management in a rural area. A web site for an activist group.
  • RFP: Procurement document whereby the buyer requests a potential seller to provide various pieces of products or services. This includes legalistic and contractual terms for the work. SOW: A narrative description of products, services, or results to be supplied. Technical requirement: actual technical description of a product or result. Market analysis involves studying the market size, growth, trends, pricing, valuations, This can lead to discovering a need for a new product for the organization.
  • Examples: Knowledge of industry and project management. People and leadership skills, negotiation skills, organizational skills. Scheduling software, PMIS. Monte Carlo analysis, EVM, WBS.
  • Knowledge of specific industry is important for project managers because they have to understand the components of work, how they fit together, and to communicate with the talented workforce that will do the creation and assembly of the work. A lot of the processes require Expert opinion on many subject matters and it would be hard for a PM who does not know the industry to understand what the actual domain experts are saying unless he/she has some industry knowledge. For functional managers, it is the same problem. However, for executive managerial levels, there is no direct interaction with the technical work below, and their work requires financial and business technical knowledge.
  • The PM orchestrates the initiation, planning, execution, monitoring, and closing activities of the project with inputs from all the stakeholders. The PM’s main concentration is on communication and integration of the various pieces of the project as planned and executed by the team. So far, the reader should get the idea of a flow of work through out the project from beginning to end. They also should get the idea of various kinds of project management knowledge to be used. Nothing specific. Emphasis on communication and integration aspects of the PM job.
  • The project life cycle is a collection of generally sequential project phases whose name and number are determined by the control needs of the organization. It can be documented with a methodology. The methodology is such as SDLC, Agile, etc.
  • Plan Do Check Act cycle.
  • Mini project: Driving a car from A to B. Scope: destination B Time: Get there by 4:30 PM hour. Depart by 11:00 AM. Today. Cost: Must not spend more than $20 dollars on gas. Quality: Must obey traffic laws with no exceptions. Risk: inadvertent crossing of a camera traffic light and getting a hefty ticket weeks later in the mail. Plan: Take the following route obtained from Google maps. Attached map, GPS, Money, Drivers License. Executing: Driving. Following the common and customary driving habits of the area. Measurements: location, speed, destination, GPS, exit numbers and names; Car engine lights: …. Quality Assurance and process improvements. Monitor and control: Quality Control: Am I driving and obeying the laws. Am I speeding too much and adding risks. Am I speeding too much and spending too much fuel. Closing: Calculate the final costs. Calculate the time. Stow away all travel related materials. Pay any monies owed or receive from ride sharers. Close.
  • Phases are formally concluded and closed with a review of deliverables. Phases are formally initiated as a result of a decision to close one phase and start the next. PMI overuses the term phase. This is a flaw in the terminology of PMBOK and the project management literature. However, it is inescapable because of the complex many-to-many nature of relationship between a product and project. Overlap of phases happens in schedule compression: fast tracking and crashing. Project phases can be related to (a) major divisions of the project deliverables or to the (b) methodology used to perform the work or a combination. Examples from software development: a) Example 1 Version 1, Version 2 of the software. Example2: A web site that will integrate data from backend systems A, B, C. Will require 3 efforts to provide linkages (API for retrieval) from the 3 backend systems to the frontend system. Plus the frontend system with some business rules. With limited personnel you will have to do each effort in sequence. b) Design, Implementation, Testing, Deployment. The methodology leads to SDLC (predictive methodology) and agile (adaptive methodlogy).
  • This can be described as the plan do check act cycle. Each phase of a multi-phase project can correspond to a product life cycle phase. Or the entire one phase project can correspond to the most of a product life cycle. Exit/Kill Points: The end of each phase the exit criteria are evaluated to see whether the phase was successful. The end of each phase the project charter and business case re-examined to decide on project continuation or not.
  • Projects produce products, services, or results.
  • The time, cost, and scope may be constraints imposed on the project and the PM has to manage within these constraints. However, the PM must verify these constraints against reality. The PM will (during initiation and early planning) create preliminary cost, time estimates based on the understood scope and come up with a likely cost and time budget. This will verify the likelihood of success within the given constraints. If the constraints cannot be met, the PM can show why they cannot be met. It is the professional responsibility of the PM to refuse such a project.
  • The triple constraint is typically the Cost/Time/Scope dimensions. However, risk, quality, and customer satisfaction affect success directly. For example, the project can be on time, on budget, and within scope, and still be a failure. Why? The customer did not get what he had in mind. The problem was that the PM did not manage stakeholder expectations correctly, and did not therefore capture the proper requirements.
  • A goal of getting rich by age 30 is specific, measurable, assignable, time framed, but not all too realistic. It could happen. The goal of saving $40,000 by age 30 fulfills SMART. The goal of setting up shop with my two programmer buddies to build a mobile app for Android 3.1 tablets to make $1,000 by the end of next year? SMART objectives apply to project business cases and to milestones and deliverables within a project.
  • Expert opinion and environmental factor and process assets are all similar in that the latter are also expert opinions and best practices codified in text. Other inputs and outputs are the various documents that are generated or updated by processes and later used by other processes.
  • WBS, Activities, network diagrams, estimates, benchmarks, reports, risks, …
  • Now we fly through the project management processes as we create a mental mind view of the process.
  • Management plans are forward looking documents that describe how the project management team and the PM will identify, describe, plan, control, and verify the target knowledge area.
  • The process involvement and interactions above are approximates. Initiating a project should mostly be done at the beginning, but in some circumstances continues through planning. If the project loses its focus, or business needs a re-visit to the project initiation maybe warranted, with the likely outcome of terminating the project and perhaps starting a new one. Planning happens mostly at the beginning. However, planning can extend through out the project as new knowledge is added to the project, re-planning or planning the next phase of the project goes underway while executing the prior phases of the project. Executing the project requires the most interactions between project management processes.. Monitoring and controlling happen through out the project but most intensity is during execution. Closing happens during execution and to the end of the project because of the need to close procurements (staff and resources and sub-projects) that were identified in the planning portion.
  • Since this is a very high level introduction, this presentation will describe some processes in some knowledge areas. The emphasis is not about mechanics of the PMI processes but the concepts behind them.
  • Management plans answer the following questions about project: How, when, how long, how much, who, for whom, which quality? Characteristics of a sound project plan: Comprehensiveness. Uniqueness. Unambiguousness. Authoritativeness. Keeping current (revisited and updated).
  • Business case includes contracts, agreements, Statements of Work, Proposals, requirement documents, business and marketing documents. Company culture, laws, business environments, industry standards, and existing project management and other systems. Must collect processes, procedures and historical information. Constraints are business/management related and not technical. Stakeholder analysis uses many tools like: Register: name, title, position, internal/external, requirements, power, influence, attitude, … Power/interest power/influence influence/impact grids.
  • Project may deliver product deliverables and project deliverable. The latter are artefacts of the project such as the various management documents, internal reports, emails, process improvements, etc. This depends on whether the project is for an internal or external customer and what is in the contract. Project deliverables can include documents such as deployment plans, testing plans, working prototypes, maintenance procedures, helpdesk manuals. The sponsor signs off the charter, however, it may be necessary to obtain other stakeholders’ signatures on the charter to make it more valid. Project approval requirements is the criteria for how to judge the success of the project. Who does that and when? The template for a project charter differs from one organization to another. Depending on the template used, differing information will be needed and therefore different levels of initial planning may be needed.
  • A quick planning iteration is done during project initiation, Collecting requirements could be a lengthy process that can be spun into a separate project phase. It could take months to finish. Use meetings, focus groups, interviews, questionnaires, survey. SoWs, contracts, etc are also used to define the requirements. Determine what to purchase and determine team are really about what will be out-sourced and therefore will require to be included in a procurement management plan. Since these things are outsourced the WBS will not include details levels for them: just a summary item. Of course, this affects schedules, resource estimates, risk, communications. So any changes in these areas will affect the planning for procurement. Hence, planning is an extremely iterative process. Project scope statement: provides a common understanding of what the project deliverables are the work needed to do them. What we will do in the project! A description of each product/result/deliverable. A list of deliverables and their acceptance criteria. What is not in the project scope. Exclusions. Risks Constraints. assumptions. Alternative ways for accomplishing the work.
  • Quality related work has an effect on the work executed to deliver the results of the project. This quality related work requires time and money and resources. And any adjustments to the quality plan affects the schedule, budget, and risk plans, and other plans. Risk management may require adjustment of the WBS, what is out-sourced or not, what insurance is bought, how risks are handled may change what is spent, or the schedule.
  • This is about the triple constraints. Control is done against these baselines. The baselines are formally approved and authorized. The baselines along with the rest of the project documents (plans, emails, etc), and products, results of the project are managed with the configuration management system.
  • A WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables, with each descending level of the WBS representing an increasing detailed definition of the project work. The WBS organizes the total scope of the project, and represents the work specified in the current approved project scope statement. Note: total PROJECT SCOPE work. This is more than the product scope. Project scope include project management work including quality, risk, etc. management and their products. Each level of the WBS contains 100% of the project work. Each descending level defines the work in more details.
  • Work package is similar to a story in agile methods. 40-80 work hours. One or small team of resources. May be out-sourced. Activities can be work packages and vice versa. Estimation methods.
  • Deliverables of this project are: Lecture Project Management Initiation Planning Execution Monitoring & Control Closing Experience Verification Sheet Presentation Notes Slides Quiz Survey Examples
  • Create the network diagram from work packages (or activities but it could become very complex). The work packages are linked with various relationships with other work packages such as: Finish to Start (FS common): A ends before B starts. Finish to Finish (FF): A and B finish together. Start to Start (SS): A and B start together. Start to Finish (SF): A starts before B can finish. Example: a line of volunteers passing a bucket of water from left to right. Lags, leads. Estimate time (ideal time), resources (ideal), and costs (ideal). You can create the critical path now, but it makes not sense now. Impose reality on the network diagram to obtain a schedule. This reality includes: work week definition, work hours, load ratio for each resource used, vacations, and holidays. Then, we do resource levelling. Crashing and Fast Tracking. Activity shifting : Move start/end dates forward or backward Activity splitting : Break an activity into two or more pieces Activity stretching : Use less of a given resource continuously Resource substitution : Assign a different resource Allocating overtim e: Work resources longer Day labor : daily allocating of resources Out-sourcing : assign to external resources Technology : Different technology or machinery Skills : Different level of skills The example above: D must wait for 10 (days?) after B is finished. Why? The reasons should be documented in the WBS dictionary entry for the work package/activity.
  • Maximize Known Unknowns. Minimize Unknown Unknowns. Start identifying risks at initiating time and continue the process through out the project. Risk checklist, experts, industry norms, etc. Maintain a risk register and watch list. Risk register contains risk information such as: probability, impact, root causes, potential responses, risk categories, plans for handling the risk. Prioritized risks. Watch List. For risks that are considered low probability and low impact, or accepted risks.
  • Contingency plans. Plan for handling each risk should it happen. Fallback plan. AKA plan b for each risk. Residual risks. Plans for handling risks that remain after risk response planning, and accepted risks. Risk owners. Who is responsible for tracking the risk.
  • Quality Assurance is auditing the quality requirements and the results of the quality control measurements. Who watches the watchers? Quality Control are the watchers activities to make sure all things are being to done according to plans to up to the quality requirements. Quality Assurance makes sure QC activities make sense and that the plan still is relevant and suggests changes to various processes. Quality audit is a tool of QA: an independent review of the Quality Management activities.
  • QC takes work measurement information from the executing process groups and analyses it against Quality standards. work that does not pass is cause for change requests, defect reports, rework, Risk audit is a review of current known risks, probabilities, impacts, and the associated responses for validity, and to identify to analyse newly discovered risks. Risk plans spring into action by their owners because they are authorised to do so by the project. Of course the PM will need to address the impact of the occurrence and adjust the plans accordingly. Performance reports takes performance measurements from the other M&C processes/and manage execution and analyses them to produces reports on schedule, budget, and scope. And shows forecasts.
  • Inspection, sampling, run charts and control charts. For software, you can keep score of the number and severity of defects, regressions, unit test failures, etc.
  • Direct Project execution, QC, scope, cost, schedule control, etc. produce change requests. Corrective actions, preventive actions, defect repairs.
  • The vendors for procurements may be viewed as sub-contracts or sub-projects from their point of view and this project can be the customer to these vendors. Completing procurements can happen through out the project and not just the very end of the project or phase. Updating lessons learned also happens through out the project. Releasing resources and acquiring resources whether they be human resources, equipment, or other items, occur through out the project as required. These resources are also released when they are not needed any more.
  • Brief Introduction to Project Management

    1. 1. A Brief Introduction to Project Management Project Management Body of Knowledge - 4 th Editition Project Management Institute
    2. 2. Table of Contents <ul><li>Preamble </li></ul><ul><li>Overview </li></ul><ul><li>How to manage a project? </li></ul><ul><li>Further Reading </li></ul><ul><li>Quiz </li></ul><ul><li>Survey </li></ul>
    3. 3. A Brief Introduction to Project Management Preamble
    4. 4. Preamble <ul><li>Scope & Target Audience </li></ul><ul><li>Prerequisites </li></ul><ul><li>Expected Outcomes </li></ul><ul><li>Measures of Success </li></ul>
    5. 5. Scope & Target Audience <ul><li>Brief introduction to project management using PMI PMBOK 4th Edition. </li></ul><ul><li>The 30,000 ft overview of project management. </li></ul><ul><li>Specific references to IT projects are used. </li></ul><ul><li>Individuals with some interest in gaining knowledge about project management. </li></ul>
    6. 6. Prerequisites <ul><li>No formal project management experience. </li></ul><ul><li>Some exposure to formal documentation, procedures and processes. </li></ul><ul><li>Have worked on projects before without a formal methodology explicitly declared. </li></ul>
    7. 7. Expected Outcomes <ul><li>This lecture is not sufficient training to become a project manager or to get certified. </li></ul><ul><li>Insight into the discipline of project management according to PMI. </li></ul><ul><li>Basic understanding of terminology of project management. </li></ul>
    8. 8. Measures of success <ul><li>Answering the quiz at the end of the lecture with no errors. </li></ul><ul><li>Receiving satisfactory responses from the audience questionnaire. </li></ul>
    9. 9. A Brief Introduction to Project Management Overview
    10. 10. What is a project? <ul><li>A Project is a temporary endeavour undertaken to create a unique product, service, or result. </li></ul><ul><ul><li>A beginning and an end. </li></ul></ul><ul><ul><li>Produces unique outcomes. </li></ul></ul><ul><ul><li>Progressively elaborated. </li></ul></ul><ul><ul><li>Requires resources to be allocated and expended. </li></ul></ul><ul><li>Operations work is possibly temporary and unique but do not qualify as projects. </li></ul>
    11. 11. What is a project? Really! <ul><li>Not all unique/temporary work should be treated as a project. </li></ul><ul><li>Nothing is said about the size of the project, or the industry of the project. </li></ul><ul><li>The project maybe temporary, but the outcomes may last for centuries. </li></ul><ul><li>The outcomes can be used by other projects, or they can the end items themselves. </li></ul>
    12. 12. Why do we have projects? <ul><li>Market demand. </li></ul><ul><li>Organizational need. </li></ul><ul><li>Customer request. </li></ul><ul><li>Technological advance. </li></ul><ul><li>Legal requirement. </li></ul><ul><li>Ecological impact. </li></ul><ul><li>Social need. </li></ul>
    13. 13. Project starting points! <ul><li>Technical requirement documents. </li></ul><ul><li>Marketing analysis documents. </li></ul><ul><li>Business case documents. </li></ul><ul><li>Statements of Work. </li></ul><ul><li>Request for Proposals. </li></ul><ul><li>Formal signed contracts. </li></ul><ul><li>External projects: </li></ul><ul><ul><li>Buyers and sellers of projects have different views of the same project. </li></ul></ul>
    14. 14. Examples of IT Projects <ul><li>Replace all desktop computers on the 5th floor with new computers. </li></ul><ul><li>Provide wireless access points for all of the campus. </li></ul><ul><li>Design and implement v2 of application X. </li></ul><ul><li>Implement a web presence strategy for company Y. </li></ul>
    15. 15. What is Project Management? <ul><li>Project Management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. </li></ul><ul><li>Project management is not necessarily applicable to all industries and all projects. </li></ul>
    16. 16. What is a Project Manager? <ul><li>The project manager is the person (or team) assigned the responsibility of achieving the project objectives. </li></ul><ul><li>PM requires industry knowledge. </li></ul><ul><li>PM uses general management skills and tools adapted for use in project management. </li></ul>
    17. 17. Project Manager job description? <ul><li>“ Plans , schedules, and controls activities to fulfill objectives applying technical, theoretical, and managerial skills to satisfy project requirements. Coordinates and integrates team and individual efforts and builds positive professional relationships with clients and associates.” </li></ul><ul><li>From Introduction to Project Management, Kathy Schwalbe </li></ul>
    18. 18. Project Life Cycle <ul><li>Generally a project goes through the following life cycle: </li></ul><ul><ul><li>Starting. </li></ul></ul><ul><ul><li>Organizing and Preparing. </li></ul></ul><ul><ul><li>Carrying out the work. </li></ul></ul><ul><ul><li>Finishing the work. </li></ul></ul><ul><li>Maps to 5 PMBOK process groups: </li></ul><ul><ul><li>Initiating, Planning, Executing, Monitoring & Controlling, and Closing. </li></ul></ul>
    19. 19. Project Management Process Group Interactions Monitoring and Control Initiating Closing Planning Executing
    20. 20. Project Management Process Group Interactions Initiating Planning Executing Closing Monitoring and Controlling Process Group Interactions 1 2 3 4 5 6 7
    21. 21. Project Phases <ul><li>Divisions in a project where extra control is needed to effectively manage the completion of major deliverable. </li></ul><ul><li>Project phases are typically sequential but may overlap in certain cases. </li></ul>
    22. 22. Project Phases Single Phase Multi Phase Monitoring and Executing Initiating Closing Planning Executing
    23. 23. Software Development Methodologies <ul><li>Systems Development Life Cycle (SDLC). </li></ul><ul><ul><li>Example: Waterfall. </li></ul></ul><ul><ul><li>Typical Phases: </li></ul></ul><ul><ul><ul><li>Concept, Design, Implementation, Testing, Deployment. </li></ul></ul></ul><ul><li>Agile Software Development Life Cycle. </li></ul><ul><ul><li>SCRUMM. </li></ul></ul><ul><ul><li>Phases: </li></ul></ul><ul><ul><ul><li>Day, Iteration, Release, Product. </li></ul></ul></ul>
    24. 24. Stakeholders! <ul><li>A stakeholder is anyone or any organization that is positively or negatively impacted by the project. </li></ul><ul><li>The impact can be related to the products of the project, or to resource contention (money, tools, or people) that other projects or operations require. </li></ul><ul><li>The stakeholders can be the team members, the sponsors, other managers, other personnel at the organization, customers, vendors, environmental groups, government agencies, etc. </li></ul>
    25. 25. Measures of Success <ul><li>Meeting stakeholders expectations. </li></ul><ul><li>Achieving the stated goals of the project. </li></ul><ul><ul><li>Time: Schedules and Milestones. </li></ul></ul><ul><ul><li>Cost: Budget forecast. </li></ul></ul><ul><ul><li>Scope: What is to be delivered. </li></ul></ul><ul><ul><li>Quality: How will quality of work be measured. </li></ul></ul><ul><li>Other factors: </li></ul><ul><ul><li>Resource contention. </li></ul></ul><ul><ul><li>Risks: how to handle the unknown. </li></ul></ul>
    26. 26. Triple Constraints Success Cost Time Scope
    27. 27. Triple Constraints? Customer Satisfaction Cost Time Scope Risk Quality Resource
    28. 28. SMART Objectives <ul><li>Specific </li></ul><ul><li>Measureable </li></ul><ul><li>Assignable </li></ul><ul><li>Realistic </li></ul><ul><li>Time-framed </li></ul>
    29. 29. Inputs and Outputs <ul><li>PMBOK processes use inputs and outputs. </li></ul><ul><li>Processes involved in project management often utilise the following inputs: </li></ul><ul><ul><li>Enterprise environmental factors. </li></ul></ul><ul><ul><li>Organizational process assets. </li></ul></ul><ul><ul><li>Expert opinion. </li></ul></ul><ul><li>Lessons learned documented by the PM about what went wrong or right and any process improvements are added to the organizational process assets is an output for several processes. </li></ul>
    30. 30. Environmental Factors <ul><li>Company culture and processes. </li></ul><ul><li>Government, industry laws and standards. </li></ul><ul><li>Infrastructure. </li></ul><ul><li>Existing human resources. </li></ul><ul><li>HR policies and procedures. </li></ul><ul><li>Company work authorisation system. </li></ul><ul><li>Stakeholder risk tolerances. </li></ul><ul><li>Commercial databases. </li></ul><ul><li>Established communication channels. </li></ul><ul><li>Project management information system. </li></ul>
    31. 31. Organisational Process Assets <ul><li>Templates for various documents. </li></ul><ul><li>Financial controls procedures. </li></ul><ul><li>Issue and defect management procedures. </li></ul><ul><li>Change control procedures. </li></ul><ul><li>Risk control procedures. </li></ul><ul><li>Historical project information. E.g., lessons learned, project files, issue and defect records. </li></ul>
    32. 32. A Brief Introduction to Project Management How to Manage a Project?
    33. 33. Project Management Knowledge Areas <ul><li>Project Integration Management </li></ul><ul><li>Project Scope Management </li></ul><ul><li>Project Time Management </li></ul><ul><li>Project Cost Management </li></ul><ul><li>Project Quality Management </li></ul><ul><li>Project Human Resources Management </li></ul><ul><li>Project Communication Management </li></ul><ul><li>Project Risk Management </li></ul><ul><li>Project Procurement Management </li></ul>
    34. 34. PMBOK Process Mapping <ul><li>Control Costs </li></ul><ul><li>Estimate Costs </li></ul><ul><li>Determine Budget </li></ul>Cost <ul><li>Control Schedule </li></ul><ul><li>Define Activities </li></ul><ul><li>Sequence Activities </li></ul><ul><li>Estimate Activity Resources </li></ul><ul><li>Estimate Activity Durations </li></ul><ul><li>Develop Schedule </li></ul>Time <ul><li>Verify Scope </li></ul><ul><li>Control Scope </li></ul><ul><li>Collect Requirements </li></ul><ul><li>Define Scope </li></ul><ul><li>Create WBS </li></ul>Scope <ul><li>Close Project or Phase </li></ul><ul><li>Monitor and Control Project Work </li></ul><ul><li>Perform Integrated Change Management </li></ul><ul><li>Direct and Manage Project Execution </li></ul><ul><li>Develop Project Management Plan </li></ul><ul><li>Develop Project Charter </li></ul>Integration Closing Monitoring & Controlling Executing Planning Initiating
    35. 35. PMBOK Process Mapping <ul><li>Report Performance </li></ul><ul><li>Distribute Information </li></ul><ul><li>Manage Stakeholder Expectations </li></ul><ul><li>Plan Communications </li></ul><ul><li>Identify Stakeholders </li></ul>Communications <ul><li>Acquire Project Team </li></ul><ul><li>Develop Project Team </li></ul><ul><li>Manage Project Team </li></ul><ul><li>Develop Human Resource Plan </li></ul>Human Resources <ul><li>Perform Quality Control </li></ul><ul><li>Perform Quality Assurance </li></ul><ul><li>Plan Quality </li></ul>Quality Closing Monitoring & Controlling Executing Planning Initiating
    36. 36. PMBOK Process Mapping <ul><li>Close Procurements </li></ul><ul><li>Administer Procurements </li></ul><ul><li>Conduct Procurements </li></ul><ul><li>Plan Procurements </li></ul>Procurement <ul><li>Monitor and Control Risks </li></ul><ul><li>Plan Risk Management </li></ul><ul><li>Identify Risks </li></ul><ul><li>Perform Qualitative Risk Analysis </li></ul><ul><li>Perform Quantitative Risk Analysis </li></ul><ul><li>Plan Risk Responses </li></ul>Risk Closing Monitoring & Controlling Executing Planning Initiating
    37. 37. Managing a Project <ul><li>The PM orchestrates the initiation, planning, execution, monitoring, and closing activities of the project with inputs from all the stakeholders. </li></ul><ul><li>The PM’s main concentration is on communication and integration of the various pieces of the project as planned and executed by the team. </li></ul><ul><li>PM prepares management plans for all Project Management knowledge areas. </li></ul>
    38. 38. Managing a Project Time Level Of Process Interaction Initiating Planning Executing Monitoring and Controlling Closing
    39. 39. Project Management Plans <ul><li>Each of the 9 knowledge area has one or more corresponding management plans. </li></ul><ul><li>The amount of rigor and details in each plan, and the project management processes used in a project depend on the project. </li></ul><ul><li>A management plan shows how you define, manage, and control the project in the knowledge area. </li></ul><ul><li>42 processes distributed over the knowledge areas and process groups. </li></ul>
    40. 40. Project Management Plans <ul><li>Project Management Plan, plus subsidiary plans: </li></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Schedule </li></ul></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Human Resources </li></ul></ul><ul><ul><li>Communications </li></ul></ul><ul><ul><li>Risk </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Change Management </li></ul></ul><ul><ul><li>Configuration Management </li></ul></ul><ul><ul><li>Requirement Management </li></ul></ul><ul><ul><li>Process Improvement </li></ul></ul>
    41. 41. Initiating a Project <ul><li>Understand the business case. </li></ul><ul><li>Identify stakeholders. </li></ul><ul><li>Develop stakeholder management strategy. </li></ul><ul><li>Uncover initial requirements, constraints, assumptions, and risks. </li></ul><ul><li>Divide large projects into phases. </li></ul><ul><li>Create measurable objectives. </li></ul>
    42. 42. Initiating a Project <ul><li>Develop a project charter which is a document signed by the sponsor. </li></ul><ul><ul><li>The project charter authorises the project and thus the sponsor must have the authority to initiate the project and assign the PM. </li></ul></ul><ul><ul><li>Defines the authority of the project manager. </li></ul></ul><ul><li>The sponsor provides direction and funding. </li></ul>
    43. 43. A Project Charter <ul><li>Title and description of the project. </li></ul><ul><li>Project Manager’s name and authority. </li></ul><ul><li>Business case. </li></ul><ul><li>Product descriptions / deliverables. </li></ul><ul><li>Measurable objectives including: </li></ul><ul><ul><li>Summary budget and milestones. </li></ul></ul><ul><ul><li>Planned Start date and estimated finish date. </li></ul></ul><ul><li>Critical assumptions, constraints, and risks. </li></ul><ul><li>Stakeholders Roles and Responsibilities. </li></ul><ul><li>Stakeholders Requirements as Known. </li></ul><ul><li>Project Approval Requirements </li></ul><ul><li>Sponsor’s name and signature. </li></ul><ul><li>Attachments. </li></ul>
    44. 44. Planning a Project <ul><li>Determine which project management processes to use. </li></ul><ul><li>Determine the level of details used with each knowledge area. </li></ul><ul><li>Create initial management plans for all areas. </li></ul>
    45. 45. Planning a Project <ul><li>Collect and Finalize Requirements. </li></ul><ul><li>Create project scope statement. </li></ul><ul><li>Determine what to purchase. </li></ul><ul><li>Create WBS and WBS Dictionary. </li></ul><ul><li>Estimate resources and time, and other activity attributes. </li></ul><ul><li>Create Network Diagram from activities. </li></ul><ul><li>Develop schedule: Time Management Plan. </li></ul><ul><li>Develop budget: Cost Management Plan. </li></ul>
    46. 46. Planning a Project <ul><li>Determine Quality standards and processes and produce the Quality Management Plan. </li></ul><ul><li>Determine roles and responsibilities for stakeholders, and produce the Communication Management Plan. </li></ul><ul><li>Perform qualitative and quantitative risk identification, and produce the Risk Management Plan. </li></ul>
    47. 47. Planning a Project <ul><li>Prepare Procurement management Plan. </li></ul><ul><li>Finalize all management plans. </li></ul><ul><li>Kickoff meeting. </li></ul>
    48. 48. Planning a Project: Baselines <ul><li>Scope baseline </li></ul><ul><ul><li>Project scope statement, WBS, WBS dictionary. </li></ul></ul><ul><li>Schedule baseline </li></ul><ul><ul><li>A specific version of the project schedule as approved by the project management team. </li></ul></ul><ul><li>Cost baseline </li></ul><ul><ul><li>Authorised time-phased budget at completion. </li></ul></ul><ul><ul><li>For use with Earned Value Management (EVM). </li></ul></ul>
    49. 49. Planning a Project: WBS <ul><li>“A WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables, with each descending level of the WBS representing an increasing detailed definition of the project work.” </li></ul><ul><li>Create WBS and WBS Dictionary down to the work package level. </li></ul><ul><ul><li>Prepare or Update Scope Management Plan. </li></ul></ul>
    50. 50. Planning a Project: WBS <ul><li>A Work package is the lowest level in the WBS. </li></ul><ul><li>A work package is a small collection of activities that is easy to estimate time and resources accurately. </li></ul><ul><li>Activities are individual tasks that need to be done. </li></ul><ul><li>Activities are scheduled and have resource and time dependencies. </li></ul>
    51. 51. Planning a project: WBS Example Project Gizmo 1.1 Web Gizmo 1.2 Mobile Gizmo 1.1.1 Requirements 1.1.2 Design 1.1.3 Implementation 1.1.4 Testing 1.1.5 Deployment Front End Middleware Server Side User Model Forms Reports
    52. 52. WBS: Example 2 <ul><li>Lecture </li></ul><ul><ul><li>1.1 Project Management </li></ul></ul><ul><ul><ul><li>1.1.1 Initiation </li></ul></ul></ul><ul><ul><ul><li>1.1.2 Planning </li></ul></ul></ul><ul><ul><ul><li>1.1.3 Execution </li></ul></ul></ul><ul><ul><ul><li>1.1.4 Monitoring & Control </li></ul></ul></ul><ul><ul><ul><li>1.1.5 Closing </li></ul></ul></ul><ul><ul><ul><ul><li> Experience Verification Sheet </li></ul></ul></ul></ul><ul><ul><li>1.2 Presentation </li></ul></ul><ul><ul><ul><li>1.2.1 Notes </li></ul></ul></ul><ul><ul><ul><li>1.2.2 Slides </li></ul></ul></ul><ul><ul><ul><li>1.2.3 Quiz </li></ul></ul></ul><ul><ul><ul><li>1.2.4 Survey </li></ul></ul></ul><ul><ul><ul><li>1.2.5 Examples </li></ul></ul></ul><ul><ul><ul><li>Project Management Plan Template </li></ul></ul></ul>
    53. 53. Planning a Project: WBS <ul><li>WBS can be in tabular format. </li></ul><ul><li>WBS does not specify: sequence of work, priorities, timing, time required, ownership, etc. </li></ul><ul><li>WBS requires the 100% rule. </li></ul><ul><li>WBS dictionary contains descriptive sheets for each node in the WBS down to the work package. </li></ul><ul><li>Work package include attributes like: dependencies, resources, costs, associated deliveries and milestones, assumptions, due date, control account, etc. </li></ul>
    54. 54. Planning a Project: Network Diagram <ul><li>Work package/activity dependencies. </li></ul><ul><li>Ideal time and resource estimates. </li></ul><ul><li>Impose reality constraints to get a schedule. </li></ul>A Start B C D E End F FS+10 FF
    55. 55. Planning a Project: Schedule
    56. 56. Planning a Project: Budget <ul><li>Once a preliminary schedule is prepared, the time-phased budget can be created. </li></ul><ul><li>Time-phased budget is a table (and associated graph) show the expenses on daily, monthly, phase, quarterly, etc. The same table will show expected funding. </li></ul><ul><li>Funding will happen at specific times as per organizational policies or external contract. </li></ul><ul><li>The schedule will be modified using resource levelling, activity manipulation, etc to make sure burn-rate is within the funding limits. </li></ul>
    57. 57. Planning a Project: Budget S-Curve <ul><li>Adjust schedule, estimates, risks to make sure expenses can be handled within the funding schedule. </li></ul>Time Cumulative Values Expenditures Baseline Funding Requirements
    58. 58. Planning a Project: Risks <ul><li>What is a risk? </li></ul><ul><ul><li>Risks are possible future threats or opportunities that impact at least one project objective. (Cost, schedule, scope, quality). </li></ul></ul>
    59. 59. Planning a Project: Risk Planning <ul><li>Identify Risks. </li></ul><ul><li>Perform Qualitative Risk Analysis. </li></ul><ul><ul><li>Subjective impact and probability scores, stakeholder risk tolerances, and urgency. </li></ul></ul><ul><li>Perform Quantitative Risk Analysis. </li></ul><ul><ul><li>Determine the sensitivity of the baselines to various risks scenarios (simulations). </li></ul></ul><ul><ul><li>Assign monetary values to risks and risk responses (reserves). </li></ul></ul>
    60. 60. Planning a Project: Risk Planning <ul><li>Plan Risk Responses. </li></ul><ul><ul><li>Threats </li></ul></ul><ul><ul><ul><li>Accept (do nothing) </li></ul></ul></ul><ul><ul><ul><li>Avoid (eliminate the threat) </li></ul></ul></ul><ul><ul><ul><li>Mitigate (reduce probability and/or impact) </li></ul></ul></ul><ul><ul><ul><li>Transfer (buy insurance, or out-source, etc). </li></ul></ul></ul><ul><ul><li>Opportunities </li></ul></ul><ul><ul><ul><li>Accept (do nothing) </li></ul></ul></ul><ul><ul><ul><li>Exploit (use the opportunity) </li></ul></ul></ul><ul><ul><ul><li>Enhance (increase probability and/or impact) </li></ul></ul></ul><ul><ul><ul><li>Share (Strategic alliances, ventures, etc). </li></ul></ul></ul>
    61. 61. Executing a Project <ul><li>Carry out activities as per schedule. </li></ul><ul><li>Use work authorisation system. </li></ul><ul><li>Follow processes. </li></ul><ul><li>Change Requests. </li></ul><ul><li>Conduct procurements. </li></ul><ul><li>Quality assurance and Quality audits. </li></ul><ul><li>Process improvements. </li></ul>
    62. 62. Executing a Project <ul><li>Acquire and develop team. </li></ul><ul><li>Manage and evaluate team. </li></ul><ul><li>Send and receive information. </li></ul><ul><li>Hold meetings. </li></ul><ul><li>Ensure common understanding. </li></ul>
    63. 63. Monitoring and Controlling <ul><li>The process of tracking, reviewing, and regulating the progress to meet performance objectives. </li></ul><ul><li>Perform Quality Control. </li></ul><ul><li>Perform Integrated Change Control. </li></ul><ul><li>Gain acceptance of interim deliveries from customer. </li></ul><ul><li>Perform Risk Audit. </li></ul><ul><li>Report on project performance. </li></ul><ul><li>Administer Procurements. </li></ul>
    64. 64. Quality Control <ul><li>Measure performance against performance metrics (time, cost, etc). </li></ul><ul><li>Determine variances. </li></ul><ul><li>Create forecasts. </li></ul><ul><li>Determine the need for change requests. </li></ul><ul><li>Request changes. </li></ul>
    65. 65. Perform Integrated Change Control <ul><li>Approve or reject change requests. </li></ul><ul><ul><li>Change Control Board and related procedures. </li></ul></ul><ul><li>Inform stakeholders of approved (and rejected) requests. </li></ul><ul><ul><li>Approved changes will necessitate updating all relevant management plans and approving new baselines. </li></ul></ul><ul><li>Manage configuration. </li></ul><ul><ul><li>Project documents and management plans versioning, distribution, and control. </li></ul></ul>
    66. 66. Closing a Project or Phase <ul><li>Verify completion of all final project deliverables. </li></ul><ul><li>Gain formal acceptance from customer. </li></ul><ul><li>Hand off to customer. </li></ul><ul><li>Finalize project documents and enter them into the PMIS. </li></ul><ul><li>Update the lessons learned. </li></ul><ul><li>Release resources. </li></ul><ul><li>Complete procurements. Make sure all contractual obligations are fulfilled and all monies paid. Obtain releases from vendors. </li></ul>
    67. 67. Conclusions <ul><li>Project management is a discipline that combines many general management tools, agreed upon project management processes, and industry specific knowledge. </li></ul><ul><li>Project management aims at increasing the likelihood of project success. However, it cannot help against bad use of these processes. </li></ul><ul><li>Highly iterative and interacting processes. </li></ul><ul><li>Knowing project management processes will help employees better interaction with their managers. </li></ul><ul><li>You gain project management experience even if you are not the project manager. </li></ul>
    68. 68. A Brief Introduction to Project Management Further Reading
    69. 69. Further Reading <ul><li>A Guide to the Project Management Body of Knowledge (PMBOK Guide), 4 th ed., PMI, 978-1-933890-51-7 </li></ul><ul><li>Information Technology Project Management 6e, Kathy Schwalbe, 978-0-324-78692-7 </li></ul><ul><li>PMP Exam Prep, 7 th ed., Rita Mulcahy, 978-1-932735-41-3 </li></ul><ul><li>PMI.ORG </li></ul><ul><li>Wikipedia </li></ul><ul><li> and similar sites. </li></ul>
    70. 70. A Brief Introduction to Project Management Quiz
    71. 71. Quiz <ul><li>1. Project process groups are: Initiating, Planning, Executing, Monitoring and Controlling, and Closing? </li></ul><ul><li> True  False </li></ul><ul><li>2. The nine project management knowledge areas include Configuration Management? </li></ul><ul><li> True  False </li></ul>
    72. 72. Quiz <ul><li>3. The constraints of a project include: Scope, Schedule, Budget, and Quality? </li></ul><ul><li> True  False </li></ul><ul><li>4. A Work Breakdown Structure (WBS) contains the entire scope of the project? </li></ul><ul><li> True  False </li></ul>
    73. 73. Quiz <ul><li>5. A project schedule is a representation of the project activities and their start and finish dates, their dependencies, and the established milestones? </li></ul><ul><li> True  False </li></ul><ul><li>6. Large projects are decomposed into manageable pieces called phases to address limitations of time, budget, and complexity, and to add a level of formal control on the progress of the project? </li></ul><ul><li> True  False </li></ul>
    74. 74. Quiz <ul><li>7. Controlling a project involves comparing the actual scope, schedule, and costs against the project baselines and determining whether actions are needed to keep the project on track? </li></ul><ul><li> True  False </li></ul><ul><li>8. Work packages are executed in the Direct and Manage Project Execution Process, validated by Perform Quality Control, and accepted by Verify Scope? </li></ul><ul><li> True  False </li></ul>
    75. 75. A Brief Introduction to Project Management Survey
    76. 76. Survey <ul><li>What is your overall assessment for the course? </li></ul><ul><li> Poor  Satisfactory  Good  Excellent </li></ul><ul><li>General organisation of the Course:? </li></ul><ul><li> Poor  Satisfactory  Good  Excellent </li></ul><ul><li>Duration and rhythm of the Course? </li></ul><ul><li> Poor  Satisfactory  Good  Excellent </li></ul><ul><li>How do you assess the Course content? </li></ul><ul><li> Poor  Satisfactory  Good  Excellent </li></ul><ul><li>If you had questions, were they answered? </li></ul><ul><li> Poor  Satisfactory  Good  Excellent </li></ul>