IT Operations, Service and Project Management

Introduction and Context

Information technology is valuable only when it reliably supports organizational goals. Designing a network, deploying an application, or purchasing cloud capacity does not by itself create business value. Value emerges when technology is operated, supported, improved, governed, and delivered through disciplined projects. IT operations and service management therefore connect technical capability with user experience, organizational performance, compliance, and cost control.

IT operations concerns the day-to-day running of technology services. It includes infrastructure administration, monitoring, incident response, backup, security operations, access management, and routine maintenance. IT service management (ITSM) provides the practices through which services are designed, delivered, supported, and continually improved. IT project management coordinates temporary efforts such as implementing an enterprise resource planning system, migrating to the cloud, or replacing a data centre.

Although operations and projects are distinct, they are interdependent. A project produces or changes a service; operations must then accept, support, secure, and measure that service. Poor handover can cause a technically successful project to become an operational failure.

Learning Objectives

After studying this chapter, you should be able to:

• distinguish IT operations, IT service management, and IT project management;
• explain the service desk, incident, problem, change, asset, and configuration management practices;
• describe monitoring, event management, service-level agreements, and ITIL concepts;
• apply the main stages of an IT project lifecycle;
• use scope, schedule, cost, quality, risk, communication, and team-management practices;
• interpret basic availability and earned-value measures;
• evaluate governance, ethical, security, and professional issues in IT service delivery.

IT Services and the Service-Value Perspective

A service is a means of enabling desired outcomes for customers without requiring them to manage specific costs and risks themselves. For example, a university email service enables communication and collaboration. Users generally do not want to operate mail servers, maintain storage arrays, or configure spam filters; they want dependable communication.

A useful distinction is between a customer, who defines service requirements and outcomes; a user, who uses the service; and a service provider, which supplies and manages it. One person may occupy more than one role. In a university, the registrar may be a customer for a student-records service, while students and lecturers are users.

Modern ITIL practice views service management as a system of value creation. Demand and opportunity enter the system; governance directs decisions; a service value chain transforms inputs into products and services; and continual improvement evaluates performance. Value is co-created: the provider supplies capabilities, but customers and users realize outcomes through their own activities.

The service value chain commonly includes:

• Plan: establish shared understanding of vision, status, and improvement direction.
• Improve: identify and prioritize improvements to services, practices, and the value system.
• Engage: understand stakeholder needs and maintain relationships.
• Design and transition: ensure that services meet requirements for quality, cost, and time.
• Obtain/build: acquire or create service components.
• Deliver and support: operate services and provide user support.

These activities are not necessarily performed once in a fixed sequence. A service may repeatedly move through design, deployment, operation, feedback, and improvement.

IT Operations and Service Delivery

IT operations converts designed capabilities into dependable daily performance. Typical operational functions include:

• infrastructure and network operations;
• server, database, endpoint, and cloud administration;
• identity and access administration;
• backup, recovery, and continuity operations;
• cybersecurity monitoring and response;
• batch processing and job scheduling;
• capacity and performance management;
• service desk and user support.

Operations must balance four objectives. Availability means that a service is usable when required. Performance concerns response time, throughput, and resource utilization. Security protects confidentiality, integrity, and availability. Resilience enables the service to withstand or recover from disruption.

Operational work may be preventive, detective, corrective, or adaptive. Patching is preventive; monitoring is detective; restoring a failed database is corrective; and scaling a platform for increased demand is adaptive. Effective teams document standard operating procedures, automate repeatable work, separate duties where necessary, and maintain auditable records.

Availability and Reliability Measures

Availability is often expressed as the proportion of an agreed service period during which a service is usable:

The time quantities must use the same unit, such as minutes per month. The calculation assumes that the organization has defined what counts as unavailable time and has excluded or included maintenance consistently. It does not by itself measure speed, correctness, or user satisfaction.

For example, suppose a service has 43,200 minutes in a 30-day month and is unavailable for 43.2 minutes. Its availability is:

(43,200 − 43.2) ÷ 43,200 × 100% = 99.9%

A small percentage difference can represent a significant operational commitment. In a 30-day month, 99.9% availability permits approximately 43.2 minutes of unavailability, while 99.99% permits approximately 4.32 minutes. These figures are useful for planning, but an SLA must state measurement windows, exclusions, service components, and consequences.

Mean time to repair (MTTR) is commonly calculated as total corrective-maintenance time divided by the number of repairs. Mean time between failures (MTBF) is the operating time between failures divided by the number of failures, when the organization uses that convention. Such measures are indicators, not complete definitions of reliability; scheduled maintenance, partial outages, and correlated failures require careful treatment.

The Service Desk and Support Practices

The service desk is the primary point of contact between users and the IT provider. It records, categorizes, prioritizes, communicates, and coordinates support work. It may also provide first-line diagnosis, password assistance, service requests, knowledge articles, and user education.

An incident is an unplanned interruption to a service or a reduction in service quality. Incident management seeks to restore normal service as quickly as reasonably possible while minimizing business impact. It does not necessarily seek the permanent technical cause during the initial response.

A service request is a pre-defined request from a user, such as requesting access, information, software installation, or equipment. Requests should follow authorized workflows rather than being treated as unpredictable incidents.

A problem is a cause, or potential cause, of one or more incidents. Problem management investigates underlying causes, records workarounds, and seeks permanent solutions. A known error is a problem that has been analyzed but not fully resolved, often with a documented workaround.

Incident priority normally combines impact and urgency. Impact concerns the extent of business harm; urgency concerns how quickly action is needed. A widespread outage affecting emergency services has high impact and high urgency. A minor inconvenience affecting one user may have lower priority, although context can change the assessment.

A support workflow generally includes logging, categorization, prioritization, initial diagnosis, functional or specialist escalation, resolution, user confirmation where appropriate, closure, and review. Closure should not erase evidence. Accurate records support trend analysis, problem management, compliance, and service improvement.

Knowledge management improves consistency by making verified solutions, diagnostic procedures, known errors, and user guidance available to support staff. Knowledge articles should have owners, review dates, access controls, and feedback mechanisms.

Asset and Configuration Management

An IT asset is a financially or operationally valuable component, such as a laptop, software licence, cloud subscription, server, or network device. Asset management emphasizes ownership, lifecycle, utilization, cost, and risk.

A configuration item (CI) is a component that must be managed to deliver an IT service. A CI may be a server, application, database, document, service, or relationship between components. Configuration management records the attributes and relationships needed to understand how services are constructed and changed.

A configuration management database (CMDB) stores information about CIs and their relationships. It is not automatically a complete or accurate inventory merely because a database exists. Data quality requires defined ownership, identification standards, discovery or verification, reconciliation, version control, and periodic review.

Consider a student-registration service. Its CIs might include a web application, authentication service, database cluster, firewall rules, DNS records, virtual machines, and support procedures. If the database cluster is changed without understanding its relationship to reporting services, a local technical change may create wider disruption.

Asset and configuration management supports:

• impact analysis before changes;
• license compliance and financial planning;
• vulnerability assessment;
• incident diagnosis;
• recovery and continuity planning;
• audit evidence;
• retirement and secure disposal.

Asset records should not expose unnecessary personal data. Disposal must address data sanitization, legal retention, environmental responsibilities, and chain of custody.

Monitoring, Events, and Capacity

Monitoring collects and interprets information about infrastructure, applications, networks, security controls, and user experience. Common measurements include CPU utilization, memory pressure, storage capacity, packet loss, latency, error rate, transaction success, queue length, and certificate expiry.

An event is a detectable occurrence significant to service management. Events can be informational, warning, or exceptional. Alerting should be based on actionable conditions rather than every unusual measurement. Excessive alerts create alarm fatigue, causing important signals to be ignored.

Effective monitoring has five properties:

1. Relevance: measures a service objective or operational risk.
2. Coverage: includes dependencies and user-facing symptoms, not only infrastructure.
3. Timeliness: detects problems early enough for useful action.
4. Context: provides ownership, severity, recent changes, and runbook links.
5. Governance: controls access, retention, privacy, and integrity of monitoring data.

Observability extends monitoring by using logs, metrics, traces, and contextual analysis to explain system behavior. Distributed applications especially benefit from correlation identifiers and end-to-end transaction tracing. Monitoring should also include synthetic transactions and real-user experience where appropriate, because a server can appear healthy while users cannot complete a business transaction.

Capacity management forecasts demand and ensures that resources are sufficient and economically appropriate. It considers current utilization, growth, peak demand, performance objectives, licensing constraints, and resilience requirements. Capacity planning should avoid both under-provisioning, which harms service, and excessive over-provisioning, which wastes funds and energy.

Service-Level Agreements and Continual Improvement

A service-level agreement (SLA) is a documented agreement between a service provider and a customer describing services, targets, responsibilities, measurement methods, reporting, and review arrangements. An SLA should be specific enough to be measurable and meaningful.

Typical SLA elements include:

• service description and scope;
• hours of service and support channels;
• availability and performance targets;
• incident response and restoration targets;
• maintenance windows and exclusions;
• customer and provider responsibilities;
• data protection and security obligations;
• reporting, escalation, review, and remedies.

An SLA target is not the same as an internal operational target. An organization may set an internal objective stricter than its contractual commitment to create a management margin. A supplier may operate under an underpinning contract that supports the provider's SLA.

SLAs can produce undesirable behavior if designed poorly. A team that is rewarded only for closing tickets may close them prematurely or avoid difficult problems. Measures should therefore combine speed, quality, recurrence, customer experience, and business outcomes. Important service measures include first-contact resolution, backlog age, repeat incidents, change failure rate, customer satisfaction, availability, and mean time to restore.

Continual improvement uses evidence to identify and prioritize beneficial changes. A practical improvement cycle is: identify the vision and baseline, assess current state, define a measurable target, create an improvement plan, implement changes, measure results, and embed successful practices. Root-cause analysis may use the five whys, fault-tree reasoning, Pareto analysis, or structured problem-solving. These methods are aids to investigation, not substitutes for evidence.

ITIL Concepts and Governance

ITIL is a widely used body of guidance for IT service management. It is not a mandatory software product, a single organizational structure, or a guarantee of service quality. Its practices must be adapted to organizational context.

Important ITIL practices include service desk, incident management, problem management, change enablement, service-level management, monitoring and event management, configuration management, information security management, deployment management, release management, and continual improvement.

Change enablement seeks to maximize successful changes by assessing risk, authorizing appropriate work, scheduling changes, and reviewing outcomes. Standard changes are low-risk, repeatable, and pre-authorized. Normal changes require assessment and authorization. Emergency changes address urgent situations and may use expedited governance, but they still require retrospective documentation and review.

Governance establishes direction, oversight, accountability, and decision rights. Management executes within that framework. Governance questions include: Who may approve access? Who accepts operational risk? How are suppliers monitored? What evidence demonstrates compliance? How are conflicts of interest handled?

Security and privacy must be integrated into service management. Least privilege, segregation of duties, strong authentication, secure logging, vulnerability management, incident notification, and data minimization are operational responsibilities. Regulations vary by jurisdiction and sector, but organizations should identify applicable privacy, records, accessibility, financial, health, and cybersecurity obligations. Contractual compliance does not eliminate professional responsibility.

The IT Project Lifecycle

A project is a temporary endeavor undertaken to create a unique product, service, or result. Operations are continuous; projects have a defined beginning and end, even if the resulting service continues indefinitely.

A typical IT project lifecycle contains the following stages:

1. Initiation: identify the problem or opportunity, stakeholders, expected benefits, constraints, and initial feasibility. A business case and project charter authorize further work.
2. Planning: define scope, deliverables, schedule, budget, quality approach, risks, communications, procurement, and resources.
3. Execution: coordinate people and suppliers, create deliverables, manage quality, and communicate progress.
4. Monitoring and control: compare actual performance with the approved baseline, manage changes, forecast outcomes, and address risks and issues.
5. Closure and transition: obtain acceptance, transfer knowledge and support responsibility, close contracts, capture lessons, and evaluate benefits.

Predictive approaches emphasize detailed upfront planning and controlled baselines. Agile approaches deliver in short iterations, obtain frequent feedback, and adapt priorities. Hybrid approaches use predictive governance for funding, architecture, or compliance while using iterative delivery for software. The appropriate approach depends on uncertainty, regulatory constraints, technological novelty, stakeholder availability, and the cost of late change.

Scope Management

Scope defines what the project will and will not deliver. A work breakdown structure (WBS) decomposes the total approved scope into manageable deliverables and work packages. The WBS is deliverable-oriented; it is not merely a list of personal tasks.

A scope statement should identify objectives, deliverables, acceptance criteria, assumptions, constraints, exclusions, and interfaces. Scope creep occurs when work is added without corresponding evaluation of time, cost, quality, resources, or risk. A change-control process does not mean rejecting all change; it means making change visible and deciding deliberately.

Schedule Management

A schedule identifies activities, dependencies, durations, resources, milestones, and constraints. Finish-to-start dependency is common: activity B cannot start until activity A finishes. Network analysis can identify the critical path, the sequence of activities with the greatest total duration. Delaying an activity on the critical path may delay the project unless corrective action is taken.

Estimates should state assumptions and uncertainty. Useful techniques include expert judgment, analogous estimation, parametric estimation, three-point estimation, and decomposition. For a three-point estimate using the PERT weighted mean:

where O is the optimistic estimate, M is the most likely estimate, and P is the pessimistic estimate. This formula is a planning approximation based on a beta-shaped distribution assumption; it should not be presented as a guarantee of actual duration.

If O = 2, M = 5, and P = 14 days, then E = (2 + 20 + 14) ÷ 6 = 6 days. The wide difference between optimistic and pessimistic values signals uncertainty that should be addressed through risk analysis.

Cost and Earned Value

A project budget includes labor, hardware, software, services, training, travel, contingency, and sometimes ongoing operational costs. Capital and operating classifications depend on accounting policy and jurisdiction; project managers should not assume that every technology purchase is treated identically.

Earned-value management compares planned work, completed work, and actual spending. The basic measures are:

• Planned value (PV): budgeted value of work scheduled by a date.
• Earned value (EV): budgeted value of work actually completed by that date.
• Actual cost (AC): actual cost incurred for completed work.

Two useful variances are:

The monetary units of SV and CV are budget currency. Positive SV means more budgeted work has been completed than planned; positive CV means the completed work cost less than its budgeted value. These interpretations assume consistent measurement of progress.

Performance indexes are:

An index of 1.00 indicates alignment with the relevant baseline; values below 1.00 indicate less progress or less cost efficiency than planned. These indicators should be interpreted with context and should not replace a schedule forecast or financial analysis.

For example, if PV = $100,000, EV = $80,000, and AC = $90,000, then SV = −$20,000, CV = −$10,000, SPI = 0.80, and CPI ≈ 0.89. The project has completed less work than planned and has spent more than the budgeted value of that completed work.

Quality, Risk, Communication, and Teams

Quality means that deliverables and processes meet agreed requirements and are fit for purpose. Quality assurance focuses on the adequacy of processes; quality control examines deliverables through reviews, tests, inspections, and acceptance checks. “More features” does not necessarily mean higher quality. Reliability, usability, security, maintainability, accessibility, and compliance may be more important than feature quantity.

A risk is an uncertain event or condition that may affect objectives; an issue is a problem that has already occurred. Risk management includes identification, analysis, response planning, ownership, monitoring, and escalation. Responses to threats include avoiding, mitigating, transferring, or accepting. Responses to opportunities include exploiting, enhancing, sharing, or accepting. A risk register should record probability, impact, proximity, owner, response, trigger, and residual risk.

Communication management identifies who needs what information, when, through which channel, and with what level of confidentiality. A technical dashboard may be appropriate for engineers, while executives may need a concise view of outcomes, risks, decisions, and benefits. Communication is also a listening activity; stakeholder concerns can reveal hidden requirements or resistance.

Team management involves role clarity, capability development, collaboration, conflict resolution, psychological safety, and recognition. A responsibility assignment matrix, such as RACI, can clarify who is responsible for performing work, accountable for the result, consulted before decisions, and informed afterward. One person may hold more than one role, but accountability should not be ambiguous.

Applied Case: University Digital Examination Service

The following is an illustrative case.

Background

A university wishes to replace paper-based examinations with a digital examination service. The service must support identity verification, question delivery, answer submission, accessibility accommodations, grading export, and retention controls. Examination periods create sharp demand peaks, and outages could affect fairness and academic schedules.

Problem

A previous pilot experienced login failures, unclear support ownership, incomplete device inventories, and late discovery that the grading system could not import the chosen file format. The university therefore treats the initiative as both a project and a future operational service.

Analysis

The project team maps stakeholders: students, lecturers, examination administrators, disability support staff, the service desk, information security, the vendor, and the data-protection officer. It defines acceptance criteria, including successful authentication under peak load, tested recovery procedures, accessible workflows, audit logging, and a documented support model.

The team creates a WBS covering procurement, configuration, integration, testing, training, pilot delivery, transition, and closure. Risks include vendor outage, identity-service dependency, insufficient capacity, unauthorized access, student device failure, and ambiguous responsibility during an examination. High-impact risks receive owners and response plans.

Asset and configuration management identifies the service, integrations, application components, examination devices, support documentation, and supplier contacts as relevant assets or CIs. Monitoring is designed around user transactions, authentication success, submission latency, queue depth, and storage capacity rather than server health alone.

Approach and Solution

A hybrid lifecycle is selected. Governance, procurement, privacy assessment, and acceptance criteria are planned predictively, while configuration and user-interface testing proceed in short iterations. A pilot is conducted with a small cohort. Change enablement requires approval for production changes during examination periods and defines an emergency procedure.

The service desk receives scripts and knowledge articles for common failures. A major-incident procedure defines technical leadership, examination-authority decisions, communications, evidence preservation, and escalation to the supplier. The SLA specifies support hours, response targets, availability expectations, maintenance exclusions, and responsibilities for student devices and network connectivity.

Before launch, the team conducts load testing, accessibility testing, security assessment, backup restoration, and a simulated outage. Operations accepts the service only after receiving runbooks, monitoring dashboards, configuration records, supplier contacts, training, and known limitations.

Outcome

The service is introduced first for low-risk assessments and then expanded. During the first examination period, monitoring detects increased authentication latency before widespread failure occurs. Capacity is temporarily increased, and a post-event review identifies a configuration improvement. The project closes after acceptance and knowledge transfer, while continual improvement remains an operational responsibility.

Learning Points

The case demonstrates that successful delivery is not merely installation. Scope and acceptance criteria protect the project; configuration records support diagnosis; monitoring must reflect user outcomes; SLAs clarify expectations; security and accessibility are quality attributes; and transition planning connects project work with sustainable operations.

Challenges and Contemporary Developments

IT services increasingly depend on cloud platforms, software-as-a-service providers, APIs, remote work, mobile devices, and globally distributed suppliers. Responsibility is shared: a cloud provider may secure its infrastructure while the customer remains responsible for identities, configurations, data, and application use. Contracts should address exit, portability, resilience, audit rights, data location, subcontractors, and incident notification.

Automation and artificial intelligence can classify tickets, summarize incidents, detect anomalies, generate documentation, and suggest knowledge articles. However, automation can amplify incorrect classifications, expose confidential data, or create opaque decisions. Human oversight is required for high-impact actions such as disabling accounts, changing production systems, or communicating a major incident. AI-generated recommendations should be traceable, tested, access-controlled, and evaluated for bias and error.

Other contemporary concerns include software supply-chain risk, ransomware, carbon and energy consumption, technical debt, platform dependency, and skills shortages. Sustainable operations consider efficient workloads, equipment lifecycle, responsible procurement, and disposal. Resilience requires more than backups: organizations should test restoration, define recovery objectives, identify dependencies, and rehearse decision-making.

Best-Practice Principles

1. Design services around outcomes and user needs, not infrastructure alone.
2. Record ownership, dependencies, decisions, and exceptions.
3. Separate incidents, requests, problems, changes, risks, and issues.
4. Measure quality and outcomes, not only ticket volume or closure speed.
5. Automate repeatable work, but preserve authorization and auditability.
6. Treat security, privacy, accessibility, and continuity as design requirements.
7. Use baselines for scope, schedule, and cost, and control changes transparently.
8. Involve operations, support staff, suppliers, and users before deployment.
9. Test monitoring, backup restoration, failover, and emergency procedures.
10. Learn from incidents and projects without blaming individuals for systemic weaknesses.

Chapter Summary

IT operations provides the daily technical and procedural work required to keep services available, secure, performant, and resilient. IT service management organizes the relationship between providers, customers, and users through practices such as service desk, incident, problem, change, service-level, monitoring, asset, and configuration management. ITIL offers adaptable guidance rather than a rigid implementation formula.

Service-level agreements define measurable expectations, while continual improvement uses evidence to reduce defects and increase value. Availability calculations, operational metrics, and monitoring help teams understand performance, but they must be interpreted within agreed definitions and business context. Asset and configuration information supports impact analysis, compliance, diagnosis, and safe change.

IT projects are temporary efforts that create or change services. Their lifecycle includes initiation, planning, execution, monitoring and control, and closure or transition. Scope, schedule, cost, quality, risk, communication, and team practices must be integrated. Earned-value measures provide an early indication of progress and cost efficiency, while agile, predictive, and hybrid approaches offer different ways to manage uncertainty.

The central professional lesson is that project delivery and service operation form a connected system. A service is successful only when it produces useful outcomes safely and sustainably after the project team has departed.

Key Terms

Availability: The proportion of agreed service time during which a service is usable.

Change enablement: The practice of assessing, authorizing, scheduling, and reviewing changes.

Configuration item (CI): A component managed as part of delivering an IT service.

Configuration management database (CMDB): A repository containing information about configuration items and their relationships.

Continual improvement: The systematic identification, prioritization, implementation, and evaluation of improvements.

Customer: A stakeholder who defines service requirements and outcomes.

Earned value (EV): The budgeted value of work actually completed by a specified date.

Incident: An unplanned interruption or reduction in the quality of an IT service.

IT operations: The activities required to run and support technology services.

IT service management (ITSM): Organizational capabilities and practices for delivering and managing IT-enabled services.

ITIL: A body of guidance for IT service management practices and service-value management.

Known error: A problem that has been analyzed and for which a workaround or explanation may be documented.

Problem: A cause or potential cause of one or more incidents.

Project: A temporary endeavor undertaken to create a unique product, service, or result.

Service desk: The primary point of contact between users and an IT service provider.

Service-level agreement (SLA): A documented agreement defining service expectations, targets, responsibilities, and measurement.

Service request: A pre-defined user request for information, access, assistance, or a standard service action.

Work breakdown structure (WBS): A hierarchical decomposition of total project scope into deliverables and work packages.

Review Questions

Short Answer Questions

1. What is the difference between an incident and a problem?
2. Why are configuration-item relationships useful during change assessment?
3. Identify three elements that should appear in an SLA.
4. What is the purpose of a service desk?
5. Distinguish a project from IT operations.

Long Answer Questions

1. Explain how ITIL practices can support reliable service delivery, and discuss why ITIL should be adapted to organizational context.
2. Describe the project lifecycle from initiation through transition, showing how scope, risk, quality, and communication are managed.
3. Explain asset management and configuration management, including the limitations of relying on an inaccurate or incomplete CMDB.
4. Discuss how monitoring, event management, capacity management, and continual improvement interact.
5. Compare predictive, agile, and hybrid project approaches and identify circumstances in which each may be appropriate.

Analytical / Application Questions

1. A university service has 43,200 agreed minutes in a month and 86.4 minutes of unavailability. Calculate its availability and explain whether the result alone proves that users experienced a good service.
2. A project has PV = $250,000, EV = $200,000, and AC = $220,000. Calculate SV, CV, SPI, and CPI, then interpret the results.
3. An organization repeatedly suffers outages after emergency changes. Design a service-management improvement involving change enablement, configuration information, monitoring, incident review, and stakeholder communication.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes an incident from a problem?

A. An incident is a planned change, while a problem is an unplanned request.

B. An incident is a service interruption, while a problem concerns an underlying or potential cause.

C. An incident is a configuration item, while a problem is a service-level target.

D. An incident is always caused by a supplier, while a problem is always caused internally.

Correct Answer: B. An incident is a service interruption, while a problem concerns an underlying or potential cause.

Question 2

What is the primary purpose of a service desk?

A. To replace all infrastructure administrators

B. To approve organizational budgets

C. To provide a primary contact point for users and coordinate support

D. To perform only software development

Correct Answer: C. To provide a primary contact point for users and coordinate support

Question 3

A service has 43,200 agreed minutes and 43.2 unavailable minutes. What is its availability?

A. 99.0%

B. 99.9%

C. 99.99%

D. 100.0%

Correct Answer: B. 99.9%

Question 4

Which item is most characteristic of configuration management?

A. Recording relationships among components that support a service

B. Calculating employee salaries

C. Selecting marketing slogans

D. Removing all change authorization

Correct Answer: A. Recording relationships among components that support a service

Question 5

If PV is $100,000, EV is $80,000, and AC is $90,000, what is the cost performance index?

A. 0.80

B. 0.89 approximately

C. 1.11 approximately

D. 1.25

Correct Answer: B. 0.89 approximately

Question 6

Which project document or structure decomposes approved scope into deliverables and work packages?

A. Service-level agreement

B. Risk trigger list

C. Work breakdown structure

D. Configuration baseline only

Correct Answer: C. Work breakdown structure

Question 7

Which response is most appropriate for a low-risk, repeatable, pre-authorized change?

A. Standard change

B. Emergency change

C. Unlogged change

D. Unapproved problem

Correct Answer: A. Standard change

Question 8

Which measure combines the extent of business harm with how quickly action is needed when setting incident priority?

A. Impact and urgency

B. Cost and procurement

C. Scope and quality

D. Availability and licensing

Correct Answer: A. Impact and urgency

Question 9

What does a positive cost variance in earned-value management generally indicate?

A. The project spent more than the budgeted value of completed work

B. The project completed no work

C. The project spent less than the budgeted value of completed work

D. The project has no remaining risks

Correct Answer: C. The project spent less than the budgeted value of completed work

Question 10

Why should AI-assisted operational actions receive human oversight?

A. AI systems cannot process any operational data

B. Automation may produce incorrect, biased, opaque, or unsafe actions

C. Human oversight makes monitoring unnecessary

D. AI is used only for financial accounting

Correct Answer: B. Automation may produce incorrect, biased, opaque, or unsafe actions