Project Management curriculum

NASA's handbook gives a project defined requirements, a life-cycle cost, a beginning and an end. Operations keep running: OMB reviews an operating asset through operational analysis of its ongoing performance, asking how costs could fall and whether the function should continue at all. Ask whether the work stops once a defined result exists.

NASA treats a project as a specific investment with its own life-cycle cost, and a program as a strategic investment that initiates and directs one or more projects. A portfolio sits above both. OMB says it covers selecting, prioritizing and monitoring the work, not managing each item, and aims to maximize return at an acceptable level of risk.

In a waterfall plan, requirements, design, development and testing run one after another. In agile they run together inside small iterations, with frequent reviews and customer feedback, so working software reaches users early enough to change course. Iteration is not a license to skip planning: GAO's comparison assumes high-level planning happens under both.

GAO records an official saying that a mix of iterative and waterfall guidance added confusion among teams. Elsewhere a program office told its agile contractor to plan out all work across builds, which GAO called inefficient in agile. Decide which parts run which way and who holds that line, or the mix happens by accident.

At a NASA Key Decision Point, a Decision Authority determines whether and how the work proceeds, approves or disapproves entry to the next phase, and authorizes the cost, schedule and content that govern what follows. The life-cycle review before it informs that decision but does not make it, so passing a review is not the same as passing the gate.

One survey found that the structures, roles and functions of these offices vary significantly, and researchers still lack an agreed definition. One study lists strategic project management, monitoring and controlling performance, building methods and competency, managing many projects, and supporting learning. You may also see labels such as supportive, controlling and directive. Read what an office actually does before you assume its authority.

A matrix adds a second line of authority, so each person reports to a functional manager and also to another manager, typically for a program or project. That can improve information exchange but can also create role conflict and ambiguity. A balanced matrix, where neither manager dominates, is the one most prone to power struggles. OMB's integrated project team instead has dedicated members responsible to the program manager.

The Iron Triangle usually means time, cost and quality or scope, and the labels vary by author. The sides trade against each other. GAO's cost guide shows it on an estimating team: to compress the schedule you need more resources, without them the scope must shrink, and with too little time the team may not reach the quality the work needs.

NASA encourages teams to drop requirements that do not contribute to mission success, and to combine documents on smaller projects. Dropping one is not a private decision: it takes permission from the requirement's owner, and requirements imposed by federal law or outside bodies generally cannot be waived.

OMB asks a team to find as many alternative solutions as it can, then compare them with benefit-cost analysis: discounted expected benefits less discounted expected costs. The case must document the specific performance measures it affects. Writing the need too narrowly shrinks the choice before the comparison even starts.

OMB says the program manager should get a written charter defining the team's responsibilities, budget constraints and the extent of authority and accountability. It is updated as needed, at least at the start of each phase. For in-house work it stands in for the contract, and the same management rigor still applies.

Finishing on budget does not prove the benefits arrived. OMB's post-implementation review asks how accurately an investment meets its objectives and expected benefits, and operational analysis keeps checking the asset once it runs. Feeding those lessons back lowers the risk of repeating past mistakes on the next project.

One framework separates project management success, which covers meeting time, cost and quality objectives, from product success, which covers the owner's strategic objectives and users' needs. Surveys of information systems projects still lean on the first. NASA turns expectations into measures of effectiveness and gets stakeholder commitment early, so you can define both tests before work starts.

Tailoring can remove a project's internal requirements, but NASA says requirements imposed by federal law or outside bodies generally cannot be waived. Treat them as fixed from the first day. DOE also lists regulatory and statutory changes among risks outside a project's control, so a rule can move mid-project and belongs on your risk list.

A new system is meant to help the people who use it work better. OMB calls that goal seemingly self-evident yet often missed, for example when systems get built by technology or finance specialists alone. It wants work processes simplified or redesigned before alternatives are sought, so you do not buy a tool for a broken process.

DoD calls these business or external risks: they generally start outside the program office or beyond the manager's control, from regulations and suppliers to market factors. DOE tells teams to address them anyway, including funding reductions and stakeholder changes, and DoD says to elevate the ones you cannot control to the next level.

NASA defines a stakeholder as any group or individual affected by or having a stake in the project. Customers and users are usually easy to spot. Other key stakeholders are harder to find and change with the phase, so keep the list open. EPA suggests asking the stakeholders you already know who else you should talk to.

Rate each stakeholder high or low on power and on interest, and you get four groups: key players, high-power allies with low interest, supporters with low power, and those you monitor. One health-policy study built its grid as a prioritization tool, not a measurement scale. There, many high-power government bodies had little documented engagement, so high power did not mean active involvement.

Decide first how much influence on the decision you are actually offering. EPA warns that agencies often promise more than is possible, and stakeholders who expected a say leave dissatisfied however many activities you ran. Activity count and real influence are different things, so plan each activity around the influence you can deliver.

NASA's program communications plan, written with public engagement in mind, names goals and key messages, target audiences and stakeholders, the products and tools used, milestones and resources, and metrics for success. Without the metrics you can report that messages went out but not whether they achieved what you wanted.

GAO notes the perception that bad news about a contract could put a program and its management in jeopardy, which makes an honest cost forecast hard to choose. Yet it treats variances as normal, since all programs carry risk, and as essential information for managers. Report the forecast and open risks alongside work done, measured against the baseline, so there is still time to respond.

NASA has stakeholders commit to a validated, baselined set of expectations, then assesses each change request for its impact on the rest of the system, comparing that with the risk of leaving the change out. That gives you a neutral answer to a new ask: what it adds, what it costs and what skipping it risks, instead of a personal yes or no.

Servant leadership puts serving followers and other stakeholders ahead of organizational performance goals. In practice that means listening, letting people decide and holding them accountable, and supporting their growth. It is not a free win: one study found the benefits are not equally available to all leaders, because gender stereotypes changed how identical behaviors were judged.

A team charter is written and agreed by the members to set ground rules and clarify direction, ideally when the team forms, and studies link it to better satisfaction, commitment and performance. Do not confuse it with the project charter, which OMB uses to set out the program manager's authority rather than how members work together.

Each stage has a recognizable feel. People meet and set goals in forming, grow uncomfortable in storming, settle norms and boundaries in norming, and manage daily work themselves in performing, where the leader mostly monitors progress. Do not try to skip the discomfort: one capstone study says long, high-stakes groups have to work through storming to find their norms.

Maslow arranges needs in a hierarchy, with people moving toward higher needs as lower ones are met. Herzberg splits motivators, tied to job satisfaction, from hygiene factors, tied to dissatisfaction. Test them in your setting: a cross-sectional study in Saudi Arabia's public sector found Herzberg's boundary did not hold there.

The Thomas-Kilmann model places five styles on two axes, assertiveness and cooperativeness: competing, collaborating, compromising, avoiding and accommodating. Other lists use words such as forcing, withdrawing and smoothing. Collaborating looks for a result that satisfies both sides, while compromising only partly meets each. Participants in one study stressed that context shapes which style to use.

Positional bargaining can work for a simple, low-stakes deal but does not put the ongoing relationship first. Interest-based negotiation has parties with competing goals work toward a mutually beneficial agreement. One paper recommends it for high-stakes settings, writing about crews on long space missions, and calls it learnable with practice. It may fit a project where you keep working with the same people, though that setting was not tested.

One model has four branches: perceiving, using, understanding and managing emotion, in yourself and others. Across 156 leader-member pairs in Chinese construction teams, project managers' scores were positively related to team effectiveness, with cohesion carrying the effect. That is a survey in one industry, not proof that raising a score improves a team.

Trust tends to build more slowly on purely virtual platforms, and you lose body language and other subtle cues. One guide for mentors advises saving agenda time for personal connection, looking for face-to-face contact when you are not on video, and having the team write its own charter covering virtual meeting behavior and when to email or call.

Directive coaching involves more leading, while non-directive coaching supports others to lead. Non-directive is widely accepted as the desired practice between people, though the debate is open: one chatbot study saw users rate the directive style higher. Mentoring emphasizes guidance and support. All three differ from assigning tasks.

Give a decision to the person best placed to make it, with authority to match. GAO says an empowered product owner should prioritize detailed requirements, though only a contracting officer can modify the contract. Empowerment can cost something too: one study of Generation Z knowledge workers treats it as a possible burden as well as a support.

OPM's roadmap for supervisors calls for monthly, or at minimum quarterly, check-ins instead of relying only on annual reviews. Feedback should reinforce as well as correct, and it should run both ways. Frequent check-ins let you raise a problem while the plan can still change, so the formal review is less likely to surprise anyone.

A needs assessment starts from the performance required, then identifies the knowledge and skills needed to reach it, so resources go where demand is greatest. Ask why the work is not being done now before you book a course. OPM warns that training is sometimes not the best solution, and other management fixes may close the gap.

Start by spending time with current and prospective users, and mix qualitative and quantitative research to learn their goals, needs and behaviors. Then test prototypes with real people, in the field if you can. NASA adds a second source: other interested parties, such as Congress, who set broad constraints within which the customer's needs must be met.

NASA asks for traceability both ways: from each requirement up to its parent and down to its allocated children, on through design documents and test plans. A requirement with no parent gets flagged as self-derived and needs concurrence from the level above. One GAO case records a division calling traceability critical to avoiding scope creep.

Exclusions belong on the page alongside deliverables. GAO says even an evolving technical baseline should clearly state which requirements are included and which are excluded, because undefined requirements can lead to cost increases and delays. Without that line, nothing on paper settles what each party assumed.

GAO describes a product-oriented hierarchy whose lowest level is the work package. Each parent must equal the sum of its children, a rule you may see labeled the 100 percent rule, and each child has only one parent, so costs are not counted twice. Smaller pieces also make it easier to plan, schedule and assign responsibility.

Requirements creep is growth so gradual it is hard to see. NASA says changes often turn out to be enhancements in disguise, though some are real new needs you cannot ignore. OMB warns of specification creep toward what would be nice to have: meet the core requirements first and add extras later if they are cost-beneficial. You may also see the label gold plating for additions like these.

Acceptance asks whether a deliverable is done: in agile, the product owner accepts a user story as complete, and GAO warns that this alone does not prove adequate testing. Control manages changes to the requirements baseline and assesses each change request. Keep both apart from NASA's pairing, where verification proves compliance with requirements and validation shows the product serves its intended purpose.

The product owner ranks user stories by business value, weighing customer needs, stakeholder priorities, risk, dependencies and expected return, and teams pull work from the top. Refinement continues throughout. Lose the trace between backlog levels and you can overlook stories that are critical to the program.

Acceptance criteria set the boundaries of one story. The definition of done covers what else must finish before release, such as testing, documentation and training material. Agree on it before development, with one shared version across teams. GAO says leaving it unclear lets uncertainty into the work, and definitions of done get more comprehensive as teams mature.

Most links should be finish-to-start, because they are easy to trace. Start-to-start and finish-to-finish model overlap, but overuse can signal an optimistic schedule. GAO calls start-to-finish theoretical and discourages it. A lag adds waiting time with no resources, and a lead, a negative lag, assumes foresight, so splitting the activity usually works better.

Engineering or hard logic must hold whatever anyone prefers, as when concrete must be poured before it can cure. Preferential or soft logic is management's chosen order and is not strictly necessary. That is where you have room to reorder work, though changing it after baselining may fall under schedule change control.

An analogy adjusts the actual figure from one similar effort, so its value depends on a strong parallel. A parametric estimate fits a statistical relationship across many past efforts, so it depends on how valid that relationship is. Three-point estimates capture uncertainty and bias rather than one number. Estimate under normal conditions, without padding.

The forward pass adds durations to early starts, and the backward pass subtracts durations from late finishes. The difference between early and late dates is float. With no date constraints, critical activities have zero float, so each day of slip moves the finish a day. If the network logic is wrong, the software reports the wrong path.

An activity can have total float with no free float: it can slip without moving the finish date yet still push its immediate successor. Negative total float means a constrained date falls earlier than the logic allows, so time must be recovered. Total float is shared along a path, so it is not contingency one activity can claim.

Two ways to compress a schedule are adding people and overlapping work. Adding people costs money and assumes they are free at short notice. Overlapping assumes the later activity does not depend on the earlier one finishing, and that enough people can cover both. Only shortening the critical path shortens the program, so aim at long critical activities. You may see the labels crashing and fast tracking.

A milestone has no duration and uses no resources, and too many can hide the work that threatens them. The baseline records the commitment to stakeholders, while the current schedule is the latest forecast, and comparing them shows variance. Rebaselining normally wipes out historical variances and should be rare.

Velocity commonly counts story points finished per iteration. It belongs to one team, so do not use it to compare teams or dictate workload. Inflating the point estimates raises velocity with no added value. A burn-down chart plots the work remaining over time, and a burn-up plots the work accomplished.

Leveling shifts start dates or reassigns work to fit availability, typically delaying activities with the most free float and the fewest resources. GAO wants it limited to absorbing available float; if the end date moves, resources have become an unavoidable constraint and you need a different plan. You may also see the label resource smoothing.

GAO treats a rough order of magnitude estimate as a fast, top-level figure that might take only days. Building a budget-quality estimate for the first time would likely run to many months, since more detail generally calls for a bigger team, more effort and more rigorous techniques. Before you reuse a rough figure, ask how much of that work stands behind it.

In its cost guide, GAO holds contingency at or above the program office for unknown unknowns, and treats management reserve as contractor-managed budget for known unknowns in the contract. GAO says other organizations may use the terms differently, so definitions vary. DOE warns that using the words interchangeably creates confusion about who is accountable, so check which definitions apply.

Planned value is the budget for work scheduled so far, earned value the budget for work actually completed, and actual cost what you recorded spending. GAO's terms for them are BCWS, BCWP and ACWP. Earned value is what makes the other two comparable, because it measures finished work at its planned cost, not time spent.

Cost variance is earned value minus actual cost, and schedule variance is earned value minus planned value. CPI and SPI divide instead of subtract. Plan 200, earn 150, spend 180, and you get CV of -30, SV of -50, CPI near 0.83 and SPI of 0.75, all unfavorable. SV is in dollars, so check whether the delay touches the critical path.

Most index-based forecasts take actual cost plus remaining work divided by an efficiency index, so the index you pick is your assumption about the future. Cumulative CPI assumes the same efficiency to the end and typically gives the lowest figure. The best predictor changes with percent complete, and a bottom-up estimate is the other route.

TCPI divides the budgeted cost of the remaining work by the money left, measured against either the budget at completion or a current estimate, which gives the efficiency the rest of the work must reach. GAO's test is to compare it with CPI: a TCPI much higher than CPI should send you asking whether that gain is even possible, and the forecast may be too optimistic.

A life cycle estimate covers developing, producing, operating, maintaining and disposing of a program, including sunk costs. The split varies by system: GAO notes that aircraft, ships and information systems often carry support costs large next to their development and investment costs. Comparing options on build cost alone can favor the wrong one.

Cost-of-quality models split spending into prevention, appraisal and failure, and predict that more of the first two brings lower failure and total costs. In a pilot of five food companies, higher prevention and appraisal spending went with a more mature safety culture, but three could not specify all failure costs. Measure yours before you trust the model.

USGS sums it up as defect prevention versus defect detection. EPA treats assurance as the management system of planning, training, assessment and improvement that makes the output fit for use, with control as one part inside it. Control is the technical work of measuring a process or item against set criteria, such as calibrations and check samples. So a passed check does not stand in for the rest of the system.

A fishbone sorts possible causes by category, and CMS warns against stating the problem as a solution. A Pareto chart ranks factors by frequency. A histogram shows center, spread and skew. A control chart tracks a measure over time, and a point outside its limits sends you looking for an assignable cause.

NASA works in layers: measures of effectiveness state what the customer needs and can be qualitative, measures of performance turn those into quantitative terms, and technical performance measures are tracked against expected values to catch deficiencies. GAO adds, for agile work, that metrics should be set early and geared toward outcomes and customer needs.

A retrospective closes each iteration with a look at how the team can improve its process and how it works together. Plan-Do-Study-Act gives you a loop for testing a change, and AHRQ advises a single step, a short duration and a small sample. Small tests show quickly whether a change works before it spreads.

Limiting identification to managers can miss risks, so DoD wants everyone on the team contributing, continuously. Draw on lessons learned, similar projects and experts, using brainstorming or interviews, and include risks you cannot control. A premortem assumes the effort failed and asks people to work out why, then suggest fixes.

A matrix combines probability and consequence into a low, moderate or high rating, which DOE calls a judgment of relative risk. DoD warns against scores like 3.4, because the scale is ordinal and a decimal implies fidelity that is not there. And when the likelihood reaches 100 percent, you are holding an issue.

Expected monetary value multiplies each outcome by its probability, so a 30 percent chance of a 70,000 overrun counts as 21,000. A decision tree compares options on that figure and favors the best one. Across a whole project, DOE models the combined risks with Monte Carlo simulation rather than summing individual expected values.

Avoiding takes a different path that removes the source. Transferring needs the receiver to acknowledge it owns the risk, and you still monitor it. Mitigating lowers likelihood or consequence, but DoD warns against defaulting to it. Accepting still means tracking the risk and knowing what you would need. Relabeling planned work as a response is acceptance in disguise.

DOE mirrors threat responses: to exploit is to try to ensure the opportunity happens, to enhance raises its likelihood or benefit, and to share splits it among parties, as an incentive contract does with savings. Do not spend more enhancing it than it would save. DoD's version is simpler: pursue it, reevaluate it or reject it.

A risk owner manages one risk from identification to closeout and checks that responses are developed and carried out. A trigger is the event or pre-step showing the risk may be about to occur, recorded when the risk is logged, with a date for monitoring. Watching it buys you time to prepare the response and confirm the money and time for it.

Risk work spends money to lower the odds or effect of an uncertain event, while issue work deals with something that has happened or is certain to. DoD says programs sometimes write an issue in future, uncertain terms, which sends it down the wrong process. Check whether a live issue creates new risks of its own.

A simulation produces an S curve of possible costs, and GAO calculates contingency as the gap between the point estimate and the confidence level you choose, so higher confidence means more money. GAO says that without this analysis you cannot defend the amount. DOE adds that planned responses go in direct cost; only those awaiting a trigger belong in contingency. Reserve definitions vary, so check whose terms apply.

A make item is work the prime contractor or its affiliates do themselves. Under the Federal Acquisition Regulation (FAR), the prime is responsible for placing subcontracts so as to reach the lowest overall cost and technical risk, and where a make-or-buy program is required the government may review it. OMB asks a prior question: should this organization do the function at all, or can another source support it better?

Under firm-fixed-price the contractor carries maximum risk and has the strongest incentive to control cost. Under cost-plus-fixed-fee the fee does not move with actual cost, so the incentive is minimal, and the type suits work of unknown effort such as research. Time-and-materials pays hourly rates plus material cost and offers no positive profit incentive, so FAR calls for appropriate surveillance.

For performance-based service contracts, FAR wants work described by required results, not how to do it or how many hours to supply, with measurable standards and a way to assess performance. Any incentives must match those standards. A vague statement leaves you nothing objective to hold the contractor to, however clear the intent felt when it was written.

In negotiated federal buys, FAR bases award on factors tailored to the purchase that allow real comparison between proposals. Price or cost is evaluated in every source selection, with limited exceptions, and quality is addressed through factors such as past performance. Conflict-of-interest rules aim to stop conflicting roles from biasing a contractor's judgment and to prevent unfair competitive advantage.

In US federal contracting, only a contracting officer can modify a contract. Others must not direct work that should be a modification, or act as if they can bind the government. A claim that cannot be settled by agreement leads to the contracting officer's written decision, citing contract terms and facts, which the contractor may appeal. Use that channel rather than relying on a hallway agreement.

A kickoff gets everyone reading the same requirements and brings problems you can already foresee into the open. The federal contract version, a postaward orientation, shows the limit: it builds mutual understanding, but it cannot rewrite the agreement already reached. If the meeting exposes a scope gap, route it through change control rather than settling it in the room.

A change request gets logged, reviewed and sent to a board that weighs cost, performance, program and safety impacts, and only approved changes are carried out. A change touching an external interface needs every affected stakeholder's approval. Then update the baseline and release the decision: version and archive the approved schedule, so status traces back to it and everyone works from the same one.

Change control answers one question: should this baseline change? Configuration management is the wider discipline that decides what sits under control, tracks every change to it and audits the result, so you can see a true picture of the product. Numbering versions helps you trace status to a baseline, but a version number alone never decides whether a change was justified.

A risk might happen; an issue already has, or certainly will, so the only open question is how to deal with the consequence. Record each one in an issue register with a handling choice, such as accepting the consequence or mitigating it, and work it to closure. Then check whether the fix leaves residual risk, which may deserve its own entry as a formal risk.

Project knowledge needs a planned route to whoever runs the work next. One federal migration playbook has the project team transfer knowledge to the operations and maintenance team as part of closeout, and keeps job aids, procedures and FAQs handy for staff afterward. Written reasoning matters too: good documentation lets someone rebuild an estimate once its original authors have gone.

Acceptance is a formal acknowledgment that what arrived conforms to the agreed quality and quantity, which is more than proof of delivery. Federal contract rules allow it before, at or after delivery, but it ordinarily waits until quality checks finish. On an agile team the product owner plays this part by defining acceptance criteria and ruling on whether they were met.

Closing a project is a checklist, and the last deliverable only starts it. Federal contract closeout begins after evidence of physical completion, then settles items such as disallowed costs, subcontracts and the final invoice before releasing excess funds. On the project side, you compare results with the baseline, archive actual costs, transfer knowledge and off-board the team.

A lesson helps only if it gets recorded and someone reuses it, so NASA expects a technical plan to say how lessons will be recorded and to draw on earlier ones. One federal playbook asks stakeholders what went well, what went wrong and what could be improved, then presents a written report. Agile teams also run a retrospective each iteration, because an end-of-project review can only help the next project.

The product owner speaks for the customer, ranks the requirements, sets acceptance criteria and rules on them. The development team organizes itself and decides how the work gets done. The team facilitator, whom Scrum calls the scrum master, runs meetings and guides the group while staying out of the discussion. Watch the product owner's load: the more teams one person covers, the less time each team gets, and the role weakens.

A sprint is a time-boxed iteration with recurring meetings: sprint planning, a daily stand-up on progress and impediments, a demonstration of working software, and a retrospective. Do not merge the last two. The demonstration asks whether the team is building the right product, while the retrospective asks how the team could work better next time.

Kanban has no fixed iterations. It shows the flow of work on a board and limits work in progress to raise throughput, while the team pulls items from a ranked backlog. Keep the two clocks apart. Cycle time starts when work on an item begins, while lead time starts when the item is identified, so a long queue inflates lead time even if cycle time looks healthy.

Test a story against INVEST: independent, negotiable, valuable, estimable, small enough for one iteration, and testable. A story that fails a letter may need rewording or a rewrite. Acceptance criteria are what make testable real, so settle them before development starts; the product owner defines them and later judges whether the finished work meets them.

With relative estimation you compare a new story with work of similar size and complexity, then refine estimates as history builds. The resulting velocity belongs to one team, so comparing it across teams, or using it to dictate how much a team must finish, misreads it. Skip the comparison with past work and you risk misjudging both complexity and time.

A minimum viable product is a working version built to learn from customers with the least effort, which makes it an experiment rather than a trimmed-down final release. Build too little and it fails, because it pays off only if customers can interact with it and respond. The timing principle sits underneath: the longer customers wait for working software after a need appears, the greater the program's risk.

The daily stand-up surfaces what is blocking the team's goals for the iteration, so those blocks can be removed. Managers may sit in and consider how to help, but the meeting should not turn into a status report for them, which also makes it run long. It is not a problem-solving session either: use it to decide which conversations need to happen that day.

Responsible people do the work, and there can be several. The Accountable person, and there is only one, approves the finished work, so the buck stops there. Consulted people give input before sign-off, while Informed people only receive updates. A US health department lessons-learned note calls a single Accountable person a requirement for success, and suggests drafting the chart during planning so staffing gaps show early.

Planning on a named expert is not the same as having one. Leveling a schedule shows which critical resources would delay the finish if they were missing, and managers then try to secure them by hiring help or negotiating vacation dates. One federal playbook also advises keeping key personnel throughout and formalizing experts' participation in a memorandum of understanding.

Capacity planning compares what the schedule demands with who is actually available. When people are overallocated, resource leveling shifts activity starts or work assignments, and that can change the end date, since availability now drives it alongside logic. Avoid hiding the conflict behind extra logic links, because the forced sequence stays even after more people arrive.

Plan a person's exit as deliberately as their arrival. A resource management plan should cover off-boarding as well as on-boarding, and it needs updating as the program's needs change. Before people roll off, get what they know into shared knowledge tools and pass it to the team taking over the work.

Materials, facilities and equipment belong in the schedule beside labor, because you need to know whether they will be available when the work needs them. Assign budgets to them as well, so the total cost to finish is visible. Include items you do not control, such as equipment another party must furnish, as scheduled receipts.

It is the budget at completion minus the estimate at completion, so a negative value means you now expect to overrun. Unlike cost variance to date, it rests on a forecast, which makes it only as credible as the estimate behind it. On one major program GAO found contractor estimates running optimistic against their own history, so test the forecast before trusting the variance.

Index-based estimates add actual cost so far to the remaining budgeted work divided by an efficiency index, and that index is the assumption. The cumulative cost performance index assumes today's efficiency continues and usually gives the lowest figure, recent averages weight current performance more, and multiplying cost and schedule indexes assumes schedule also drives cost. Validate the data first.

A single month's index says where you stand, while the line across months says where you are heading. With monthly reporting a trend takes at least three data points, so a six-month project may be half over before one appears. Plot current and cumulative values together and track management reserve use, which gives you a fuller view of status.

A single finish date hides how uncertain each activity is. Simulation draws a duration for each activity from its probability distribution, recalculates the critical path and dates, and repeats thousands of times, giving you a distribution of outcomes rather than one number. It also shows the compound effect of parallel paths and how much contingency the schedule may need.

Network logic alone can ignore who is actually free. The path driven by both logic and resource availability, called the resource critical path or critical chain, is a more realistic model of the shortest possible duration. Estimate durations under most likely conditions with no hidden padding, then show margin as separate contingency activities so management can monitor it.

Near-critical activities have nearly as little total float as the critical path, so a small slip can make them critical. Several such paths add up: each additional path into a milestone lowers the chance of hitting it on time. Monitor them against a float threshold scaled to the program, since a slip that matters on a short schedule may be noise on a multiyear one.

Aim recovery at critical work, because only shortening the critical paths shortens the program. Adding workers can cut an activity's duration, but you pay for the labor and need people free at short notice. Overtime adds a higher labor rate. Overlapping activities works only where the logic allows, and it stacks demand: two tasks needing two carpenters each now need four. You may see the labels crashing and fast tracking.

A definition of ready states how much detail a story needs before work begins, such as an estimate and acceptance criteria. Think of it as the entry check, with the definition of done as the exit check. Because requirements keep evolving, it keeps the team on current, highly ranked work; without clear definitions, effort can drift to requirements that rank lower.

Some stories resist estimating because of an open design question or a technical challenge the team has not met before. A spike, a term from eXtreme Programming, holds a place in the backlog for that research, so the team can then size the real story with more confidence. Its product is understanding, while the feature itself still sits in the story it supports.

Whatever format you pick, the job stays the same: the team reflects on what went well and what to improve in the next iteration, and the team itself decides and implements the findings. Put action items in the backlog as stories so their completion gets tracked. Skip retrospectives and the team may never improve how it works, which can cost timely delivery.

An information radiator is a highly visible, easily accessible display of performance data, whether a whiteboard or a screen, that can improve communication among staff and stakeholders. A burn-up chart plots work completed over time, and a burn-down chart plots what remains. Its usefulness depends on the data, so review what is displayed before decisions rest on it.

When many teams share one product, frameworks supply the shared rules. GAO's 2023 Agile guide describes the Scaled Agile Framework as a governance model for aligning modest to large numbers of teams, with guidance on roles, inputs and processes up through portfolios. It adds that a scaling approach might include a pilot to discover problems and fold in lessons before full adoption.

Treat the plan as the rulebook: one federal playbook lists schedule, scope, risk, acquisition, cost, communications and quality in it. Working records sit apart and change far more often. That playbook updates its log of risks, actions, issues and decisions biweekly during an early phase, yet revises the risk management plan only as needed, so keep the two from blurring.

A gate asks whether the project is ready for the next phase, and the answer need not be a plain yes or no. At NASA's Key Decision Points, a decision authority can let work proceed with conditions to clear in an agreed time, let a project retry after fixing its shortfalls, or end it. Review results against entrance and success criteria feed that call.

Finishing the project does not deliver the benefit, so someone must own the outcome after the team leaves. Set metrics with baselines and targets at the start, compare results at completion, and hand oversight to an operations governance group that reviews its plan at least yearly. Set expectations about timing too, since savings can lag and costs may look higher during stabilization.

Recheck fit during execution, not only at approval. Federal auditors at GAO warn that if a program's approved goals do not align with IT and business goals, lower-level decisions risk drifting out of line as well, and they point to road maps and product portfolios as sources of objective measures. Portfolio review also asks whether the whole set stays affordable or some programs should be restructured or canceled.

Program-level measures should tie to program objectives and carry baselines and targets from early on. Under the right circumstances, dashboards can show management consistent data across programs, but not every number travels: velocity belongs to one team, so ranking teams by it misleads. Management should let programs tailor the metric set to meet organizational needs while limiting unnecessary work.

Settle who can decide what, and how a risk or issue moves up, before anything goes wrong. One federal playbook writes escalation procedures into its governance plan and pushes decisions to the lowest possible level, while leaving a route up for important or contentious issues. It also trains the team to escalate effectively, because a path nobody knows how to use will not help.

A message sent is not a message understood, so build in ways to catch the gap. Agreeing on shared terms early removes one source of confusion. A communications plan names audience, purpose, delivery method and timing, and a feedback mechanism gives stakeholders a route to respond. Frequent, multi-directional communication raises the odds that most people actually receive the message.

NASA defines inspection as a visual examination of a realized end product, suited to physical features such as a required marking, and it can extend to drawings and records. Its configuration audits ask a wider question, reviewing documents, products, records, procedures and processes to verify the product met its requirements and its design is documented. So the split is scope, not paper versus product.

A gate works only if its criteria exist in advance and it can really say no. Set entry and success criteria for each review ahead of time and make them measurable. Federal migration guidance sets go/no-go criteria across program, systems, workforce and operations, and it calls for a contingency plan, which makes a no-go decision or rollback a usable answer.

A risk register is a snapshot, so re-score on a schedule. Check likelihood and consequence at regular updates, and scan for new risks when program strategy shifts. When you retire a risk, document it, so a relapse does not go unnoticed. Keep a line open to management so you can tell them when handling has stopped working.

A workaround is a warning sign even when the work still gets done. A 2015 Defense Department guide's consequence criteria place work-arounds needed to achieve mission tasks beside a moderate reduction in technical performance, not at the bottom of its scale. So log it the way you would an issue: record what happened and how you handled it, then assess what residual risk remains.

Plan near-term work in detail and hold distant work in summarized planning packages, adding detail as you learn more. Program managers set the detail window by size, phase, scope, risk and complexity. It is no license for a partial plan: packages must still be defined and estimated as well as possible, and they stay in the schedule logic with budgets attached.

An assumption is a judgment treated as true without proof, used when no firm ground rule exists, while a ground rule is an agreed standard. Log and brief each assumption, because rejecting even one can ripple through an estimate. As facts arrive, replace assumptions with them, and uncertainty falls.

The work breakdown structure splits scope into a hierarchy of elements, and GAO's cost guide treats organizing them around products, not functional activities, as best practice. Its dictionary says in brief narrative what work each element includes and how it relates to the element above, so the relationships stay clear. With minor changes and additions, the dictionary can even become a statement of work.

Many agile methods sort stories as must have, should have, could have or won't have, known as MoSCoW, to rank the backlog by value. Without clear priorities, developers may build features customers do not count as must-haves, which can add to cost and schedule overruns. A usage target set beforehand gives you a benchmark after deployment for whether what you ranked is really used.

Padding buries risk inside each estimate, where nobody can see or manage it. Estimate at most likely conditions and hold risk openly instead, running schedule contingency through change control so its use stays traceable. GAO's cost guide keeps contingency for unknown unknowns outside the contractor's control and management reserve for known unknowns within contract scope. Many project frameworks swap those labels, so check which one applies.

Work you do not control still drives your dates, so put deliverables and services from other programs in your schedule and link giver and receiver milestones between schedules. Missing logic lets teams misunderstand what each side owes. Review external dependencies on a set rhythm with the programs involved, because a broken link can leave the critical path without credibility.

When people report elsewhere, you cannot assign their work, so influence has to come from somewhere else. A later paper describes a three-year ethnography of one inter-organizational research team: informal leaders who shared expertise often swayed it more than formal ones, and influence fell quickly once someone put personal interests first. That is one team, not a law. In practice, seek buy-in early and put commitments in writing.

Tailor recognition to the person and give it close to the moment. The federal personnel office tells supervisors to customize it, since one person may prefer public praise and another private thanks, and not to save it for annual reviews. Spot awards or real-time recognition reinforce a behavior close to when it happened.

Hard feedback lands better when it is not the first feedback. The federal personnel office advises giving constructive, actionable feedback regularly so assessments hold no surprises, and looking for the root cause first, such as a skill gap, motivation or role mismatch. Make the regular feedback reinforcing as well as corrective, so a conversation with you does not always signal bad news.

Pick the decision mode before pressure arrives; one federal note on program evaluations says decisions there often must be rapid and rest on limited input. A named lead can gather views by a deadline and then decide. One survey paper on shared leadership suggests delegating to the most knowledgeable person in an area. Self-organizing agile teams sit at the other end, collectively deciding how the work gets done.

Adding or losing people mid-project changes the plan, not just the roster. Keep the resource plan current as staff come and go, and try to hold key personnel steady. Train newcomers when they join, not only at launch. Track subject matter experts by name, since the absence of one can delay an activity on its own.

Across time zones someone always gets the inconvenient hour, so decide openly who it is. One analysis of global health calls warns that scheduling for the organizer's convenience can compromise participation and well-being, and describes rotating slots so the burden is shared. Repeating a call at several times trades away whole-group discussion; a shared chat space can help between meetings.

Activity is not outcome. Federal auditors at GAO note that 80 percent complete on a five-day task can look almost finished even when the team has left the difficult work for last, and that this subjectivity worsens on long activities. So report remaining work and finished results instead of effort. Agile principles go further, ranking working software above other signs of progress.

A dashboard should help the team, leaders and the sponsor understand progress, so choose metrics with that audience in mind. NASA summarizes a project's technical measures with red, yellow and green alert zones, which mean something only when the numbers behind them hold up. Review what is displayed: one official told GAO that teams grew frustrated by negative statistics under oversight not adjusted to agile work.

Programs rarely run exactly to plan, so a variance alone is not a verdict. A threshold defines the acceptable range, and crossing it triggers inspection of the cause and a choice of action. Review thresholds periodically or they stop showing real problems. Tie award fees to reported variances and contractors may overstate performance or change the baseline to stay inside them.

A forecast is honest only if it moves when the facts do. Update the estimate as requirements change and at major milestones, reconcile it with the budget, and record why the numbers moved. Review earned value data at least monthly. Be suspicious of an estimate at completion that sits below what past performance supports, a pattern federal auditors at GAO have found on a major program.

Cost and schedule tell you whether you delivered, not whether it helped. Set metrics with baselines and targets at the start, then watch early signals such as feature usage against a target set beforehand; low use suggests effort went to the wrong place, unless the feature is critical but rarely needed. Keep savings expectations realistic, since efficiencies may not appear immediately after a change.

Residual risk is what remains after you handle a risk, and NASA keeps mitigating until it is acceptable. Project frameworks call a new risk created by your response a secondary risk. Federal guides show the route: NASA notes baseline changes can introduce new risk, and a 2015 Defense Department guide says changing design or constraints to cut a consequence most likely yields a new risk. Compare options on what each leaves behind.

A risk burn-down plan lays handling activities out in sequence, each with specific, measurable outcomes and a planned likelihood and consequence value. That lets you track progress toward an acceptable level or closure. Count results rather than effort: a 2015 Defense Department guide points out that a meeting reduces no risk by itself, and it rejects an activity written only as performing a test.

A contract is not closed when the last deliverable arrives. Administrative closeout follows physical completion and settles costs, subcontracts and the final invoice. Federal policy tries to resolve disputes by agreement at the contracting officer's level before anyone files a claim. Rate the vendor as well: federal evaluations are due at least annually and at completion, and they can inform later source selections.

Incentive contracts relate profit or fee to performance against targets you can state up front. When objective targets are not feasible, an award fee lets the government judge cost, schedule and technical results against an award-fee plan, and nothing is earned below satisfactory. Design carefully: federal auditors warn that fees tied to reported earned value can reward overstated performance.

Depending on one supplier is a risk to name early: a 2015 Defense Department guide lists sole and single source suppliers among the items to consider when identifying program risks. Federal rules can let a buyer skip full competition when only one responsible source can meet the need, so the arrangement may be legitimate and still leave you exposed. Give it an owner and a handling plan in the register.

A pilot tests your approach at small scale so you can find problems and learn before committing everyone. GAO describes one when adopting agile methods, to mature processes and fold in lessons before full adoption, and a federal migration playbook suggests considering phased implementation for quick wins. Keep key experts on hand during the final pilot trial as well as the actual deployment.

A cutover plan covers the steps before, during and after go-live and ties them to the communications and program schedules. Agree measurable go/no-go criteria in advance, and prepare a contingency plan that spells out communications, impacted systems and roles for both a no-go and a rollback. Schedule checkpoints so you can see how the go-live is progressing.

Support should not drop to normal the day a system goes live. Plan for a stabilization period with extra help: warranty-period support from the provider, a committed contact center, key experts on hand and daily meetings to resolve issues in time. Keep training and communications going through this window, and assess whether they are working.

Go-live readiness covers the workforce as well as the system. Identify audiences and training needs early, tailor training to each group, offer several formats, and use feedback to improve it. Training does not end at launch: keep job aids and FAQs available, train new hires and process changes, and assess whether the change is taking hold.

Before operations takes over, settle who decides what afterward: authority, roles, issue escalation, service levels and change requests, plus a meeting and reporting cadence. NASA's readiness review checks that hardware, software, people, procedures and user documents match the system as deployed. Transfer knowledge to the run team as part of closing out.