Project Initiation, Feasibility and Planning

Introduction

Software projects rarely fail because programmers cannot write code. They more often fail because the organisation begins with an unclear problem, unrealistic expectations, inadequate resources, weak stakeholder agreement, or insufficient attention to risk. Project initiation and planning provide the disciplined transition from an idea to an authorised, feasible and manageable project.

Project initiation asks whether a proposed software product is worth investigating and who has authority to proceed. Feasibility analysis tests whether the proposal is practical from technical, financial, organisational, legal and scheduling perspectives. Planning then converts an approved proposal into a defined scope, work breakdown structure, schedule, resource plan, cost estimate and risk-management approach.

Planning does not eliminate uncertainty. Its purpose is to make assumptions visible, support evidence-based decisions and provide a baseline against which progress and change can be evaluated. A plan should therefore be treated as a decision-making instrument, not merely as a document produced for administrative compliance.

Learning Objectives

By the end of this chapter, you should be able to:

• explain the purpose and contents of a software project business case;
• distinguish project initiation, feasibility analysis and project planning;
• define scope, assumptions, constraints, exclusions and acceptance criteria;
• construct a work breakdown structure and identify dependencies;
• develop a schedule using effort, duration and resource information;
• estimate effort and cost using transparent assumptions;
• create and maintain a practical risk register;
• evaluate alternatives using financial and non-financial evidence; and
• recognise ethical, legal, governance and professional responsibilities in project decisions.

1. From an Idea to an Authorised Project

A software project may originate from a business problem, a regulatory requirement, a customer request, an operational inefficiency or an opportunity created by new technology. An idea is not yet a project. A project is a temporary endeavour undertaken to create a defined product, service or result. It has an intended outcome, a beginning and an end, identified stakeholders and constraints.

The early lifecycle commonly includes the following stages:

1. Opportunity or problem identification: a need is described in business terms.
2. Initial assessment: the organisation checks strategic alignment, urgency and likely benefits.
3. Business case development: alternatives, costs, benefits, risks and feasibility are investigated.
4. Authorisation: an accountable sponsor decides whether to fund and initiate the project.
5. Detailed planning: scope, deliverables, activities, resources, schedule, cost and controls are defined.
6. Execution and control: the team produces the solution while monitoring performance and change.

A project sponsor owns the business justification and provides organisational authority. A project manager coordinates planning and delivery. Business analysts clarify needs and processes. Technical specialists assess architecture, integration, security and implementation feasibility. End users and other stakeholders contribute knowledge about operational requirements and acceptance.

A useful initiation document should identify:

• the problem or opportunity;
• the proposed outcome and expected benefits;
• the sponsor and decision authority;
• key stakeholders;
• initial scope and exclusions;
• assumptions and constraints;
• high-level milestones;
• indicative resources and cost;
• major risks and dependencies; and
• the decision required from management.

The document should be concise enough for decision makers but evidence-based enough to expose uncertainty. Unsupported statements such as “the system will be easy to build” or “users will adopt it immediately” are not adequate planning evidence.

2. Building a Business Case

A business case explains why an organisation should invest in a proposed project. It is not a technical specification and it is not a promise that every benefit will occur. It is a structured argument supported by assumptions, evidence and comparison of alternatives.

2.1 The problem and desired benefits

The problem statement should describe the current condition, its effects and the reason action is needed. For example, “the organisation needs a mobile application” is a solution-oriented statement. A stronger problem statement might be: “Customers abandon approximately 35% of service requests because the current web process is difficult to use on mobile devices.” The second statement identifies an observable condition and suggests a measurable improvement.

Benefits may be:

• Financial: reduced processing cost, increased revenue or avoided expenditure.
• Operational: shorter cycle time, fewer errors or improved capacity.
• Customer-related: improved satisfaction, accessibility or retention.
• Strategic: support for a new market, capability or compliance objective.
• Social or environmental: improved inclusion, safety or reduced resource use.

Benefits should have an owner, a measurement method and a target date. A software team may deliver a product, but a business owner normally realises the resulting benefit through changed processes, training and adoption.

2.2 Alternatives analysis

A credible business case compares alternatives rather than assuming that a new software system is the only answer. Typical alternatives include:

• do nothing or continue with the current process;
• improve the existing system;
• buy and configure a commercial product;
• subscribe to a cloud service;
• build a new solution internally; or
• outsource development and operation.

Each alternative should be evaluated against common criteria: expected benefits, cost, implementation time, technical fit, security, legal obligations, maintainability, supplier dependence and organisational readiness. The cheapest option is not automatically the best option if it produces unacceptable risk or fails to meet essential requirements.

2.3 Financial reasoning

Financial estimates should distinguish costs and benefits by time period. Common cost categories include development labour, equipment, licences, cloud services, training, data migration, support, security assurance and eventual retirement. Benefits may be recurring or one-off.

A simple net benefit calculation is:

Both benefits and costs must use the same monetary basis and time period. If the values occur over several years, time value of money may be considered through present value:

where PV is present value, FV is a future cash flow, r is the discount rate per period, and t is the number of periods. The formula assumes a constant discount rate and that the cash flow occurs at a defined point in each period. The rate and cash flows must be expressed using consistent periods, such as annual values with an annual rate.

For a simplified project comparison, return on investment may be expressed as:

ROI is useful for communicating a basic relationship but can be misleading if projects have different durations, risk profiles or benefit timing. It should not replace a full financial and strategic assessment.

The payback period estimates how long it takes cumulative benefits to recover the initial investment. If annual net cash benefit is constant, a simple approximation is:

This approximation is not appropriate when benefits vary substantially by period or when discounting is required.

Worked example. A proposed system costs $80,000 initially and is expected to produce $50,000 of benefits in year one and $45,000 in year two. Operating costs are $10,000 per year. Over two years, total benefits are $95,000 and total costs are $100,000, including $80,000 initial cost plus $20,000 operating cost. The simplified net benefit is therefore −$5,000. A decision maker should not immediately reject the proposal: important non-financial benefits, later benefits, risk reduction or regulatory necessity may change the conclusion. However, the example demonstrates why costs must include operation and not only development.

3. Feasibility Analysis

Feasibility analysis investigates whether a proposal can reasonably be delivered and sustained. It is an early decision process, so its conclusions should state confidence levels and assumptions rather than pretending to be exact.

3.1 Technical feasibility

Technical feasibility considers whether the organisation can create, integrate, secure, operate and maintain the solution. Questions include:

• Does the required technology exist and is it sufficiently mature?
• Can the proposed system integrate with existing databases and services?
• Are performance, availability, accessibility and security requirements achievable?
• Does the team possess the necessary skills?
• Are data quality, migration and interoperability problems understood?
• Can the solution be supported after delivery?

A proof of concept may reduce uncertainty about an unfamiliar framework, interface, algorithm or integration. A proof of concept is not a complete product; its value lies in testing a specific assumption.

3.2 Economic and financial feasibility

Economic feasibility compares expected value with total cost and risk. Estimates should include the full lifecycle: initiation, analysis, design, development, testing, deployment, training, operation, maintenance and retirement. Opportunity cost also matters: assigning a team to one project may delay another project with greater value.

3.3 Operational and organisational feasibility

A technically successful product may fail if users cannot or will not use it. Operational feasibility examines process fit, workflow changes, training, support, culture, management capability and stakeholder readiness. Questions include whether staff have time to participate, whether responsibilities will change and whether service levels can be maintained during transition.

3.4 Legal, regulatory and ethical feasibility

The project may involve privacy, intellectual property, accessibility, consumer protection, records retention, employment law, cybersecurity obligations or sector-specific regulation. Legal review should occur early, particularly when personal, health, financial or children’s data are processed.

Ethical feasibility asks whether the proposed system could cause unfair exclusion, unsafe decisions, intrusive surveillance or unjustified discrimination. Compliance is a minimum requirement, not the complete definition of responsible practice. Requirements should include privacy by design, appropriate access control, transparency and mechanisms for correcting inaccurate data.

3.5 Schedule feasibility

Schedule feasibility asks whether the required outcome can be delivered by the needed date with available resources and realistic dependencies. A fixed deadline does not make work smaller. If time is constrained, scope, resources, quality risks or delivery strategy must be consciously negotiated.

A feasibility conclusion can be classified as feasible, feasible with conditions, requiring further investigation, or not currently feasible. Conditions should be explicit—for example, “feasible if a database specialist is available by month two and the supplier confirms the interface specification.”

4. Defining Scope and Requirements

Scope defines the boundaries of the project. Product scope describes the features and qualities of the resulting system. Project scope describes the work required to produce it. Confusing these concepts causes teams to omit essential management work such as testing, training and deployment preparation.

A scope statement normally includes:

• purpose and objectives;
• deliverables;
• in-scope features and processes;
• explicit exclusions;
• assumptions;
• constraints;
• interfaces and dependencies;
• acceptance criteria; and
• change-control arrangements.

Objectives should be specific enough to evaluate. “Improve customer service” is a direction, not a measurable objective. “Reduce average online application processing time from five days to two days within three months of deployment” is more useful, provided a baseline and measurement method exist.

Requirements may be functional, describing what the system does, or non-functional, describing qualities and constraints such as performance, security, usability, accessibility, reliability and maintainability. Requirements should be traceable to business objectives and acceptance tests.

A scope baseline often consists of the approved scope statement, work breakdown structure and its associated dictionary. A baseline is not permanent; it is a controlled reference. Proposed changes should be analysed for impact on cost, time, quality, risk and benefits before approval.

5. Work Breakdown Structures

A work breakdown structure (WBS) is a hierarchical decomposition of the total project scope into progressively smaller components. The lowest meaningful components are work packages. A WBS is deliverable-oriented: it describes what must be produced, rather than merely listing departments or calendar dates.

For a customer portal, a high-level WBS might contain:

1. Project management
2. Requirements and analysis
3. User experience and interface design
4. Application development
5. Integration and data migration
6. Testing and quality assurance
7. Deployment and training
8. Closure and handover

Each branch should be decomposed until work can be estimated, assigned, scheduled and monitored. Decomposition should stop when further subdivision adds little control or creates artificial precision. The WBS should cover 100% of approved scope, including management, assurance, documentation and transition work. This is sometimes called the 100% rule.

A WBS is not a schedule. It does not necessarily show sequence, dates or resource loading. Those are developed after the work has been identified. A WBS dictionary can define each work package’s description, completion criteria, assumptions, responsible role, estimated effort and dependencies.

6. Scheduling and Resource Planning

Scheduling transforms work packages into activities with logical relationships and time estimates. A dependency may be finish-to-start, start-to-start, finish-to-finish or start-to-finish, although finish-to-start is common in software planning. Dependencies may be technical, contractual, resource-based or external.

A simple activity network enables identification of the critical path, the sequence of activities that determines the earliest possible project completion under the stated assumptions. If an activity on the critical path is delayed and no corrective action is taken, the project completion date is delayed. Activities not on the critical path may have float, meaning scheduling flexibility, but their delay can still create later problems.

For an activity, a basic duration relationship is:

Effort is the amount of labour, such as person-hours. Productive capacity is the realistic amount of that labour available per unit of calendar time. The relationship assumes effort and capacity are measured consistently and does not imply that adding people always reduces duration proportionally. Communication, learning, coordination and technical dependencies limit parallelism.

Worked scheduling example. Activity A requires 16 person-days and one analyst is available at 80% productive capacity. The available productive work per calendar day is 0.8 person-days, so the estimated duration is 16 ÷ 0.8 = 20 working days. If two suitably skilled analysts can work independently with no coordination loss, the ideal duration might be 16 ÷ 1.6 = 10 working days. In practice, the manager must allow for collaboration and dependency effects; the 10-day value is an idealised lower estimate, not a guarantee.

Resource planning identifies the people, skills, environments, tools, data and facilities needed. It should distinguish roles from named individuals where assignment is not yet known. A resource plan may include analysts, developers, testers, security specialists, database specialists, trainers, product owners and operational support. It should also identify scarce skills, procurement lead times, holidays, onboarding time and competing organisational commitments.

Estimating with uncertainty

Early estimates are uncertain because requirements, technology and productivity are not fully known. A three-point estimate can represent optimistic, most likely and pessimistic effort. The PERT expected estimate is:

where O is optimistic effort, M is most likely effort and P is pessimistic effort, all in the same unit. The method gives greatest weight to the most likely estimate and assumes the three values reasonably describe uncertainty. It is not a substitute for evidence and should not be used to create false precision.

If O = 4 person-days, M = 7 person-days and P = 16 person-days:

The spread also signals risk. A wide difference between optimistic and pessimistic values indicates that more investigation or contingency may be justified.

7. Effort and Cost Estimation

Effort is the amount of labour required; duration is elapsed calendar time. Cost is the monetary value of labour and other resources. These terms must not be used interchangeably.

A basic labour cost estimate is:

The symbol Σ means that the calculation is repeated and added across all roles. Effort must be measured in the period used by the rate. For example, 120 developer-hours multiplied by $35 per hour produces $4,200.

A total project estimate may be represented as:

The categories should be defined to avoid double counting. Contingency is an allowance for known-unknowns within the approved scope; it is not a licence to hide poor estimates. A management reserve, where used by organisational policy, is normally controlled separately for unforeseen work and should not be silently included in activity estimates.

Estimation approaches include:

• Analogous estimation: uses actual data from similar projects; quick but dependent on comparability.
• Bottom-up estimation: estimates work packages and aggregates them; detailed but time-consuming.
• Parametric estimation: applies a calibrated relationship between measurable size and effort; useful only when the relationship and data are credible.
• Expert judgement: draws on experienced practitioners; valuable but vulnerable to bias.
• Three-point estimation: represents uncertainty explicitly.

A good estimate records its basis, date, assumptions, exclusions, confidence range and owner. Estimates should be revised as knowledge improves. Changing an estimate is not necessarily poor performance; refusing to update an estimate in light of evidence is poor control.

8. Risk Management and Evidence-Based Decisions

A risk is an uncertain event or condition that could affect project objectives. A risk differs from an issue, which has already occurred. A dependency is a relationship in which one activity, team or organisation relies on another.

A risk register commonly contains:

A simple qualitative priority matrix may classify a risk as low, medium or high using probability and impact ratings. If numerical ratings are used, a common screening measure is:

Probability must be represented as a value from 0 to 1, or as a clearly defined rating scale. Impact must use a consistent scale, such as monetary loss, schedule delay or an agreed ordinal score. Multiplication of ordinal labels is only a rough prioritisation device; it does not produce a precise probability of loss.

Example. A risk has estimated probability 0.30 and a potential cost impact of $20,000. Its expected monetary exposure is 0.30 × $20,000 = $6,000, assuming the probability estimate is meaningful and the impact is represented as a monetary loss. This does not mean that exactly $6,000 will be lost; it is a decision-support estimate under uncertainty.

Responses should address causes where possible. For example, “hire more people if delayed” is weaker than “validate the integration interface with the supplier during the first sprint and build a test stub.” Risks should be reviewed regularly because their probability, impact and response may change.

Evidence-based decisions combine several evidence types:

• measured baseline data;
• stakeholder interviews and observation;
• prototypes and technical experiments;
• supplier quotations and service-level information;
• historical project performance;
• legal or security assessments; and
• explicit expert judgement.

Evidence must be relevant and reliable. A single enthusiastic stakeholder is not sufficient evidence of organisation-wide demand, and a vendor’s unverified performance claim should not be treated as an established fact.

9. Integrated Planning and Governance

Scope, schedule, cost, quality, resources and risk are interdependent. Reducing scope may shorten the schedule, but removing security testing may increase risk. Adding resources may increase cost and may initially reduce productivity while new members learn the system. Therefore, planning decisions should describe trade-offs rather than treating each constraint independently.

Governance defines who can make which decisions. A project may use a sponsor, steering group, product owner, project manager and technical authority. A responsibility assignment matrix, such as RACI, can clarify who is Responsible for doing work, Accountable for the outcome, Consulted for input and Informed of decisions. Each important deliverable should have a clear acceptance authority.

Change control protects the integrity of the baseline. A change request should state the requested change, reason, urgency and impact on requirements, schedule, cost, quality, risks, security and benefits. Approved changes update the relevant plan and baseline. Unapproved additions constitute scope creep.

A plan should also define reporting and control mechanisms: milestone reviews, risk reviews, quality gates, issue escalation, decision logs, configuration management and benefits tracking. Lightweight governance is appropriate for a small diploma-level project, but “lightweight” does not mean undocumented or uncontrolled.

10. Illustrative Case: Community Health Appointment Portal

This is a fictional illustrative case.

Background

A community health organisation receives appointment requests by telephone and paper form. Staff manually enter information into a scheduling system. Management proposes a web portal to reduce administrative workload and improve access.

Problem and initial evidence

A four-week review finds that staff process approximately 1,000 requests per month. Average manual entry time is 12 minutes per request, and incomplete forms create follow-up calls. The organisation has not yet established whether patients have sufficient internet access or whether the existing scheduling system provides a reliable integration interface.

Feasibility analysis

Technical feasibility is uncertain because the scheduling supplier has not confirmed its application programming interface. The team proposes a two-week proof of concept using test data. Operational feasibility requires an alternative telephone process for patients who cannot use the portal, accessibility testing and staff training. Legal and ethical analysis identifies health information as sensitive personal data; privacy impact assessment, least-privilege access and secure retention are required. Economic feasibility must include development, hosting, support, accessibility assurance and training rather than only programming cost.

Scope and WBS

The initial scope includes patient registration, appointment request submission, confirmation messages, staff review and an audit trail. It excludes clinical diagnosis, automated treatment recommendations and replacement of the scheduling system. The WBS includes requirements, interface prototype, portal development, integration proof of concept, security and accessibility testing, deployment, staff training and post-release support.

Estimate and risks

A bottom-up estimate identifies 420 person-hours of labour. At a blended labour rate of $45 per hour, labour cost is:

Additional hosting, testing, training and contingency are estimated separately. Major risks include unavailable supplier integration, data breach, low patient adoption and delayed accessibility review. The integration risk is assigned to the technical lead, with a trigger of failure to obtain interface documentation within five working days. Its response is early supplier validation and a tested manual export fallback.

Decision and outcome

The sponsor authorises a limited discovery phase rather than full development. The proof of concept confirms that appointment availability can be retrieved securely, but the supplier requires a new contract. The business case is updated to include that procurement cost and a longer schedule. The organisation then approves a phased pilot with two clinics, retains telephone access and defines success measures: at least 60% of eligible requests submitted digitally within three months, no critical security findings at release, and a reduction in average manual entry time.

Learning points

The case demonstrates that initiation is a learning process. A proposal was not rejected merely because uncertainty existed; uncertainty was converted into a targeted investigation. The scope excluded unsafe or unrelated features, the benefits were measurable, and operational inclusion was preserved. Most importantly, technical feasibility, privacy, accessibility and adoption were treated as connected project concerns rather than afterthoughts.

11. Challenges, Limitations and Contemporary Practice

Planning is affected by optimism bias, anchoring on a preferred solution, political pressure, incomplete requirements and availability bias from memorable projects. Teams may also confuse precision with accuracy by presenting a single number without a range or assumptions. Historical data should be used where available, but past productivity may not transfer to a new technology, team or domain.

Agile approaches do not remove the need for initiation and planning. They commonly replace a detailed long-range feature specification with a product goal, prioritised backlog, release forecasts, short iterations and frequent feedback. A high-level business case and feasibility assessment remain necessary, while detailed planning is progressively elaborated as evidence improves. Traditional predictive planning may be suitable where scope and regulation are stable; adaptive planning is valuable where learning and changing requirements are central. Hybrid approaches are often practical.

AI-assisted estimation, code generation and risk analysis can support planning, but outputs require human review. AI may reproduce historical bias, expose confidential project information or generate unjustified confidence. Teams should protect proprietary data, record significant assumptions, validate generated estimates against evidence and retain accountable human decision makers. AI should augment professional judgement, not replace governance or stakeholder consent.

Best practices include:

• define the problem before selecting a technology;
• involve affected users and operational staff early;
• record assumptions and confidence, not only point estimates;
• estimate the full lifecycle cost;
• use prototypes to test high-risk assumptions;
• include security, privacy, accessibility and maintainability from initiation;
• make exclusions explicit;
• link requirements, deliverables, tests and benefits through traceability;
• review risks and estimates as evidence changes; and
• obtain approval from an appropriately accountable decision maker.

Chapter Summary

Project initiation converts an idea into a proposal with a problem statement, sponsor, stakeholders and decision requirements. A business case explains the expected value of action and compares alternatives, including the option of doing nothing. Feasibility analysis examines technical, economic, operational, schedule, legal and ethical conditions. Financial measures such as net benefit, present value, ROI and payback can support decisions, but they depend on consistent assumptions and should be supplemented by strategic and social considerations.

Planning defines product and project scope, exclusions, assumptions, constraints and acceptance criteria. A deliverable-oriented WBS decomposes scope into estimable and assignable work packages. Scheduling uses dependencies, resource availability and realistic productivity; effort, duration and cost are related but distinct. Estimation should document its basis and uncertainty. Risk registers identify causes, events, effects, owners, triggers and responses, while evidence-based decision making combines data, experiments, stakeholder knowledge and professional judgement. Effective governance controls change, clarifies authority and protects quality, security, privacy and benefits throughout the project lifecycle.

Key Terms

Project initiation: The process of assessing and authorising a proposed project.

Business case: A structured justification for investing in a project.

Sponsor: The person accountable for organisational support and business justification.

Feasibility analysis: Investigation of whether a proposal can be delivered and sustained.

Technical feasibility: Assessment of technological capability, integration and supportability.

Operational feasibility: Assessment of process fit, adoption and organisational readiness.

Scope: The boundaries of the product and work included in a project.

Assumption: A planning statement treated as true for decision purposes.

Constraint: A limitation affecting project choices or delivery.

Acceptance criterion: A condition used to determine whether a deliverable is acceptable.

Work breakdown structure: A hierarchical decomposition of total project scope.

Work package: The lowest practical WBS component used for estimating and control.

Effort: The quantity of labour required to perform work.

Duration: Elapsed calendar time required by an activity.

Critical path: The sequence of activities determining the earliest possible completion date.

Risk: An uncertain event or condition that may affect objectives.

Issue: A problem or event that has already occurred.

Risk register: A controlled record of identified risks and their responses.

Contingency: An allowance for recognised uncertainty within approved scope.

Change control: The process for evaluating and authorising changes to an approved baseline.

Review Questions

Short Answer Questions

1. What is the purpose of a software project business case?
2. Distinguish effort from duration.
3. What information should be recorded in a risk register?
4. Why should a WBS include project management and testing activities?
5. What is the difference between a risk and an issue?

Long Answer Questions

1. Explain how technical, operational, economic, schedule, legal and ethical feasibility contribute to an initiation decision.
2. Describe how a WBS is developed and explain the 100% rule.
3. Discuss the relationship among scope, schedule, cost, quality, resources and risk.
4. Compare analogous, bottom-up, parametric and expert-judgement estimation approaches.
5. Explain how governance and change control help protect an approved project baseline.

Analytical / Application Questions

1. A proposed system has a development cost of $60,000, operating costs of $8,000 per year for two years, and expected benefits of $45,000 in year one and $40,000 in year two. Calculate the simplified two-year net benefit and explain two non-financial factors that should also influence the decision.
2. Construct a risk-register entry for a project whose external payment provider has not confirmed its integration interface. Include the cause, event, effect, owner, trigger and response.
3. A manager proposes adding three developers to reduce a schedule from six months to three months. Analyse the assumptions and risks behind this proposal and recommend evidence that should be collected before approval.

Multiple Choice Questions with Answers

Question 1

Which document primarily justifies why an organisation should invest in a proposed software project?

A. Business case

B. Test script

C. Configuration file

D. User interface mock-up

Correct Answer: A. Business case

Question 2

Which feasibility category focuses most directly on user adoption, workflow fit and organisational readiness?

A. Technical feasibility

B. Operational feasibility

C. Schedule feasibility

D. Economic feasibility

Correct Answer: B. Operational feasibility

Question 3

A project has benefits of $95,000 and total costs of $100,000 over the assessed period. What is its simplified net benefit?

A. $195,000

B. $5,000

C. −$5,000

D. −$95,000

Correct Answer: C. −$5,000

Question 4

What is the primary purpose of a work breakdown structure?

A. To assign salaries to employees

B. To decompose project scope into manageable work packages

C. To replace all requirements documents

D. To calculate tax on project expenditure

Correct Answer: B. To decompose project scope into manageable work packages

Question 5

An activity requires 16 person-days and has productive capacity of 0.8 person-days per calendar day. What is its estimated duration?

A. 12.8 days

B. 16 days

C. 20 days

D. 25 days

Correct Answer: C. 20 days

Question 6

Which statement correctly distinguishes effort from duration?

A. Effort is elapsed calendar time, while duration is labour quantity

B. Effort is labour quantity, while duration is elapsed calendar time

C. Effort and duration always have identical values

D. Duration is measured only in monetary units

Correct Answer: B. Effort is labour quantity, while duration is elapsed calendar time

Question 7

Using the PERT formula, what is the expected effort when O = 4, M = 7 and P = 16 person-days?

A. 6 person-days

B. 7 person-days

C. 8 person-days

D. 9 person-days

Correct Answer: C. 8 person-days

Question 8

Which item is an example of a project issue rather than a project risk?

A. The supplier may miss a future delivery

B. Users may reject the proposed workflow

C. The database server has already failed

D. A regulation may change next year

Correct Answer: C. The database server has already failed

Question 9

In the simple expression Risk exposure = Probability × Impact, what must be true for a monetary exposure calculation to be meaningful?

A. Probability and impact must use consistent, interpretable units

B. Impact must always be measured as a letter grade

C. Probability must be greater than 100%

D. The risk must already have occurred

Correct Answer: A. Probability and impact must use consistent, interpretable units

Question 10

Which practice best supports evidence-based planning?

A. Using a single optimistic stakeholder opinion

B. Hiding assumptions to avoid concern

C. Testing high-risk technical assumptions with a focused proof of concept

D. Refusing to revise estimates after new evidence appears

Correct Answer: C. Testing high-risk technical assumptions with a focused proof of concept