Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Project Management V1


Published on

  • Be the first to comment

Project Management V1

  1. 1. Project Management
  2. 2. Project Management  To provide an overview of Project Management  To review some of the various methods and knowledge bases available to Project Managers  Who am I?
  3. 3. Project Management Worldwide, infrastructure spending will grow from $4 trillion per year in 2012 to more than $9 trillion per year by 2025. Overall, close to $78 trillion is expected to be spent globally between 2014 and 2025. Source: PWC and Oxford economics Capital project and infrastructure spending: Outlook to 2025
  4. 4. Project Management  What is it?  Which Project Method?  Waterfall?  Agile?
  5. 5. Project Management  The 3P’s:  Project  Programme  Portfolio
  6. 6. What is a Project? A project is a temporary endeavour designed to produce a unique product, service or result with a defined beginning and end, undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. The temporary nature of projects stands in contrast with business as usual, which are repetitive, permanent, or semi-permanent functional activities to produce products or services.
  7. 7. What is a Programme? Programme management is the co- ordinated management of related projects, which may include business as usual activities that together achieve a beneficial change of a strategic nature for an organisation. Source: APM BOK
  8. 8. What is a Portfolio? Portfolio management is the selection and management of all an organisations projects, programmes and related business as usual activities taking into account resource constraints. A portfolio is a group of projects and programmes carried out under the sponsorship of an organisation. Portfolios can be managed at an organisational , programme or functional level. Source: APM BoK
  9. 9. Project Management Project Management is the process and activity of planning, organising, motivating, and controlling resources, procedures and protocols to achieve specific goals in scientific or daily problems.
  10. 10. Characteristics of a Project  Change  Temporary  Cross – functional  Unique  Uncertain
  11. 11. Project Management A project is usually deemed to be a success if it achieves the objectives according to their acceptance criteria, within an agreed timescale and budget.
  12. 12. Project Management  The core components of project management are:  defining the reason why a project is necessary;  capturing project requirements, specifying quality of the deliverables, estimating resources and timescales;  preparing a business case to justify the investment;  securing corporate agreement and funding;  developing and implementing a management plan for the project;  leading and motivating the project delivery team;  managing the risks, issues and changes on the project;
  13. 13. Project Management  monitoring progress against the plan;  managing the project budget;  maintaining communications with stakeholders and the project organisation;  provider management;  closing the project in a controlled fashion when appropriate.
  14. 14. Why Use a Metodology?  Better control of financial, physical, and human resources.  Improved customer relations.  Shorter development times.  Lower costs.  Higher quality and increased reliability.  Higher profit margins.  Improved productivity.  Better internal coordination.  Higher worker morale (less stress).
  15. 15. Project Management  Prince2  PMI – PMBOK  APM – Body of Knowledge  Praxis Framework  Agile  ISO 21500
  16. 16. Prince2 Prince2 addresses four integrated elements: The Principles The Themes The Processes Tailoring
  17. 17. Prince2 What’s excluded? Specialist Aspects Detailed Techniques Leadership Capability
  18. 18. Prince2 Benefits of Prince2? Proven best practice and governance Applicable to any type of project Widely recognised and understood Recognises project responsibility Clear project delivery Designed to meet varying needs Manages by exception
  19. 19. Prince2  Focus on viability vs Business case  Structured reporting  Ensures stakeholder involvement in planning and decision making  Promotes learning and continuous improvement  Consistent  Diagnostic tool
  20. 20. Prince2 – The Principles  Continued Business Justification  Learn from Experience  Defined Roles and Responsibilities  Manages by Stages  Manages by Exception  Focus on Products  Tailor to suit the Project Environment
  21. 21. Prince2 – The Themes  Business Case  Organisation  Quality  Plans  Risk  Change  Progress
  22. 22. Prince2 – The Processes  Start – up  Directing  Initiation  Controlling  Managing Product Delivery  Stage Boundaries  Closing
  23. 23. Prince2 - Tailoring  The appropriate use of Prince2 on any given project, ensuring that there is the correct amount of planning, control, governance and use of the processes and themes.  Done by the project team to adapt the methods to the specific project
  24. 24. Prince2 – Tailoring  Adapt the Themes  Apply the organisations terms and language  Revise the product descriptions  Revise the role descriptions  Adjust the processes to match the above
  25. 25. PMBoK  The Project Management Institute is a professional PM membership organisation that provide standards and qualifications for project professionals.  The PMBOK Guide contains the processes that project management experts agree are necessary for most projects in most environments. It reflects the evolving knowledge within the profession. Processes are presented by Process Group and Knowledge Area.  Processes overlap and interact throughout a project or its various phases.
  26. 26. PMBoK  Processes are described in terms of:  Inputs (documents, plans, designs, etc.)  Tools and Techniques (mechanisms applied to inputs)  Outputs (documents, plans, designs, etc.)  There are 47processes that fall into five basic process groups and ten knowledge areas.
  27. 27. PMBoK – Process Groups  Initiating : Those processes performed to define a new project or a new phase of an existing project by obtaining authorisation to start the project or phase.  Planning : Those processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve.  Executing : Those processes performed to complete the work defined in the project management plan to satisfy the project specifications
  28. 28. PMBoK – Process Groups  Monitoring and Controlling : Those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.  Closing : Those processes performed to finalise all activities across all Process Groups to formally close the project or phase.
  29. 29. PMBoK – Knowledge Areas  Project Integration Management includes the processes and activities needed to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups.  Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.
  30. 30. PMBoK – Knowledge Areas  Project Cost Management includes the processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling costs so that the project can be completed within the approved budget.  Project Time Management includes the processes required to manage the timely completion of the project.
  31. 31. PMBoK – Knowledge Areas  Project Quality Management includes the processes and activities of the performing organisation that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken.  Project Human Resource Management includes the processes that organise, manage, and lead the project team.
  32. 32. PMBoK – Knowledge Areas  Project Communications Management includes the processes that are required to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and the ultimate disposition of project information.  Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project.
  33. 33. PMBoK – Knowledge Areas  Project Procurement Management includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team  Project Stakeholder Management includes the processes required to identify all people or organisations impacted by the project, analysing stakeholder expectations and impact on the project, and developing appropriate management strategies for effectively engaging stakeholders in project decisions and execution
  34. 34. PMBOK Processes Map Initiating Planning Executing Monitoring & Controlling Closing Integration Develop Project Charter Develop Project Management Plan Direct and Manage Project Work Monitor and Control Project Work Perform Integrated Change Control Close Project or Phase Scope Plan Scope Management Collect Requirements Define Scope Create WBS Validate Scope Control Scope Cost Plan Cost Management Estimate Costs Determine Budget Control Costs Time Plan Schedule Management Define Activities Sequence Activities Estimate Activity Resources Estimate Activity Durations Develop Schedule Control Schedule Quality Plan Quality Management Perform Quality Assurance Control Quality Human Resources Plan Human Resource Management Acquire Project Team Develop Project Team Manage Project Team Communications Plan Communications Management Manage Communications Control Communications Risk Plan Risk Management Identify Risks Perform Qualitative Risk Analysis Perform Quantitative Risk Analysis Plan Risk Responses Control Risks Procurement Plan Procurement Management Conduct Procurements Control Procurements Close Procurements Stakeholder Identify Stakeholders Plan Stakeholder Management Manage Stakeholder Engagement Control Stakeholder Engagement
  35. 35. APM - BoK  The Association for Project Managers is a professional PM membership organisation that provide standards and qualifications for project professionals  Their objectives are “to advance the science, theory and practice of project and programme management for the public benefit.”  The APM BoK has 7 chapters, each broken down into its component parts and amounting to 52 topics in all.
  36. 36. APM - BoK  APM BoK is not a set of rules or practices, it’s aim is to convey knowledge on the discipline of managing projects rather than the processes.  The APM BoK is not in reality a method for project management, but provides a solid foundation of project knowledge.  Derived and published through APM - Praxis is a free framework for the management of projects, programmes and portfolios.
  37. 37. APM - BoK Project Management in Context Project Management Programme Management Portfolio Management Project Context Project Sponsorship Project Office Planning the Strategy Project success & benefits management Stakeholder Management Value Management Project Management Plan Project Risk Management Project Quality Management Health, Safety & Environmental Management Executing the Strategy Scope Management Scheduling Resource Management Budgeting & Cost Management Change Control Earned Value Management Information Management & Reporting Issue Management Techniques Requirements Management Development Estimating Technology Management Value Engineering Modelling & Testing Configuration Management Business & Commercial Business Case Marketing & Sales Project Financing & Funding Procurement Legal Awareness Organisation & Governance Project Life Cycles Concept Definition Implementation Handover & Closeout Project Reviews Organisation structure Organisational Roles Methods & Procedures Governance of Project Management People &the Profession Communication Teamwork Leadership Conflict Management Negotiation HRManagement Behavioural Characteristics Learning & Development Professionalism & Ethics
  38. 38. Praxis  Praxis is a free framework for the management of projects, programmes and portfolios. It includes a body of knowledge, methodology, competency framework and capability maturity model.  Praxis Framework provides a single, integrated framework for the management of projects, programmes and portfolios.  Praxis takes the principles of existing, proven guides and adapts them so that they have a common terminology, structure and approach. Source: Praxis Framework Limited
  39. 39. Praxis Overview  Contextual functions are not directly responsible for achieving project, programme or portfolio objectives but are part of the context which supports that endeavour.  Management functions are the ones that are applied in the completion of projects, programmes and portfolios.  The knowledge section integrates with all the other sections of Praxis.
  40. 40. Praxis Framework  The four core sections of the Praxis Framework are:  Knowledge  Method  Competence  Capability Maturity
  41. 41. Praxis Framework
  42. 42. Knowledge
  43. 43. Method
  44. 44. Competence
  45. 45. Maturity
  46. 46. Agile What is Agile Project Management? Agile project management is an iterative and incremental method of managing change, that provides a new product or service in a very flexible and interactive manner.
  47. 47. Agile Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management methodologies include scrum, extreme programming (XP), lean and kanban, among others.
  48. 48. Agile Iterative Model
  49. 49. General Agile Principles  The highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.  Deliver working products frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  50. 50. General Agile Principles  Business people and developers must work together daily throughout the project.  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  51. 51. General Agile Principles  A working product is the primary measure of progress.  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  Continuous attention to technical excellence and good design enhances agility.
  52. 52. General Agile Principles  Simplicity — the art of maximizing the amount of work not done — is essential.  The best architectures, requirements, and designs emerge from self-organizing teams.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. ©Agile Manifesto Copyright 2001
  53. 53. Agile Methodologies  SCRUM  A product owner creates a prioritised wish list called a product backlog.  During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.  The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
  54. 54. SCRUM  Along the way, the Scrum Master keeps the team focused on its goal.  At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.  The sprint ends with a sprint review and retrospective analysis.  As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. Source:
  55. 55. SCRUM
  56. 56. SCRUM Beyond the sprint the cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of these milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.
  57. 57. Extreme Programming(XP) Extreme programming is a software development methodology, which is intended to improve software quality and responsiveness to changing customer requirements. It advocates frequent releases in short development cycles, which are intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
  58. 58. Basic XP Values  Communication - the XP practices are designed to keep communication flowing within the development team and with stakeholders.  Simplicity - XP bets that doing the simplest thing that works today and paying tomorrow if a change is needed, is cheaper than doing a more complicated thing today that adds flexibility that may never be needed.  Feedback - concrete feedback based on production-quality, working code enables better communication.  Courage - the courage to make changes both supports and is supported by the other three values.  Respect; respect for other members and roles within the project team and respect for all interested parties.
  59. 59. 12 XP Principles The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:  Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required.  Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).  Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
  60. 60. 12 XP Principles Small Releases:  Start with the smallest useful feature set. Release early and often, adding a few features each time. System Metaphor:  Each project has an organising metaphor, which provides an easy to remember naming convention. Simple Design:  Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.
  61. 61. 12 XP Principles Continuous Testing:  Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Refactoring:  Refactor out any duplicate code generated in a coding session. Pair Programming:  All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
  62. 62. 12 XP Principles Collective Code Ownership:  No single person owns a module. Any developer is expected to be able to work on any part of the codebase at any time. Continuous Integration:  All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
  63. 63. 12 XP Principles 40-Hour Work Week:  Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process On-site Customer:  Development team has continuous access to a real live customer, that is, someone who will actually be using the system.
  64. 64. 12 XP Principles Coding Standards:  Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.
  65. 65. ISO 21500 ISO 21500 is the first in a planned family of project management standards. It is designed to align with related International Standards such as  ISO 10006:2003, Quality management systems − Guidelines for quality management in projects,  ISO 10007:2003, Quality management systems − Guidelines for configuration management,  ISO 31000:2009, Risk management – Principles and guidelines,  sector-specific standards in industries such as aerospace and IT.
  66. 66. Purpose  Provides a generic guidance on the concepts and processes of project management & referred to as “an informative standard”  Recognised as a foundational reference for the application of project management knowledge and good practices  One global standard for project management
  67. 67. ISO 21500 Content & Structure  Clause 1 Scope  Clause 2 Terms and definitions  Clause 3 Project management concepts  Clause 4 Project management processes  Annex A (Informative) process group: processes mapped to subject groups Source: ISO 21500, Guidance on project management, A Pocket Guide: Anton Zandhuis, Rommert Stellingwerf, (c) Van Haren Publishing 2013
  68. 68. ISO21500 Clause 1  Clause 1 covers the scope of ISO 21500, which is to provide guidance for project management and may be used by any type of organisation and for any type of project.  The guideline provides a high level description of concepts and process that are considered to form good practice in project management.
  69. 69. ISO 21500 Clause 2  Clause 2 contains 16 project management terms and their definitions, those specific terms that from a project management practice viewpoint are not properly defined in the standard lists of ISO or Oxford English Dictionary
  70. 70. ISO 21500 Clause 3  Clause 3 describes the concepts which play an important role during the execution of most projects:  Project;  Project management;  Organizational strategy and projects;  Project environment;  Project governance;  Projects and operations;
  71. 71. ISO 21500 Clause 3  Stakeholders and project organisation;  Competences of project personnel;  Project life cycle;  Project constraints;  Relationship between project management concepts and processes.
  72. 72. ISO 21500 Clause 4  Clause 4 identifies the recommended project management processes that should be applied, consisting of:  5 process groups  39 processes divided into 10 project management themes, called subject groups
  73. 73. ISO 21500 Clause 4  The 5 process groups are:-  Initiating  Planning  Implementing  Controlling  Closing
  74. 74. ISO 21500 Clause 4  These process groups are based on the Deming Circle (Plan-Do - Check – Act) for continuous improvement.
  75. 75. ISO 21500 Clause 4  There are 39 processes divided into 10 project management themes, called subject groups:  Integration  Stakeholders  Scope  Resource  Time  Cost  Risk  Quality  Procurement  Communication
  76. 76. Annex A SUBJECT GROUPS PROCESS GROUPS INITIATING PLANNING IMPLEMENTING CONTROLLING CLOSING TIME   Sequence activities Estimate activity  durations Develop schedule   Control schedule   COST   Estimate costs Develop budget   Control costs   RISK   Identify risks Assess risks Treat risks Control risks   QUALITY   Plan quality Perform quality  assurance Perform quality control   PROCUREMENT   Plan procurement Select suppliers Administer  procurements   COMMUNICATION   Plan communications Distribute information Manage  communications   INTEGRATION Develop project  charter Develop project plans Direct project work Control project work Control changes Close project phase or  project Collect lessons learned STAKEHOLDER Identify stakeholders   Manage stakeholders     SCOPE   Define scope Create work  breakdown structure Define activities   Control scope   RESOURCE Establish project team Estimate resources Define project  organisation Develop project team Control Resources Manage Project team  
  77. 77. Which Method?  Waterfall or Agile?  Waterfall methods – Importance on the process  Agile methods – Importance on the result  Can one Method fit all purposes?
  78. 78. Variations on a Theme?