1 / 36

Quick Recap

Quick Recap. Project Initiation overview. Awareness of the need for change (situation, context) and recognition by stakeholders that only a project can bring about the desired change Consideration of project options

pwesley
Download Presentation

Quick Recap

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Quick Recap

  2. Project Initiation overview • Awareness of the need for change (situation, context) and recognition by stakeholders that only a project can bring about the desired change • Consideration of project options • Collection of basic information to perform a preliminary project feasibility assessment and determine possible project costs and outcomes (positive and negative) • Preparation of a formal project proposal for consideration by the project sponsors • Undertake a detailed project feasibility study if required • Decide whether project should be pursued, put on-hold for a future time or rejected • Make contracts with key stakeholders, issue project charter and assign resources for the project • Move the project into the (detailed) planning phase

  3. Lesson 5: Initiating a Project Topic 2D: Create a Project Charter Topic 2E: Identify Project Stakeholders

  4. Project charter • According to the Project Management Institute, the Project Charter is the document that “formally authorises the project”. • The Project Charter provides the Project Manager and Project Team with the authority to use resources for the purpose of undertaking the project. • The Project Charter is usually short and is issued by the Project Sponsor or a senior official outside the level of the project organization. • Some Project Charters contain brief general information about the project; others may contain specific details

  5. Project charter • The project charter is a high level agreement between the project sponsor and the project team • Documents the scope, which may have been refined since the business case • Define project infrastructure • What resources, technology, methods, and PM processes will support the project?

  6. Project charter • Identify key personnel, facilities and tools • Summarize the project plan • Scope, schedule, budget, and quality objectives • Deliverables, major milestones • Define roles and responsibilities • Identify project sponsor, manager, key leads, and how they will communicate and make decisions

  7. Project charter • Express commitment to the project • Describe the resources committed to the project • Who will take ownership of the final product? • Define project control mechanisms • What processes will be followed for requesting, reviewing, and approving changes to project scope, cost, or schedule?

  8. Charter contents • A charter typically can contain: • Project identification, such as the name or acronym or logo by which it’s known • Critical for your team coffee mugs • Project stakeholders • Who are they? • What roles do they play? • Who reports to whom?

  9. Charter contents • Project description • Give a nice overview of the project, for someone who’s never heard of it • Might include the project’s vision or overall goals • Measurable organizational value • Yes, it’s important enough to get its own section • Project scope • Could be a formal SOW, or less formal narrative

  10. Charter contents • The project scope is less detailed than the project plan, but outlines the major features of the project, and what is not part of the project scope • Project schedule – at a high level, such as major phases and overall duration • Project budget – at least the totals • Quality issues, such as the standards to be followed, or other overall quality objectives

  11. Charter contents • Resources – who is providing people, technology, facilities, etc. to support the project • You don’t want an office in your daughter’s dorm room… • Assumptions and risks • Key people availability • Events that could change project scope, budget, or duration

  12. Charter contents • External constraints on the project, e.g. project interfaces to existing systems • Internal constraints, such as resource competition • Project impact on other parts of the organization • Environmental, political, economic, or other issues • Project administration • What plans will be developed to support this project? Scope mgmt, communications, quality mgmt, quality mgmt, change mgmt, HR, etc.

  13. Charter contents • Acceptance and approval • Who signs off? • References • Terminology • Particularly helpful if the project scope spans many technical specialties, who don’t know each others’ acronyms and phrases

  14. Project Stakeholders • Individuals who are actively involved in the project • Those whose interests may be affected by the project completion • Those who may have influence over the project or its results

  15. Key stakeholders include • Project Manager – the individual responsible for handling the project • Customer – the individual or organisation who will use the project’s product • Performing Organisation – the enterprise whose employee’s are most directly involved in doing the work of the project • Project Team Members - the group that is performing the work of the project • Project Sponsor- the individual or group that provides the resources for the project • Regulatory or government agencies • Sellers and contractors • Individual citizens or groups of citizens

  16. Project sponsor • The project sponsor is a critical role for the success of any project • It’s someone outside the development team who is not only paying for the project, but also acts as a champion to support the project and protect it from outside threats

  17. Project sponsor • The sponsor: • Empowers the project manager • Maintains project support (“buy-in”) from other key stakeholders • Clears political and organizational roadblocks • Ensures availability of resources • Monitors project status and progress

  18. Project sponsor • Approves plans, schedules, budgets, and deliverables • Keeps the project focused on the goal • Since the sponsor is outside the development team, the project manager doesn’t control them • Loss of a sponsor can kill a project

  19. Project constraints • Project constraints are anything that restricts or dictates the actions of the project team. That can cover a lot of territory. • The triple constraints—time, resources, and quality – are the big hitters, and every project has one or two, if not all three, of the triple constraints as a project driver. • Many projects in the Information Technology area, for instance, are driven by time.

  20. Project constraints • Scope - The deliverables that the project team must create and the activities required to create them. Scope also includes the quality of the work or deliverables that need to be created. • Cost - The budget or cost to deliver the project. • Schedule - The deadline by which the project must be delivered.

  21. Often represented by a triangle

  22. Trade off triangle • Other way of looking at it • Fast, cheap, good • Choose two • Know which of these are fixed or variable for every project • Time and cost deviations tend to be overruns whereas product or performance will be a shortfall

  23. Managing trade-off • Any process for managing time cost and performance trade-off should emphasis the systems approach • Recognise and understand the basis for project conflicts • Review the project objectives • Analyse the project environment and status • Identify the alternative courses of action • Analyse and select the best alternative • Revise the project plan

  24. Sample Constraints • Resource constraints • Delivery constraints • Environmental constraints • Budgetary constraints • Functionality constraints

  25. Resource constraints • Key staff resources will only be available part time • Computer resources will only be available on a limited basis • Limited access to client resources

  26. Delivery constraints • Cannot accurately specify delivery lead times • Approval of deliverables requires at least five working days for review

  27. Environmental CONSTRAINTS • Staff are unfamiliar with new development environment • Overtime ban restricts working time • Key decisions makers not on site and difficult to contact • Using an unfamiliar project management methodology • Project is dependent on other projects

  28. Budgetary constraints • Accuracy of schedule estimates is unreliable • Outside consultancy requirements cannot be accurately estimated

  29. Functionality CONSTRAINTS • Scope of project unclear • The project dependent on data form external applications

  30. Project Assumptions • An assumption is the act of taking something for granted or supposing. In a project sense, an assumption is something we establish as true for the purposes of allowing us to proceed with our project work, usually during the planning and estimating phase. Assumptions enable the project to move forward without absolutely certain information

  31. What happens when an Assumption is wrong? • In a general sense we can say that if an assumption turns out to be true, then the project benefits (or at least doesn’t suffer). If an assumption turns out to be false, then the project will suffer. • To minimise the potential impact of false assumptions it is the job of the project manager to monitor and review assumptions

  32. Resource assumptions • Project staff resources will be available when and as they are needed. • Required hardware resources will be available when and as they are needed. • Required customer resources will be available when and as they are needed. • A significant percentage of the project staff will be experienced with the technical environment. • A significant percentage of the project staff will be experienced with the operating environment. • Access to industry experts and specialized skills will occur as needed. • A "full-time" resource implies at least 35 hours productive work per week.

  33. Delivery assumptions • Deliverables will be subject to no more than a specific number of review cycles. • Equipment order lead times are known and can be expected to be met.

  34. Environmental assumptions • No industrial action will be taken that will affect the project. • Issues will be resolved in a timely manner. • The project organization described in the project plan will be put in place. • Systems components will be capable of being integrated with minimum rework.

  35. Budgetary assumptions • The statistics used in preparing the estimates are accurate within a given percent. • No outside consulting will be required or Outside consulting will be limited to a • specified number of days at a specified rate per day.

  36. Functionality assumptions • The scope of the project is limited to that described in the project charter. • Formal charter and scope change procedures will be followed

More Related