RACI chart

Previously we discussed the various steps a product manger is involved in during the innovation and operation phases of a product lifecycle. One may wonder how one person could be capable of so many aspects of product development and management? The answer is they're not. Product mangers need to be a jack of all trades, they need familiarity in all aspects of the product process.

Facilitation: Product mangers, need a strong background in driving initiatives forward, they need to be comfortable speaking in front of senior management; this requires excellent public speaking capabilities along with organisational abilities and the ability to mediate multiple points of view and align a group along one objective. 

Design: Product managers must have a strong understanding of UX design, they need to be able to understand how research is conducted, that the right research is conducted, and that the right audience is being targeted. Product managers also need to often act as the middle man between engineering and design ensuring that designs are validated as feasible and optimal.

Engineering: Product managers must be able to engage with engineering teams, ensuring that engineering understands the designs as intended. Product managers also need to provide enough guidance to ensure that the product is not over or under engineered; factoring in budget and timelines.

Marketing: Product managers need to engage with marketing teams, for an internal initiative, it'll be change management, regardless, the Product manager must specify who the target audience is, what is the value proportion, that the marketing or change process aligns with the overall vision and mission of not just the product/service, but the organisation.

Project management: product managers often times need to work very closely with project managers or even take one many of those responsibilities themselves working cross functionally to ensure the product/service is delivered on time and on budget.

Customer support: Product managers need to be able to ensure that Customer support has everything they need to engage with customers confidently and effectively. 

Ideally product managers have a familiarity of all of the above, but will generally possess a proclivity towards the aspects which align with their background. There is no right or wrong, just which strengths are appropriate to which context.

The product mangers job at the end of the day is to guide the innovation and operation processes, while making sure that each contributor and stakeholder aligns to vision and mission of the product or service; with so many moving parts it's very simple lose track of who is responsible for what. Luckily we can borrow a simple artefact from project management known as the RACI chart.

Responsible: The individual or group who is/are responsible for the actual work of a deliverable, they are the ones doing the "work". 

Accountable: refers to the individual who leads those responsible, this individual must have the authority over those responsible and will be judged by the final output, for example the marketing strategy, their will most likely be a number of contributors, but only one senior who is able to identify what should be done, and what done looks like.

Consulted: refers to the individuals(s) who have expertise or will be impacted downstream and should be consulted throughout each process.

Informed: refers generally to stakeholders who want/need to be kept up to date with progress.

Throughout the innovation and operational processes of a product's lifespan, their can be dozens if not hundreds of tasks; a RACI chart allows us to keep track of who is/was responsible, accountable, consulted and informed throughout the process. Depending on the Product/Service this chart can span anywhere between one to dozens of pages.

A RACI chart could look something like this

The tasks and roles above are not important, it's the concept of clearly being able to understand which role is responsible, accountable, consulted, or informed regarding which task. A RACI chart will target the appropriate communications to the appropriate audience, ensuring that the right people have the information they need while minimising information overlaod. 

Closing: Closure Plan

There are various reasons of why a project would close

• It has completed the objectives as stated in the project plan.
• Management has pulled the plug for one reason or another

regardless the reason there needs to be a project closure plan. The goal of the closure plan is to ensure that all of the project objective have been achieved, the deliverables where delivered, resources reassigned to other projects or operations, lessons learned and best practices are captured. Project closure can be viewed as a mini sub project. The closure plan consists of

• Confirm all work of the project has been completed 
• Update project documents to indicate the final status, and store them in a shared repository 
• Turn over deliverables to the customer and/or to operations, and obtain approval to close the project 
• Assign resources to other project or operational work 
• Capture lessons learned and best practices for the benefit of future projects 
• Celebrate the team and project success

Execution: Change Control Process

Changes to a project can occur:

• Scope
• Add/Remove features or functions
• Add/Remove deliverables 
• Add/Remove requirements 
• Add/Remove activities 
• Budget
• Add/Remove money to budget 
• Schedule 
• Extra time to deliver project
• extra time for deliverables 
• extra time for milestones

Change order is a form that details the change, the buiness impact and reason for the change, its approval or rejection follows a procedure:

1. Change Order comes from any source internal or external to team
2. Change order is submitted to the PM or Change Control Board
3. Change order is logged in the Change control log
4. Change order is reviewed by PM and Change Control Board
5. If Change order is rejected or put on hold
1. Rejection is logged 
2. Change order initiator is notified 
6. If change order is considered
1. PM & Team analyse the change and impact to
• Scope
• Work Effort
• Time Required 
• Resources
• Quality
• Risks
2. Change Control board reviews analysis and decides to accept or reject chang
• Rejected
• initiator notified
• change logged
• Accepted
• initiator notified 
• baseline changed
• project docs updated
• new baseline communicated to stakeholders

Execution: Control

the goal of controlling a project is to pay attention to the various metrics of the project and ensure that the project is being delivered as closely as possible to the baselined plan. if the performance begins to veer off the original plan then the PM must institute corrective measures. If process improvements are identified they should be implemented money and time saved for one activity could be needed by another.

If poor project health is identified using the CPI or SPI then the PM needs to analyse what the cause is:

• Poor original estimates
• Personal lack expertise 
• Unforeseen Risks or issues
• More expensive resources then anticipated 
• Scope Creep
• etc

any number of things could veering the project off kilter, however when the culprit is identified the PM must implement corrective measures, if these corrective measures bring the budget or schedule outside the acceptable variance levels then a change order has to be requested to the Project sponsor and stakeholders. 

Change orders are not a cure all for poor planning or performance, each change order takes personnel away from their tasks costing more time and money on the project. they should be used sparsely and only when necessary. an abundance of change orders is generally a sign of poor planning.

to keep the project on track the PM must review project KPI's regularly and handle discrepancies sooner rather then later.

Execution: Calculations

Now that we've established:

• Planned Value: is the amount we planned to spend up until the current point in time
• Actual Cost: is the amount we spent up to the current point in time
• Earned Value: is the amount we planned to spend on the completed activities.
• Budget at Completion: is the amount we spent when to project is completed

we can use these values to calculate values that indicate project health

Cost Variance = EV - AC indicates the budget surplus or deficit.

• CV >  0 we've earned more value than expected for the cost we incurred; budget surplus
• CV  = 0 we've earned as much value as we planned for the cost; budget is on-target
• CV < 0 we've earned less value then expected for the cost we incurred; budget-deficit

Schedule Variance = EV - PV indicates if the project is ahead or behind schedule

• SV > 0 we've earned more value than expected: ahead of schedule
• SV = 0 we've earned the planned value: on-schedule
• SV < 0 we've earned less value than expected: behind-schedule

Cost performance index = EV / AC indicates the health of our budget

• CPI > 1 we've earned more value than expected meaning we're under-budget
• CPI = 1 we've earned as much as we planned meaning we're on-budget
• CPI < 1 we've earned less value than expected meaning we're over-budget.

Schedule performance index = EV / PV indicates the health of our schedule 

• SPI > 1 we've earned more value than expected up to this point in time: ahead of schedule
• SPI = 0 we've earned the panned value up to this point in time: on-schedule
• SPI < 1 we've earend less value than expected up to this point in time: behind-schedule

The CPI and SPI can be used to forecast the expected project cost based on our current performance, if the projected cost is within the variance all is well, if it's not then corrective measures must be implemented.

Estimate to complete = (BAC - EV) / CPI how much money is required to complete the project

Estimate at completion = ETC + AC how much money the entire project will cost.

Execution: Earned Value

Earned Value

is the the industry standard for measuring progress, earned value is the Actual cost of the activities that we've completed. It gives us an accurate depiction of how much money we've spent accomplishing our tasks. Earned value provides us with:

• Progress of status of work being done 
• Comparison of planned schedule and cost to, actual schedule and cost based on the work completed 
• Objective data from the baseline compared to actual progress 
• A forecasting method for estimating project completion 
• Comprehensive insight into cost and schedule portions of the project

Earned Value Terminology 

• Planned Value (PV): the amount you planned to spend based on your baseline estimates up to the current point in time.
• Budget at Completion (BAC): the amount you planned to spend on the entire project.
• Actual Cost (AC): the amount you've actually spent on the project up to the current point in time.
• Earned Value: the value of what you've accomplished based on your original estimates, what the cost should be based on how much work is accomplished. 

the relationships between these values will indicate the health of a project

• EV = PV: on schedule, earned the value planed up to this point in time
• EV = AC: on budget, earned the value for the cost planned up to this point in time
• EV < PV: Behind schedule, accomplished less then planned up to this point in time
• EV < AC: Over budget, paid more for the value than planned up to this point in time
• EV > PC: Ahead of schedule, earned more then planned up to this point in time
• EV > AC: Under budget, earned more value for our cost then planned up to this point in time

there are various methods for determining "Earned Value", the one(s) selected should be defined in the Quality plan. 

• 0/100 Rule: an activity is either complete, or not complete. You've earned 100% of the value or 0% of the value.
• 50/50 Rule: the project earns 50% of the value when the activity starts and 100% when it's complete.
• Proportional rule: the value earned is based on the activity status, so if an activity is 25% done then you earn 25% of it's value.

Execution: Monitoring

Once the project plan is complete and baselined, it's time for the execution phase. This is where we leverage the plan we've so meticulously put together, it is the PM's responsibility to ensure that during the execution phase the work get's completed as defined in the project plan. It is the PM's responsibility to:

• Ensure that the resources required are available as scheduled 
• The budget, scope, and schedule are aligned with the Activity list\
• The communication plan is followed as defined.
• If risks occur the strategies are implemented as designed 
• Issues are handled
• Contracts with suppliers or providers are managed 
• Project & Product quality are ensured
• Deliverables are signed off by the customer

In essence the PM must ensure that the project follows the plan as it was laid out.

As we execute the plan, we monitor our KPI's are we meeting our estimates, both for time and money, as we collect these measurements we monitor them, we analyse what we monitor and we control our items, and act on the information we collect to execute our plan.

there's an over used quote "If you fail to plan, plan to fail" without planning out our project the team will wander around solving problems that may not need to be resolved delivering features that may or may not be used, which will most likely fall short of customer expectations. Project management is all about delivering the right thing, for the right price at the right time.

Monitoring
While we execute our plan we need to monitor our progress to ensure that we are staying as close to our project plan as we can, we constantly need to analyse our metrics that we defined in our quality plan and act on the information to keep the project on time, budget and scope.

We consolidate our metrics into something called a "Project status report" this is usually done weekly and reviewed by the PM and team. the report captures:

• project KPI's; their history and variance, 
• high priority risks and issues, 
• Change Order summary, 
• Milestone achievement, 
• deliverable acceptance by the customer.

Baseline & Approval

Now that we've come up with all of the project documentation & planning
Project Charter: hi level list of objectives, deliverables, stakeholders, risks, etc
WBS: grouping of deliverables-> work packages -> activities
Activity List with estimations: list of activities with successors and predecessors identified
Network Diagrams: sequential diagram identifying the critical path and revealing if  smoothing or leveling is required.
Risk Plan: mitigation, avoidance, transfer or acceptance of risk with contingency funds
Quality Plan: strategy for ensuring that the project is following procedures and meeting expectations of objectives & deliverables
Communications Plan: plan of what communications go out when, to whom, how and who's responsible
Team Plan: selection of team members and strategy to get them to work cohesively together
Procurement Plan: a plan to procure personnel or other resources required
Stakeholder Plan: Identification of stakeholders along with their role, power & influence

Once the project plan is created it is time to seek approval from the key stakeholders, generally the sponsor, key client, and senior management paying for the project, once these parties have signed off on the project the project plan is complete and the execution phase may commence. The plan is what the execution performance will be measured against.

When the execution phase begins this does not mark the project plan as written in stone as the project progresses and change orders are approved the scope, schedule and budget will change.

Stakeholder Planning

The stakeholder plan is in place to ensure that all stakeholders are identified along with their role, interest and influence into the project and a engagement strategy is in place.

Based on stakeholder role, interest & influence they may be a passive stakeholder, one who is supplied with status reports and kept in the loop as to the progress of the project or they may be an active stakeholder that is one who approves modification to the project plan, participates in status meetings and provides input and feedback throughout the project.

Team Planning

The purpose of team plan is to assemble the best team possible to ensure a successful delivery and to facilitate a positive working environment. throughout the planning phase we specified profiles required to complete activities as laid out in the activity list, schedule and budget, but now it's time to put names to those profiles with allocation percentages. During the team planning the dates when a team member is joining the team and leaving are also specified.

It is when assigning direct team members that the assessment of whether the appropriate skill and allocation levels are meeting what is required by each activity, if these values do not align then the activity duration may need to be revisited and the schedule adjusted as needed.

Team Environment

Training: Once the team is selected, then it's time to establish how to best work as a team. Any personnel training that is specific to the project should also be included as an activity and be factored into the project plan.
Recognition: recognition for a job well done is important and various milestones or for individual accomplishments employees and teams should be recognized with team events or individual bonuses, these must also come out of the budget and as such should be planned for.
Knowledge Sharing: the team requires one place for the truth a repository that they can go to that will house the latest specifications and documentation relevant to the project..
Synergy: To facilitate the construction of inter-personal relationships between team members, building a sense of trust and respect throughout the team through team events.

Procurement plan
Generally organizations have their own procurement procedures which a PM should be familiar with, during team planning it may turn out that a specific profile required for the project completion is not available, because of other project commitments by the company or because such a profile just doesn't exit within the company, in such a case the PM must either come up with a procurement plan either for a temporary consultant or to hire an employee for the purpose of the project.

Communication Plan

The communication plan is a formal outline of:

• What communications will go out
• How often they will be communicated
• How they will be communicated
• Who's responsible for preparing and distributing the communication

the things being communicated could be:

• Status reports
• Meetings
• Risk reports
• Issue reports
• change orders
• performance data
• audit reports 
• meeting minutes 
• quality reports

A Communication plan will often be in the form of a table

Item/Topic	Purpose	Audience	Responsible	Frequency	Mechanism
What is being comunicated	Why it is being comunicated	Who is the target audience	Who will distribute it	how often or what intervals	how will it be distributed

Quality Planning

The quality plan is made up of the processes and activities that are in place to ensure that the deliverable meet the requirements of the stakeholders & project objectives. The quality plan must also ensure that the project is running efficiently, the minimum quality metrics for a project are:

• Schedule performance: are we on time
• Cost performance: are we on budget
• Scope performance: are we getting the work done
• Based on deliverables
• Deliverables 
• Number of change requests 
• Project Reviews

To manage the quality of a project metrics must first be established, typical metrics could be

• Earned value analysis (add link): actual effort of activity vs estimated effort
• Cost Performance based on Earned value analysis: actual cost of activity vs estimated cost
• Requirements completion including test acceptance
• Deliverable approval with test and customer acceptance
• Rework hours or cost
• Defects
• Change orders with budget and scope impact

The metrics chosen should be easy to collect and provide valuable information as to the overall health of the project. 

The metrics selected must have a tolerance level, remember every project is different and no project plan is perfect it's normal for a %5 variance, depending on the metric and the project the variance could be greater or lower. If a metric is outside the accepted level of variance then the root cause must be identified. there are numerous approaches that can be taken to do this:

• Cause and Effect Diagram: a decomposition technique that helps trace an undesirable effect back to its root cause.
• Flowchart: the depiction in a diagram format of the inputs, process actions, and outputs of one or more processes within a system.
• Checksheet: a tally sheet that can be used as a checklist when gathering data.
• Pareto Diagram: a histogram, ordered by frequency of occurrence, that shows how many results were generated by each identified cause
• Histogram: a special form of bar chart used to describe the central tendency, dispersion, and shape of a statistical distribution.
• Control Chart: a graphic display of process data over time and against established control limits, which has a center line that assists in detecting a trend of plotted values toward either control limit.
• Scatter Diagram: a correlation chart that uses a regression line to explain or to predict how the change in an independent variable will change a dependent variable.

Once the root cause of leaving the metric tolerance is established the PM must come up with an action plan to bring the project back within the acceptable tolerance, if this is not possible then the PM may have to submit a change request to cover the deviation in budget, schedule or scope. 

Project Reviews

It is in the quality plan that the project review meetings are defined, these meetings are used to monitor and control the quality performance and expectations of the project and its deliverable. common meetings are:

• Management Reviews: typically a monthly summary level review of the quality metrics, the projects major accomplishments, and status. Can also include phase gate reviews.
• Team Reviews: detail-level reviews of the quality metrics, project accomplishments, progress, and performance held as often as daily, however weekly is common.
• Customer Reviews: summary level reviews with a focus on the production and acceptance of deliverables scheduled monthly or timed with the production of key deliverables.
• Retrospective Reviews: used to collect feedback from Stakeholders as to what went well and what could be improved for future projects. A key outcome of this review is the collection of lessons learned and best practices that can be used in future projects.

Quality Audits

Project audits are typically performed by someone within the organization but not staffed on the project being audited, they are to provide 3rd party feed back as to the health and efficiency of the project as well as the level of compliance to internal processes.

Audits are completed to find ways of improving project performance this is why they are most valuable in the start of a project the sooner performance boosts are identified the longer the project will benefit from them. generally audits are completed near the end of the initiation and planning phases and at the start of the execution phase.

Quantitative Risk Analysis

Once our risks are identified and prioritized, we develop risk response plans; these pans need to have contingency funds within the project budget. To determine this contingency budget we leverage an approach called "Expected Monetary Value" EMV.

to find our EMV we use our previously established probability and convert it to a percentage

Probability	%
Won't happen Not likely to happen May or may not happen Likely to happen Definitely will happen	0% 25% 50% 75% 100%

Once we correlate our probability values with percentages we can leverage our risk prioritization to figure out

Risk	Probability	Estimated Cost	EMV
Risk # 4	4 = 75%	-$5000	-$3750
Risk # 2	4 = 75%	-$2500	-$1875
Risk # 1	4 = 75%	-$2000	-$1500
Risk # 3	2= 25%	-$300	-$0075
Total			-$7200

as always our estimated cost is just an estimate and is only as valuable as its accuracy, once all the Estimated monetary values for each risk that you're going to cover are calculated their total is contingency budget, the amount of money you need set aside should the worst occur.

during the project when a risk is closed the funds for that risk can be released from the contingency fund.

Risk Monitoring and Control
As a project progress the probability of risks decreases however the impact increases. as the project progress and risks are closed that is there is no possibility of the risk occurring, while this happens new risks can be identified and those risks have to be logged in the "risk register". The "Risk Register" should be reviewed on a regular basis to ensure that risk status is tracked irrelevant risks are closed and new risks are identified an captured.

Risk Response Plans

Now that we've identified and prioritized the project risks, it's time to build response plans, these plans are proactive measures to try and do the following:

• Avoid the risk
• Mitigate the risk's impact or probability
• Transfer it to a 3rd party.

there may also be risks that have such a low RPN/Probability/Impact that we may choose to just accept or there just may be no way to avoid, mitigate or transfer the risk and we have to accept it.

Risks with negative impact

1. Accept: by accepting a risk we decide not to take an preventative action; accepted risks are monitored throughout the project in status updates. accepting risk is not the same as ignoring risk
2. Mitigate: try to adjust the budget, scope, or schedule to reduce the likelihood of the impact and/or probability of risks
3. Avoid: Take preventative actions to eliminate the chance of the risk occurring.
4. Transfer: this does not eliminate the risk, but moves it to a 3rd party that is better equipped to deal with the risk.

Commonly 

• Low priority risks are accepted
• Medium & High priority risks are mitigated 
• Ideally Medium & High priority risks are avoided
• however avoiding a risk may not be feasible or the cost outweighs the impact

Risks with positive Impact

1. Accept:the risk is observed in status meeting and if occurs will be happily accepted, but no proactive measures will be taken to insight the risk
2. Enhance: implement proactive measure to try and insight the risk
3. Exploit: try to ensure the risk will occur.
4. Share: try to share the risk occurrence with a 3rd party

once the risk response plans are established the project scope, schedule and budget must be updated to ensure that these risk response plans are available should the need arise.

Risk Identification

All projects have varying levels of risk, the more unknowns the more risk, Risk planning is the process of proactively preparing for risks, these proactive measures are part of the project scope, budget and schedule. One thing to keep in mind is the difference between a risk and an issue, a risk is something that can be identified and planned for an issue is something out of left field that needs to be dealt with for example lightning strikes the project sponsor, whereas a risk could be new legislation that may or may not be passed during the project.

We plan for risks early on because preparing for a risk will greatly decrease the cost of resolution if identified and prepared for vs taking the project by surprise. The greatest level of unknown is also at the start of the project, as the project moves through the execution phase more and more of the unknowns are identified and risks tend to decrease as the project approaches closing.

Risk Identification 
Risk planning starts with identify risks, the whole project team should be involved in this process; risks can be: technological, economic, cultural, environmental, organizational, external, internal, business, resources, schedule, budget, profit, quality of deliverables, etc. the list goes on, what has to be established is the likely hood of a risk affecting the project, this can be done by:

• Review historical records of similar projects 
• Use a checklist of common risks that can occur
• Brainstorm with the team what possible risks might occur 
• Review the Project Scope (WBS and activities), schedule, and budget for any assumptions that could manifest themselves into risks
• Any risks identified outright when creating the project documents

When identifying risks it is important to not just identify the event but also the impact of the risk. It is easy to focus on the negative risks, but there could also be positive risks, that is events that might occur that could benefit the project; such positive risks should also be identified.

Risks should be captured in a document called a "Risk Register" or "Risk Log"

Not all risks have an equal chance of occurring and since there is far more risks in a project then can possibly be addressed it is imperative that the risks with the highest chance of occurring are the risks the project is prepared for.

Qualitative Risk Analysis

allows the prioritization of risks based on

• likely of occurring
• their impact
• ease of identifying their occurrence 

The risk matrix is designed in such a fashion that it uses a heat map to establish the order that risks should be panned for

for example a risk that has a high impact and a medium probability falls into the top middle square which is red. whereas a risk that has a low probability and impact would fall into the bottom left square that has a risk of green. 

the idea is that all red risks need to of high priority, usually all read and yellow risks have mitigation plans and green risks are reviewed to decide if they need a specific mitigation plan.

For a more sophisticated scale we can use the RPN or risk priority number, this number is generated 

by multiplying the probability value by the impact value by the detraction value 

Probability	Impact	Detection
Won't happen Not likely to happen May or may not happen Likely to happen Definitely will happen	No Impact Not significant May or may not be significant Significant Severe	Definite Detection Easy to detect May or may not be detected Difficult to detect Impossible to detect

with these scales in place and our rpn formula
rpn = probability * impact * detection

Risk	Impact	Probability	Detection	RPN
Risk # 4	4	4	5	80
Risk # 2	3	4	2	48
Risk # 1	2	4	2	16
Risk # 3	1	2	3	6

Risks are ordered from highest RPN to lowest , there is no hard had fast rule as to how many risks should be planned for but between the top 1/3rd and 1/2 is a usual amount.

Baseline a Project

Once the entire project plane is complete, that is the budget, schedule, and scope are agreed to by the project sponsor and management; this is known as the baseline. the baseline is used to monitor and control the project throughout the execution phase, at the very least the documents that are baselined are:

• the Scope Statement
• the Requirements document
• the WBS
• the schedule
• the time-phased budget

Once a project it baselined the only way to make modifications to it is through the "Change Control Process" that was defined in the {charter???}, this is to help insure that the Stakeholders expectations and requirements are met. by following the "Change control process" any changes are reviewed and agreed with by the stakeholders.

Scope Creep vs Scope Change

Scope creep is when requirements work their way into your project through a back channel that is they do not go through the "Change control process" and as such the project scope, budget or schedule do not get adjusted putting the project at risk of failure, whereas scope change does go through the "Change control process" and thus all stakeholders are aware of the change and how it will affect the scoped, budget and delivery of the project.

it is essential that any change to the project, scope, budged or schedule is captured and approved before it is implemented. No changes are allowed to be made to the project baseline without written notice that is approved, if approved this notice is called a "Change Notice" and it is a formal proposal to modify any document, deliverable or the schedule baseline.   

Schedule Optimization

Once we've attempted resource smoothing and still needed to leverage resource leveling which in most cases will elongate a project delivery date, we must agree with the sponsor and management on the appropriate course of action, should it be deemed that a delay in project delivery is unacceptable then the options are as follows

Crashing: is used to add resources to a project to meet an accelerated or constrained delivery date. When crashing a project schedule it is important to not only focus on the critical path, but ensure that as the original critical path is shrunk that no new critical paths do not emerge and if they do to focus on them. Forcing employees to work overtime is also considered crashing.

Crashing may seem attractive initially but it increases the required budget costs and has an adverse affect on moral if personnel are required to work overtime. bringing more personnel  onto a project also has adverse effects, these newbies often come with a learning curve and use up the time of your seasoned personnel slowing productivity initially before the newbs are ramped up.

the decision to crash and how much to crash a project should be made very carefully. 

Fast Tracking:If a project cannot be elongated and suffers from a resource constraint once it has been smoothed and leveled and adding resources is not an option then a PM can attempt to fast track some activities that is to look at sections of the critical path where alternative paths have slack, and leverage that slack to take critical path activities and try to start them in parallel with the resources from the alternative path that has slack.

this can't always be accomplished because it is depended on the types of resources available and critical path tasks that could potetially run in parallel at least partially.

Scope Reduction: if crashing and fast tracking a project are not an option then the PM can discuss with the sponsor about reducing the scope of work, by removing non-critical activities from the critical path the project delivery date can be hastened. it is very important to remove non critical activities as not to degrade the performance or quality of the end product.

by removing activities we in turn will be reducing deliverables or potentially even dropping some, any reduction of scope must then be captured in all appropriate project documentation.

• WBS
• Scope Statement 
• Requirements documentation
• Project Charter

There can come a project that cannot be crashed, fast tracked and the sponsor with  management will not agree to a scope reduction, this is an over-constrained project. This is where softskills come into play it is the PM's job to demonstrate to the sponsor and management that the project is high risk; it needs to be established which two of the three constraints are the most important to understand which one can be manipulated to give the project a chance of success.

Resource Optimization Techniques

now that we have our network diagram and from our activity list we are aware of which activities require what resources it's time to assign/allocate those resources throughout our project and identify any resource constraints we may have. up to now we haven't considered resources availability, we've just identified required resources but now that we have a network diagram of our project we can identify resource bottlenecks for example if two activities.

Our aim is to create a smooth resource distribution throughout the project as well as identify any resource over or under allocations.

Resource Smoothing
is a technique that is used to adjust activities within the constraint of the project duration to evenly distribute resources throughout the project it is done by establishing usage limits for each resource to ensure that resources are note over or under utilized. The float of non critical items is used to reschedule activities to smooth out the use of resources.

Resource Leveling 
is used when resource smoothing is not sufficient to distribute resources without elongating the project. It's a technique that involves adjusting the start and finish dates with the intent of balancing demand with availability of resources. leveling will defer activities until required resources are available, this may very well elongate the project. That is leveling doesn't factor in activity float.

in the event that resource smoothing is not enough and we need to utilize resource leveling odds are that we have to either adjust our project deliver date or we need to allocate more resources to the project, either way we must return to the sponsor and align either we add resources or increase the schedule. if we add resources we must ensure that these are captured in the resources activity list

Network Diagramming

Project scheduling often leverages a network diagram, this is the case because network diagrams provide two major benefits

• displays the critical path: activities that must be done end to end
• reveals flexibility: places we can optimize resources to increase delivery

this visual representation of all the activities that must be done in a particular order is invaluable to understand a project

insert diagram

Critical Path method
this method is used to map the shortest path possible to project completion, it also reveals the tasks that if delayed will ultimately delay the project delivery. The critical path is the longest path from project start to finish whereas the non-critical paths can be adjusted in duration within reason and not affect the project delivery date.

With the network diagram complete and our critical path identified we can look at our alternative paths and identify their slack or float value, that is the amount of time from the earliest start date for each activity that can be deferred or extended without pushing the projects delivery date.

To Identify our critical path

Forward pass analysis
is the process of moving through each path identifying the earliest start and end date for each activity.

• Earliest start date (ES) is the earliest date that an activity can begin with respect to it's predecessor relationships
• Earliest finish date (EF) is the earliest date that an activity can finish, (ES + duration)

insert diagram

float: is between paths is the difference between the duration of the critical path and all alternative paths, each alternative path has it's own float value, that value is how many days that path can be delayed without delaying the project

Backward pass analysis
The backward pass analysis is the process of moving from the end of our project back to the beginning to determine the latest start date and the latest finish date for each activity

• Latest start date (LS) is the latest date an activity can start without delaying the project delivery. (LF - Duration)
• Latest finish date (LF) is the latest date that an activity can finish without delaying the project delivery.

Activities who's ES & EF values are the same as their LS & LF values are on the critical path.

the difference between an activities LS and ES is the float

Reconciling Estimates

As we've mentioned before, when the developing the project charter it is common to use a top-down estimating approach, however once the charter is signed off at the end of the project initiation phase it's time to start the project planning phase. In the planning phase when building the work breakdown structure it is time to implement the more accurate estimation approach of bottom-up.

In the Planning phase when a bottom up estimation is completed it is common for the two estimations to be different, this is of course the result of the bottom up approach being more labor intensive, difficult and accurate than the top down approach. More often than not the bottom-up approach is generally higher than the top-down, this is usually because of political reasons or optimistic estimations or just during the charter the whole scope just wasn't evident.

When the bottom-up estimation is higher than the top-down estimation

• Ask the project sponsor for more budget to cover the difference in cost
• Modify the scope by removing or scaling down requirements 
• Negotiate with vendors to try to get better prices thus decreasing the budget required
• Some combination of the above

If the bottom-up estimation is lower than the initial top-down estimation:

• Settle with the project sponsor on the lower estimate
• Add requirements to the scope to user up the extra budget
• upgrade the current requirements
• Some combination of the above

Once the project budget is finalized and it's allocation to activities, all agreed changes must be updated in the:

• Project Charter
• Requirements document
• Scope Statement
• Work Breakdown Structure
• Activity List

All documents must reflect the agreed upon Resources, Scope, and Schedules and should always be kept in sync with the current agreement between the PM and Stakeholders.

When all reconciliation is complete and confirmed and the budget is aligned to the project scope, it's time to consider adding contingency funds based on the risks identified in the project. The contingency portion of the budget is additional money added to the budget to cover the cost of incurring potential risks that have been identified.