Project Planning, Risk and Resource Management

Introduction

An electrical-engineering dissertation is both a technical investigation and a managed project. A sound idea can fail because objectives are vague, components arrive late, test facilities are unavailable, software changes are uncontrolled, or design decisions are not documented. Project planning converts an approved research problem into an executable sequence of work. Risk management protects that plan from uncertainty, while resource management ensures that people, equipment, money, information, and time are available when needed.

These activities are not merely administrative. They influence technical quality, safety, reproducibility, academic integrity, and the credibility of the final dissertation. Planning should therefore begin before detailed design and continue through commissioning, analysis, writing, and archiving.

Learning Objectives

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

1. Translate project objectives into a work breakdown structure (WBS).
2. Develop schedules, dependencies, milestones, and realistic buffers.
3. Estimate costs and prepare a procurement plan.
4. Identify, analyse, respond to, and monitor project risks.
5. Allocate people, facilities, instruments, software, and funds.
6. Use version control and collaborative digital tools responsibly.
7. Record, evaluate, and approve changes to scope, design, schedule, and budget.
8. Explain how planning decisions affect safety, ethics, quality, and research validity.

1. Project Planning as a Systems Activity

Project planning integrates four questions:

• What must be delivered?
• How will the work be performed?
• When will activities occur?
• With what resources and controls will they be completed?

A dissertation normally produces several deliverables: a proposal, requirements specification, literature review, preliminary design, detailed design, prototype or simulation, test plan, results, dissertation, and presentation. Each deliverable should have an owner, acceptance criteria, due date, and evidence of completion.

Planning must distinguish scope from method. Scope defines what the project promises to deliver; method describes how it will be investigated. For example, “evaluate the efficiency of a photovoltaic maximum-power-point tracker under three irradiance conditions” is a measurable scope statement. “Use a microcontroller and laboratory solar simulator” is a method choice. Confusing the two makes later changes difficult to control.

A useful requirements statement identifies:

• functional requirements: what the system shall do;
• performance requirements: how well it shall do it;
• constraints: limits on voltage, cost, safety, size, time, or facilities;
• verification method: inspection, calculation, simulation, measurement, or demonstration;
• acceptance criterion: the evidence required to judge success.

Requirements should be traceable to design decisions and test results. A requirements traceability matrix links each requirement to its implementation and verification evidence.

2. Work Breakdown Structures

A WBS is a hierarchical decomposition of the total project scope into manageable work packages. It is deliverable-oriented rather than simply a list of personal activities. The top level is the project; successive levels divide it into deliverables, sub-deliverables, and work packages.

A suitable electrical-engineering WBS might be:

A work package should be small enough to estimate and assign but large enough to produce a meaningful result. “Develop and validate control algorithm” is usually more useful than “do software.” Each work package should specify its input, activity, output, responsible person, estimated effort, dependencies, and completion evidence.

The WBS is not a schedule. It answers what must be done, while the schedule adds duration and sequence. A WBS also provides the basis for cost estimation, risk identification, responsibility assignment, and progress reporting.

The 100% rule states that the WBS should include all work necessary to satisfy the approved scope, and no work outside that scope. It should avoid both omission and double counting. A responsibility assignment matrix, such as a RACI matrix, can identify who is Responsible, Accountable, Consulted, and Informed for each work package. In a student project, the student may perform most work, but supervisors, laboratory technicians, safety officers, and suppliers may have distinct responsibilities.

3. Scheduling and Milestones

A schedule represents activities, durations, dependencies, resources, and dates. Common representations are bar charts, network diagrams, and critical-path schedules.

A dependency describes the logical relationship between activities. The most common is finish-to-start: activity B cannot begin until activity A is complete. Other relationships include start-to-start, finish-to-finish, and start-to-finish, although they should be used only when technically justified.

A milestone is a zero-duration control point, such as “design review passed,” “prototype safely energised,” or “data collection complete.” Milestones are not merely calendar dates; they require objective evidence.

Critical Path Method

For a simple activity network, the earliest finish is calculated by a forward pass:

where ES_i is the earliest start of activity i, EF_i is its earliest finish, and d_i is its duration. For an activity with predecessors, ES_i is the greatest earliest finish among its immediate predecessors. The project duration is the largest final earliest finish.

A backward pass calculates latest allowable dates:

where LF_i is latest finish and LS_i is latest start. The total float is:

Activities with zero total float form a critical path under the stated assumptions. The critical path may change when durations, dependencies, or resource constraints change. Therefore, it is not a permanent label.

Worked example. Suppose A, B, and C have durations of 3, 4, and 2 days. B follows A, while C follows A and B is not its predecessor. A precedes both B and C. Thus A finishes on day 3; B finishes on day 7; C finishes on day 5. The project finishes at day 7, and A–B is the critical path. C has 2 days of float. This conclusion assumes unlimited resources and fixed durations.

Critical-path analysis alone ignores competition for resources. If the same oscilloscope or laboratory bench is needed by two parallel activities, the schedule must be resource-levelled. Resource levelling may extend the project and can create a new critical path.

Estimating Duration

Duration is elapsed calendar time; effort is labour time. A task requiring 12 person-hours may take three days if a student can work four hours per day, or much longer if equipment access is limited. Estimates should state assumptions, include review and rework, and distinguish optimistic confidence from evidence-based estimates.

A simple three-point estimate may be used when uncertainty is significant:

Here t_o, t_m, and t_p are optimistic, most-likely, and pessimistic durations, and t_e is the weighted expected duration. This is an approximation, not a guarantee; the assumptions of the chosen estimation method should be recorded.

4. Budgeting and Resource Planning

A project budget estimates the financial resources needed to achieve scope. Typical categories include components, printed circuit boards, fabrication, laboratory charges, software, travel, external testing, contingency, and disposal.

The basic cost estimate is:

where C_i is each planned cost and C_contingency is an explicitly identified allowance. Contingency should not conceal poor estimating or unapproved scope.

A student project resource plan should cover:

A bill of materials should include reference designator, description, rating, quantity, approved specification, supplier, unit price, lead time, and substitute policy. Electrical ratings must be checked rather than inferred from a similar-looking part. Substituting a capacitor, semiconductor, fuse, connector, or insulation system can change safety and performance.

Procurement Planning

Procurement begins with a specification, not a preferred product name. The specification should identify function, electrical and mechanical ratings, tolerance, environmental conditions, compliance requirements, quantity, and acceptance checks. Suppliers should be evaluated for technical conformity, lead time, reliability, warranty, documentation, and total cost—not price alone.

A procurement schedule should classify items as:

• long-lead items, which can determine the project start date;
• critical items, whose absence prevents a major test or build;
• ordinary consumables, which can be replenished easily;
• safety-critical items, which require approved specifications and inspection.

Order long-lead items after requirements and interfaces are stable. Keep evidence of quotations, approvals, delivery records, inspection, and nonconformance decisions. Sustainable procurement considers repairability, energy use, hazardous substances, packaging, and end-of-life disposal.

5. Risk Management

Risk is the effect of uncertainty on objectives. A risk may create a threat, an opportunity, or both. It is different from an issue: a risk may occur in the future, whereas an issue has already occurred.

Risk management is a continuous cycle:

1. establish context and objectives;
2. identify risks;
3. analyse likelihood and consequence;
4. select responses;
5. assign owners and action dates;
6. monitor triggers and residual risk;
7. communicate and review.

Risk identification techniques include design reviews, checklists, failure-mode analysis, supplier review, assumption analysis, laboratory walk-throughs, and consultation with supervisors and technicians. Categories should include technical, safety, schedule, cost, procurement, data, regulatory, environmental, and human factors.

A qualitative risk matrix often ranks likelihood and consequence on defined scales. A numerical score may be represented as:

where L is the likelihood rating and S is the severity or consequence rating. This is a prioritisation aid, not a physical probability law. Scales must be defined, consistently applied, and supplemented by professional judgement. A low numerical score must not override a legal or life-safety requirement.

A risk register should contain the risk statement, cause, event, consequence, category, initial rating, preventive actions, contingency actions, owner, trigger, due date, status, and residual rating. A good statement has the form: “Because of cause X, event Y may occur, leading to consequence Z.”

Risk responses include:

• avoid: change the design or method to remove the exposure;
• reduce/mitigate: lower likelihood or consequence;
• transfer/share: use a qualified service, contract, or insurance arrangement where appropriate;
• accept: consciously retain the risk within approved tolerance;
• exploit or enhance: increase the probability or benefit of an opportunity.

Safety risks require the hierarchy of controls: elimination, substitution, engineering controls, administrative controls, and personal protective equipment. PPE is important but should not be the sole control for accessible hazardous voltage, stored energy, rotating machinery, or high-temperature systems.

6. Quality, Safety, and Verification Controls

Planning and risk management are inseparable from verification. A design review should check requirements, calculations, interfaces, component ratings, thermal behaviour, protection, earthing, isolation, electromagnetic compatibility, and foreseeable misuse. Before energisation, a documented checklist should confirm visual inspection, continuity, polarity, insulation where appropriate, current limiting, emergency isolation, protective equipment, and competent supervision.

Measurement plans should define the measurand, instrument, range, resolution, calibration status, sampling method, environmental conditions, repetitions, and acceptance criterion. A result without conditions and uncertainty information may be difficult to reproduce. Raw data should be retained; processed plots must not replace original measurements.

Academic and professional integrity require that failed tests, changed methods, negative results, and anomalous data be recorded honestly. Selective deletion of inconvenient results is not acceptable. Personal data, confidential industrial information, and export-controlled or security-sensitive designs require appropriate access controls and approvals.

7. Version Control and Collaborative Digital Tools

Version control is a technical control against accidental loss and an evidential record of how a project developed. It should be used for source code, scripts, configuration files, text, models, and documentation where practical. Large binary files may require a managed repository or data-management system.

A useful workflow is:

1. create a repository with a clear directory structure;
2. commit small, coherent changes with descriptive messages;
3. use branches for experimental or high-risk changes;
4. review and merge changes deliberately;
5. tag stable releases used for tests or dissertation figures;
6. record software versions, dependencies, and build instructions;
7. back up the repository and test restoration.

A commit message such as “change ADC scaling and update test” is more useful than “miscellaneous.” Never store passwords, private keys, or personal data in a repository. Licence third-party code and datasets correctly. Collaboration tools should define permissions, ownership, naming conventions, decision records, and retention periods.

Reproducibility requires an environment record: operating system, compiler or interpreter version, libraries, instrument firmware, calibration information, parameter files, and random seeds where applicable. AI tools may assist with brainstorming, coding explanations, or language editing, but generated content must be checked, cited where required, and tested. Confidential project data should not be uploaded to an external AI service without authorisation. The student remains responsible for technical accuracy and academic authorship.

8. Change Control and Decision Documentation

Change is normal when experiments reveal new information. Uncontrolled change is scope drift. A change request should state:

• proposed change and reason;
• affected requirements, WBS elements, drawings, code, tests, and documents;
• impact on safety, quality, cost, schedule, procurement, and ethics;
• alternatives considered;
• decision authority and approval;
• implementation owner and due date;
• verification required after implementation.

A change log can use the following structure:

Configuration baselines are approved versions of requirements, design, software, or test procedures. A revised baseline should have a new identifier, date, author, and approval record. Decisions should record not only what was selected but why alternatives were rejected. This prevents repeated debate and supports dissertation reflection.

9. Integrated Case Study: Illustrative Battery-Monitoring Dissertation

Background

A student project proposes a low-voltage battery-monitoring unit for a laboratory energy-storage demonstrator. The unit must measure pack voltage and current, estimate state of charge using a documented method, log data, and provide an overvoltage warning. This is an illustrative case, not a substitute for institutional safety procedures.

Problem

The initial proposal assumes that a preferred current sensor will arrive within one week and that the laboratory can provide daily access. A review reveals a six-week supplier lead time, limited bench availability, and uncertainty about sensor offset and isolation. If these assumptions remain hidden, hardware assembly and testing may be delayed beyond the academic deadline.

Analysis

The student decomposes the project into requirements, literature review, architecture, sensor evaluation, procurement, firmware, enclosure, verification, analysis, and reporting. The WBS shows that sensor selection is on the procurement path and that measurement validation precedes state-of-charge claims. The risk register identifies late delivery, incorrect polarity, overcurrent, corrupted data, and insufficient test time.

Approach and Solution

The student compares three sensors against range, accuracy, isolation, bandwidth, cost, and lead time. A readily available device is selected, but the decision includes a calibration test and a design margin. A spare sensor is ordered only if its specification is compatible. The schedule includes an early breadboard measurement using available equipment, followed by a formal prototype test.

The student establishes a repository with folders for requirements, hardware, firmware, data, analysis, and reports. Raw data are write-protected after collection. A weekly review checks milestones, risk triggers, procurement status, and changes. Before energisation, the supervisor approves the safety checklist. A change request is raised when the selected sensor’s offset is larger than expected; the firmware filter is changed, the verification procedure is updated, and the effect on measurement uncertainty is documented.

Outcome

The prototype is completed with a shorter experimental campaign than originally planned, but the results are defensible because the claims are limited to the tested voltage, current, temperature, and sampling conditions. The final dissertation includes the original plan, approved deviations, test evidence, limitations, and recommendations for future work.

Learning Points

The central lesson is that early procurement investigation and explicit assumptions are technical activities. A risk register is useful only when it leads to action. Version control and change records improve not just organisation but reproducibility and academic credibility. Finally, a project should be judged against its verified requirements, not against an unrecorded expectation that changed during implementation.

10. Challenges and Limitations

Planning estimates are uncertain, especially for novel research. Excessive detail creates administrative burden, while insufficient detail hides dependencies. Critical-path schedules may be misleading when resources, learning curves, or experimental iteration dominate. Risk matrices can create false precision, and contingency budgets can encourage waste if not governed. Version control cannot guarantee valid science; it records change, but does not replace peer review, calibration, or sound experimental design.

Projects also face institutional constraints: purchasing rules, laboratory booking, safety approvals, intellectual-property agreements, data-protection requirements, and dissertation deadlines. Students should consult local policies before committing to hazardous experiments or external publication. Ethical practice includes truthful reporting, respectful collaboration, responsible environmental disposal, and recognition of contributions.

Best-Practice Checklist

Before implementation, confirm that:

• requirements have measurable acceptance criteria;
• the WBS covers the complete approved scope;
• dependencies, milestones, and resource constraints are visible;
• long-lead and safety-critical items are identified;
• the budget includes justified estimates and contingency;
• risks have owners, triggers, responses, and review dates;
• safety and verification plans are approved;
• repositories, backups, licences, and naming conventions are established;
• changes require documented impact assessment and approval;
• raw data, decisions, and final baselines will be archived.

Chapter Summary

Project planning transforms a dissertation objective into deliverables, work packages, dependencies, milestones, resources, and evidence of completion. The WBS defines scope; the schedule defines sequence and timing; critical-path analysis identifies activities that currently control completion; and resource levelling addresses shared facilities and equipment. Budgeting and procurement convert technical specifications into affordable, timely, and compliant acquisitions.

Risk management is a continuing process of identification, analysis, response, ownership, and monitoring. Safety risks require appropriate engineering and administrative controls, not merely numerical scores. Version control, reproducible environments, and collaborative digital practices preserve technical history and support trustworthy results. Change control prevents scope drift by recording impacts, alternatives, approvals, and verification. Effective project management therefore strengthens engineering quality, safety, academic integrity, and employability.

Key Terms

Work breakdown structure: Hierarchical decomposition of project scope into manageable deliverables and work packages.

Work package: A defined unit of work with an output, owner, estimate, and completion evidence.

Milestone: A zero-duration control point representing an important achievement or decision.

Dependency: A logical relationship governing the order of activities.

Critical path: The currently longest sequence of dependent activities controlling project duration.

Float: Allowable schedule movement without delaying a defined project or successor date.

Resource levelling: Adjusting activity timing to resolve resource over-allocation.

Bill of materials: Structured list of components, quantities, specifications, and procurement information.

Lead time: Time between placing an order and receiving an acceptable item.

Risk: Effect of uncertainty on project objectives.

Issue: A problem that has already occurred.

Risk register: Controlled record of risks, ratings, owners, responses, and status.

Residual risk: Risk remaining after controls or responses are applied.

Contingency: Planned allowance for identified uncertainty in cost or time.

Configuration baseline: Approved reference version of a requirement, design, code, or procedure.

Version control: System for recording, managing, and recovering changes to project artefacts.

Change request: Formal proposal to alter approved scope, design, schedule, or resources.

Traceability: Ability to link requirements to design, implementation, verification, and evidence.

Resource assignment matrix: Table showing responsibility and accountability for project work.

Verification: Evidence-based determination that a requirement or specification has been satisfied.

Review Questions

Short Answer Questions

1. What is the difference between a WBS and a project schedule?
2. Define a milestone and give one electrical-engineering example.
3. Why should a risk register assign an owner to each significant risk?
4. What information should be included in a bill of materials?
5. Why are raw data and software versions important for reproducibility?

Long Answer Questions

1. Explain how a WBS, schedule, budget, and procurement plan are mutually related.
2. Describe critical-path analysis, including the meaning and limitations of float.
3. Discuss the hierarchy of controls for a hazardous electrical prototype.
4. Explain how version control and configuration baselines support dissertation quality.
5. Describe a formal change-control process and its effect on scope, cost, and schedule.

Analytical / Application Questions

1. Construct a WBS and dependency network for a microcontroller-based motor-drive prototype. Identify at least three milestones and a likely critical path.
2. A sensor has a high likelihood of late delivery but a readily available alternative has lower accuracy. Analyse the technical, schedule, cost, and verification trade-offs and recommend a documented decision.
3. During testing, a prototype exceeds its expected temperature but still operates. Prepare a risk response, change request, and verification plan that address safety and research validity.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a work breakdown structure?

A. A list of calendar dates only

B. A hierarchical decomposition of the total project scope

C. A register containing only safety hazards

D. A record of supplier invoices

Correct Answer: B. A hierarchical decomposition of the total project scope

Question 2

In critical-path analysis, an activity with zero total float generally means that it

A. requires no resources

B. has no predecessor

C. can be delayed indefinitely

D. currently controls the project completion date

Correct Answer: D. currently controls the project completion date

Question 3

Which item is most appropriately treated as a milestone?

A. Design review passed

B. Write code for two hours

C. Purchase a resistor

D. Read one journal article

Correct Answer: A. Design review passed

Question 4

A risk register is most useful when each significant risk has

A. a decorative colour only

B. a guaranteed outcome

C. an owner, response, trigger, and review status

D. a supplier invoice attached

Correct Answer: C. an owner, response, trigger, and review status

Question 5

For activities A and B where B follows A, A takes 3 days and B takes 4 days. Ignoring resources and calendars, the earliest completion is

A. 3 days

B. 4 days

C. 7 days

D. 12 days

Correct Answer: C. 7 days

Question 6

Which procurement practice is technically strongest?

A. Choose the cheapest visually similar component

B. Specify ratings and acceptance criteria before selecting a supplier

C. Order only after testing is complete

D. Allow undocumented substitutions

Correct Answer: B. Specify ratings and acceptance criteria before selecting a supplier

Question 7

What is the principal purpose of a configuration baseline?

A. To prevent all future changes

B. To identify the approved reference version of an artefact

C. To replace laboratory safety procedures

D. To estimate supplier profit

Correct Answer: B. To identify the approved reference version of an artefact

Question 8

Which action best supports reproducible software-based research?

A. Overwrite the only copy after each run

B. Store passwords in the repository

C. Record versions, dependencies, parameters, and test data

D. Use unnamed files with automatic dates only

Correct Answer: C. Record versions, dependencies, parameters, and test data

Question 9

Which response changes the design to remove exposure to a hazard?

A. Acceptance

B. Avoidance

C. Transfer

D. Monitoring only

Correct Answer: B. Avoidance

Question 10

A formal change request should primarily evaluate

A. only whether the change is interesting

B. only the purchase price

C. scope, safety, quality, cost, schedule, and verification impacts

D. whether the original plan can be hidden

Correct Answer: C. scope, safety, quality, cost, schedule, and verification impacts