Intro to Classical PM - PM Triangle: Scope PDF

#### **Intro to Classical PM - PM Triangle: Scope** **Project Charter** A document that kick-starts a project. It describes: - - - - - - - Can be broken down with: - - - - - - - - - - - - - **Project Plan** - - - - **Charter vs Plan*...

#### **Intro to Classical PM - PM Triangle: Scope** **Project Charter** A document that kick-starts a project. It describes: - - - - - - - Can be broken down with: - - - - - - - - - - - - - **Project Plan** - - - - **Charter vs Plan** - - *What is a project?* - - - - - **Short PMI History (Project Management Institute) (unsure if we really need this)** - - - - Now 700k members from more than 200 countries. - - - - #### **Project Management Triangle: Scope, budget and time** The quality of a project is dictated by three factors: - - - This creates the project management triangle. It is up to the manager to achieve proper trades. You can have (Pick two): - - - Realistically, you don't get all 3. **Scope** The scope of a project is the set of all deliverables that the team will create. - May include: - - - - - **Deliverables** are products, services or outcomes created to fulfil **requirements.** **Requirements** describe the characteristics of the final deliverable. They describe the functionality or specific conditions the final deliverable must meet. **Types of Requirements:** - - - - - - Collecting requirement tech: - - - **Work Breakdown Structure (WBS)** A deliverable-oriented grouping of the work involved in a project and provides the basis for planning and managing schedules, costs, resources and changes. Is Hierarchical - - - - **Requirements Traceability Matrix (RTM)** A RTM is a table that maps the requirements to their deliverables. Helps ensure that reach requirement adds value. Facilitates tracking of requirements throughout the project's lifecycle. RTM Field includes: - - - - -  **Time Management** The **first 90% of the code** accounts for **the first 90% of development time** The **other 10% of the code** accounts for t**he other 90% of development time.** **Time** is a variable that has the least amount of flexibility. Many project have hard due dates: Christmas, Tax season, competition, contracts, etc. Poor management can lead to extra costs. After a scope has been determined, focus switches to the order in which activities are carried out. There are a number of tools that can help such as Gantt' Chart and PERT charts. They help determine the order, dependencies and how long a project will take. **Dependencies (or relationships)** dictate the logical sequencing of project activities. A clear understanding of depdenencies is required to build proper charts and diagrams. Example: "Wireframing [depends] on Requirement Gathering Front-end Development [depends] on Wireframing Back-end Development [depends] on server setup\* Testing and Deployment [depends] on CI" Three types of dependencies: - - - **Gantt Chart** List of project activities vs their start and finish dates. The critical path determines the earliest completion of a project. THe more activities are in this path, the harder it is to make a proper prediction. **Network Diagrams** Network diagrams can show dependency relationships. The Program Evaluation and Reivew Technique (PERT) is the most popular network diagram. **PERT** Each **milestone** is represented as a node. Tasks connecting milestones are shown as arrows. Following arrows allow one to follow dependencies. Each arrow has up to three timestamps: - - -  **Cost Management** **Cost** are resources sacrificed or foregone to achieve a specific objective. After estimating the cope and timeline, a **cost analysis** is required to start up a project. Cost come from multiple sources: - - - - - **Cost Estimation Techniques** - - - **Estimation problems** - - - Profit Revenue minus Expenditures ROI Ratio by which revenue exceeds investment Cost Overrun How much actual costs exceeds estimates **Budgeting in Scrum** The **Product Owner** is responsible for budgeting. There are two main components. - - For personnel costs, it is best to get the cost per sprint. Each emmber has a daily rate and an allocation rate. Daily rate \* allocation rate = daily burn rate. Daily burn rate \* number of days = sprint burn rate. Total sprint cost = the cost of all members Example\ \ Let's say we got **three developers.** Each developer has a **daily rate (for weekdays) of annual divided by 260.** Each **developer has their own allocation rate** between projects. Each sprint takes **two weeks**. If a project is expected to last for a total of 6 sprints: 10k \* 6 = \$60,000 If the fixed cost is around 20k: 60k + 20k = 80k **It is always good to have a 10% - 15% contingency.** In this case: 80,000 \* 10% = \$8000 Total cost for the project: \$88,0000 **STAKEHOLDER MANAGEMENT AND COMMUNICATIONS** **Stakeholders** are **all those who have an interest** in the project and are affected in some way by it. Thus, they will have an interest in influencing it. Stakeholders in software development can be: - - - - - - +-----------------------------------+-----------------------------------+ | Internal | External | +===================================+===================================+ | Top Management | Clients (customers, users) | | | | | Developers | Government (regulatory) | | | | | Direct Managers | Contractors and suppliers | | | | | System Admins | Anyone affected | +-----------------------------------+-----------------------------------+ **Stakeholder influence** 1. 2. 3. **Note:** Agile methods try to maintain engagement throughout the project **Stakeholder Analysis** 1. 2. a. b. Then you make this shitty chart we did in class  KMMK (keep satisfied, manage closely, monitor, keep informed) After classification, you develop a stakeholder management strategy. Strategies are based on the stakeholder spot in the matrix and their attitude: Positive or negative. Specific strategies for high influence and interest stakeholders: - - - - - - - - **Communication Plan** A communication plan allows you **set expectations and standard**s. It define h**ow and when** information is communicated. It also shows who receives which updates. Things to include: - - - - Do not include: - - - Note that your communication plan is deeply tied to your stakeholder analysis. Example **Risk Management** A **risk** is any uncertain event or condition that might affect your project. They are uncertain, they may or may not happen. They **can** happen. There are **Four basic ways to handle risk:** - - - - **Risk Management Activities** - Identify all the risks that could impac the project. Previous experience is invaluable. Checklists and categorization helps. Type of risks: - - - - - - Understand the potential impact of the risk. Asses how **likely** it is going to happen: Large impact \* great likelihood = trouble  - There are 4 ways to handle mitigate - - - - - **"The alternative method** for accomplishing a project goal" Switching technologies, duplicated infrastructure, extra personnel, etc. Or extra money.\ \ Basically, when shit goes down, have a backup plan. **Supposedly, people believe Scrum does not handle risk. Risk management is embedded in scrum's core. I dunno why though.** **Quality Assurance (QA)** **QA** is a set of processes and practices that aim to ensure high product quality. **Quality Control (QC)** is a set of processes that aim to ensure that the desired quality standards have been met. **Testing:** specific set of processes done as part of QC. **QA Principles** **Defect Prevention:** Identify and address potential issues early **Continuous Improvement:** Consistently monitor and improve the quality of a product. **Stakeholder involvement:** Collaboration and communication between the involved parties **Risk-based approach:** Identify and address the most significant risks (Prioritization). **Implementing QA** 1. 2. 3. 4. 5. 6. **QA in SCRUM** QA is an activity inside the dev team. It is an integral part of a sprint. The whole team is accountable. Even if 1 person is responsible. If they fuck up, you fuck up. **Testing** There are six kinds of Testing: **Smoke Testing** Basic check to see if functionality works. Quick and easy. Useful to prevent running expensive tests. **Unit Testing** Check if the single component works properly on its own. Very narrow scope (limited to its own thing) **Integration Test** Checking to see if the functionality of components work well together. After unit testing, you try to integrate a component into the system and run test to see nothing screws up. **Functional testing** Test particular requirements of a system. Like integration but you have a very specific goal or function you want to test. **End to end testing** Similar to function test but includes end-user input and output. **Performance testing** Test the system under heavy load. Checks for **reliability, stability and availability. Normally costly and complex.**