1. Project?
1.1. Unique Deliverable
1.2. Defined Timeframe
1.3. Budget
2. Project manager
2.1. Job
2.1.1. **Get the job done within the timeline**
2.1.2. Planning & Organizing
2.1.3. Budgeting
2.1.4. Managing Task
2.1.5. Controling the cost & other factors
2.2. Skills Required
2.2.1. Strategic planner
2.2.2. Strong organization
2.2.3. Delegation
2.2.4. Prioritization
2.2.5. Action-Oriented / **Enable** decision making
2.2.6. Communication Conflict resolution & Escalation Manage team/people
2.2.6.1. Understanding Team's motivation
2.2.6.2. Communicating what the success will look like, will motivate them For ex: Telling the team how the bridge will look like and how many ppl will use it and how it will save 10000's of hours for commuters will motivate them when you have just started to build
2.2.6.3. Influencing *without* **authority**
2.2.7. Flexibility & Handling ambiguity
2.2.7.1. External Constraints
2.2.7.2. Plan - Risk & Challenges
2.2.7.3. Add "Float/Slack" in schedule
2.3. Impact
2.3.1. Customer/Stakeholder centric
2.3.2. Bulding a great team
2.3.3. Fostering relationship & communications
2.3.4. Innovate - Breaking barriers
2.3.5. Managing project
3. Project Lifecycle
3.1. Initiation of the project 1 (Stakeholder/Client)
3.1.1. Intro with stakeholders/clients
3.1.2. Understanding the mission and vision of the company and the project
3.1.3. Understand the goal and unique deliverables
3.1.4. Timline and Budget if any
3.1.5. Metrics for success
3.1.6. Bonus: What is the need of this project/How will this impact their company
3.1.7. Document everything
3.2. Initiation of the project 2 (Internal team)
3.2.1. Do we have the resource, technology, capacity, venue, talent required?
3.2.2. Is the timeline and budget doable?
3.2.3. Create project proposal and get approval
3.3. Planning
3.3.1. Assemble the team Define the roles and responsiblities
3.3.2. Breakdown the goals and deliverables into **milestones** and furhter into tasks
3.3.3. Create item wise budget
3.3.4. Set *schedules* for tasks and milestones
3.3.5. Set communication channels & modes, establish escalation paths
3.3.6. **Account for risk & challenges**
3.3.7. Create a plan B
3.4. Execution & completion of the task
3.4.1. Assign and prioritize the tasks
3.4.2. Monitor the progress, set daily, weekly or more frequent huddles
3.4.3. Remove obstacles / Enable decision making by putting > 2 right people on a call
3.4.4. Consider any **changes** to budget/plan/schedule/resourece
3.4.5. Motivate the team & keep the team aware of progress
3.4.6. Improve the process if any weakness found
3.4.7. Keep an eye on quality
3.4.8. Call out any risks/delays. Keep the communication open to stakeholders
3.5. Closing the project
3.5.1. Ensure all tasks are completed, Submit the documentations, Handover to support or other team (if req)
3.5.2. Get a confirmation from stakeholders that project is accepatable & the goals are met
3.5.3. Retrospect & check the success metrics. What worked and what did not work
3.5.4. Communicate the project completion to the world and *celebrate *
4. Methodology
4.1. Linear
4.1.1. Waterfall
4.1.1.1. When to use
4.1.1.1.1. End goals are fixed and cannot change
4.1.1.1.2. Stakeholders knows exactly what they want
4.1.1.1.3. You know exactly how to do it and know everything
4.1.1.1.4. New task can start only when the previous task is completed
4.1.1.1.5. Changes are very expensive or not possible
4.1.1.1.6. Phases are clearly defined
4.2. Iterative
4.2.1. Agile
4.2.1.1. When to use
4.2.1.1.1. End goal is an idea, rather than concrete plan
4.2.1.1.2. You don't have clear pathway to the goal / You don't know everything
4.2.1.1.3. Plan can change based on initial feedback from customer/stakeholder
4.2.1.1.4. Stakeholders need want to get involved in each stage
4.2.1.1.5. When change is definite / Flexible
4.2.1.1.6. Get something done quicker by doing task in non-orderly way
4.2.1.1.7. Team's are responsible for their own work
4.2.1.2. How it works
4.2.1.2.1. Task from different lifecycle can be done togehter
4.2.1.2.2. Uses scrum - **sprints** and small milestones to complete work
4.3. Process Improvement
4.3.1. Lean Six Sigma
4.3.1.1. When to use
4.3.1.1.1. Make things which already exist - **better**
4.3.1.1.2. Improve quality
4.3.1.1.3. Improve process / Efficiency
4.3.1.1.4. Reduce wastage/Save money
4.3.1.2. How it works
4.3.1.2.1. D : Define the goal, problem, issue
4.3.1.2.2. M : Measure - understanding the current process and where to find the problem is and what to measure
4.3.1.2.3. A : Analyze using the data received and processes understood
4.3.1.2.4. I : Improve based on the analyzation by putting up processes
4.3.1.2.5. C : Control the process which you have set-up, and put guard rails so it does go haywire like before
5. Organization
5.1. Structure
5.1.1. Classic/Top Down
5.1.1.1. Resource allocation
5.1.1.2. Limited Authority
5.1.2. Matrix
5.1.2.1. More authority
5.1.2.2. Faster Delivery
5.1.2.3. Resource Sharing
5.1.2.4. Role Ambiguity
5.1.2.5. Negotiation Skills Required
5.1.3. PMO
5.1.3.1. Align projects with companies vision
5.1.3.2. Select projects
5.1.3.3. Connect multiple projects
5.1.3.4. Set best practices
5.1.3.5. Resource allocation
5.1.3.6. Documentation, tools
5.2. Culture
5.2.1. Companies identity/personality
5.2.2. Value
5.2.3. Mission
6. MIscellaneous
6.1. Change Management
6.1.1. Process of delivering **completed** project and getting it **adopted** by people People here can be companies employees, end users, top management, sales/marketing team
6.1.2. 5 steps before normalcy by humans
6.1.2.1. Resistance
6.1.2.2. Letting-go
6.1.2.3. Acceptance
6.1.2.4. Insight
6.1.2.5. Practice
6.1.3. 3 Important questions
6.1.3.1. Who get's affected
6.1.3.2. How do they get affected
6.1.3.3. How to help
6.1.4. How to plan for change? Even with planned change there will be disturbance, but the chaos will be better than non-planned change
6.1.4.1. Communicate the plan to change
6.1.4.2. Tell them the bigger picture
6.1.4.3. Motivate them by telling how this will make their life better. Evernthough it will be difficult in the beginning
6.1.4.4. Show them the plan, ask for feedback
6.1.4.5. Make the release step-by-step Do not release everything at once
7. Real Course Project LifeCylce
7.1. Initiation
7.1.1. Goals
7.1.1.1. SMART
7.1.1.1.1. Specific
7.1.1.1.2. Measurable
7.1.1.1.3. Attainable
7.1.1.1.4. Relevant
7.1.1.1.5. Time-bound
7.1.1.1.6. Example
7.1.1.2. OKR
7.1.1.2.1. Objective
7.1.1.2.2. Key Result
7.1.2. **Scope** Boundaries of the project
7.1.2.1. How to know the scope?
7.1.2.1.1. Talk to the stakeholders and ask them what they have in mind
7.1.2.1.2. Do research based on the goals
7.1.2.2. Questions to ask to define the scope
7.1.2.2.1. **In what way you want to achieve the goal/delivarable?** For increasing revenue there are 100 ways, how and what do you want to do? Example: As a company selling plants, you can borrow money gamble and increase the revenue. Or you can create a new plant line, create a website, market and sell it.
7.1.2.2.2. What does stakeholder have in mind?
7.1.2.2.3. Who approves the final result?
7.1.2.2.4. Who will be using the service?
7.1.2.2.5. Who should we deliver the project to?
7.1.2.2.6. What is the project expected to achieve?
7.1.2.2.7. Example: For Pet Pal project let's say to achieve the goal, the customer had to purchase the plants from online or print catlog. Scope will be - Research the market to understand the needs for creating a new product - Find a merchant that will deliver this new product - Create a website suitable for tablet with shopping cart, online payment, search functionality. - The size and thickness of the paper will be A4 and 250gsm and the color of the print will be B/W
7.1.2.3. In-scope
7.1.2.3.1. What is **included** in the project which contribute to the project goal
7.1.2.4. Out-of-scope
7.1.2.4.1. What is **excluded** in the project which contribute to the project goal
7.1.2.4.2. Example: Pet Pal which is suppose to deliver small plants, suddenly if the sales team tell you to start delivering big plants then it is out-of-scope
7.1.2.5. Scope Creep
7.1.2.5.1. Changes, growth or un-controlled factors that changes the scope after the project has begin
7.1.2.6. Managing the scope
7.1.2.6.1. Scope and goal go hand-in-hand, If you change the scope goal will change Similarly, if you change the goal scope will change
7.1.2.6.2. Solution to scope creep
7.1.2.6.3. How to trade-off
7.1.2.7. Remember any change to the scope, internal or external should be informed to the stakeholder and the team
7.1.3. Deliverables
7.1.3.1. Products/Services you need to deliver for completing the project Tanglible/Intangnible outcome
7.1.3.2. Example: For plan pal, Submitting the newly designed website Deliering 1000 plants to 100 customers Completing marketing campaign These are all deliverables
7.1.4. Success Criteria
7.1.4.1. Criteria to measure the success of the project
7.1.4.2. Nomenclature
7.1.4.2.1. **Launch** Delivering the final product to the users and stakeholders ----------------------------------------------
7.1.4.2.2. **Landing** When you succeed in what you launched Measuring the success of the project using criteria established in the beginning ----------------------------------------------
7.1.4.2.3. **Adoption** How customers are using the product or services without any issues ----------------------------------------------
7.1.4.2.4. **Engagement** How ofter customer interact over a time ----------------------------------------------
7.1.4.3. What?
7.1.4.3.1. Tells us whether or not a project is successfull
7.1.4.3.2. Standard by which the project is judged
7.1.4.4. How to determine?
7.1.4.4.1. Measurable component of the goal M from SMART and KR from the OKR
7.1.4.4.2. Quality of the product/service
7.1.4.4.3. Does it fulfill the need of the customer
7.1.4.5. Important things to consider
7.1.4.5.1. Once the success criteria is defined, get it signed off from the stakeholder
7.1.4.5.2. After the project is completed, use the document to validate if everything has been completed
7.1.4.6. How to measure?
7.1.4.6.1. Google follows a 0.0 - 1.0 approach for setting OKRs. Typically, they set ambitious goals with the aim of achieving 0.7-0.8 of the target, considering this range to be a good outcome. If they reach 1.0, it suggests the goal was too easy. Sample scorecard - https://tinyurl.com/yeynbz5s
7.1.5. Project Roles & Stakeholder Analysis
7.1.5.1. Project Roles
7.1.5.1.1. Project Sponsor
7.1.5.1.2. Team Members
7.1.5.1.3. Customer
7.1.5.1.4. Users
7.1.5.1.5. Stakeholders
7.1.5.1.6. Project Manager
7.1.5.2. Stakeholders Analysis
7.1.5.2.1. Why?
7.1.5.2.2. Preparation
7.1.5.2.3. Analysis
7.1.6. Resource
7.1.6.1. People
7.1.6.1.1. Team
7.1.6.1.2. Roles & Responsibilities
7.1.6.2. Budget
7.1.6.2.1. Discuss and lock-in the budget
7.1.6.3. Materials
7.1.7. Cost benefit analysis / ROI
7.1.7.1. The benifit for the project
7.1.8. Documentation
7.1.8.1. Project Proposal
7.1.8.1.1. Documentation used to persuade the project sponsor to initiate the project
7.1.8.1.2. This is done by senior team and before the project is assinged to the PM
7.1.8.1.3. Mode could be formal document, an email or a presentation
7.1.8.2. Project Charter
7.1.8.2.1. Formal document outlining everything fromExecutive summary, goal, scope, why we are doing it (business case) deliverable, wteam, budget, cost benefit anaylysis and success criteria.
7.1.8.2.2. Example
7.1.8.2.3. Example Plan pal
7.2. Planning
7.2.1. Intro
7.2.1.1. What does Project Plan Doc contains?
7.2.1.1.1. Milestone
7.2.1.1.2. Tasks
7.2.1.1.3. People
7.2.1.1.4. Documentation
7.2.1.1.5. Time
7.2.1.2. Project Kick-off meeting
7.2.1.2.1. First meeting where the whole project team get's togehter to understand the - **Vision** - **Goals** - **Scope of the project** - **Share roles and responsibilities** of each team member
7.2.1.2.2. Why?
7.2.1.2.3. Who?
7.2.1.2.4. Agenda
7.2.1.2.5. Best practice
7.2.2. Work
7.2.2.1. Milestone
7.2.2.1.1. Project schedule that indicates progress or completion of a **deliverable** or a phase Basically, they are important checkpoints for completing the project goal
7.2.2.1.2. Why milestones?
7.2.2.1.3. How to define milestones and deadlines
7.2.2.1.4. Mistakes to avoid
7.2.2.2. Tasks
7.2.2.2.1. Activity that needs to be done in a specific timeline
7.2.2.2.2. How to define tasks
7.2.2.2.3. How to assign tasks
7.2.2.3. **Work Breakdown Structure (WBS)**
7.2.2.3.1. Tool/Methodology to sort milestones and tasks into hierarchy **in the order** they need to be completed
7.2.2.3.2. How?
7.2.2.3.3. Example
7.2.3. Schedule/Timeline
7.2.3.1. Estimation
7.2.3.1.1. As a project manager, you will not know how muct time/effort it will take to complete a task Ask your teammates to tell you
7.2.3.1.2. Time Estimation
7.2.3.1.3. Effort Estimation
7.2.3.1.4. Buffer
7.2.3.1.5. Capacity planning
7.2.3.1.6. Project Schedule using "Critical Path"
7.2.3.1.7. Best Practices
7.2.4. Budget & Procurement?
7.2.4.1. Intro
7.2.4.1.1. Resource needed to complete the project
7.2.4.1.2. Not all company allows PM's to do budgeting, but it is important for you to know what all are the parts
7.2.4.1.3. Break budget my milestone
7.2.4.1.4. Budget is split into 3 major parts
7.2.4.1.5. Budget is consider as deliverable and success metric in itslef
7.2.4.1.6. Budget is set on **initiation** phase
7.2.4.1.7. Budgeting should be planned along with scheduling as they work in conjunction
7.2.4.2. Questions to ask?
7.2.4.2.1. What does **stakeholder wants?** Most project goal is to either - Increase revenue - Reduce cost - Reduce time All of these comes at a cost, understand that from the stakeholder
7.2.4.2.2. **Suprise expenses** There will always be suprise expense, so account for buffers
7.2.4.2.3. **Review and re-forecast** Things might change, you will over/underestimate things, as the project progress review and rebalance
7.2.4.3. Factors to consider
7.2.4.3.1. **Resource cost rate** How much your labour, software, equipment, materials will cost
7.2.4.3.2. **Contingency fund / Buffer** Money added to the estimate to conver un-forseen costs
7.2.4.3.3. **Reserve analysis** Method to calculate remaining resources
7.2.4.3.4. **Cost of Quality** Cost incurred to prevent issues with product, process, tasks
7.2.4.4. How?
7.2.4.4.1. **Historical data** Use the old projects data too come up with the cost and understanding the risks involved
7.2.4.4.2. **Leverage experts/Team** Ask your teammates and external experts, get quotes
7.2.4.4.3. **Bottom-up method** Methodology to list down all the task from start to end and assign dollar value to it
7.2.4.4.4. **Accuracy** Make sure to double check before submitting it for approval
7.2.4.4.5. **Buffer** - As a general practice 5% to the total cost Can vary depending on the project.
7.2.4.4.6. **Baseline budget** - It is an estimate budget which you created and should be used as the benchmark when the project is ongoing to comparet the forecast vs real budget Change of the scope = change of budget, re-baseline is required
7.2.4.4.7. **Payments** 1. Fixed contract - Paid when you reach a certain milestone 2. Time/Material contract - Paid by end of every month, like salary.
7.2.4.4.8. Example - https://tinyurl.com/bdfbhr4f
7.2.5. Risk Management
7.2.5.1. Things will definitely *not* go as planned, it's how you react, and what you do about the risk matters.
7.2.5.2. Nomenclature
7.2.5.2.1. **Risk** A **potential/possible** event which can impact the project
7.2.5.2.2. **Issue** A **real problem** which can effect the ability to complete the task
7.2.5.2.3. A *risk* is something which **can ** happen, an *issue* is something which **is happening** Basically risk becomes issue
7.2.5.2.4. **Risk Management** A process to identify the risk and issue and creating a mitigation plan for that
7.2.5.3. Identify the risk
7.2.5.3.1. **Brainstorm with team** use RACI chart and include a diverse set of people for all backgrounds on **what could go wrong?**
7.2.5.3.2. Looks for **historical trends,** other project with similar goals and deliverables
7.2.5.3.3. Connect with **SME's** and ask the stakeholders themselves
7.2.5.3.4. **Type of risk** Could be both internal or external
7.2.5.3.5. Critical path risk/ Project dependecy risk
7.2.5.4. Analyze the risk
7.2.5.4.1. Step know what **causes** the risk
7.2.5.4.2. Categories of **causes**
7.2.5.4.3. Brainstorm with the team and create a **Fish-bone / Cause & effect diagram**
7.2.5.5. Evaluate the risk
7.2.5.5.1. Steps to prioritize the risk
7.2.5.5.2. Impact
7.2.5.5.3. Probability
7.2.5.5.4. Inherint Risk
7.2.5.6. Treat the risk
7.2.5.6.1. Steps to **mitigate** the risk
7.2.5.6.2. Example: Contractor who has a history of *delay* but gives the best price
7.2.5.6.3. AVOID
7.2.5.6.4. ACCEPT
7.2.5.6.5. CONTROL
7.2.5.6.6. TRANSFER
7.2.5.7. Document and communcate the risk
7.2.5.7.1. Risk register
7.2.5.7.2. Example - https://www.smartsheet.com/risk-register-templates
7.2.5.7.3. Risk management plan document Should contain - Risk - Impact - Priority - Probability - Inherint Value - Mitigation note - **Owner**
7.2.5.7.4. Example - https://docs.google.com/document/d/1AXYhogd_jpYax6mED6-k7YNbkdDz1pZiOJmkrdfqDxo/
7.2.5.7.5. Mode of comms
7.2.5.7.6. Why communicate
7.2.5.8. Control & Monitor
7.2.5.8.1. Risk management is an ongoing process, set-up a call every week, bi-weekly to monitor all the risk and update them
7.2.5.8.2. Assign a owner wherever required, you might not be able to monitor all the risks
7.2.6. Documentation & Communication plan
7.2.6.1. Documentation
7.2.6.1.1. Having everything in one place - Quicker - Easier - Streamlined - Continous
7.2.6.1.2. Specially for you who forgets what you ate in the morning, documentation is very important and keeping everything in one place
7.2.6.1.3. It should contain everything from project charter, stakeholder analysis, planning docs everything
7.2.6.1.4. Example - https://docs.google.com/spreadsheets/d/1HhXIkZS7Qec8GRJ7hriRp2rLeBikKcXZx57_kOG7b10/
7.2.6.1.5. Keep a **drive** as well with all the docs, media
7.2.6.1.6. Example - https://drive.google.com/drive/folders/17L9AL0wYXz0NqFd9-DLS2uS7lo452F_m
7.2.6.2. Communication
7.2.6.2.1. One of the most important peice of project, without this nothing goes as plan
7.2.6.2.2. **Commnuication plan** It is a document consisting of all the things communication
7.2.6.2.3. Structure of communication plan
7.2.6.2.4. Example
7.2.6.2.5. This does not need a seperate doc for smaller, internal projects you can add these details in the project tool itself
7.3. Execution
7.3.1. Tracking
7.3.1.1. - To see if everything is going as per plan - Monitor risk and issues - Keep everyone informed on progress
7.3.1.2. Nomenclature
7.3.1.2.1. **Tracking** Following the progress of the activity
7.3.1.2.2. **Deviation** Anything that alters the set course of action in positive or negative way
7.3.1.2.3. **Story points** Point system to know who much time a task will take.
7.3.1.2.4. **Velocity** Story points completed within a sprint (or multiple sprints) This will tell at what speed the tasks are getting completed for a given duration
7.3.1.3. What to track
7.3.1.3.1. **Work** - Tasks, activities
7.3.1.3.2. **Schedule** - Are the task being done on schedule
7.3.1.3.3. **Milestone** - Are the milestone getting completed on time. There is a possbility tasks are getting completed, but milestone is not getting completed, this could be because of **tasks getting added**
7.3.1.3.4. Cost
7.3.1.3.5. Key decision, changes, risks and dependencies
7.3.1.4. How to track
7.3.1.4.1. Burndown chart
7.3.1.4.2. Epic Burndown
7.3.1.4.3. Gantt chart
7.3.1.4.4. Road map
7.3.1.5. Dashboards
7.3.1.5.1. Should have features
7.3.1.5.2. Top level metrics (KPI)
7.3.1.5.3. Task
7.3.1.5.4. Team wise progress
7.3.1.5.5. Employee wise progress
7.3.1.6. Project Status Report
7.3.1.6.1. Report sent to stakeholders on a regular basis to update them on the project status
7.3.1.6.2. What should it contain?
7.3.2. Managing Risks and Changes
7.3.2.1. Changes
7.3.2.1.1. Changes due to risk materialization(issues) or any other apect
7.3.2.1.2. Type of change
7.3.2.1.3. If you manage scope creep and dependency 90% of your issues are mitigated
7.3.2.1.4. Change request form
7.3.2.1.5. Communicate the change and put it in a Change registry
7.3.2.2. Risk
7.3.2.2.1. What to do once the risk materialize?
7.3.2.2.2. Precaution
7.3.2.2.3. Biggest risks
7.3.2.2.4. How to manage
7.3.2.2.5. Escalation
7.3.3. Quality management & Retrospective
7.3.3.1. Quality & continous improvement
7.3.3.1.1. To fulfill the requirement and meet or exceeds the expectation of the user/customer
7.3.3.1.2. Phases of Qaulity
7.3.3.1.3. Communication with customers
7.3.3.1.4. User Testing and Feedback
7.3.3.1.5. Continuos Improvement
7.3.3.2. Restrospective
7.3.3.2.1. Meeting to reflect on what went good, bad and how to improve
7.3.3.2.2. Why?
7.3.3.2.3. When?
7.3.3.2.4. How?
8. Interview Prep
8.1. Finding the skiils
8.2. STAR methodolgy for answering questions
8.3. Questions about tools, how did you use the tool? How did you know using the tool that the project is going off etc.,
9. Tools
9.1. General info
9.1.1. Only introduce new tools when there is a need or gap in the current tool
9.1.2. Use simple tools if the project is small / Sophisticated tools if the project is complex
9.1.3. Team will take time to learn Sophisticated tools
9.1.4. If you are introducing a new tool in middle of the project make sure - You know the benefit - The tool is working completely Use change management principles here
9.2. Scheduling and work management tools
9.2.1. Jira
9.2.2. Spreadsheet
9.2.3. Basecamp
9.2.4. Linear
9.3. Colloboration tools
9.3.1. Mail
9.3.2. Slack
9.4. Productivity tools
9.4.1. Google docs
9.4.2. Spreadsheet
9.4.3. Slides
9.5. QA tools (evaluation, productivity tracker, reports)
10. Prioritize requirement
10.1. MoSCoW
10.1.1. **Must have** Critical/Priority requirements. Must have for success of the project Ex: Message sending functionality in the messaging app
10.1.2. **Should have** Imprortant feature that add value Ex: Group chat
10.1.3. **Could have** Nice to have Ex: Emoji reaction for messages
10.1.4. **Won't have** Out of scope for now Ex: Audio call.
10.2. Value vs Complexity matrix
10.2.1. High value, low complexity
10.2.2. High value, high complexity
10.2.3. Low value, low complexity
10.2.4. Low value, high complexity
10.3. **Kano model** Requirements based on **cusotmer satisfaction**
10.3.1. **Basic needs** These are the requirements which customers thinks are minimum. - Failing to meet these leads to dissatisfaction. - Meeting them *doesn’t* increase satisfaction.
10.3.2. **Performance needs** - Customer satisfaction increases. - The more better, the more happy customers
10.3.3. **Excitement needs** - Unexpected feature that delight customers
10.3.4. **Indifferent needs** - Don’t have any significant impact on customer satisfaction.
10.3.5. **Reverse needs** - Feature that reduces customer satisfaction and needs to be removed