Project Management

Chapter learning objectives

1. Develop a business-case rationale that compares feasible alternatives and portfolio constraints.
2. Connect scope, schedule, cost estimates, benefits, stakeholders, and risks.
3. Distinguish quality assurance, quality control, and evidence-based acceptance.
4. Evaluate sourcing options, service commitments, vendor dependence, and transition costs.

Goals for this part

• Explain Business Case and Portfolio Fit.
• Explain Scope, Schedule, and Cost.
• Explain Benefits, Stakeholders, and Risk.

Business Case and Portfolio Fit

A business case explains the problem, feasible alternatives, expected benefits, costs, risks, and proposed decision. It should include the consequences of continuing with the current arrangement where that is feasible. A proposal that compares a new system only with an imaginary zero-cost alternative can misrepresent the decision.

Business Case and Portfolio Fit

A project portfolio is the set of proposed or active investments considered together. Projects compete for money, skills, management attention, and operating capacity. A worthwhile project can still be poorly timed if the organization cannot support it alongside other commitments.

Business Case and Portfolio Fit

For the service platform, managers should distinguish the capability delivered from the benefit expected. Installing a workflow feature is a deliverable. Reducing repeated data entry is an operational change. Lower cost or improved service is an outcome that also depends on adoption and process redesign. Assigning a benefit owner makes that connection more explicit.

Business Case and Portfolio Fit

Project management coordinates a temporary effort to achieve defined outcomes within its constraints. Cost-benefit analysis compares relevant costs and benefits over a stated period. A simple return on investment (ROI) can express estimated net benefits relative to an investment, but the meaning depends on the costs, benefits, and horizon included.

Business Case and Portfolio Fit

It should not be reported without those assumptions or treated as the only criterion for a consequential service decision.

Scope, Schedule, and Cost

Scope defines the work and results included. A schedule connects activities, dependencies, resources, and timing. A budget authorizes or plans spending. The three need a common understanding of the proposed work; an apparently precise cost estimate is unreliable when the scope is unclear.

Scope, Schedule, and Cost

A work breakdown structure decomposes work into manageable elements. Dependencies show which tasks rely on others. Adding people does not automatically shorten a schedule when the next activity cannot begin until a predecessor finishes or when the new staff need scarce expertise.

Scope, Schedule, and Cost: comparison

Scope, Schedule, and Cost

The GAO's cost-estimating guide emphasizes a defined baseline, assumptions, evidence, uncertainty, and updates using actual costs. These practices make estimates reviewable; they do not make uncertain work perfectly predictable.

Scope, Schedule, and Cost

Net present value (NPV) compares discounted future net cash flows with the investment. In a hypothetical example, an initial $1,000 outflow followed by $600 at the end of each of two years has NPV of about $41.32 at an assumed 10% discount rate: −1,000 + 600/1.10 + 600/(1.10²).

Scope, Schedule, and Cost

The undiscounted two-year net benefit is $200, giving a simple two-year ROI of 20%. The difference illustrates the effect of timing; neither calculation includes every possible risk or nonfinancial consequence. A discount rate for an actual decision requires an appropriate organizational basis.

Benefits, Stakeholders, and Risk

A project risk is an uncertain condition or event that could affect objectives. A useful risk description connects a cause or scenario to a consequence, an owner, and a response. “Data risk” is vague; “unreconciled customer records delay migration and undermine service continuity” guides investigation and action.

Benefits, Stakeholders, and Risk

Benefits also depend on stakeholders changing how they work. A project can deliver on schedule while employees continue using an older process because responsibilities were not redesigned. Change activities, training, and operating support should therefore be planned rather than treated as optional communication after delivery.

Benefits, Stakeholders, and Risk

The business case should be revisited as evidence changes. If migration costs rise or an expected benefit becomes unlikely, managers need to reconsider alternatives and priorities. Continuing only because money has already been spent can compound a poor decision. Planning supports informed choices throughout delivery, including decisions to reduce scope, change the approach, or stop work when justified.

Benefits, Stakeholders, and Risk

Risk management identifies, evaluates, responds to, and reviews uncertainty affecting objectives. Stakeholder management supports communication and involvement appropriate to people's roles and effects on or from the project. Project failure and implementation success need stated criteria: a project can miss a schedule yet deliver a useful improvement, or meet a deadline while failing the service need.

Benefits, Stakeholders, and Risk

A balanced review explains which outcome occurred and the evidence behind it.

Goals for this part

• Explain Quality Assurance and Quality Control.
• Explain Acceptance and Defect Management.
• Explain Usability and Delivery Quality.

Quality Assurance and Quality Control

Quality assurance (QA) concerns arrangements that provide confidence in the processes used to produce the result. Quality control (QC) examines outputs or performance to identify departures from requirements. The distinction is useful for management even though practices can contribute to both.

Quality Assurance and Quality Control

A requirements-review process can prevent ambiguity before configuration begins. Testing a configured workflow can identify an incorrect approval route. Neither makes the other unnecessary. Repeatedly detecting the same problem should prompt investigation of the process creating it.

Quality Assurance and Quality Control

For the service platform, a QA arrangement might require business review of data definitions and traceability from requirements to tests. QC might sample migrated records and test realistic submissions. Managers should identify the evidence each activity is intended to provide.

Quality Assurance and Quality Control

Completing a checklist is meaningful when it demonstrates that a relevant check occurred, rather than simply documenting that someone signed a form.

Acceptance and Defect Management

Acceptance criteria state the conditions under which an authorized party will accept a result. They should be agreed early enough to guide work and verification. Criteria such as “users like the system” need clarification through tasks, conditions, and evidence appropriate to the service.

Acceptance and Defect Management

Defect management records the problem, consequence, status, responsible party, and evidence of correction. Severity concerns impact; priority concerns when the organization will address the problem. A visually minor defect can be consequential if it hides a critical instruction.

Acceptance and Defect Management: comparison

Acceptance and Defect Management

Acceptance should record unresolved issues and responsibilities. Declaring every issue closed for the deadline can conceal risk rather than reduce it.

Usability and Delivery Quality

Quality includes the complete service experience as well as correct calculations. A workflow may satisfy a technical rule while requiring employees to perform unnecessary steps or leaving users unable to recover from an error. Observing realistic tasks helps reveal those problems.

Usability and Delivery Quality

Delivery quality also depends on data, requirements, usability, security controls, and vendor performance interacting. A correctly functioning interface with outdated records can produce the wrong business result. A secure service that authorized users cannot operate can fail its organizational purpose.

Usability and Delivery Quality

The project team should therefore assess the outcome across roles and handoffs. For the platform, that means following an application from preparation to review, decision, and communication, including exceptions. Managers need both evidence that requirements were met and evidence that the resulting process addresses the original problem.

Usability and Delivery Quality

A launch date is a delivery milestone; service quality must continue to be monitored after it.

Goals for this part

• Explain Build, Buy, and Outsource.
• Explain SaaS, Managed Services, and SLAs.
• Explain Vendor Dependence and Hidden Costs.

Build, Buy, and Outsource

Build uses internal or contracted development to create a solution. Buy obtains a product or package and adapts organizational work or configuration to it. Outsource assigns specified work to an external provider. The options can overlap: a purchased package may be hosted by one provider and configured by another.

Build, Buy, and Outsource

The appropriate comparison considers process fit, required differentiation, available skills, timing, integration, control, and operating consequences. Internal development can support specialized needs while requiring maintenance capability. A standard package can reduce some development effort while constraining how the organization works.

Build, Buy, and Outsource

The service platform's business case should compare feasible arrangements against the same requirements. A low initial price is not comparable with a broader offer unless the included work is understood. Managers should identify what the organization still must provide, including data preparation, decisions, user support, and coordination among suppliers.

SaaS, Managed Services, and SLAs

Software as a service (SaaS) provides a provider-operated application. A managed service assigns defined operating work to a provider. A service-level agreement (SLA) specifies agreed service expectations, measurement, responsibilities, and remedies. Details depend on the agreement and service.

SaaS, Managed Services, and SLAs

An availability target needs a defined service boundary, measurement period, exclusions, and response when the target is missed. A service credit may compensate for part of a fee without covering the organization's actual disruption. Managers should not mistake a contractual remedy for continuity of essential work.

SaaS, Managed Services, and SLAs: comparison

SaaS, Managed Services, and SLAs

The table helps make supplier promises concrete. Technical procurement specialists and appropriate professional review may be needed to establish the final arrangement.

Vendor Dependence and Hidden Costs

Dependence can arise from specialized configuration, proprietary record formats, integration work, staff expertise, and the provider's control of changes. A nominal right to export data is less useful if the export lacks relationships or cannot be interpreted without additional work.

Vendor Dependence and Hidden Costs

Hidden costs are costs omitted or underestimated in the initial comparison, such as migration, additional support, integration maintenance, user training, and transition at the end of a relationship. They are not necessarily concealed deliberately; they may simply fall outside the initial purchasing boundary.

Vendor Dependence and Hidden Costs

For the platform, an exit scenario should ask how records, workflows, access, and user support would continue if the provider changed terms or the organization chose another arrangement. A realistic transition estimate can alter the sourcing decision.

Vendor Dependence and Hidden Costs

Selecting a provider is the beginning of vendor management, which includes monitoring performance, maintaining internal knowledge, and reviewing whether the service continues to meet the business need.

Reading and assignments

• Chapter reading
• Curated references
• Preview, Case Study, and Homework