Project Management

1. What is software project planning?

Software project planning is the activity of defining what the project will deliver, how it will be delivered, and when — before the actual work begins. It turns a vague idea into a concrete plan that the team can execute and management can track.

Planning produces several deliverables. The project scope defines what is in and out of the project. The work breakdown structure (WBS) decomposes the scope into manageable tasks. Estimates predict the effort, cost, and duration of each task. The schedule sequences the tasks and shows their dependencies and milestones. The resource plan assigns people, tools, and budget. And the risk plan identifies what could go wrong and how to respond.

Planning is not a one-time event at the start — it is revisited and refined as the project progresses and reality diverges from the plan. Its value is forcing decisions early: scope, priorities, and constraints get agreed before resources are burned. A project without a plan is a project that cannot be measured, controlled, or steered.

2. What is project scope?

Project scope is the complete set of work that must be done to deliver the project — and, just as importantly, the work that is explicitly excluded. It defines the boundaries: what the product will do, what it will not do, what is included in the effort, and what is not.

Scope is documented in a scope statement or scope section of the project charter, listing the deliverables, features, functions, and constraints. It is the foundation of all planning — the schedule, budget, and resources all derive from the scope. Scope also protects the team: when a stakeholder asks for more, the scope statement is the reference for what was agreed.

The great danger is scope creep — uncontrolled additions to scope that inflate cost and schedule. Scope must therefore be formally defined, baselined, and controlled: new requests are evaluated as changes, not absorbed silently. Clear scope is the difference between a project that finishes and a project that grows forever.

3. What is scope creep?

Scope creep is the uncontrolled expansion of a project’s scope after it has been baselined — new features, requirements, or changes added without corresponding adjustments to schedule, budget, or resources. The team quietly ends up building more than was agreed.

Scope creep happens through small increments that individually seem harmless: “just one more button,” “let’s also support this format,” “can it do X too?” Each addition looks tiny, but accumulated over a project they blow up cost and schedule and erode quality as the team rushes to absorb unplanned work. It is the most common cause of project overruns.

The root causes are unclear scope at the start, weak change control, and stakeholders who add requirements without going through the process. The defense is a clear scope statement, a formal change control process where every addition is evaluated for impact and cost, and the discipline to say no — or to re-baseline the plan when scope genuinely must grow. Scope creep is not a technical problem; it is a governance problem.

4. How do you control scope creep?

Scope creep is controlled through a formal change management process and disciplined communication. The first line of defense is a clear, written scope statement that everyone agreed to, so there is a baseline to compare new requests against.

When new scope is requested, it goes through the change control process, not straight to the team. The request is evaluated for impact — what it costs in effort, schedule, and risk, and what value it adds. A change control board or product owner then decides to accept, defer, or reject it. Accepted changes update the scope, schedule, and budget together, so the plan stays consistent.

Communication discipline matters just as much. Stakeholders must understand that adding scope means adding time and cost — the trade-off is stated openly, never absorbed silently. Regular reviews catch emerging creep before it compounds. The goal is not to refuse every addition; it is to make scope changes visible, priced, and agreed, so the project grows only deliberately.

5. What is Work Breakdown Structure?

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total project scope into smaller, manageable components. It breaks the project down, layer by layer, from the whole project into phases, deliverables, and finally into individual work packages.

The WBS is built top-down: the project at the top, then major deliverables or phases, then sub-deliverables, and so on until each leaf is a work package small enough to estimate, schedule, assign, and track. A good WBS follows the 100% rule — every level’s components sum to exactly the scope of the level above, so nothing is missing and nothing is double-counted.

The WBS is the backbone of planning. Effort estimates hang off its work packages, the schedule is built from its dependencies, and costs roll up through it. It is also the communication tool that shows everyone the shape of the project. Skipping the WBS is the classic route to missing work, which is the classic route to project failure.

6. What is project scheduling?

Project scheduling is the process of sequencing the project’s tasks in time — deciding what happens when, how long each task takes, and what depends on what. It turns the WBS and its estimates into a timeline.

Scheduling begins by identifying task dependencies — which tasks cannot start until others finish. Then durations are estimated, resources are assigned, and the tasks are laid out on a timeline. The schedule’s most important output is the critical path: the chain of dependent tasks that determines the project’s minimum duration. Anything that slips on the critical path delays the whole project.

The schedule is a living document, not a one-time drawing. It is tracked during execution — actual progress against planned progress — and updated as reality diverges. Tools like Gantt charts visualize it. Scheduling exists to answer the fundamental project question: when will we finish, and what is keeping us from finishing earlier?

7. What is a Gantt chart?

A Gantt chart is a bar chart that visualizes a project schedule. Each task is a horizontal bar whose position shows its start date and whose length shows its duration, laid out against a calendar timeline.

The chart shows tasks in sequence down the left and the calendar across the top. Bars can be connected by dependency arrows — when one task must finish before another begins. Milestones appear as diamonds marking significant points in time. Some Gantt charts also show who owns each task and current progress as a portion of the bar shaded differently.

Its strength is instant readability: anyone can glance at it and see what is happening when, which tasks are parallel, which are sequential, and where the project stands. Its weakness is scale — a Gantt chart with hundreds of tasks becomes cluttered, and it shows schedule, not dependencies or criticality. Gantt charts are the standard tool for communicating schedules; they complement, but do not replace, critical path analysis.

8. What is the Critical Path Method?

The Critical Path Method (CPM) is a scheduling technique that identifies the sequence of dependent tasks that determines the project’s shortest possible duration. That sequence is the critical path, and it is called critical because any delay on it directly delays the entire project.

The method works by building a network of tasks with their durations and dependencies, then computing two things for each task: the earliest it can start and finish, and the latest it can start and finish without delaying the project. The difference is the task’s float or slack. Tasks with zero float lie on the critical path — they have no room to slip.

CPM gives project managers three powerful answers: the minimum project duration, which tasks must be watched hardest (the critical ones), and where schedule can be compressed — crashing critical tasks or fast-tracking parallel ones. It also reveals non-critical tasks that can slip harmlessly. CPM is the analytical backbone behind the schedule; the Gantt chart is its visual face.

9. What is a milestone?

A milestone is a significant, zero-duration point in a project timeline that marks the completion of a major deliverable or phase. It is a marker, not a task — it consumes no time and no resources.

Examples include approval of the requirements document, completion of the design, code freeze, test completion, and release. A milestone is reached when a named deliverable is finished and often when a gate is passed — a checkpoint where the project is reviewed before continuing.

Milestones serve several purposes. They break a long project into reviewable chunks, giving management points to check progress against the plan. They are natural decision points — continue, change direction, or stop. And they create a simple, high-level progress metric: a project at “milestone 4 of 8” is easy to communicate. Because they are so useful, milestones must be tied to real, verifiable deliverables — a “milestone” that means nothing is just decoration.

10. What is resource allocation?

Resource allocation is the process of assigning the project’s limited resources — people, budget, equipment, time — to its tasks, so each task has what it needs to be done, when it needs it. The resources are usually people with specific skills, and the allocation problem is matching them to the work.

Allocation starts after the schedule is built: each task needs people with the right skills for its duration, and the team must figure out who works on what and when. The hard part is balancing: a person cannot be on two tasks at once, so overlapping demands must be sequenced, and no one should be overloaded. Allocation tools reveal conflicts — two critical tasks needing the same specialist — before they become crises.

Good allocation avoids both over-allocation (people burning out) and under-allocation (people idle while the schedule slips). It also accounts for availability — vacations, other projects, onboarding. The output is a resource plan showing who does what, when, and how much of their time each task takes. Allocation is where the schedule meets reality.

11. What is software cost estimation?

Software cost estimation is predicting the effort, time, and money required to develop a software project before it is built. It answers the question the sponsor asks first: what will this cost, and when will it be done?

Estimation happens at multiple levels of precision. Early in the project, rough estimates based on scope and analogy with past projects guide go/no-go decisions. Later, as the WBS and requirements firm up, detailed estimates per task are built bottom-up and summed. The better the input, the better the estimate.

The techniques range from expert judgment and analogy to formal algorithmic models like COCOMO and Function Point Analysis. Effort, measured in person-months, is estimated first; cost follows from the team’s rates, and duration follows from effort and team size. Estimation is inherently uncertain — requirements change, productivity varies — so good estimates are expressed as ranges and revisited, not locked in stone. An estimate is a forecast, not a promise.

12. What is Function Point Analysis?

Function Point Analysis (FPA) is a method of estimating software size by counting the functionality the system delivers, independent of the technology used to build it. Instead of measuring lines of code, it measures what the user gets.

The method counts five types of functions from the requirements: external inputs (user entries), external outputs (reports and screens), external inquiries (queries), internal logical files (data stored inside), and external interface files (data shared with other systems). Each is weighted by complexity — simple, average, complex — and the weighted counts are summed into a raw function point count, then adjusted by 14 factors like performance, reusability, and complexity of processing.

The function point count is used to estimate effort (by dividing by historical productivity like function points per person-month), to compare productivity across projects and teams, and to measure maintenance size. Its advantage over code counting is that it can be computed early from requirements, before a line of code exists, and it is language-independent. Its weakness is that counting requires judgment and training.

13. What is COCOMO?

COCOMO (Constructive Cost Model) is an algorithmic model for estimating software cost and effort, developed by Barry Boehm in 1981 (COCOMO 81) and refined as COCOMO II in 1995. It derives effort from the estimated size of the software, measured in lines of code or function points.

COCOMO 81 has three levels of precision. Basic COCOMO computes effort from size alone using one of three project modes — Organic (small, simple, experienced team), Semi-detached (medium), and Embedded (complex, tight constraints) — with the formula Effort = a × (KLOC)^b, where the constants differ by mode. Intermediate COCOMO multiplies this by 15 cost drivers — factors like required reliability, team capability, and complexity. Detailed COCOMO adds phase-level and module-level precision.

COCOMO II updates the model for modern development: reuse, incremental development, and the software maturity of the organization. COCOMO’s value is its structure — it makes the assumptions explicit and lets a manager vary inputs and see the effect. Its weakness is shared by all estimation models: garbage-in, garbage-out, since the size input itself must be estimated.

14. What are the different types of project risks?

Project risks are uncertain events that could affect the project’s objectives, and they come in categories. Scope risks are requirements growing or changing — scope creep, unclear or missing requirements. Schedule risks threaten the timeline — underestimated effort, dependency delays, resource unavailability. Cost risks threaten the budget — estimation error, price changes, wasted rework.

Technical risks are engineering uncertainties — unfamiliar technology, integration problems, performance or security issues discovered late. Resource risks involve people and materials — key people leaving, skills gaps, burnout. Quality risks threaten the product — defects, inadequate testing, poor design. And external risks sit outside the team — vendor failures, regulatory changes, market shifts, third-party dependencies.

Risks are usually classified further by their nature — known risks are identifiable in advance, known unknowns are predictable but uncertain in magnitude, and unknown unknowns are unanticipatable. The risk management process — identify, analyze, respond, monitor — treats each category. The point of classification is coverage: risks are missed not because they are unknowable, but because nobody looked in that category.

15. What is risk identification?

Risk identification is the process of systematically finding the risks that could threaten a project, before they happen. It is the first step of risk management, and its goal is completeness — the risks you never identify are the ones that hurt you.

Identification uses structured techniques so nothing is left to chance. Brainstorming brings the team and stakeholders together to generate risks. Checklists of common project risks force coverage of each category — scope, schedule, cost, technical, resource, quality, external. SWOT analysis examines strengths, weaknesses, opportunities, and threats. Interviews and expert judgment pull in experience from previous projects. Assumption analysis examines what the project is taking for granted — the assumptions that turn out false become risks.

Each identified risk is recorded in a risk register with a description, category, and owner. Identification is not a one-time workshop — new risks surface throughout the project, so identification is continuous. The output is a living list that feeds risk analysis: rating each risk’s likelihood and impact to decide which need attention.

16. What is risk mitigation?

Risk mitigation is the set of actions taken to reduce the likelihood or impact of a risk before it occurs. It is one of the four standard risk responses — along with avoidance, transfer, and acceptance — and the most common in software projects.

The response chosen depends on the risk’s likelihood and impact, usually plotted on a probability-impact matrix. Avoidance eliminates the risk entirely — dropping a risky feature or choosing proven technology. Mitigation reduces it — adding review checkpoints, building prototypes for a risky integration, staffing extra buffer on an uncertain task. Transfer shifts the risk to someone else — outsourcing a part, buying insurance, signing a fixed-price contract. Acceptance acknowledges the risk and prepares a contingency plan, taken when the risk is small or mitigation is too costly.

Each response is captured in the risk register with its owner and action. Mitigation is proactive — the action happens before the risk does. The distinction interviewers probe: mitigation reduces a risk, contingency is executed after the risk materializes. Mitigation is what you do to keep the risk small; contingency is what you do when it still happens.

17. What is a risk register?

A risk register is the central document of risk management — a living list of all identified risks, their assessment, and their planned responses. It is the single source of truth for the project’s risk posture.

Each entry records: the risk’s description, its category, its likelihood and impact (often as a score on a 1–5 scale), its priority (likelihood × impact), the risk owner responsible for managing it, and the planned response — avoidance, mitigation, transfer, or acceptance. The register also tracks the response’s status and any contingency plan for risks that are accepted. For tracked risks, it can log trigger conditions — the warning signs that a risk is about to materialize.

The register is not a static document. It is reviewed regularly — typically at project status meetings — with new risks added, assessments updated, and statuses refreshed. Its value is that risk management becomes visible and accountable: every significant risk has an owner and an action. A project without a risk register is a project managing risk by hope.

18. How do you manage project delays?

Managing project delays starts with detecting them early. That requires tracking actual progress against the plan — not effort spent but work completed — through status reports, burndown charts, and milestone reviews. A delay noticed a week in is fixable; a delay noticed at the deadline is a failure.

When a delay is detected, the first step is to find its cause and assess its impact on the critical path. If it is on the critical path, the project end date is at risk and action is needed. Options include crashing — adding resources to critical tasks, accepting higher cost — and fast-tracking — running dependent tasks in parallel, accepting more risk and rework. Re-scoping is another lever: dropping or deferring lower-priority features to protect the critical ones, agreed with the stakeholders.

Transparency is essential — the stakeholders must hear about the delay and its impact before it is a surprise. The manager revises the schedule and budget honestly and communicates the new baseline. Managing delay is not about hiding it; it is about detecting it fast, attacking it at its root, and re-baselining the plan with everyone’s agreement.

19. How do you handle an unrealistic deadline?

An unrealistic deadline is best handled early and honestly. The first step is to assess the request objectively — estimate the effort and compare it to the time available, using the team’s data and historical velocity, not optimism. If the deadline genuinely cannot be met, say so, with the evidence.

Then negotiate across the three constraints: scope, time, and quality. If the date cannot move, the scope must shrink — agree on the must-have features and defer the rest. If the scope cannot shrink, resources can be added (though this has limits — adding people to a late project often makes it later, the classic Brooks’s Law trap). A third option is to deliver a smaller working version by the deadline and complete the rest after, which is exactly the Agile approach.

What not to do: silently accept the deadline and fail. Or throw more people at it and call that planning. The professional response is to state the trade-off explicitly, get the stakeholders to choose between scope, schedule, and resources, and re-baseline the plan accordingly — with the decision documented. An unrealistic deadline handled this way becomes a real decision; handled by silence, it becomes a failed project.

20. How do you manage conflicts within a project team?

Conflicts within a team are inevitable and, handled well, productive — differing views on how to build something often produce the best solutions. The first skill is distinguishing technical disagreements from personal ones, and addressing the issue, not the person.

The standard approach is to surface the conflict early and openly, in a safe setting, and let both sides state their positions. The goal is understanding, not victory. Techniques range from collaboration — working through the disagreement together to find a solution that satisfies both — to compromise — each side concedes something. The manager’s role is facilitation: keep the discussion focused on facts and project goals, listen to both sides, and separate the people from the problem.

Where resolution is not achieved by the parties, the manager decides, using the project’s objectives as the tie-breaker, and documents the decision so the team can move on. Persistent personal conflict may need escalation to HR or reassignment. The key mindset: conflict is normal and resolvable, but unaddressed conflict corrodes the team — so it is addressed quickly, fairly, and at its root.

21. How do you monitor project progress?

Progress is monitored by comparing actual work completed against the plan, using both status reports and objective measures. The tools are the schedule, the WBS, and the metrics the team records.

Objective measures include task completion against the schedule, milestone attainment, and — in Agile — velocity and burndown charts. The manager also tracks effort spent versus earned value: work completed compared with cost and time consumed. In earned value management, comparing planned value, earned value, and actual cost yields the schedule variance and cost variance — the objective answers to “are we on time and on budget?”.

Status meetings and reports layer in what the numbers cannot say — risks materializing, blockers, team morale, stakeholder feedback. Monitoring is continuous, not just at milestones: the daily standup and weekly status reviews catch divergence early. The output is a decision — re-plan, re-scope, add resources, or confirm the plan is sound. Monitoring without action is just watching; the point is to detect problems early enough to steer.

22. What project metrics are commonly used?

Project metrics fall into three families. Schedule metrics answer “are we on time?”: task completion against plan, milestone attainment, schedule variance, and for Agile teams, velocity and burndown. Cost metrics answer “are we on budget?”: cost variance, earned value, actual versus planned spend.

Quality metrics answer “is it good?”: defect density (defects per thousand lines of code), defect removal efficiency, defect leakage to production, test coverage, and rework percentage. Team metrics capture throughput and stability: velocity trend, cycle time, and team capacity. Scope metrics track the project’s shape: requirements volatility and scope change count.

The art is choosing few and relevant metrics, not collecting everything. Metrics must tie to the project’s objectives and to decisions — a metric nobody acts on is noise. And metrics must be interpreted carefully: velocity can be gamed, defect counts reward hiding bugs, and raw numbers without context mislead. The project manager picks a small dashboard of schedule, cost, and quality indicators and watches the trends, because trends reveal problems before levels do.