A project turns a defined need into a delivered result, under limits on scope, time and money that keep pressing against each other. The chapters follow that arc: decide the work is worth doing, define it, schedule and cost it, build quality in, manage risk, buy what you cannot make, control change, and hand over something people keep using. Agile changes the rhythm of the work, and most of the questions stay. The examples lean on US federal guidance, so terms and rules can differ elsewhere, and older guidance carries its date. Orientation for study, not legal, contracting or professional advice, and not affiliated with the Project Management Institute (PMI).
Each chapter opens with the short version. Tap one to read the detail.
What a project is, and who decides it continues
~2 min
A project is work with a defined result and an end, while operations keep running. Phases end at gates where someone with authority decides what happens next, and the weight of the process should fit the project.
A project has its own requirements and life-cycle cost, and it starts and stops, while operations keep running. So ask whether the work ends when a defined result is in hand. NASA's 2014 project management handbook has a program direct one or more projects toward a strategic aim, and a federal portfolio selects, prioritizes and monitors the whole set.
Plan-driven work runs requirements, design, development and testing in sequence, while agile runs them together in small iterations with frequent customer feedback. If you mix them, decide which parts run which way. The Government Accountability Office (GAO) records an official saying teams found a mix of iterative and waterfall guidance confusing.
Phases end at gates. At a NASA Key Decision Point, a decision authority can let work proceed, attach conditions, let a project retry after fixing shortfalls, or end it. The review beforehand informs that call without making it. NASA also encourages dropping requirements that add nothing to mission success, with the owner's permission.
Your reach depends on structure. In a matrix, each person answers to a functional manager and to a second manager, which can improve information exchange and can create role conflict. Project management offices differ too: you may meet labels such as supportive, controlling and directive, so read what an office actually does.
The trap is treating a good review as an approval. Say a design review goes well on Tuesday and the team starts buying hardware on Wednesday. Nobody with authority has yet authorized the next phase's cost, schedule and content, so the spending has outrun the decision.
Rule: before work continues, name who can say no, and fit the process to the risk without dropping what an outside body imposes.
Deciding the work is worth doing
~2 min
A business case compares real alternatives, and a charter sets out the manager's authority. Finishing on time and on budget is one test of success. Whether the promised benefits arrive is another, and someone has to keep checking after delivery.
The Office of Management and Budget (OMB), in its 2016 capital programming guide, asks a team to find as many alternatives as it can, then weigh discounted expected benefits against discounted expected costs. It also wants work processes simplified or redesigned before the search for alternatives begins, which keeps you from buying a tool to prop up a broken process.
In OMB's view, a written charter should go to the program manager, covering the team's responsibilities, budget limits and how far the manager's authority and accountability reach, refreshed no later than the start of each phase.
Define success twice. One framework separates project management success, meaning time, cost and quality objectives, from product success, meaning the owner's strategic aims and users' needs. Benefits arrive after delivery, so set metrics with baselines and targets at the start. One federal migration playbook hands oversight to an operations governance group and warns that savings can lag.
Some inputs sit outside your control. NASA's 2014 handbook treats requirements set by federal law or outside bodies as something you generally cannot waive, and the Department of Energy (DOE) lists regulatory and statutory changes among risks beyond a project's control, to be addressed anyway.
The trap is writing the need as a solution. Say the request reads "replace the ticketing tool." Every alternative now involves buying a tool, and fixing how tickets get routed never reaches the comparison.
Rule: state the need without naming the solution, write down both success tests, and name who checks the benefits after the team leaves.
Stakeholders, communication and honest reporting
~2 min
Find the people a project affects, then decide how much influence each one really gets. Plan who hears what and when, agree how problems move up, and report forecasts and risks beside the work done.
NASA's systems engineering handbook counts as a stakeholder any group or individual affected by a project or holding a stake in it. Customers are usually easy to spot; others are harder to find and change with the phase. The Environmental Protection Agency (EPA) suggests having the stakeholders you know name others you should talk to.
A power-interest grid rates each person high or low on both axes, which gives you four groups and a way to divide your effort. One health-policy study built its grid as a prioritizing tool, not a measurement scale. Then settle how much say over the decision you are really offering, since EPA warns that agencies sometimes promise more than is possible.
A communications plan states who hears what, why, by what method and when, and a feedback route catches the gap between sent and understood. One federal playbook writes escalation into its governance plan, pushes decisions to the lowest possible level and keeps a route up for contentious issues.
GAO records a perception that a contract's bad news can put a program and its managers in jeopardy, yet it treats variances as normal and as essential information. So show forecasts and open risks beside the work done, while there is still time to respond.
The trap is counting activity as engagement. Say you run six town halls on a new system, and staff arrive believing they have a vote on a decision already made. They leave dissatisfied however many sessions you held.
Rule: keep asking who else is affected, promise only the influence you can deliver, and report the forecast along with the progress.
Leading people, and knowing who does what
~2 min
When people report elsewhere, you cannot simply assign their work, so you rely on influence, clear roles and regular feedback. Separate who does the work from who answers for it, and treat the people a plan names as commitments to secure.
One paper describes a three-year ethnography of a research team in which informal leaders who passed on their expertise often moved the team more than formal ones did. That is one team, but you can still seek buy-in early and put commitments in writing.
Tuckman's stages run from forming through storming and norming to performing, when a team manages its daily work and the leader mostly monitors. The Thomas-Kilmann model plots five conflict styles against assertiveness and cooperativeness: competing, avoiding, accommodating, compromising and collaborating. You may also meet labels such as forcing, withdrawing and smoothing. Collaborating seeks an outcome that works for both sides, and compromising leaves each only partly satisfied. Test motivation theories in your own setting: a study in Saudi Arabia's public sector found Herzberg's split between motivators and hygiene factors did not hold there.
The Office of Personnel Management (OPM) calls for monthly, or at minimum quarterly, check-ins, so the formal review holds fewer surprises. A Responsible, Accountable, Consulted, Informed (RACI) chart separates the people who do the work, who can be several, from the one person who approves it.
The trap is treating a name in the plan as a person you have. Say the schedule assigns a database specialist in March and her manager never agreed. One federal playbook advises formalizing experts' participation in a memorandum of understanding, and it pays to track them by name, since one absence can delay an activity.
Rule: get commitments in writing, keep one accountable name per deliverable, and give feedback early enough that a review holds no news.
Scope: what is in, what is out, and how it breaks down
~2 min
Requirements come from users and from whoever sets constraints, and each should trace to a source and a check. A work breakdown structure divides the work into a hierarchy that adds up, and written exclusions settle arguments before they start.
Requirements come from research with current and prospective users, plus parties who set broad constraints. Trace each one up to its parent and down through design and test plans, so a requirement with no parent gets flagged. Rank them too: under the acronym MoSCoW, many agile methods label each story must have, should have, could have or won't have.
A scope statement should say what is excluded as well as what is included, since GAO warns that undefined requirements can drive up cost and cause delays. A work breakdown structure then splits the work into a hierarchy built around the product, with the work package at the bottom. Children must add up to their parent, which you may see labeled the 100 percent rule, and no child has two parents, so no cost is counted twice.
You do not need every detail on day one. Rolling-wave planning details near-term work and holds later work in planning packages that are still estimated and scheduled. Log each assumption, a judgment treated as true without proof, because rejecting even one can ripple through an estimate. NASA's systems engineering handbook separates two checks: verification proves the product meets its requirements, and validation shows it does the job intended.
The trap is growth by small yeses. Say a booking system's statement covers payments and is silent on refunds. The client assumed refunds, the vendor did not, and nothing on paper settles it. That handbook says a change is often an enhancement in disguise, though some are real new needs. You may also hear the label gold plating for additions like these.
Rule: write the exclusions down, make the pieces add up to the whole, and assess every addition before you agree to it.
Schedule logic, the critical path and float
~2 min
Dependencies set the order of work, and the critical path, generally the schedule's longest chain, sets the earliest finish. Float tells you how far work can slip, and simulation turns a single date into a range.
Make most links finish-to-start, since those are easy to trace. Hard logic holds no matter what anyone wants: concrete has to be poured before it can cure. Soft logic is management's chosen order, which is where you have room to reorder.
Here is a worked case. Activity A takes 5 days, and the last activity, D, also takes 5. Between them run two paths: B alone at 10 days, or C then E at 3 days each. A-B-D totals 20 days and is the critical path, while A-C-E-D totals 16. B has zero float, so each day it slips moves the finish. C and E share 4 days of total float. E also has 4 days of free float, because it can slip that far without touching D. C has no free float, because any slip pushes E at once.
To recover time, aim at critical work, since only shortening the critical path shortens the program. Adding workers to a critical activity can cut its duration, but you pay for the extra labor and need people free at short notice. Overlapping activities can also save days where the logic allows it: a sewer must be finished before it is inspected, and two tasks that each need two carpenters need four at once. You may see these moves labeled crashing and fast tracking.
A single finish date hides uncertainty. Monte Carlo simulation draws a duration for each activity, works out new dates and does this thousands of times, so you get a spread of outcomes. Every extra path feeding a milestone cuts the odds that it lands on time.
The trap is treating float as one activity's private cushion. In the case above, if C uses all 4 days of float, E has none left, and that second path is now critical too.
Rule: get the logic right before you trust any date, treat float as shared, and shorten only what is critical.
Cost estimates, earned value and honest forecasts
~2 min
Earned value measures finished work at its planned cost, which makes plan and spending comparable. From it you get variances, indexes and a forecast of final cost, and that forecast is only as good as the assumption behind it.
GAO describes a rough order of magnitude figure as a quick, high-level estimate that might take days, while a first budget-quality estimate would likely need many months. A life cycle estimate runs through operating and disposing of a program, so weighing options by build cost alone may point you to the wrong one.
Earned value management rests on three numbers: planned value, what you budgeted for the work due by now; earned value, what you budgeted for the work finished; and actual cost. Effort is not progress. GAO's December 2015 schedule guide warns that a five-day task reported at 80 percent can seem nearly done even if the hard part was left for last.
Say a project with a budget of 1,000 has planned 200, earned 150 and spent 180. Cost variance is 150 minus 180, or -30. Schedule variance is 150 minus 200, or -50, in money rather than time, so check whether the delay touches the critical path. The cost performance index (CPI) is 150 divided by 180, about 0.83. Actual cost plus the remaining 850 divided by that index gives an estimate at completion (EAC) of about 1,200.
Choosing an index means assuming something about the future, and GAO says cumulative CPI tends to produce a best-case figure.
The trap is a forecast nobody tested. Suppose the team still reports 1,000 at completion. The to-complete performance index (TCPI), remaining work divided by money left, is 850 over 820, about 1.04, against a CPI of 0.83. GAO's rule of thumb calls an EAC too optimistic when TCPI runs more than 5 percentage points above CPI.
Rule: measure finished work rather than effort, and test every forecast by asking what efficiency the remaining work would need.
Building quality in, and checking it
~2 min
Quality assurance aims to prevent defects, and quality control aims to detect them. Decide what good means in measurable terms before work starts, then build gates that can actually say no.
The US Geological Survey boils the split down to preventing defects and detecting them. For EPA, assurance is a management system that takes in planning, training, assessment and improvement, and control is one part of it: technical measurement against set criteria, such as calibrations and check samples. Cost-of-quality models predict that more prevention and appraisal spending lowers failure costs, but in a pilot of five food companies, three could not specify all failure costs, so measure yours before you trust the model.
NASA's systems engineering handbook layers its measures: effectiveness measures say what the customer needs, performance measures restate that in numbers, and technical performance measures get tracked against expected values.
Each quality tool answers its own question. A fishbone sorts possible causes by category, a Pareto chart orders factors by how often they occur, a histogram displays center, spread and skew, and a control chart tracks a measure over time, where a point outside the limits sends you looking for an assignable cause. To test a fix, Plan-Do-Study-Act gives you a loop, and the Agency for Healthcare Research and Quality (AHRQ) advises keeping each cycle to one step, briefly, on a small sample.
The trap is a gate that cannot say no. Say a launch review has a date on everyone's calendar, no written criteria and no plan for failure. A gate needs measurable criteria set in advance. Federal migration guidance pairs go/no-go criteria with a contingency plan, which makes a no-go a usable answer.
Rule: define what passing means before the work is done, and give every gate a real way to say no.
Risk: rank it, own it, and fund it on purpose
~2 min
A risk might happen, and an issue already has or certainly will. Rank risks by judgment, give each an owner and a trigger, choose a response deliberately, and let analysis rather than an arbitrary percentage set the money you hold.
The Department of Defense's June 2015 risk guide warns that limiting identification to managers can miss risks, so keep it continuous and open to the whole team. A probability-and-impact matrix rates a risk low, moderate or high, a judgment of relative risk in DOE's words, and the Defense guide warns against fractional scores like 3.4 on what is an ordinal scale. Expected value is an outcome times its probability: a 70,000 overrun at 30 percent counts as 21,000.
Threats get avoided, transferred, mitigated or accepted. Transfer needs a receiver that acknowledges it owns the risk, and acceptance still means tracking. DOE's opportunity responses mirror these: exploit, enhance or share. Give each risk one owner and a trigger, the event showing it may be about to occur.
Reserves are where vocabulary bites. GAO's 2020 cost guide keeps contingency for unknown unknowns, held at or above the program office, and treats management reserve as budget the contractor manages for known unknowns. GAO allows that other bodies may define these terms their own way, so definitions vary, and DOE warns that interchangeable use confuses accountability. GAO gets contingency from a simulation: it is the distance from the point estimate to your chosen confidence level.
The trap is assuming everyone means the same thing by reserve. Say a sponsor hears "we hold 10 percent contingency" and your contractor reads that as its own money. Nobody is sure who can spend it, and no analysis defends the amount.
Rule: write each risk as an uncertain event with one owner, and before you quote a reserve, say whose definition you are using and what analysis set it.
Buying work: contract type, terms and changes
~2 min
Decide what to make and what to buy, then pick the contract type knowing it decides who carries cost risk. Describe results you can measure, and route every change through the person with authority to make it.
These examples come from the Federal Acquisition Regulation (FAR), which covers US federal buying. Commercial contracts can differ, and rules change, so check the current text before you rely on one. Make-or-buy choices turn on overall cost and technical risk.
A firm-fixed-price contract puts maximum risk on the contractor, which also gives it the strongest reason to hold costs down. In a cost-plus-fixed-fee contract, actual cost leaves the fee unchanged, so the incentive to save is minimal, and the type suits research and other work of unknown effort. Time-and-materials buys hours at set rates plus materials at cost. It carries no positive profit incentive, which is why FAR calls for appropriate surveillance.
In a performance-based service contract, FAR asks you to state the results required, not the method or the hours, and to set measurable standards and a means of judging performance. In negotiated buys, award rests on factors tailored to the purchase.
The trap is the hallway change. Say an engineer asks a contractor in a meeting to add a monthly report, and the contractor starts work expecting to be paid. In federal work, modifying a contract is for a contracting officer alone, and nobody else may direct work that belongs in a modification. If agreement fails on a claim, the contracting officer issues a written decision, and the contractor may appeal it.
A contract does not close with the last deliverable. Once the work is physically complete, closeout settles costs, subcontracts and the final invoice.
Rule: pick the contract type by who should carry the cost risk, describe results you can measure, and put every change through the person authorized to make it.
Controlling change, and handing the result over
~2 min
Every change to a baseline gets logged, weighed, decided and communicated. The last deliverable starts the closing work rather than ending it, with acceptance, handover, stabilization, closeout and lessons still ahead.
Change control answers one question: should this baseline change? Each request is logged and reviewed, a board weighs its effect on cost, performance, program and safety, and nothing unapproved goes ahead. Then update the baseline and release the decision, so everyone works from the same one. Configuration management is wider: it decides what sits under control, tracks every change and audits the result. Acceptance goes beyond proof of delivery: you formally acknowledge that what arrived meets the agreed quality and quantity.
Going live needs its own plan. A pilot tests your approach at small scale. A cutover plan lays out what happens before, during and after go-live, with measurable go/no-go criteria agreed in advance and a contingency plan for a no-go or a rollback. Then plan for stabilization with added support: warranty-period help, a dedicated contact center, key experts within reach and daily meetings on open issues.
Closing is a checklist: measure results against the baseline, archive what the work really cost, hand over knowledge and off-board the team. A lesson pays off only once it is written down and somebody applies it.
The trap is treating go-live as the finish. Say a payroll system goes live on Friday and the project team rolls off on Monday. Nobody settled who approves next month's change request, and the people who know why a rule was built that way have moved on. Settle authority, roles, escalation, service levels and change requests before operations takes over.
Rule: change nothing baselined without a recorded decision, and stay until the people running the result can decide without you.
Agile delivery: roles, iterations and flow
~2 min
Agile works in short iterations from a ranked backlog, with frequent feedback from working software. Kanban limits work in progress on a visible board, and velocity belongs to one team.
In GAO's November 2023 Agile guide, the product owner represents the customer, orders the requirements and decides whether acceptance criteria are met. The development team organizes itself. The team's facilitator is called the scrum master in Scrum. Work runs in time-boxed iterations, which Scrum calls sprints, with a daily stand-up, a demonstration of working software and a retrospective, whose action items can go in the backlog so their completion gets tracked.
Without fixed iterations, Kanban aims to raise throughput by making the flow visible on a board and capping work in progress, and the team pulls its next item from a ranked backlog. Cycle time runs from the start of work on an item and lead time from the moment the item is identified, so a long queue swells lead time even while cycle time looks fine.
INVEST gives you a test for a story: independent, negotiable, valuable, estimable, small and testable. A definition of ready is the entry check, such as an estimate and acceptance criteria, and a definition of done is the exit check. When a story resists estimating, a spike holds a place in the backlog for the research. A minimum viable product is a working version meant to teach you about customers at the lowest effort, so it pays off only when they can actually interact with it.
The trap is treating velocity as a score. Say you rank two teams at 40 and 25 points a sprint. Velocity is team-specific, so GAO says it should not be used to compare teams, and inflating estimates raises it with no added value.
Rule: judge progress by working software, and use velocity only to help one team plan its own next iteration.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.