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.

WBS: Budgeting

Once all activities are listed with their Duration & Effort estimates, the budget can be composed, the budget is the cost element of the triple constraint. Costs are allocated to the activity level, all costs including personnel, assets, subscriptions etc need to be allocated to get the most accurate estimate per activity as possible. even the estimate cost of contingencies is included in the estimating of activities.

since each activity is tied to it's precursor and successor; work packages are comprised of activities and deliverables are made up of work packages; with all this information we can track how much each deliverable will cost and when it will be delivered. The WBS and activity list are used to manage the triple constrained, the budget scope and schedule are managed together, the WBS and activity list documents are the corner stone of the project plan.

Estimating
there are multiple ways to estimate to cost of activities

• Bottom-up estimating: estimates are done from the bottom of the WBS, starting with estimating how much each activity will cost adding those values up to figure out the cost of a work package, etc up to the project
• Top-down estimating: involves estimating how much a work package will cost, then dividing that estimate up among the activities, this can start at the project, deliverable or work package level.

there are pro's and con's of each

Top-down Estimating 
The advantage of top-down estimating is that it can be done fairly simply and quickly however it is not as accurate as bottom up estimating techniques, it is best used for the project selection or developing a project charter, some techniques are:

• Pragmatic estimating: leverage historical data, for example a company can use data from previous projects similar in scope to estimate the cost of new projects. it leverages the cost per unit times how many units needed paradigm. 
• Analogous estimating: leverages historical data, if a company completed a similar project, but twice the size you could argue that the new project will be similar in costs just divided by two.
• Group Decision making: involves leveraging experts, each expert would create their own estimate for the project, deliverables, work packages and activities, then in an iterative fashion the experts discuss and narrow down to the best estimate.
• Software estimating: leverages historical data with statistical analyses and various algorithms to help estimate as well as define odds of success vs failure. 

Bottom-up Estimating
The advantage of bottom-up estimating is that it's much more accurate however it's also far more difficult and involved, it requires granular analyses of each activity by experts then all costs for all activities are aggregated to come up with a project estimate.

it is recommended to use both a top-down and bottom-up estimation to get a more accurate understanding of the project cost. typically when project selection is done and the charter is written a top-down approach is used, then when in the planning phase it's normal to use the bottom-up approach to get a more accurate depiction on budget needed. if there's a discrepancy then it becomes a negotiation between the PM, sponsor and senior management of whether to decrease scope, increase budget or some combination of the two.

WBS: Activities

Activity Planning
Activities make up work packages; activities are the line items inside of work packages that need to be completed to close a work package. some activities need to be completed before others, these are referred to as "predecessors". predecessor activities have to be completed before its "successor" activity. The "predecessor" to "successor" relationship is referred to as a "Finish to start" relationship.

By laying out all our activities with a predecessor successor relationship we can layout the timeline for our entire project. activities with no predecessor can be started on day one of the project, otherwise they need to be completed sequentially.

Predecessor relationships are only defined at the activity level and not the work package or deliverable levels.

Activity Resourcing
Once we've planned our activities we need to assign resources to them, these could be people, assets, commodities, services, supplies, materials, or money, basically anything that is required to complete the activity.

Activity Duration & Effort
After the resources are assigned to each activity it's time to estimate

• Duration: The number of business days required for an activity; used to estimate schedule
• Effort: The total number of hours required for an activity; used to determine the budget.

For example 3 employees could be working on a activity at the same time, so it would be 1 workday of duration but 24 hours of effort; or you could have 2 employees working 50% of an 8 hour work day on an activity that requires 12 hours of effort, two employees working half their time would have an 1.5 days of duration.

as always you're values are only as good as your estimates, ideally you would want the people who will be doing the work estimating or someone who has a good understanding for the activities and their complexity

Work Breakdown Structure

The Work Breakdown Structure is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS is a key tool that can be used by PMs to define and manage scope, it is used to break down a project into smaller workable sections (work packages)

A WBS can be represented as a hierarchical tree diagram

Based on the complexity of the project the hierarchical tree could have more or less levels

Our WBS can also be represented as an outline

1         Project

1.1         Deliverable

1.1.1        Work Package

1.1.1.1         Activity A

1.1.1.2         Activity B

1.1.1.3         Activity C

1.1.2        Work Package

1.1.2.1         Activity D

1.1.2.2         Activity E

1.1.2.3         Activity F

1.1.2.4         Activity G

1.1.3        Work Package

1.1.3.1         Activity H

1.1.3.2         Activity I

1.2         Deliverable

1.2.1        Work Package

1.2.1.1         Activity J

1.2.2        Work Package

1.2.2.1         Activity K

1.2.2.2         Activity L

Both represent the same work breakdown structure.

Activities
When defining activities which represent the work that needs to be completed at a granular level within a WBS the order of each activity is the order it should be completed in. The rule of thumb for activities is that they should represent 1 to 2 weeks worth of effort for 1 resource, if they're out side of the 5 to 10 working day range then either they are too granular or too broad.

Project Scope Statement

The project scope statement is similar but more detailed to the project charter, it defines the objectives and deliverables of the project.

Project Charter

Project Scope Statement

Project purpose or justification Measurable project objectives and related success criteria High-level requirements High-level project description High-level risks Summary milestone schedule Summary budget Stakeholder list Project approval requirements (what constitutes success, who decides it, who signs off) Assigned project manager, responsibility, and authority level Name and authority of the sponsor or other person(s) authorizing the project charter

Project scope description (progressively elaborated) Acceptance criteria Project deliverables Project exclusions Project constraints Project assumptions

as we further define the details of the project these details mature and more accurately represent the scope of work. the project scope statement must be mature enough that the Stakeholders can clearly understand what will be delivered within the project in order for them to confirm that the scope accurately represents the objectives and requirements of the project. Details of on the deliverables that will be produced as well as their acceptance criteria, assumptions and exclusions are also included in the project scope statement.

Project Scope Statement

• Scope Description:
• Narrative Description
• Expected results
• Project Objectives
• Clear & Measurable statements of results and expected benefits of project
• Acceptance Criteria
• Measurable Criteria 
• Used by key stakeholders to provide approval of the objectives & deliverables
• Project Deliverables
• Outputs of the project
• created during
• Planning phase
• Executing phase
• closing phase
• Exclusions
• Not included in the scope of work
• Functions
• Features
• Services 
• Deliverables
• Assumptions
• Criteria or characteristics that are expected to be true about deliverables 
• Constraints
• Limits that are known and must be accommodated 
• Restrictions that are known and must be accommodated 
• Change Management plan
• The process of how changes will be managed
• Project scope
• deliverables 
• requirements 
• Budget
• Schedule
• Changes can be initiated from any stakeholder & must be documented
• Change control board
• team of stakeholders that review & make decisions on changes that will or will not be made to a project.
• Change order from
• Used to document any changes that need to be made to the project
• Version control
• documented history of when and by whom the Project scope statement was approved
• a list of any subsequent agreed to changes approved by the change control board

All project planning documents are live documents that can, and do evolve with the project, this is why all project planning documents require a version control section.

To produce the Project Scope statement, the project charter as well as the project requirements documentation need to be reviewed by the team. The project scope statement provides additional details of what will and will not be included in the project. By explicitly specifying the exclusions of the project it better defines the boundaries of the project scope helping clarify to the stakeholders what is in scope vs what's not in scope. This is very useful during the execution phase of a project and helps protect against scope creep and keep the project within the triple constraint. 

Scope of Work: Collecting Requirements

To fully understand the scope of work not only must we understand the final deliverable but we must also understand all of the incremental deliveries along the way to the project completion. Collecting requirements starts in the initiation phase with the project charter, however the requirements in the project charter are a starting point.

All stakeholder input is required for requirements collection, this can be done in a one to one bases but it is preferred to bring all of the stake holders together for a group requirements gathering session. This group requirements gathering sessions provides three benefits:

• Collects requirements for the project plan
• Gives stakeholders a common understanding of the requirements 
• Resolves competing and/or conflicting requirements

Requirements must support the project objectives, the Project Manager must ensure that at all times the requirements support and do not conflict with the project objectives; it is also important to ensure that the requirements are feasible. Requirements define what needs to be done and not how.

Requirements will generally fall into the following list:

• Product technical or functional requirements  
• Project  process/management requirements 
• Quality or performance requirements (for the project and product)
• Business or organizational requirements (for the project and product)
• Support or operational requirements (for the product)
• Profitability or sales/Marketing requirements (for the product)

Documenting Requirements
All requirements are collected, documented, reviewed, prioritized and approved by the stakeholders. these requirements are the basis from which the work activities/tasks are defined. These requirements are often documented in a "Requirements Tractability Matrix"; it's a grid that links product requirements from their origin to the deliverables that satisfy them.

Requirements map directly to deliverables or objectives, each requirement must support an objective or deliverable directly. If a requirement doesn't support an objective or deliverable then there is a problem that needs to be addressed, either you're missing an objective/deliverable, or the requirement is not valid.

The main deliverable is comprised of smaller ancillary deliverables that build up to support the project purpose and objectives; the main deliverable, the successful completion of the project.

Requirements should be traceable to deliverables which in turn support the Project Objectives. in this way requirements are connected to work items that produce deliverables which support objectives.

Requirements need to be measurable and testable to show the customer that they where successfully completed as defined in the project plan to gain customer approval. All assumptions and limitations should be tracked by the project manager as discussions with stakeholders take place, these items need to be documented in the project scope statement.

Prioritizing Requirements
Not all requirements are of equal importants, some are essential while other a nice to haves. A popular method for prioritizing requirements is the MoSCoW method which breaks requirements down into:

• Must Have: critical have to meet project Objectives
• Should Have: important and should be included in final deliverable if time and budget permits, otherwise need to be delivered at a later date or in a subsequent version.  
• Could Have: nice to have, but the project objective can still be met without these requirements.
• Wont Have: will not be included in the current iteration of the product, these are agreed upon with the stakeholder in the outset of the project that they will not be included, but can be revisited in the future.

Stakeholders need to be involved in the prioritization process of requirements this helps the PM and team understand the most critical requirements that need to be delivered. It is normal to move some requirements to the wont have prioritization as the project plan progresses to facilitate the budget and time restrictions of the project. as the project progress the PM with stakeholder approval can move could have and should have requirements out of scope to deliver the project on time and budget. Since it was decided with the stakeholder that these requirements are not essential to project success getting approval to de-scope them is usually straight forward.

The PM must ensure that the Requirements Traceability matrix is maintained throughout the lifespan of the project to track which requirements are within the scope of the project.

Planning phase

Once we have created a project charter and it's signed off by the stakeholders it's time to start the project plan. The project plan consists of

• Defining the scope of work
• Defining the costs and budget
• Defining the schedule
• Preparing the project plan

The project plan is the road-map for how the objectives laid out in the project charter will be achieved. To begin the project planing phase, first the key personnel with the right skill sets required for the project must be selected, these team members will be leveraged for the planning of the project. The entire team is not necessary, however the key members should have input.

Kickoff or Startup meeting
The purpose of this meeting is to bring the team together, and review the project charter to make sure that everyone understands what the team is expected to deliver and why, if possible the project stakeholders and sponsor should be included; this is an excellent opportunity for the team to start building the interpersonal relationships that are essential for a project's success.

The kickoff meeting is intended to establish how the team is going to complete the planning phase of the project and may even begin the process. It's perfectly normal for these meetings to last from several hours to several days pending on the complexity of the project. It's not uncommon for project teams to take up to a full week to outline the project plan, by working on the project plan together it gives the team a common understanding of what has to be completed and why.

Defining the scope of work
The first thing that needs to be established in a project plan is the scope of work, the reason for this is because it creates a basis for the schedule of activities and the budget. A budget cannot be defined without knowing the activities and tasks that are required for the successful completion of the objectives. By focusing on the objectives from the get-go the team concentrates their efforts on solving the essential problems and not going off on tangents.

The project's scope defines the project in the terms of deliverables and the work required to produce those deliverables. It is comprised of the work required to manage the project as well as the work required to complete the project, they are two parts of the same whole and their purpose is to successfully deliver the product, service, or resultt. It is essential that the project plan contains all of the work required to fulfill the requirements to deliver the product, service or result because only the work within the scope will be completed.

Developing the Project's Scope requires that we identify the requirements and work for the successful delivery of our product/service/result. the Project scope is comprised of the following:

Project scope

• Requirements documentation
• Scope statement
• Work breakdown Structure (WBS)

Project Charter

• Purpose of the project: a simple business statement about what the project is about
• Objectives: are clear an measurable statements as to the results of the project. When defining Objectives make sure that they meet the SMART criteria
• Specific & clearly stated
• Measurable or Quantifiable
• Achievable
• Relevent
• Time-bound
• Key requirements: List what is needed to achiece the objectives
• Main deliverables (Schedualed milestones): a schedual of what will be deliverd and when
• Resources Required: the things needed to deliver the project succesfully
• Budget
• Personnel
• Equipment
• Materials 
• Major Risks: what could prevent the project from being a success
• Schedule
• Budget
• Profitability 
• Technical
• Organizational
• External
• Key stakeholders & sponsers: people who are affected by the project and people who have influence over the project, at a minimum this will be the sponsor, the clients and the team. 
• Project Sign off: this is where the project signed off by the sponsor and PM and client

Project Initiation

Once a project is selected it must be initiated, it is in this phase that the project manager learns:

• The objectives of the project
• The business reasons as to why the project was selected
• Information about the project deliverables, Timeline, and budget
• Gains approval to proceed with the project

The initiation phase of a project lays the groundwork for the project

• defines the reasons why they project is undertaken
• the primary business benefits of the project
• the goals the project is expected to achieve
• ensures that all stakeholders are on the same page
• acknowledgment by management of resources required: time, budget, scope
• Project Charter (main deliverable)

Once a project has been added to the project portfolio the organization assigns a project manager to it. The main deliverable of the initiation phase of a project is the charter, the project charter defines:

• Purpose of the project: a simple business statement about what the project is about
• Objectives: are clear an measurable statements as to the results of the project. When defining Objectives make sure that they meet the SMART criteria
• Specific & clearly stated
• Measurable or Quantifiable
• Achievable
• Relevent
• Time-bound
• Key requirements: List what is needed to achiece the objectives
• Main deliverables (Schedualed milestones): a schedual of what will be deliverd and when
• Resources Required: the things needed to deliver the project succesfully
• Budget
• Personnel
• Equipment
• Materials 
• Major Risks: what could prevent the project from being a success
• Schedule
• Budget
• Profitability 
• Technical
• Organizational
• External
• Key stakeholders & sponsers: people who are affected by the project and people who have influence over the project, at a minimum this will be the sponsor, the clients and the team. 
• Project Sign off: this is where the project signed off by the sponsor and PM and client

Stakeholders & Sponsors

Stakeholders 

Not all stakeholders have equal amounts of power or interest in a project, typically the two groups to focus your energy on are whoever is paying for the project, and the personnel who will be using the system.

It's fairly obvious that a you should establish a close relationship with all stakeholders on a project but most importantly those with power and interest, managing their expectations and interests is one of the main keys to a successful delivery.

Not only should stakeholders be identified in the Project charter, but they should also review and sign off on it, to ensure that everyone is on the same page as to what the objectives and deliverables are.

the expectations & requirements of all stakeholders along with their roles & responsibilities must be captured.

Project Sponsors

The project sponsor is usually a management level executive who is championing the project, it is this champion who's identified the financial and non financial benefits of the project and guided it into the project portfolio. This champion usually has a vested interest in the project and thus will be the main source of support for the PM. Usually the Project sponsor is the main stakeholder, the budget is provided by them they are where to go when resources are needed and often times the deciding factor as to what is being built.

The Project Organization

Different organizations have different structures, these differences in organization structure will translate into the organization of a project.

three types of organizational structures are

Functional: also known as traditional, hierarchical or vertical.

Organizations that utilize the Functional structure have a clear chain of command, typically if a project resides inside of a functional unit for example HR, that PM will generally report to the functional head and build the majority of their team from within that functional unit.

Pro's	Con's
Simple	Coordination between functions can be difficult
Direct Access to technical resources	Project can take a back seat to operations
Team members report to their boss

this structure is best when the project is contained within one functional area, since as a PM you'll be reporting to a functional head who's in charge of the personnel, money and scope you'll have very little power, you'll be more of a project coordinator than manager. You'll also be competing against operational priorities for resources. In this type of structure you'll have to rely heavily on soft skills to get what you need to be successful.

Pure Project Organization
this is the opposite of the functional organization, in the projectized organization the PM is the boss, is responsible for time, resources and scope. The personnel are 100% allocated to the project, the PM has full authority. In organizations that utilize the pure project approach to organization every endevour is temporary. Project work isn't organized by function but is rather allocated to a group of resources that come together to solve that particular unique problem.
In such an organization all of the team members report directly to the PM, and only work on their current project deliverables; this type of approach is ideal for multi year projects that require a dedicated team to solve a complex problem.

Pro's	Con's
PM has full authority, all members report to PM	Temporary all good things must come to an end
Simple structure don't have to negotiate for resources	Resources can't be shared, must keep team busy
Direct access to permanent resources allocated to your project	can create duplication
strong team identity and commitment, bonds form between colleagues

Matrix Organization
This organization structure tries to leverage the Pro's of both the functional and pure project organizations. In a matrix organization there are traditional functional units, but the projects will draw members from these functional units, but unlike the functional organization structure the resources are shared by the PM and the functional head, meaning that they have two bosses. Matrix organizations come in multiple flavors, ones that are considered weak will take on more of the traditional functional organization attributes whereas ones that are considered strong matrix organizations will take on more of the characteristics of the pure project organization.

the distinction of whether a matrix organization is considered

• Weak: functional head controls resources
• Balanced: functional head and PM share responsibility of resources
• Strong: PM controls resources

Pro's	Con's
Shared & flexible access to resources	Employees have two Bosses
Resources are project focused	Increased Conflict, employees have to balance operational with project work
Shared commitment between PM and functional head	Communication complexity

As you can see none of these approaches are perfect the trick is to pick the approach that best fits the particular project.

Project length: for projects that are cross-functional and run multiple years the preferred structure is pure project or strong matrix.

# of functional areas needed: when numerous functional areas are required to complete a project than the more valuable it is to use a strong matrix or pure project approach.

Functional knowledge is key: when the project is within a functional unit and the knowledge is very niche than a functional organization may be best suited.

Project Selection

Organizations generally don't have enough resources (people or money) to complete every project they'd like to, thus what they need to do is pick the projects that will have the highest Return on investment. The collection of projects that an organization considers key to it's success is referred to as a project-portfolio; this project-portfolio is a collection of projects that can realistically be completed in a timely fashion and help the organization achieve it's strategic goals, which are high level goals to benefit the company in the grand scheme.

Organizations generally have limited resources, more often than not they don't have enough resources to realistically complete every project they'd like to and thus they need some sort of logical way to select projects with the highest ROI; here are three financial selection processes:

Payback Period
This approach is a simple calculation: Payback period = (Initial investment)/(Periodic cash flow) this means that if our project cost $100 and our projected returns where $20 a year it would take 5 years for this project to break even on the investment, after that the project would begin to generate revenue for the organization. The downside of this approach is that it doesn't factor in the time value of money, meaning that because of inflation a $100 investment today is worth less in 5 years.

Net present value
Is a fairly straightforward calculation where
NPV = sum((ROI per year)/(1+discount value)^(Year Count)) - initial investment

so that means that if your project has an initial investment of $100
a projected ROI for year 1 of $20
a projected ROI for year 2 of $10
a projected ROI for year 3 of $25
a projected ROI for year 4 of $30
and a discount rate of 10%

npv = (20/(1+0.1)^1) + 10/(1+0.1)^2 + 25/(1+0.1)^3 + 30/(1+0.1)^4 - 100

npv = 20/1.1^1 + 10/1.1^2 + 25/1.1^3 + 30/1.1^4 - 100

npv = 20/1.1 + 10/1.21 + 25/1.331 + 30/ 1.4641 - 100

npv = 18.18 + 8.26 + 18.78 + 20.49 -100

npv = 65.71 - 100

npv = -34.29

NPV of 0: project will make enough money to meet the organizations needs
NPV of positive:project will surpass the requirements of the organization
NPV of Negative: project will fall short of the organizations requirements

Profitability index
is a simple ratio
PI = present value of future cash flows/Initial investment,

>1: financial benefits to organization
<1: financial drain to organization also the NPV will be 0.

these calculations are only as good as their estimates.

Numbers are great but sometimes cold hard numbers are trumped by non-financial criteria such as

• Legal requirements: to meet the requirements of a new law
• Competitive advantage: to beat the competition to market for example
• new tech or process: to facilitate earnings in the future.

organization use a combination of financial and non financial criteria to select projects for their portfolio. a typical project selection process maybe something like

1. Business plan identifies project opportunities aligned to the organization's strategy or an employee has an idea for a project and reviews it with their management team for concurrence to proceed and get allocated funding. 
2. Management submits project information on a standardized form. This form typically includes basic level business criteria such as the project goals and deliverables, project purpose, the business reason or business problem addressed by the project, and general information about the project cash outflow, inflow, and market potential. 
3. Project Portfolio team reviews the project suggestions and pre-selects projects based on a set of criteria that best matches the strategic plans of the organization. 
4. Projects undergo additional feasibility studies to confirm viability and confirm the financial and non-financial benefits. This typically includes a review of the project resource requirements. 
5. A final set of projects is prioritized and selected with Project Managers assigned to begin Project Initiation.

organizations will generally stick to their project selection process and not deviate from it. while reviewing the projects in their portfolio trying to ensure that only high value projects are committed to because the more projects an organization is committed to the fewer resources can be allocated to each and thus diluting the value added.

Project Management Office

The Project Management Office(PMO) or just Project Office (PO) is an internal unit that is sometimes set up by organizations to help facilitate project management. They're function is to increase the project success ration by providing support to projects and project managers.

The PMO can provide a wide variety for services

• Be responsible and support the organizations Project Management methodologies and processes.
• Provide Project management expertise and training
• Project auditing
• Support Organizations project management tools.
• Serve as a repository for Best practices 
• Provide standards for collecting project KPI's as well as reporting and measuring project progress
• Facilitate project reviews: lessons learned.
• Help allocate resources across multiple projects.
• Assist with project selection and Project portfolio management. 

PMO's often try to standardize the Project management approach within an organization, keep all PM's using constant PM techniques, tools, and processes. PMO's are responsible to support projects and project managers doing what they can to help increase the success rates of projects.

Initialization before instantiation

Are you telling me that I can initialize a class without running the default constructor? and why on earth would I want to do this?

the answer is yes you can and when you're unit testing.

Within the system.runtime.serialization namespace there's a static FormatterServices class with a GetUnitializedObject(Type) method, this method lets you create a new instance of an object without constructing it.

using System;

using System.Runtime.Serialization;

namespace pav.InitializationB4Instantiation

{

    class Dog 

    {

        string name;

        public string Name {

            get => name ?? "Spot";

            set => name = value;

        }

        public Dog() => Console.WriteLine($"Name: {Name}");

    }

    class Program

    {

        static void Main(string[] args)

        {

            //Create instance of dog without instantiating the object

            var dog = FormatterServices.GetUninitializedObject(typeof(Dog));

            //get an instance of the parameterless constructor of Dog

            var dogCtor = typeof(Dog).GetConstructor(Type.EmptyTypes);

            //Set the Name property to "Fluffy" 

            ((Dog)dog).Name = "Fluffy";

           

            //instantiate Dog

            dogCtor.Invoke(dog, null);

            //instantiate a default dog

            new Dog();

        }

    }

}

and this is what results

Obviously this is an extremely contrived example, but the take away is that you can modify the classes properties before "newing" up an instance of it which can be vary useful when unit testing code.

Xamarin's Command implementation of ICommand

When using Xamarin forms Command class which Implements the ICommand interface, there is one strange caveat to look out for, and that is that the CanExecute func must be declared within the constructor of the ViewModel or have a "Lazy" implementation otherwise it will never fire. What i mean is if you have the following xaml

<StackLayout Grid.Row="2" Orientation="Horizontal" Margin="10,5">

    <Entry Placeholder="Task name" Text="{Binding TaskName, Mode=TwoWay}"

        HorizontalOptions="FillAndExpand" />

    <Button Text="+" FontSize="Large" FontAttributes="Bold" WidthRequest="70"

        BackgroundColor="{StaticResource ContrastColor}"

        TextColor="{StaticResource Backgorund}"

        Command="{Binding AddTaskCommand}" />

</StackLayout>

and it's coupled with this codebehind

string taskName;

public string TaskName

{

    get => taskName;

    set

    {

        base.SetProperty(ref taskName, value);

        ((Command)AddTaskCommand).ChangeCanExecute();

    }

}

public ICommand AddTaskCommand { get => new Command(

    execute: () => TaskName = string.Empty,

    canExecute: () => true);

}

Then the canExecute func is evaluated on the initial page load and the execute action is executed whenever the command is called, however it is never called again, namely when the ChangeCanExecute method is called from the TaskName's setter the condition is never reevaluated and the add button remains in whatever state it was on the initial page load.

Let's add some logic into the can execute func

string taskName;

public string TaskName

{

    get => taskName;

    set

    {

        base.SetProperty(ref taskName, value);

        ((Command)AddTaskCommand).ChangeCanExecute();

    }

}

public ICommand AddTaskCommand

{

    get => new Command(

        execute: () => TaskName = string.Empty,

        canExecute: () => !String.IsNullOrEmpty(TaskName));

}

now under these conditions the "Add" button shall never become enabled. Now if we simply assign our command in the constructor of the view model everything works just fine.

string taskName;

public string TaskName {

    get => taskName;

    set {

        base.SetProperty(ref taskName, value);

        ((Command)AddTaskCommand).ChangeCanExecute();

    }

}

public ICommand AddTaskCommand { get; private set; }

public ProjectPageViewModel()

{

    AddTaskCommand = new Command(

        execute: () => TaskName = string.Empty,

        canExecute: () => !String.IsNullOrEmpty(TaskName));

}

bizarre yes, why you may ask? well a kind soul pointed it out to me that in the above implementation every single time you call the AddTaskCommand you receive a new instance of the Command implementation, which is why it works when you assign it in your constructor but not when you define it inline. So another alternative to defining all your Commands in your constructor is to use a backing field for the AddTaskCommand property and use a lazy implementation for your commands.

string taskName;

public string TaskName

{

    get => taskName;

    set {

        base.SetProperty(ref taskName, value);

        ((Command)AddTaskCommand).ChangeCanExecute();

    }

}

ICommand addTaskCommand = null;

public ICommand AddTaskCommand {

    get {

        this.addTaskCommand = this.addTaskCommand ?? new Command(

            execute: () => TaskName = string.Empty,

            canExecute: () => !String.IsNullOrEmpty(TaskName));

        return addTaskCommand;

    }

}

in the above we check if the addTaskCommand backing field is null, if yes then we assign an instance of command to it, if not then we just return it, this keeps us from having to define all of our commands within the constructor.