Attend to project initiation management processes

Project initiation is the formal first phase of the project life cycle in which a project is officially recognised, its purpose and boundaries are established, and the foundational documents that will govern all subsequent work are created or reviewed. In practice, the initiation phase produces two primary artefacts: the project charter (sometimes called a project brief) and the project scope statement. The charter authorises the project's existence and gives the project manager the authority to apply resources; the scope statement then translates that authority into a precise definition of what work will be done, what deliverables will be produced, and — critically — what is excluded.

For a qualifying project manager completing workplace activity WM-01-WE01, 'observing and assisting with project initiation processes' means being physically present and intellectually engaged during the actions that lead to these documents. This includes watching how an experienced practitioner reads and interrogates a charter or brief, how they surface the client's actual needs (which frequently differ from the client's stated wishes), how they develop a project management approach suited to the specific context, and how all of this thinking gets compressed into a scope statement that the entire team and client will later treat as the boundary of the project.

It is important to distinguish initiation from planning. Initiation answers the questions 'Should we do this project?' and 'What, at the highest level, does it involve?' Planning then answers 'How exactly will we do it, in what sequence, with what resources, over what timeline?' A learner who conflates the two risks producing a scope statement that is actually a detailed schedule — a very common early-career error. The workplace activity is deliberately scoped to initiation precisely so that the learner builds a clear mental model of this boundary.

The core purpose of project initiation — and of this workplace activity — is to prevent the most expensive category of project failure: doing the wrong project, or doing the right project in the wrong way from the very first day. Research across industries consistently shows that errors made in initiation are far more costly to correct later than errors made during execution, because every subsequent decision, resource allocation, and stakeholder expectation is built on top of the initiation documents.

From the learner's perspective, the activity exists to make abstract classroom knowledge tangible. Reading about a project charter in a textbook gives you the vocabulary; watching a seasoned project manager work through one in a live meeting shows you the judgment involved — the pauses, the questions they ask the client, the phrases they probe, and the risks they mentally flag before anything is written down. That observational experience cannot be replicated through simulation.

From the qualification's broader perspective, this workplace activity exists to anchor the theoretical components of project management to real professional practice. A project manager who has never witnessed initiation done well has no calibration point: they do not know what 'good' looks like, and they are therefore unlikely to produce it themselves. By observing and assisting an experienced practitioner, the learner gains a reference experience they can draw on throughout their career.

Client consultation during initiation also exists for a specific reason: clients rarely articulate requirements in project management language, and they frequently confuse requirements (what the project must achieve) with solutions (how they imagine it will be achieved). Part of the purpose of structured client consultation at initiation is to separate these two, ensuring that the scope statement captures requirements — leaving room for the project manager to propose the optimal solution rather than being locked into the client's first idea.

A learner sitting in on initiation meetings will encounter a dense cluster of terms that experienced practitioners use interchangeably or in subtly different ways. Knowing these before stepping into the observation gives the learner the cognitive bandwidth to focus on the judgment being exercised rather than decoding the language being used.

Project charter / project brief: A document issued by a sponsor or client that formally authorises the project. In some organisations, particularly in the public sector or engineering fields, the word 'brief' is used. In others, 'charter' is the standard. The document typically contains the project's purpose, high-level objectives, key constraints (time, cost, quality), identified risks, and the names of the sponsor and project manager. It confers authority on the project manager to use organisational resources.

Project scope statement: The document that formally defines what the project includes and excludes. It converts the high-level authorisation of the charter into a concrete boundary. A well-written scope statement specifies deliverables, acceptance criteria, assumptions, constraints, and explicit exclusions. It becomes the primary tool for managing scope creep.

Scope creep: The gradual, often unnoticed expansion of project work beyond what the scope statement authorised. Initiation is the first line of defence against scope creep, because a vague scope statement almost guarantees it.

Stakeholder: Any person or organisation that can affect or be affected by the project's outcome. During initiation, identifying stakeholders early is critical because different stakeholders have different requirements, and failing to surface a stakeholder's requirements at initiation typically means discovering them much later at much greater cost.

Assumptions and constraints: Assumptions are things the project team accepts as true for planning purposes without proof. Constraints are limitations imposed on the project (budget caps, regulatory deadlines, available technology). Both must be documented during initiation because they shape all subsequent decisions.

Project management approach: The overarching methodology or framework the team will use (e.g., waterfall, agile, PRINCE2-aligned, or a hybrid). Selecting the approach during initiation determines how the rest of the project will be structured, what documents will be produced, and how decisions will be made.

Deliverable: A specific, verifiable output of a project. Deliverables must be defined with enough precision that both the team and the client agree on when they have been produced to an acceptable standard.

Acceptance criteria: The specific conditions that a deliverable must meet before the client or sponsor will formally accept it. Absent clear acceptance criteria, 'done' is whatever the client decides it means on the day.

Several foundational principles govern how skilled project managers approach initiation. Understanding these principles helps the learner interpret what they observe — not just what the mentor is doing, but why.

Progressive elaboration with controlled scope: At initiation, not everything can be known. The principle of progressive elaboration acknowledges that detail will emerge over time; the job of initiation is not to define everything but to define enough to start planning responsibly. The key discipline is ensuring that as detail emerges it is incorporated through a formal change process rather than simply absorbed into the project without adjustment to the plan.

The cost of late discovery: Problems identified at initiation cost a fraction of what they cost to fix at execution or closure. This principle motivates the rigour that experienced project managers bring to reviewing a charter: every ambiguity they resolve now saves many times that effort later. A learner observing this rigour may initially perceive it as excessive caution; understanding this principle reframes it as economic prudence.

The primacy of the client's underlying need: Clients present requirements; good project managers uncover needs. A client who says 'we need a new building' may have an underlying need for more workspace, which could be met through a refurbishment, a lease arrangement, or a redesign of existing space. Initiation is the appropriate moment to ask the question behind the question, because once a scope statement says 'construct a new building' the conversation about alternatives is essentially closed.

Authority must be explicit: A project manager who begins work without a properly authorised charter has no formal mandate. If priorities shift, resources are reallocated, or a dispute arises, they have nothing to point to. The project charter is not bureaucratic formality — it is the project manager's licence to act.

Assumptions are risks in disguise: Every assumption documented during initiation is effectively a risk statement: 'We are proceeding as if X is true. If X turns out to be false, the project will be affected in Y way.' Experienced project managers treat assumptions with the same seriousness as identified risks, because that is what they are.

Stakeholder alignment reduces downstream conflict: The earlier stakeholder requirements are surfaced and reconciled, the less likely they are to collide during execution. Initiation is the moment to identify competing stakeholder interests and either resolve them or document that they remain unresolved and require a governance decision.

The following sequence describes how experienced project managers typically move through initiation, and therefore what a learner observing and assisting with WM-01-WE01 is likely to witness across the initiation period. The exact order may vary by organisation and project type, but the core actions are consistent.

Step 1: Receive and read the project charter or brief in full Before any meeting, the project manager reads the entire charter or brief independently. This first reading is not passive — they annotate it, highlighting unclear phrases, missing information, internal contradictions, and statements that will require verification. A learner preparing for an observation session should do the same, so the observation is a comparison of interpretations rather than an introduction to the document.

Step 2: Identify the key requirements and needs of the project This involves separating what the document says (the stated requirements) from what the sponsor or client actually needs (the underlying business or organisational driver). The project manager asks: Why does this project exist? What problem does it solve? What would happen if the project were not done? These questions reframe requirements in terms of purpose rather than prescription.

Step 3: Identify stakeholders Using the charter as a starting point, the project manager maps all parties who have an interest in or will be affected by the project. This typically produces a stakeholder register or at minimum a stakeholder list. For the scope statement to be complete, all stakeholder requirements need to be collected, which means knowing who all the stakeholders are before requirements-gathering begins.

Step 4: Conduct client consultation A formal or semi-formal meeting with the client is held to validate understanding of the requirements, surface unstated needs, negotiate constraints, and confirm acceptance criteria for key deliverables. This is not a simple question-and-answer session — it is a structured conversation designed to produce shared understanding. The learner should observe how the experienced project manager phrases questions: open questions to surface needs, closed questions to confirm specific facts, and reflective questions to verify that both parties mean the same thing by the same words.

Step 5: Develop the project management approach Based on the nature of the project, its complexity, the client's preferences, regulatory requirements, and the organisation's standard practices, the project manager selects and documents the methodology and governance framework that will be used. This might be a standard methodology like PMBOK-aligned waterfall, an agile approach, or a hybrid. The approach determines what documents will be produced, how decisions will be escalated, and how progress will be reported.

Step 6: Draft the project scope statement Using the charter, the client consultation outputs, and the decisions made about approach, the project manager drafts the scope statement. This document should include: a project description and objectives, a list of deliverables with their acceptance criteria, identified assumptions, documented constraints, explicit exclusions (what is NOT in scope), and an initial list of risks. Every exclusion is as important as every inclusion — an exclusion prevents the client from later arguing that something was implicitly included.

Step 7: Review and validate the scope statement The draft scope statement is shared with the sponsor, key stakeholders, and team leads for review. The project manager facilitates discussion of any contested items, incorporates agreed changes, and obtains formal sign-off. A signed scope statement is the foundation of every subsequent change control decision.

Step 8: Capture initiation documentation in the project file All documents produced during initiation — the annotated charter, meeting minutes from client consultations, the stakeholder list, and the signed scope statement — are filed in the project management information system or document repository. This creates the audit trail that will be referenced if disputes arise later.

Experienced project managers rely on a standard toolkit during initiation, and a learner on placement is likely to encounter most of the following. Familiarity with these tools in advance of the observation makes the learner a more useful assistant and enables more productive questions.

Project charter template: Most organisations have a standard charter format that includes fields for project purpose, objectives, scope summary, key milestones, budget authority, identified risks, and the signatures of the sponsor and project manager. Some organisations use a single-page brief for smaller projects and a multi-section charter for complex ones. The learner should ask to see the organisation's standard template before the first initiation meeting.

Stakeholder register: A structured list of all identified stakeholders, typically recording their name, role, interest in the project, influence level, and communication preferences. During initiation this document begins as a short list derived from the charter and grows as consultation reveals more affected parties.

Requirements collection tools: Structured interviews, facilitated workshops, questionnaires, and observation of current processes are all used to collect requirements from stakeholders. At initiation the requirements are high-level; detailed requirements gathering is usually a planning-phase activity. The learner is likely to observe structured interviews during client consultation.

Scope statement template: Like the charter, most organisations have a standard format. Key sections include: project and deliverable descriptions, acceptance criteria per deliverable, assumptions log, constraints log, exclusions list, and a change control clause. The exclusions list is often the most revealing section — a sparse exclusions list usually means the project manager has not thought carefully about the project boundary.

Assumptions and constraints log: A simple table listing each assumption or constraint, the basis for it, its potential impact if it proves incorrect, and who owns the responsibility to monitor it. This log becomes a risk input during planning.

Meeting agenda and minutes templates: Client consultation meetings during initiation should be formally minuted. The agenda ensures the meeting covers all required topics; the minutes create the agreed record that both parties sign. A learner assisting with a client consultation meeting may be asked to take the minutes — a task that requires active listening, accurate recording, and enough project management knowledge to distinguish a significant decision from a passing comment.

RACI matrix (sometimes introduced at initiation): A tool that maps deliverables or activities to roles (Responsible, Accountable, Consulted, Informed). Some project managers begin developing this during initiation to clarify stakeholder roles; others defer it to planning. The learner should ask where their mentor places this tool in the sequence and why.

Digital project management platforms: Many organisations use tools like Microsoft Project, Asana, Monday.com, or similar platforms. During initiation, these tools are often used to capture the scope statement, set up the project folder structure, and record initial stakeholder information. The learner should observe how the organisation's chosen tool is configured during initiation, as the choices made here affect how information flows throughout the project.

Initiation generates more documentation than most junior project managers expect, and the discipline of record-keeping during this phase has consequences that extend across the entire project life cycle. Understanding why each record exists helps the learner take record-keeping seriously rather than treating it as administrative overhead.

The project charter or brief (received document): Even though the charter is typically issued by the sponsor rather than created by the project manager, the project manager must file a copy — ideally the signed, dated version — in the project file. This document is the legal and organisational authority for the project's existence. If the project is ever audited, cancelled, or disputed, the charter is the first document anyone will ask for.

Annotated working copy of the charter: Experienced project managers often retain their own annotated copy — the one with their handwritten notes, highlighted questions, and margin comments — as a record of their thinking at initiation. This is not required by any formal standard, but it is professionally valuable: it shows the questions that were asked, which demonstrates professional diligence if a dispute arises later about what was understood at the outset.

Stakeholder register: As noted above, this living document begins at initiation and must be maintained throughout the project. The version produced at initiation represents the project manager's understanding of the stakeholder landscape at the start; later versions record how that understanding evolved. In South African public-sector projects, stakeholder documentation is often a compliance requirement.

Client consultation records: All meetings with the client during initiation must be minuted. Minutes should record who attended, what was discussed, what decisions were made, and what action items were assigned (with responsible person and due date). Both parties should sign or formally acknowledge the minutes within a specified period. Unsigned or informal records of client consultations are a significant risk: if the client later disputes what was agreed, unsigned records have little evidentiary weight.

The signed project scope statement: This is the single most important document produced at initiation. It must be formally signed by the project sponsor and, where appropriate, key client representatives. The signature represents formal agreement that the scope as defined is what the project will deliver. Any subsequent change must go through formal change control.

Assumptions and constraints log: Filed as part of the initiation documentation and reviewed regularly during planning and execution. Changes to the status of an assumption (e.g., an assumption that proves false) should trigger a review of the scope statement and project plan.

Workplace logbook entry: Specific to this qualification, the learner must document one specific instance of observing or participating in initiation in their logbook. The logbook entry must describe the situation, what was done (by them or their mentor), and what they would do differently on a future project. This reflective requirement is not merely bureaucratic — it forces the learner to extract transferable learning rather than simply recording events.

Scenario: Retail fit-out project in Johannesburg

A property development company has been awarded a contract to fit out a 1,200 square metre retail space for a clothing retailer in a new shopping centre in Sandton. The client has provided a two-page brief describing their vision: 'a modern, high-end feel with excellent lighting and a clear customer flow from entrance to fitting rooms to cashiers.'

The senior project manager, Nomsa, is joined by her learner, Luyanda, who has read the brief in advance and flagged three questions: (1) What does 'high-end feel' mean in measurable terms? (2) Is the client expecting the project team to procure fittings and fixtures, or will the retailer supply them? (3) The brief mentions a 'completion date' of eight weeks but does not clarify whether this means construction complete, snag-list resolved, or ready for the retailer to begin their own fit-out.

Nomsa opens the client consultation meeting by thanking the client for the brief and immediately surfacing these three questions. The discussion reveals that 'high-end feel' means specific finishes — polished concrete floors, recessed LED lighting, and a branded feature wall — all of which the client has a specification sheet for (but did not attach to the brief). The fittings and fixtures question reveals a critical gap: the client assumed the project team would procure them; the project team's budget assumed the client would. This is resolved in the meeting by adjusting the project budget. The completion date is clarified as 'construction complete and signed off by the client's interior designer' — not snag-list cleared, which gives Nomsa more flexibility on minor defects but creates a risk around the designer's availability.

After the meeting, Nomsa and Luyanda draft the scope statement together. Luyanda is asked to write the exclusions list. His first draft has only two exclusions: 'Retailer's own stock and merchandising' and 'IT and POS systems.' Nomsa adds twelve more, including: the retailer's own signage, staff training, landlord-controlled areas of the building, external facade work, and ongoing maintenance post-handover. Each exclusion corresponds to something a client in a previous project had assumed was included. She explains to Luyanda: 'Every item on this list is an argument I have already won. Writing it down means I won't have to win it again on this project.'

Luyanda's logbook entry for this session notes the moment he realised that the exclusions list is not a defensive document — it is a shared agreement about the project's shape. He notes that on a future project he would ask the client to review the exclusions list specifically, rather than just the deliverables section, because that is where the most consequential assumptions are hiding.

Scenario: IT system upgrade for a municipal water utility

This contrasting example illustrates initiation in a public-sector context with a more complex stakeholder environment and formal regulatory requirements.

A project manager, Andile, is assigned to lead an upgrade of the billing and customer management system for a mid-sized municipality in the Eastern Cape. The project charter has been issued by the municipal manager's office following a council resolution, which means it carries formal legal authority but was written by administrators, not project managers, and contains language that is legally precise but operationally vague.

Andile's first initiation action is not a client meeting — it is a review of the council resolution and the associated service delivery and budget implementation plan (SDBIP) to understand the strategic intent behind the project. This is a layer of initiation that does not exist in private-sector projects: public-sector project managers must ensure their scope statement is consistent with the council's resolution and the budget allocation, because any deviation is potentially an irregular expenditure under the Municipal Finance Management Act (MFMA).

His learner, Sipho, sits in on the initiation meetings. He observes that Andile conducts three separate client consultations before drafting the scope statement: one with the Chief Financial Officer (whose team will use the new system's billing functions), one with the customer services director (whose agents will use the customer management functions), and one with the IT director (who will own and maintain the system post-implementation). Each stakeholder has different requirements, and several of these requirements conflict — the CFO wants maximum automation of payment processing, while the customer services director wants flexible manual overrides. Andile documents both sets of requirements in the scope statement as 'requirements to be resolved through system configuration during the design phase,' meaning he does not attempt to resolve the conflict at initiation but does flag it formally.

Sipho's logbook entry reflects on the difference between this experience and the retail fit-out example he had read about. In the municipal context, initiation took three weeks rather than a few days, involved far more stakeholders, required cross-referencing to legislative instruments, and produced a scope statement that was a formal document requiring sign-off at a senior management committee meeting. He notes that the principles were the same — identify requirements, resolve ambiguity, define what is in and out of scope — but the complexity, formality, and time required were dramatically different. This observation forms the basis of his 'what I would do differently' reflection: on a future public-sector project, he would build the stakeholder consultation schedule into the project timeline from day one, because the multiple sign-off layers make the initiation phase significantly longer than a private-sector equivalent.

Understanding the mistakes that commonly occur during project initiation — and the reasons those mistakes happen — gives the observing learner a framework for noticing when they are being avoided and understanding why certain practices that might seem excessive are in fact important protections.

Mistake 1: Accepting the charter without questioning it New project managers frequently treat the project charter as an authoritative, complete document and begin planning from it without critically examining its contents. Experienced practitioners know that charters are written by sponsors or clients, not by project managers, and therefore reflect the issuer's perspective and assumptions. A charter that says 'the project will be completed within six months at a cost not exceeding R2 million' may be aspirational rather than evidence-based. Failing to surface this at initiation means inheriting an impossible constraint. This mistake happens because junior project managers are conditioned to defer to senior stakeholders — a reasonable reflex that becomes problematic when it suppresses legitimate professional scrutiny.

Mistake 2: Conflating initiation with planning A scope statement that includes a detailed schedule, resource assignments, and a risk register is actually a project plan — it has gone well beyond what a scope statement is for. This happens because learners (and some junior project managers) try to complete all project thinking in one step, not yet having internalised the different purposes of different phases. The consequence is a document that is too detailed to get stakeholders to agree on at the outset, and too rigid to accommodate the legitimate evolution of requirements during planning.

Mistake 3: Inadequate client consultation One meeting is rarely sufficient to surface all stakeholder requirements. Experienced project managers return to clients multiple times, ask questions from different angles, and sometimes hold separate sessions with different stakeholder groups to avoid group-think or social dominance suppressing minority views. Junior project managers often conduct one meeting, fear being perceived as disorganised if they return with more questions, and draft a scope statement that reflects what one person said in a single session. The consequence is a scope statement that the client later contests.

Mistake 4: Omitting the exclusions list A scope statement without explicit exclusions is fundamentally incomplete. Exclusions define the project boundary as clearly as inclusions do — perhaps more so, because they prevent the most common form of scope creep (the 'but I assumed that was included' conversation). This mistake happens because writing exclusions requires the project manager to think adversarially about their own scope statement — to ask 'What could a stakeholder reasonably assume is included that I have not explicitly included?' — which is a more sophisticated cognitive task than describing what is included.

Mistake 5: Not obtaining formal sign-off on the scope statement A scope statement that has been reviewed but not formally signed is significantly weaker as a change control tool. If the client later argues that something is in scope, a signed document gives the project manager a definitive reference point; an unsigned email chain gives them a protracted argument. This mistake often happens when the project manager is eager to move into planning and treats sign-off as a formality that can be obtained later — and later never comes.

Mistake 6: Treating the logbook reflection as a description, not a reflection Specific to this workplace activity: many learners write logbook entries that describe what happened without extracting learning. A description says 'we attended a meeting where the scope statement was reviewed.' A reflection says 'I noticed that the project manager asked the client to specifically read the exclusions list aloud, which surfaced two assumptions the client had not previously expressed. I would adopt this technique on a future project because it converts passive reading into active engagement.' Assessors are looking for the latter.

Several misconceptions about project initiation are prevalent among learners and even among practitioners early in their careers. Identifying and correcting these explicitly helps the learner approach their observation with more accurate expectations.

Misconception 1: 'The project charter is the same as the project scope statement.' These are distinct documents with different purposes and different authors. The charter is issued by the sponsor or client and authorises the project's existence. The scope statement is produced by the project manager and defines the project's work in operational detail. The charter is an input to the scope statement, not a substitute for it. In practice, some small organisations conflate them into a single document, but understanding their conceptually distinct functions is essential.

Misconception 2: 'Client consultation is a single event.' Effective requirements elicitation is an iterative process. The first consultation uncovers stated requirements; subsequent consultations surface hidden requirements, resolve ambiguities, and validate the project manager's interpretation of what was discussed previously. Treating client consultation as a single meeting is one of the most common causes of incomplete or disputed scope statements.

Misconception 3: 'Initiation is primarily a documentation exercise.' The documents produced during initiation (charter, scope statement, stakeholder register) are evidence of thinking, not substitutes for it. A beautifully formatted scope statement that was produced without genuine requirements analysis and stakeholder consultation is worthless. The initiation phase is primarily a thinking and communication exercise; the documentation records the outcomes of that thinking.

Misconception 4: 'Observing is passive — the value comes from doing.' This is directly addressed in the curriculum, which instructs learners to come with the charter read in advance, prepare specific questions, and use the observation period to close gaps in understanding rather than simply confirming presence. Observation, done properly, is active engagement with someone else's expert practice — it is one of the most efficient learning modes available to a professional. A learner who treats observation as passive watching is wasting their placement time.

Misconception 5: 'A good scope statement locks everything down.' A scope statement defines the boundary of the project at a point in time; it does not pretend the future is fully knowable. A good scope statement explicitly documents what is assumed, what is excluded, and what is subject to formal change control if it needs to change. This is very different from 'locking everything down' — it is building a disciplined mechanism for managing change, not preventing it.

A learner observing initiation with an experienced project manager should be able to recognise the signals that the process is not going well — both to support their mentor and to build the professional instincts they will need when running their own projects.

The charter has not been formally issued If the project is proceeding on the basis of an email, a verbal instruction, or a draft document that has not been signed by an authorised sponsor, the project has no formal mandate. The project manager is using resources without authority, and any dispute about scope, budget, or priority will be very difficult to resolve. A learner observing this should note it and ask their mentor how they are managing the risk.

Stakeholders are being excluded from consultation If the client consultation involves only one or two individuals and the learner knows that there are other significant stakeholders (end users, regulatory bodies, maintenance teams, neighbouring departments), the scope statement will reflect an incomplete picture of requirements. Requirements that are not captured at initiation typically surface during execution as change requests — expensive, disruptive, and sometimes project-threatening.

The scope statement contains no exclusions As noted above, an exclusions list that is empty or minimal is a red flag. It usually means the scope boundary has not been thought through carefully enough.

Assumptions are not being documented If the project manager is making statements like 'we're assuming the client will provide X' or 'we're assuming the regulation doesn't apply to this project' but these are not being written down, the project is accumulating hidden risk. Undocumented assumptions are the silent precursors to scope disputes.

Client sign-off is being deferred If the project manager is planning to 'get the client's signature later' once planning has started, the scope statement is effectively operating without formal agreement. The learner should observe how their mentor handles this situation — experienced practitioners know that a scope statement without sign-off is a negotiating document, not a controlling one, and they will push for sign-off before planning begins.

The initiation phase is being rushed Pressure from sponsors or clients to 'get started' is one of the most common reasons initiation is compressed. A project manager who moves into planning before the scope statement is agreed and signed is building a plan on an unstable foundation. When things go wrong (and they will), there is no agreed-upon baseline to measure against.

For a learner preparing for and participating in the observation and assistance described in WM-01-WE01, the following questions provide a practical thinking framework at each stage of initiation.

Before reviewing the charter with your mentor:

• Have I read the charter in full, independently, before the session?
• What parts of the charter are unclear or ambiguous to me?
• What information would I expect to be in a complete charter that is absent from this one?
• What assumptions seem to be embedded in the language of the charter?
• Who issued the charter, and what is their perspective likely to have shaped?

Before client consultation:

• Who are all the stakeholders who should be represented in this consultation, and who is actually attending?
• What requirements have been explicitly stated in the charter, and what requirements might still be unstated?
• What questions will help the client articulate their underlying need rather than just their stated solution?
• What constraints is the client likely to impose, and how do they interact with each other?
• What does 'project success' look like from the client's perspective?

Before drafting the scope statement:

• Do I have confirmed requirements from all key stakeholders?
• Are there any conflicting requirements that need to be escalated or resolved before the scope is defined?
• Have all significant assumptions been documented?
• Is the project management approach selected and documented?
• Can I write an exclusions list that would prevent the most common scope disputes?

Before seeking sign-off on the scope statement:

• Have all key stakeholders reviewed the scope statement, not just the primary client contact?
• Are the acceptance criteria specific enough that both parties would agree on whether they have been met?
• Is the change control process referenced in the document so stakeholders know what happens if scope needs to change?
• Is the person being asked to sign the scope statement actually authorised to do so on behalf of their organisation?

For the logbook reflection:

• What did I observe that I did not expect?
• What question did I ask that produced the most useful response?
• What did I observe that I did not understand at the time but have since understood?
• What would I do differently — and why, specifically, not just vaguely?

Experienced project managers bring a layer of tacit knowledge to initiation that is not captured in templates or methodologies. A learner who knows to look for these behaviours during observation will extract far more from the placement period than one who is only watching for the formal activities.

Reading what the charter doesn't say An expert reads a charter looking for absences as much as presences. If a charter is silent on budget, that is not an oversight — it is a signal that either the budget has not been agreed, or someone doesn't want it committed to writing yet. If a charter names the project manager but does not name the sponsor, the governance structure is unclear. If the charter describes a timeline without any reference to dependencies or assumptions, the timeline is probably aspirational. A novice reads a charter for information; an expert reads it for signals.

The language of requirements Experts are exquisitely sensitive to the difference between words like 'shall,' 'should,' 'will,' and 'may' in charter and requirements documents. 'Shall' is typically mandatory; 'should' implies preference; 'may' implies option. A requirement that says the system 'should be available 24/7' is meaningfully different from one that says it 'shall be available 24/7.' A learner who has not been sensitised to this distinction will miss important differences in the document they are reviewing.

Managing the power dynamics of client consultation In many client consultations, the most senior person in the room dominates the conversation, and their subordinates — who often have more operational knowledge — do not speak unless invited. An expert project manager knows to explicitly invite input from quieter participants, to conduct follow-up conversations with operational staff separately, and to watch body language for signs of disagreement that is not being voiced. None of this is captured in a meeting agenda template, but it dramatically affects the quality of requirements collected.

The relationship between scope and risk Experts understand that every boundary they draw in a scope statement creates a risk: anything that is included creates a delivery risk (what if we can't deliver it to the specified standard?), and anything that is excluded creates a relationship risk (what if the client expected it to be included?). Novices treat scope and risk as separate concerns. Experts treat every scope decision as a risk decision.

Building the relationship, not just the document Initiation is the moment in which the relationship between the project manager and the client is established. An expert uses the client consultation meetings not only to collect requirements but to build trust, demonstrate competence, and establish the communication norms that will govern the relationship for the life of the project. A project manager who is purely transactional during initiation — focused only on getting the scope statement right — may produce a good document but a poor relationship. A learner watching an expert will observe how they balance task focus with relationship investment.

The quality of project initiation has a direct and lasting impact on the client experience throughout the project and at handover. For a learner observing initiation in a workplace context, understanding these client-facing consequences helps motivate the rigour that might otherwise seem like internal process formality.

When initiation is done well, the client experiences a project that is scoped to what they actually need (not just what they said they wanted), managed within the constraints they care about, and delivered with minimal surprise. The client's confidence in the project manager is established early, which reduces the friction that arises when problems occur during execution — and problems always occur. A client who has been well served during initiation has a reservoir of trust that can absorb setbacks; a client who felt heard only superficially during initiation will interpret every execution problem as evidence of the project manager's incompetence.

When initiation is done poorly, the client is likely to experience scope disputes ('I thought that was included'), budget overruns (because unidentified requirements are added during execution without corresponding budget), schedule delays (because poorly defined acceptance criteria lead to rework and re-deliveries), and a general sense that the project is not under control. These experiences damage the client relationship and, in commercial contexts, can lead to disputes, withheld payments, or loss of future work.

For the learner, the practical implication is that every action taken during initiation — every clarifying question asked during client consultation, every exclusion added to the scope statement, every assumption documented — is an act of client service. Framing initiation as a client service activity rather than an internal documentation exercise changes the learner's engagement with it.

The following checklist can be used by a learner to self-assess the quality of initiation they have observed or participated in during their workplace placement. It can also be used to structure the logbook reflection by working through which items were done well and which were absent or incomplete.

Charter review: ☐ The project manager read the entire charter independently before any meeting ☐ Unclear, ambiguous, or contradictory elements were identified and recorded ☐ The charter was confirmed as formally issued and signed by an authorised sponsor ☐ The strategic purpose behind the project (the 'why') was confirmed or derived

Stakeholder identification: ☐ All parties who can affect or be affected by the project were identified ☐ Stakeholder interests, influence levels, and communication needs were documented ☐ Multiple stakeholder groups were consulted separately where their interests might differ

Client consultation: ☐ At least one formal client consultation meeting was held ☐ The meeting was minuted and the minutes were distributed and acknowledged ☐ Open-ended questions were used to surface unstated needs ☐ Requirements were distinguished from preferred solutions ☐ Conflicting requirements were identified and either resolved or documented

Project management approach: ☐ The appropriate methodology was selected and justified ☐ The governance structure (reporting lines, escalation path, decision authority) was defined ☐ The approach was documented as part of the initiation records

Scope statement: ☐ Deliverables are described in sufficient detail to distinguish them from one another ☐ Acceptance criteria are specific, measurable, and agreed with the client ☐ Assumptions are explicitly listed and each one is traceable to a source ☐ Constraints are documented ☐ Exclusions are listed comprehensively ☐ The change control process is referenced

Sign-off: ☐ The scope statement was reviewed by all key stakeholders, not just the primary contact ☐ Formal sign-off was obtained from an authorised representative of the client ☐ All initiation documents were filed in the project management information system

Learner-specific: ☐ The learner read the charter before the observation session ☐ The learner prepared specific questions before each initiation meeting ☐ The learner actively participated (asked questions, took notes, assisted with specific tasks) ☐ The learner completed a substantive logbook reflection capturing situation, action, and future improvement

Project managers operating in South Africa work within a regulatory and legal environment that directly affects how project initiation is conducted, particularly in the public sector, construction, environmental, and procurement contexts. A learner on placement should be aware of these frameworks, as they will observe their mentor navigating them during initiation.

Public Procurement and the PFMA/MFMA: Projects funded by national or provincial government entities are governed by the Public Finance Management Act (PFMA); those funded by municipalities fall under the Municipal Finance Management Act (MFMA). Both statutes require that expenditure be authorised, that procurement processes be followed, and that any deviation from approved scope and budget be formally reported. This means that a project manager in a public-sector context cannot simply revise the scope statement based on a conversation with the client — they must navigate formal variation or amendment processes that may require council or treasury approval. The scope statement in a public-sector project is therefore not just a project management tool; it is a document with regulatory weight.

Construction Industry Development Board (CIDB) regulations: In construction and infrastructure projects, the CIDB regulates contractor grading, tendering processes, and certain project management practices. The initiation phase of a construction project often involves reviewing whether the project's procurement strategy is compliant with CIDB requirements, particularly in public-sector projects. The scope statement must be detailed enough to support compliant tendering.

National Environmental Management Act (NEMA) and Environmental Impact Assessments: Projects that may have significant environmental impacts require an Environmental Impact Assessment (EIA) before work can commence. Identifying during initiation whether an EIA is required — and if so, incorporating it into the project management approach and timeline — is a critical initiation task. A scope statement that does not account for regulatory approval timelines in environmentally sensitive projects is fundamentally incomplete.

Protection of Personal Information Act (POPIA): Projects involving data systems, customer information, or human resources processes must be initiated with POPIA compliance in mind. This affects the scope statement by defining requirements (data protection measures that must be built into deliverables) and exclusions (scope that falls outside the implementing organisation's responsibility and into the client's).

Labour Relations Act and Basic Conditions of Employment Act: Projects that involve staffing changes, restructuring, or new employment arrangements must be initiated with awareness of South African labour law. The project management approach should identify whether the project triggers any consultation requirements under the LRA, and these should be reflected as constraints or dependencies in the scope statement.

Broad-Based Black Economic Empowerment (B-BBEE): Many public and some private-sector projects require that procurement and subcontracting arrangements comply with B-BBEE requirements. This is an initiation-phase consideration because it affects how the project management approach is developed and how the stakeholder list is constructed.

WM-01-WE01 does not exist in isolation — it is the workplace anchor for a cluster of knowledge and practical standard elements that the learner will have encountered or will encounter in their qualification. Understanding these connections helps the learner make sense of why the workplace activity is structured as it is, and how to maximise the learning transfer between classroom and workplace.

Connection to knowledge elements on project initiation: The qualification's knowledge components cover the theory of project charters, scope statements, stakeholder management, and requirements gathering. WM-01-WE01 is the mechanism by which that theory becomes grounded in real practice. A learner who has studied the knowledge elements but not yet completed this workplace activity knows what a scope statement should contain; after completing WM-01-WE01, they know what it feels like to produce one under real conditions, with real clients, real ambiguity, and real consequences.

Connection to practical standards: Practical standard assessments will often ask the learner to demonstrate skills like interpreting a project charter, identifying stakeholder requirements, or drafting a scope statement in a simulated context. The workplace activity provides the reference experience that makes these simulated tasks meaningful rather than abstract. A learner who has observed an experienced project manager handle a contested exclusion in a client meeting has a mental model for how to approach the equivalent question in a practical assessment.

Sequencing within the qualification: This workplace activity is appropriately placed at the beginning of the work experience component of the qualification. Initiation is the beginning of the project life cycle, and starting the workplace experience with initiation means the learner sees the project from its first moments. This contrasts with a learner who is placed into an already-running project — they see execution and control but miss the decisions that shaped those phases.

The logbook as a portfolio artefact: The logbook entry produced for this workplace activity is not a private journal — it is an evidence document that the mentor and assessor will evaluate. A logbook entry that demonstrates genuine reflection, specific observation, and concrete future-focused learning is an asset in the learner's portfolio. Multiple strong logbook entries build a picture of a developing professional; thin, descriptive entries signal a learner who is going through the motions.

The mentor evaluation: The experienced project manager who supervises this activity produces an evaluation report. This evaluation is an external witness statement: the mentor confirms that the learner was present, engaged, and contributed meaningfully. The evaluation is more likely to be positive when the learner has demonstrated curiosity (asking thoughtful questions), reliability (reading documents before sessions, meeting commitments), and professionalism (behaving appropriately in client-facing meetings). These behaviours should not be calculated for effect — they should reflect genuine engagement with the material — but it is useful for the learner to know that their conduct during the placement shapes both the evaluation and their own learning.

Project initiation follows broadly consistent principles across sectors, but the specific practices, terminology, document formats, and regulatory requirements vary considerably depending on where the project is being executed. A learner whose placement is in one sector should understand that their experience represents one valid instance of initiation, not the universal standard.

Construction and infrastructure: Initiation typically involves reviewing engineering briefs, geotechnical reports, and planning permissions alongside the project charter. The scope statement in construction is often called a 'scope of works' and must be detailed enough to support contractor tendering. Environmental authorisations and heritage impact assessments may be prerequisites that must be reflected in the project management approach. The client consultation process often involves multiple professional disciplines (architects, engineers, quantity surveyors) rather than a single client representative.

Information technology: IT project initiation frequently involves reviewing business cases, system requirement specifications, and existing architecture documentation. The project management approach selection is particularly consequential in IT — the choice between waterfall and agile fundamentally changes what initiation documents are produced and how detailed they need to be. In an agile approach, initiation produces a product vision and initial backlog rather than a detailed scope statement, and the concept of 'scope' is deliberately left flexible. A learner on IT placement should observe how their mentor addresses this flexibility while still providing enough definition to manage stakeholder expectations.

Healthcare and social services: Projects in these sectors often involve regulatory approvals (health authority sign-offs, social development department reviews) that must be incorporated into the initiation timeline. Stakeholder consultation is particularly complex because it must include patient/client advocates, clinical governance bodies, and community representatives alongside the commissioning organisation. The project management approach must account for clinical risk, which is different from project risk.

Events and creative industries: Initiation in events management is often faster and more relationship-driven than in construction or IT. The project charter may be a signed event brief; the scope statement may be embedded in the commercial proposal. Client consultation is often iterative and conversational rather than formal. The learner in this sector should observe how their mentor maintains rigour (documented requirements, agreed exclusions, signed scope) within a culture that tends to value speed and flexibility over process.

South African government and development projects: As noted in the regulatory context section, public-sector initiation in South Africa carries additional compliance obligations. It also typically involves more stakeholders, longer approval chains, and more formal documentation requirements. The combination of these factors makes initiation in the public sector significantly more time-consuming than in comparable private-sector projects — a reality the learner should observe and factor into their understanding of what 'normal' initiation looks like.

The following self-check questions are designed for the learner to use during and after their observation period to test their own understanding of what they have witnessed. Work through each question before reading the answer, and note where your own response differs — the gap is the learning.

Question 1: Your mentor reviews the project charter and says 'this budget figure is aspirational, not authorised.' What does she mean, and why does it matter for the scope statement?

The answer is shown to learners enrolled in this module.

Project initiation activities refer to the formal set of processes, tasks, and decisions that mark the beginning of a project's life cycle. In the context of this workplace activity (WM-01-WE02), initiation encompasses everything from receiving and interpreting a project charter or brief, through to producing a completed project scope statement that captures the key requirements and agreed management approach. It is the phase during which a project moves from being an idea or a client request into a structured, documented commitment that can be planned and executed.

The word 'initiation' is deliberately distinct from 'planning' in project management methodology. Initiation establishes whether a project should exist and what it is broadly intended to achieve; planning then determines how it will be achieved. Under close supervision means that the trainee project manager does not act independently — every significant output (a requirements list, a draft scope statement, a set of client questions) passes through an experienced project manager before it is used or shared. This is a deliberate safeguard that mirrors formal apprenticeship logic: you build skill and confidence in authentic conditions while the risk of error to the client and organisation is managed by the mentor's oversight.

A project scope statement, one of the key outputs of initiation, is the written document that defines the boundaries of the project: what work is included, what is explicitly excluded, what the deliverables are, what the acceptance criteria are, and what constraints and assumptions apply. It is not a contract on its own, but it forms the technical basis on which a contract or formal agreement with a client is built. Compiling a project scope statement therefore requires a thorough prior understanding of the charter or brief, the client's needs, and the organisation's approach to project management.

The purpose of conducting project initiation activities is to create shared, documented clarity between all parties — client, project team, and sponsoring organisation — about what a project is, why it exists, what it will produce, and how it will be managed. Without this clarity, projects routinely suffer from scope creep, misaligned expectations, cost overruns, and outright failure to deliver what the client actually needed.

For a trainee project manager, the deeper purpose of this workplace activity is experiential learning under real conditions. The curriculum is explicit that the focus of the work experience in this module is on building confidence through repetition under close supervision and on exposing the learner to the complexities of real workplace demands, the pressure of work, and genuine client needs. You cannot replicate this in a classroom: a client who is impatient, a brief that is ambiguous, a mentor who expects professional conduct — these are the actual learning stimuli.

Initiation activities also exist to protect the organisation and the client from preventable downstream problems. A well-constructed scope statement, grounded in thorough requirements gathering and client consultation, makes it significantly harder for misunderstandings to compound into disputes. For the trainee, understanding this protective function is important: initiation is not administrative box-ticking — it is the structural foundation of every project decision that follows. Every change request, every budget variance, every stakeholder conflict during execution traces back either to something that was or was not established during initiation.

The requirement to attend to initiation across at least two projects reinforces this purpose. A single project exposes you to one set of circumstances; a second project shows you how context changes the application of the same principles, which is the beginning of genuine professional judgment.

Understanding the specific language used during project initiation is essential, because imprecise use of terms in a professional setting signals inexperience and can cause real confusion in client-facing documents.

Project Charter / Project Brief: These two terms are sometimes used interchangeably in practice, but they carry a subtle distinction. A project charter is a formal document — often internally generated — that authorises the project and gives the project manager authority to apply organisational resources to it. A project brief is more commonly a client-facing document that describes what the client wants, the context, and the constraints. In this curriculum, they are referred to together as the starting point for interpretation.

Project Scope Statement: The document that defines the boundaries, deliverables, acceptance criteria, assumptions, and exclusions of the project. It answers the question 'What exactly are we doing, and what are we not doing?' It is one of the primary outputs of the initiation phase in this curriculum.

Requirements: The specific conditions, capabilities, or characteristics that a deliverable must have in order to satisfy the client's stated and unstated needs. Requirements can be functional (what the deliverable must do), operational (how it must work in real use conditions), technical (what specifications it must meet), or compliance-based (what standards it must adhere to). The curriculum specifically flags the risk of missing operational requirements — such as after-hours access in the worked example — when focusing only on functional ones.

Needs Assessment: The process of identifying what the client and other stakeholders actually need from the project, as distinct from what they have stated they want. Needs are often broader than stated requirements, and a thorough needs assessment surfaces unstated expectations before they become disputes.

Project Management Approach: The chosen methodology, governance structure, and process framework through which the project will be managed. This includes decisions about how communication will be handled, how decisions will be escalated, and which project management tools or templates will be used.

Stakeholder: Any person, group, or organisation that has an interest in or is affected by the project. In initiation, identifying all relevant stakeholder groups is critical — the curriculum specifically warns against capturing requirements only from the most vocal or accessible stakeholders.

Close Supervision: In this context, close supervision means that the trainee's work is reviewed and approved by an experienced project manager before it is used or shared externally. The mentor's role includes reviewing draft documents, attending client meetings with the trainee, and providing structured feedback.

Workplace Logbook: The formal record that documents the trainee's actual activities, observations, reflections, and outcomes during the placement. Under this curriculum, logbook entries must be specific, dated, and verifiable. A vague entry earns no credit.

Project initiation activities under close supervision follow a recognisable sequence, even if the specific steps vary by organisation, sector, and project type. The following sequence reflects what this curriculum expects a trainee to be able to carry out or meaningfully observe.

Step 1: Receive and review the project charter or brief. Before any meeting or conversation happens, read the document carefully. Note every explicit requirement, every constraint (budget, time, resource), every stakeholder mentioned, and every term or phrase that is ambiguous or undefined. Create a written list of your observations. This is not a passive reading — you are analysing the document for gaps and clarity issues.

Step 2: Identify gaps and ambiguities. Using your initial review, formulate a specific list of clarifying questions. These questions should address things the brief does not answer, things it says that could be interpreted in more than one way, and anything that seems inconsistent. The curriculum's worked example shows that this step produced three identified gaps in the brief, which led to a drafted list of clarifying questions. Your mentor should review this list before you take it to the client — this is a direct application of 'close supervision.'

Step 3: Conduct client consultation. Meet with the client (or client contact) to close the gaps identified in Step 2. This meeting should be structured: have your questions ready, take notes, confirm your understanding of each answer before moving on, and — critically — ask about requirements beyond the obvious functional ones. Check for operational requirements (how the deliverable will be used day-to-day), access requirements, maintenance requirements, compliance requirements, and any non-negotiable preferences. The curriculum's worked example highlights that the initial gap of after-hours access was an operational requirement that was missed in the first pass.

Step 4: Conduct a needs assessment across all stakeholder groups. Client consultation often focuses on one or two individuals. A needs assessment asks: who else will be affected by or have requirements of this project? End users, maintenance staff, regulatory bodies, neighbouring departments, suppliers — each may have requirements that the primary client contact did not mention. Systematically identify these groups and determine their requirements before finalising any requirements document.

Step 5: Produce a revised requirements document. Consolidate all findings from the brief, the gap analysis, the client meeting, and the broader needs assessment into a single requirements document. This document should be structured, clearly worded, and traceable — meaning you can point to where each requirement came from. Submit this to your mentor for review before sharing it with the client or any other stakeholder.

Step 6: Determine the project management approach. Based on the project's nature, the client's preferences, and the organisation's standard practices, document the management approach. This includes the methodology (e.g., waterfall, agile, or hybrid), the governance structure (who makes what decisions), the communication plan (who gets which information and how often), and the key tools and templates that will be used.

Step 7: Compile the project scope statement. Drawing on the approved requirements document and the agreed management approach, draft the project scope statement. This document should include: the project's purpose and objectives, the in-scope deliverables with acceptance criteria, any explicitly out-of-scope items, key constraints and assumptions, identified risks or dependencies at initiation stage, and the agreed management approach. This draft goes to your mentor for review, and then to the client for approval.

Step 8: Document everything in your logbook. For each of the above steps, record what you did, what your mentor's involvement was, what the outcome was, and what you would do differently. The curriculum is explicit: specific, dated, verifiable detail is what earns credit, not general descriptions.

During project initiation, a range of tools and templates help ensure that the process is thorough, documented, and consistent. Exposure to these real documents is explicitly emphasised in the curriculum — you are instructed to ask to see at least one real document rather than only a description of one.

Project Charter / Brief Template: Most organisations have a standard format for project charters or briefs. These typically include fields for project title, purpose, sponsor, objectives, high-level scope, constraints, assumptions, known risks, and authorisation signatures. When you receive this document, look at which fields are complete, partially complete, or blank — the blanks are often where your gap-analysis questions should start.

Requirements Traceability Matrix (RTM): A table that lists each requirement, its source (who specified it), its priority, its acceptance criteria, and its current status. This tool ensures that every requirement is tracked from identification through to delivery and acceptance. In initiation, you build the first draft of this matrix.

Stakeholder Register: A document that lists all identified stakeholders, their role relative to the project, their interests, their level of influence, and the requirements associated with them. This supports the needs assessment step and ensures no stakeholder group is overlooked.

Scope Statement Template: A structured template that guides the compilation of the project scope statement, typically including sections for project objectives, deliverables, exclusions, constraints, assumptions, and acceptance criteria.

Meeting Agenda and Minutes Template: For client consultation meetings, a formal agenda prepared in advance and minutes completed immediately afterward are standard professional practice. The agenda signals preparation and respect for the client's time; the minutes create a written record that both parties can confirm and sign off on.

Issue and Gap Log: A simple register where identified gaps, ambiguities, or open questions from the brief review are logged, assigned, and tracked until closed. This is the tool that supports Step 2 of the initiation sequence described above.

Project Management Approach Document / Project Management Plan (Initial Draft): Some organisations produce a brief management approach document at initiation that is later expanded into a full project management plan. This may cover methodology selection, key roles and responsibilities, communication frequency, and decision-making authority.

In your workplace placement, ask your mentor to walk you through the specific templates your organisation uses, and record these in your logbook. Note what the template includes, why each section exists, and how your organisation's version differs from or aligns with the standard formats described above.

Documentation during project initiation serves two distinct purposes: it creates the formal project record that will guide execution, and it provides the evidence base for your workplace logbook and assessment. Understanding both purposes will help you treat documentation as a professional habit rather than a compliance chore.

For the project itself: Every significant output of the initiation phase must be formally documented, version-controlled, and approved. This includes the annotated review of the brief, the gap analysis and clarifying questions, meeting agendas and minutes from client consultation sessions, the requirements document (with revision history), the stakeholder register, the scope statement (with client and mentor sign-off), and the management approach document. The principle underlying this is that any future project participant — or any party in a dispute — should be able to reconstruct exactly what was agreed at initiation and why.

For your logbook: The curriculum is unambiguous about what constitutes an acceptable logbook entry. It must be dated, describe a specific activity (not a general category of activity), explain what you did or observed, describe your mentor's involvement, state the outcome, and include a genuine reflection on what you would do differently. The worked example in the curriculum shows this in action: the entry identifies the exact date, the specific project, the precise tasks performed (reviewed the signed brief, identified three gaps, drafted clarifying questions, met with client contact, produced a revised requirements document), the mentor's specific role (reviewed draft questions, sat in on meeting, gave feedback on one ambiguously phrased question), the outcome (revised requirements document approved), and a concrete reflection (initially missed operational requirements — the after-hours access gap).

Version control: When documents are revised following feedback (from your mentor, from the client, or following the needs assessment), each version should be saved with a clear version number and date. Submitting an outdated version of the scope statement to a client because version control was not maintained is a common and preventable professional error.

Approval and sign-off: The curriculum implies a two-stage approval process for key initiation outputs: mentor approval before client sharing, and client approval before the output is treated as final. This dual-approval discipline is worth recording in your logbook as a specific practice, not just an implicit background assumption.

Workplace logbook as professional development record: Beyond its role as an assessment submission, your logbook is a record of your professional development. When you look back at entries from early placements versus later ones, you should see a clear progression in complexity, in the depth of your reflections, and in the ratio of 'observed' to 'conducted independently.' Recording this progression honestly is itself a mark of professional maturity.

The curriculum itself provides a detailed worked example, and it is worth unpacking that example in depth so that you understand not just what the trainee did but why each step mattered and what professional judgment was being developed.

The situation: A trainee project manager is placed on a site-refurbishment project for a client. The starting point is a signed project brief — a formal document that the client has already authorised.

Step 1 — Brief review and gap identification: Rather than simply accepting the brief at face value, the trainee reads it analytically and identifies three gaps in the stated requirements. This is significant: most novices, eager to appear capable and efficient, would move directly to drafting the requirements list without questioning the brief. The trainee's willingness to interrogate the document — even though the client has already signed it — is a mark of professional rigour. The three gaps are not described in the example, but the process is: identify them specifically, articulate why each is a gap (missing information? ambiguity? inconsistency?), and formulate a precise question for each one.

Step 2 — Drafting and reviewing clarifying questions: The trainee drafts the clarifying questions and takes them to the mentor before going to the client. This is the first application of close supervision. The mentor reviews the draft — not to do the work for the trainee, but to check quality. The mentor finds that one question was phrased ambiguously. This is an important learning point: a question that confuses the client wastes the meeting and may produce a misleading answer. The mentor's feedback here is a direct quality control intervention that protects both the trainee and the client relationship.

Step 3 — Client meeting: The mentor sits in on the meeting. Again, this is close supervision in practice — not surveillance, but professional support. The trainee leads the meeting (or participates as a co-lead), uses the reviewed questions to close the three gaps, and records the answers.

Step 4 — Revised requirements document: The trainee produces a revised requirements document incorporating the client's responses. This document then goes back to both the client and the mentor for approval. The dual approval is achieved.

Reflection — The missed operational requirement: The trainee's reflection identifies that the initial review missed a requirement about after-hours access. This is a classic category of missed requirement: it is operational (about how the space will be used in practice) rather than functional (about what the space must physically contain or be capable of). A refurbished site might meet every functional requirement perfectly — correct room sizes, correct finishes, correct equipment — and still fail to serve the client if operational requirements like after-hours access, cleaning schedules, or security protocols are not incorporated into the design. The trainee's recognition of this gap, and the self-instruction to 'check operational, not just functional, requirements systematically' in future, shows that genuine learning has occurred — not just task completion.

What the example teaches overall: The worked example demonstrates that project initiation is not a one-pass activity. It requires iterative review (brief → gap analysis → client consultation → revised document), professional checkpoints (mentor review at each significant output), and honest reflection on what was missed and why. It also demonstrates the appropriate scope of a logbook entry: specific enough to be verifiable, reflective enough to show learning, and professionally written enough to be shared with a supervisor and assessor.

To illustrate how context changes the application of the same initiation principles, consider a contrasting scenario: a trainee project manager placed in a public sector infrastructure project rather than a private-sector site-refurbishment project.

The situation: A local municipality has issued a project brief for the upgrade of a community centre. The brief has been through a formal procurement process and is accompanied by a terms of reference document. Multiple stakeholder groups are involved: the municipality as client, the community residents as end users, a ward councillor as a political stakeholder, and a facilities management team as the operational stakeholder.

How initiation differs in this context:

First, the project charter / brief has a more complex origin. In a private-sector refurbishment, the brief typically comes from a single client organisation. In a public sector project, the brief may have passed through a procurement committee, a technical advisory team, and political approval. This means that gaps and ambiguities in the brief may reflect deliberate compromises between competing interests — and closing those gaps may require more careful navigation than a straightforward client meeting.

Second, the stakeholder landscape is significantly broader. The trainee conducting a needs assessment here cannot limit consultation to the municipal project officer. End users (community members) may have very different requirements from the technical staff who specified the brief. The ward councillor may have political requirements that are unstated but real. The facilities management team will have operational requirements (maintenance access, cleaning schedules, utility connections) that no one else in the process has articulated. Missing any of these groups would produce a scope statement that serves the most vocal stakeholder — the municipal project officer — while failing others.

Third, regulatory and compliance requirements are more prominent. Public sector projects in South Africa are subject to procurement regulations, environmental assessment requirements, and community participation requirements that may not appear explicitly in the brief but are legally mandated. The trainee needs to be alert to these as a category of requirements that must be incorporated into the scope statement even when the client has not explicitly listed them.

Fourth, the documentation and approval process is more formal. In a private-sector project, the scope statement may be approved by the client and the senior project manager. In a public sector project, approval may require a formal sign-off by a procurement official, a technical committee, and sometimes a council resolution. The management approach document must reflect these governance requirements.

What this contrast teaches: The same initiation activities — interpret the charter, assess needs, consult the client, compile the scope statement — look different depending on the sector, the stakeholder landscape, and the regulatory environment. This is why the curriculum requires attendance at initiation for at least two projects: a single project teaches you the steps; a second project teaches you judgment about how context modifies the application of those steps.

The curriculum identifies one common mistake explicitly — under-consulting the client before finalising the requirements list, particularly the failure to capture requirements from every relevant stakeholder group rather than just the most vocal or accessible one. But there are several other common mistakes that a trainee project manager should understand and actively work to avoid.

Mistake 1: Treating the signed brief as complete. A project brief carries authority because it has been signed and approved. Novice project managers often mistake this authority for completeness — if the client signed it, it must be right. But a signed brief represents what the client knew how to ask for at the time of signing, not necessarily what they actually need. Gaps, ambiguities, and unstated assumptions are common in even well-prepared briefs. The curriculum's worked example shows a signed brief that still contained three gaps. The discipline of analytical review — before any meeting or action — is a professional habit that must be developed early.

Mistake 2: Focusing only on functional requirements. Functional requirements describe what a deliverable must do. Operational requirements describe how it will be used in real conditions. Technical requirements describe how it must be built or specified. Compliance requirements describe what standards it must meet. Novice requirements gatherers tend to focus on functional requirements because these are what the client most naturally talks about. The after-hours access gap in the curriculum's worked example is a reminder that a complete requirements picture requires deliberately asking about each category.

Mistake 3: Consulting only the primary client contact. The most accessible stakeholder is often the project sponsor or the client's project officer. This person knows the project well but may not represent the full range of stakeholder needs. End users, maintenance staff, adjacent departments, regulatory bodies, and community members may all have requirements that the primary contact has not articulated. A needs assessment is only complete when it has identified and addressed every relevant stakeholder group.

Mistake 4: Skipping mentor review to appear capable. There is a natural tendency for trainees to want to appear competent by not asking for help. In this context, bypassing your mentor's review of draft documents before client sharing is not a sign of competence — it is a violation of the close-supervision structure that protects both you and the client. The mentor's review is not a reflection of your inadequacy; it is a professional quality control step that experienced project managers use in various forms throughout their careers (peer review, client review, sponsor review).

Mistake 5: Vague and undated logbook entries. The curriculum is direct: a vague entry earns no credit. Why does this mistake happen? Because logbook entries are often written at the end of a long workday, when detail feels less important than rest. The discipline of specific, dated, verifiable entries must be built into the daily routine of the placement — not left until the submission deadline.

Mistake 6: Waiting too long to flag that the placement does not cover all required activities. The curriculum explicitly instructs trainees to tell their facilitator early if their organisation does not run a project that touches every listed activity, so that an alternative placement or simulated exercise can be arranged. Novices often wait, hoping the right project will materialise, and find themselves at the logbook deadline with insufficient evidence. Early communication with the facilitator is the professional response.

Mistake 7: Confusing initiation with planning. Initiation establishes what the project is and whether it should proceed. Planning determines how it will be executed. Trainees who jump from brief review directly into scheduling or budgeting are skipping the foundational clarity work of initiation. The scope statement must be in place and approved before detailed planning begins, because everything in the plan is built on the scope.

Several misconceptions about project initiation activities are common among trainees and can limit the quality of their work if not corrected early.

Misconception 1: 'The client knows exactly what they want — my job is just to document it.' This is one of the most persistent misconceptions in project management. Clients often know what problem they want solved, but they do not always know the best way to solve it, and they frequently omit requirements they consider obvious, requirements they have not yet thought of, or requirements that exist in other stakeholder groups they are not representing in the meeting. A project scope statement that simply transcribes what the client said in one meeting — without gap analysis, needs assessment, or broader stakeholder consultation — is incomplete. Initiation is an investigative process, not a dictation exercise.

Misconception 2: 'Close supervision means I do everything and then show the mentor at the end.' Close supervision, as described in this curriculum, means that the mentor is involved at each significant checkpoint — reviewing draft questions before the client meeting, sitting in on the meeting, reviewing the requirements document before client sharing, approving the scope statement. The trainee does the work, but the mentor reviews and approves each stage. Showing the mentor a finished scope statement without any prior checkpoints is not close supervision — it is independent work with a final review, which is a different and more advanced stage of professional development.

Misconception 3: 'The scope statement is just a summary of the brief.' The scope statement is not a restatement of the brief. The brief is the client's starting point; the scope statement is the product of analysis, consultation, needs assessment, and negotiation. It should contain information that was not in the brief (requirements uncovered through consultation), exclusions that the brief did not address (making explicit what is not included), and assumptions and constraints that need to be formally acknowledged. A scope statement that merely summarises the brief has not added value.

Misconception 4: 'Once the scope statement is approved, the initiation phase is over and I cannot revisit requirements.' While the scope statement is a formal document that creates a baseline, it is not immutable. In practice, requirements may evolve as understanding deepens, and changes to scope must be managed through a formal change control process. The approval of the scope statement does not mean requirements are frozen forever — it means that any subsequent change must be formally assessed for its impact on time, cost, and quality, and formally authorised. Understanding this distinction protects both the client and the project team.

Misconception 5: 'Project initiation is something that happens once at the beginning of a project.' For a trainee attending two or more projects during this placement, each project has its own initiation phase. But even within a single project, initiation activities sometimes recur — for instance, when a project is significantly rescoped, a sub-phase begins, or a major deliverable is added. The skills developed during initiation (analytical reading, structured questioning, stakeholder mapping, requirements documentation) are applied repeatedly across the project life cycle in various forms.

Use the following checklist to assess whether you have conducted project initiation activities to a professional standard. This checklist is designed for self-assessment before you submit your logbook entries or present your outputs to your mentor.

Charter / Brief Interpretation ☐ I have read the entire charter or brief at least once before any meetings or conversations. ☐ I have identified all explicit requirements, constraints, and assumptions stated in the document. ☐ I have noted every term or phrase that is ambiguous, undefined, or potentially misleading. ☐ I have identified all gaps — information that is missing and will be needed to proceed. ☐ I have formulated a specific, written question for each gap and ambiguity. ☐ My mentor has reviewed my list of clarifying questions before I take them to the client.

Client Consultation ☐ I have prepared a formal agenda for the client meeting. ☐ The meeting covered all gap and ambiguity questions from my list. ☐ I asked about requirements beyond the functional — specifically operational, technical, and compliance requirements. ☐ I confirmed my understanding of each answer during the meeting before moving on. ☐ I took formal notes during the meeting (or minutes were taken by an identified person). ☐ Meeting minutes have been distributed to all attendees and confirmed as accurate.

Needs Assessment ☐ I have identified all relevant stakeholder groups — not just the primary client contact. ☐ I have determined the requirements of each stakeholder group. ☐ I have confirmed that no significant stakeholder group has been overlooked. ☐ My requirements document distinguishes between requirements from different stakeholder sources.

Requirements Document ☐ All requirements are clearly and specifically stated (not vague or ambiguous). ☐ Each requirement is traceable to a source (who specified it and where). ☐ Requirements are categorised (functional, operational, technical, compliance). ☐ The document has been reviewed and approved by my mentor. ☐ The document has been approved by the client.

Project Management Approach ☐ The chosen methodology is documented and appropriate to the project type. ☐ The governance structure (who decides what) is clearly described. ☐ Communication protocols are defined (who gets what information, how often, through which channel). ☐ Key tools and templates to be used are identified.

Scope Statement ☐ The scope statement includes project purpose and objectives. ☐ In-scope deliverables are listed with acceptance criteria for each. ☐ Out-of-scope items are explicitly stated. ☐ Key constraints and assumptions are documented. ☐ The management approach is referenced or incorporated. ☐ The document has been reviewed and approved by my mentor. ☐ The document has been approved by the client.

Logbook ☐ Each activity is recorded with a specific date. ☐ Each entry describes the specific situation, not a general category of activity. ☐ My mentor's involvement in each step is recorded specifically. ☐ The outcome of each step is recorded. ☐ Each entry includes a genuine reflection on what I would do differently.

Recognising early warning signs during project initiation can prevent problems from compounding into serious failures. As a trainee under close supervision, your ability to notice these signals and raise them with your mentor is itself a professional skill.

Warning sign 1: The client is reluctant to answer clarifying questions or dismisses gaps as unimportant. This may indicate that the client has not fully thought through the project, is under pressure to show progress rather than thoroughness, or has political reasons for keeping the scope vague. A vague scope is not a safe scope — it is an invitation for future disputes. Raise this with your mentor: 'The client did not want to address these three questions — how should we proceed?'

Warning sign 2: Requirements keep expanding after each consultation. A small amount of scope expansion during initiation is normal — consultation surfaces previously unstated needs. But if requirements are expanding significantly with each conversation, it may indicate that the project's purpose has not been clearly defined, that too many stakeholder groups are adding competing wishes, or that the client organisation does not have clear internal alignment on what they want. This pattern, if not addressed during initiation, will produce a scope statement that no one is fully committed to.

Warning sign 3: Different stakeholders give contradictory requirements. Contradiction between stakeholder requirements is a normal reality in complex projects, but it must be resolved during initiation — not left as an implicit conflict in the scope statement. If two stakeholders have requirements that cannot both be met within the project's constraints, this must be escalated and resolved before the scope statement is finalised.

Warning sign 4: The mentor's feedback on your drafts is consistently pointing to the same type of error. If your mentor repeatedly notes that your requirements are vague, or that you are missing certain categories of requirements, or that your questions are ambiguous, this is a signal that a systematic skill gap needs to be addressed — not just a series of isolated corrections. Ask your mentor for a structured feedback session that addresses the pattern, not just individual instances.

Warning sign 5: You are being asked to finalise the scope statement before the needs assessment is complete. Time pressure sometimes pushes initiation to be curtailed — the project needs to start, the client is waiting, the deadline is close. If you are being asked to sign off on a scope statement before all stakeholder groups have been consulted, flag this explicitly. A premature scope statement may satisfy the schedule pressure but creates a weak foundation for everything that follows.

Warning sign 6: Your logbook is falling behind and you are reconstructing entries from memory. If you are writing logbook entries days or weeks after the fact, the specific, verifiable detail required by the assessment criteria will be difficult to reconstruct accurately. This is a process warning sign, not a knowledge gap — and the solution is a daily or weekly entry discipline, not a retrospective writing exercise.

The quality of project initiation activities has a direct and significant impact on the client, both immediately and over the duration of the project.

During initiation: The client's experience of being consulted thoroughly — having their stated requirements captured, their unstated needs surfaced through a structured needs assessment, and their clarifying questions taken seriously — builds confidence in the project team. A client who feels heard and understood during initiation is more likely to be a cooperative and constructive partner throughout the project. A client who feels that the project team merely took their brief and ran with it, without genuine consultation, often harbours unspoken concerns that emerge later as objections, change requests, or dissatisfaction with deliverables.

During execution: A well-crafted scope statement, built on thorough initiation, gives the client a clear and agreed reference point. When questions arise during execution about whether something is in or out of scope, both the client and the project team can refer to the scope statement rather than arguing from memory or competing interpretations of the original brief. This reduces client-facing conflict and supports a professional relationship.

At project closure: Projects that were poorly initiated — with incomplete requirements, unconsulted stakeholders, or a vague scope statement — frequently fail to achieve client satisfaction at closure, even when the project team has worked diligently. The deliverable may be technically complete but operationally inadequate, because operational requirements were not captured during initiation. The worked example's missed after-hours access requirement is a small-scale illustration of this risk: a refurbished site that does not accommodate after-hours access may be technically finished but practically unusable for the client's purposes.

For the trainee: Understanding the client impact of initiation quality is important because it frames your work as professionally consequential, not as an academic exercise. Every gap you identify in a brief, every question you ask in a client meeting, every stakeholder group you include in your needs assessment, directly improves the likelihood that the project will genuinely serve the client.

Under close supervision, the bar for escalation to your mentor is lower than it would be for an independent project manager — and this is intentional. Part of the learning process is developing a well-calibrated sense of when to act independently, when to seek advice, and when to stop and escalate a decision.

Escalate immediately if:

• A client provides information during consultation that directly contradicts something stated in the signed brief. This is not a gap you can resolve alone — it may indicate a change in the client's position, a misunderstanding in the original brief, or a conflict between different parts of the client organisation.
• A stakeholder raises a legal, regulatory, or compliance requirement that you do not know how to assess or incorporate. In South African construction, infrastructure, or built-environment projects, compliance requirements (such as environmental impact, occupational health and safety, or National Building Regulations) are non-trivial and must be assessed by appropriately qualified professionals.
• The client's primary contact is unavailable and the initiation timeline is under pressure. Do not substitute guesswork for consultation — escalate the timeline risk to your mentor and agree on a revised approach.
• You receive feedback from two or more stakeholders that they have not been consulted and have significant requirements. This is a signal that the stakeholder identification process was incomplete, and the scope of consultation needs to be reassessed before the scope statement is finalised.
• You are unsure whether a piece of information from a client meeting is confidential or can be shared in your logbook. Ask your mentor before recording anything that could be commercially or professionally sensitive.

Escalate for guidance (not emergency, but before proceeding) if:

• Your draft requirements document contains requirements that seem technically unfeasible within the stated budget or timeline. Flag these to your mentor before presenting them to the client as agreed requirements.
• You are uncertain which project management approach is appropriate for this specific project type. Different project contexts call for different methodologies, and selecting an inappropriate approach during initiation creates problems throughout the project.
• Your organisation's standard templates do not fit the project's specific requirements. Ask your mentor how deviations from standard practice should be handled and documented.

The professional discipline of appropriate escalation is not weakness — it is one of the core competencies that distinguishes a competent junior project manager from an overconfident one. Close supervision exists precisely because the trainee's judgment is still developing; using it effectively is the most direct path to moving from closely supervised to independently capable.

Measuring the success of project initiation activities is not as straightforward as measuring budget variance or schedule adherence, because the outputs of initiation are primarily documents and agreements rather than physical deliverables. Nevertheless, several metrics and indicators of quality can be tracked.

Completeness of requirements documentation: Can every requirement in the scope statement be traced to a specific source (stakeholder, document, consultation meeting)? Are all identified stakeholder groups represented? Does the document address functional, operational, technical, and compliance requirements, or only one category? Completeness is one of the strongest indicators of initiation quality.

Stakeholder coverage ratio: Of all the stakeholder groups identified in the stakeholder register, what percentage had their requirements formally assessed and incorporated? A well-conducted initiation process should achieve close to 100% coverage of identified stakeholder groups. If significant groups were not consulted, this is a measurable gap.

Number of change requests generated by uncaptured initiation requirements: During project execution, track how many change requests arise because a requirement was not captured during initiation. This is a lagging indicator — you can only measure it after execution has begun — but it is one of the most direct measures of initiation quality. Projects with thorough initiation produce fewer change requests of this type.

Approval cycle time: How many revision cycles did the scope statement require before receiving final client and mentor approval? A scope statement that went through five revision cycles before approval is not necessarily a failure — it may reflect genuinely complex requirements — but consistently high revision cycles across multiple projects may indicate that the initial requirements gathering needs to be more thorough.

Logbook quality indicators: For this workplace activity specifically, the quality of your logbook entries is a measurable output. Entries that are dated, specific, verifiable, describe mentor involvement, state outcomes, and include genuine reflections meet the assessment standard. Entries that are vague, undated, or non-specific do not. Tracking your own logbook entry quality over the placement period is a form of self-assessment.

Client satisfaction with the initiation process: After the scope statement has been approved, a brief, structured conversation with the client contact about their experience of the consultation process can provide qualitative data about whether the initiation activities met their expectations. Did they feel heard? Were there any requirements they expected to be captured that were not? This feedback, recorded in your logbook, is both professionally valuable and demonstrates the kind of client-orientation that strong project managers exhibit.

WM-01-WE02 sits within a module that focuses on project planning processes under authentic working conditions. Understanding where project initiation activities fit within the broader module — and the broader project management qualification — helps you recognise why this activity is placed where it is and what it is preparing you for.

Initiation is the first phase of the project life cycle. The activities you are learning and practising here — charter interpretation, needs assessment, client consultation, scope statement compilation — are the foundation on which all subsequent project management activities are built. If the scope is poorly defined, the project plan will be built on an unreliable foundation. If stakeholder requirements are incomplete, the project's deliverables will fail to satisfy at least some of those stakeholders. If the management approach is not documented, the project team will operate without clear governance, leading to confusion about who makes which decisions and how communication flows.

The module's broader work experience focus builds progressively. In this element, you are working on initiation. Elsewhere in the module and qualification, you will engage with planning (developing schedules, budgets, risk registers, and communication plans), execution monitoring, and project closure. Each of these phases builds on initiation: the schedule is built from the scope; the budget is built from the scope and the management approach; the risk register is built from assumptions and constraints identified during initiation; the communication plan is built from the stakeholder register developed during initiation.

The requirement for at least two projects is significant in this broader context. Each project gives you a new context in which to apply the same principles, which accelerates the development of contextual judgment — understanding not just what to do, but how the right approach changes depending on the project type, sector, client, and organisational environment. This is the kind of judgment that can only be developed through practice, not through classroom instruction alone.

The close supervision structure of this element also reflects a progression that the qualification is designed to support. Close supervision here is appropriate because your judgment is still developing. As you move through the qualification and accumulate workplace experience, the expectation shifts from 'under close supervision' toward 'under general supervision' and eventually toward independent professional practice. Recognising where you are in this progression — and actively working to develop the judgment that will allow you to move forward — is part of what the logbook reflection process is designed to support.

Developing the habit of structured, deliberate questioning before taking action is one of the most valuable professional disciplines a trainee project manager can build. The following questions are calibrated to the specific activities of WM-01-WE02 and should become part of your standard practice at each stage of initiation.

Before reviewing the charter or brief:

• What is the source of this document? Who prepared it, when, and in what context?
• Has it been formally authorised? By whom?
• Do I have the most current version?
• Are there any companion documents (terms of reference, feasibility studies, earlier correspondence) that I should read alongside it?

Before formulating clarifying questions:

• Have I read the entire document at least once before forming any conclusions?
• Have I distinguished between things that are genuinely unclear and things that I simply do not yet know enough to interpret? (The latter is a knowledge gap I should address by research or asking my mentor, not by querying the client.)
• Is each of my questions necessary — i.e., would the answer materially change the requirements document?
• Have I phrased each question clearly enough that a non-technical client contact will understand what I am asking? (The curriculum's worked example flags that one question was ambiguously phrased.)

Before the client consultation meeting:

• Has my mentor reviewed my draft questions?
• Do I have a clear agenda and am I prepared to lead the meeting professionally?
• Do I have a system for recording what is said (notes, minutes)?
• Am I prepared to go beyond my question list if the conversation surfaces new requirements?

Before finalising the requirements document:

• Have I addressed requirements in each category: functional, operational, technical, compliance?
• Have I consulted every relevant stakeholder group, not just the primary client contact?
• Is each requirement traceable to a source?
• Has my mentor reviewed this document?

Before submitting the scope statement to the client:

• Has my mentor reviewed and approved the document?
• Does the scope statement include explicitly stated exclusions, not just inclusions?
• Are all assumptions and constraints formally documented?
• Is the acceptance criteria for each deliverable clear and measurable?

Before writing a logbook entry:

• Do I have the specific date and a specific description of the activity?
• Have I described what I did (or observed), not just what the project team did in general?
• Have I described my mentor's specific involvement?
• Have I stated the outcome?
• Have I written a genuine reflection — something I would actually do differently, with a specific reason why?

WM-01-WE02 is a Workplace Activity element, which means its primary mode of assessment is evidence of real workplace engagement, not examination performance. Understanding how this element connects to the qualification's broader practical and workplace components helps you maximise the value of your placement time and ensure that your logbook evidence is as strong as possible.

The logbook as evidence: The workplace logbook is both a learning tool and an assessment instrument. It serves as evidence that you have engaged with specific activities in a real workplace context, at a level of detail that allows a supervisor and assessor to confirm that the activity genuinely happened as described. The curriculum's distinction between a strong logbook entry and a vague one is not just about credit — it reflects the professional standard for project documentation generally. A project manager who can only produce vague records of what was done and decided is a professional liability.

The mentor relationship as a learning structure: Close supervision by an experienced project manager is not just a safety mechanism — it is the pedagogical structure of this element. The mentor's role is to review your drafts, attend key meetings with you, provide structured feedback, and walk you through workplace-specific practices, policies, and documents. Recording the mentor's specific contributions in your logbook demonstrates that the close-supervision requirement was genuinely met, not just nominally satisfied.

The two-project requirement as depth-building: The requirement to attend to initiation for at least two projects is a practical component requirement, not just a guideline. It reflects the qualification's recognition that competence requires more than a single exposure. From an assessment perspective, evidence from two distinct projects demonstrates that your application of initiation skills is not project-specific but transferable — which is the hallmark of genuine professional competence.

The connection to other workplace activity elements: Within the same module, other workplace activity elements cover project planning, monitoring, and closure. The initiation skills developed in WM-01-WE02 directly feed into those subsequent elements. A scope statement produced during initiation becomes the baseline against which schedule, budget, and scope changes are assessed during planning and execution. Stakeholder groups identified during initiation become the audience for communication plans developed during planning. This sequential dependency means that the quality of your initiation work has downstream consequences for your performance in later placement activities.

Demonstrating progression in your logbook: Across the two or more projects you attend to, your logbook entries should show a progression. Early entries may describe more observation and less independent action; later entries should show increasing independent application of initiation skills, with the mentor shifting from co-participant to reviewer. This progression is itself evidence of learning and is part of what assessors look for when evaluating the workplace component.

Understanding where marks are typically lost in the assessment of this workplace activity element helps you focus your effort on the aspects that matter most to assessors.

Trap 1: Vague logbook entries. The curriculum states this explicitly: a vague entry earns no credit. The most common form of this trap is writing about categories of activity rather than specific instances — 'I worked on project initiation activities this week' rather than 'On 14 March, I reviewed the signed brief for the [Client Name] site-refurbishment project, identified three gaps, and drafted the following clarifying questions.' The fix is to write entries at the level of the worked example provided in the curriculum: dated, specific, verifiable, with mentor involvement and outcome described.

Trap 2: Undated entries. Dates are required. An entry without a date cannot be verified as having occurred during the placement period, and cannot be cross-referenced with a mentor or supervisor's records. Date every entry at the time of writing, not retrospectively.

Trap 3: Describing what 'the team' did rather than what you specifically did or observed. Assessors need evidence of your engagement, not the project team's activity. 'The team reviewed the project brief and identified gaps' tells an assessor nothing about your role. 'I reviewed the brief and identified three gaps, which I documented in a gap log and reviewed with my mentor before the client meeting' demonstrates your specific engagement.

Trap 4: Omitting the reflection component. The logbook structure requires a reflection: what you would do differently on a similar project in future. Entries that describe activity and outcome but omit a genuine reflection are incomplete. More importantly, shallow reflections ('I would be more careful next time') do not meet the standard. The reflection should be specific — identifying a concrete aspect of your practice that you would change and explaining why, as the curriculum's worked example does with the operational requirements gap.

Trap 5: Only one project's worth of evidence. The requirement for at least two projects is a minimum standard for this element. Logbooks that only provide initiation evidence from a single project are incomplete, regardless of the quality of the evidence for that project.

Trap 6: No evidence of mentor involvement. Close supervision is a defining feature of this element. If your logbook entries do not describe your mentor's specific role at each stage — what they reviewed, what feedback they gave, what they approved — an assessor cannot confirm that the close-supervision requirement was met. Record the mentor's involvement specifically and concretely.

Trap 7: Confusing scope statement compilation with brief summarising. If your logbook and submitted scope statement suggest that you treated scope statement compilation as a brief-summarising exercise, this indicates a fundamental misunderstanding of what the activity requires. A scope statement that was produced through analysis, consultation, and needs assessment — and that contains requirements not in the original brief — demonstrates genuine engagement with the initiation process.

Use the following self-check questions to test your understanding of the key concepts and practices in WM-01-WE02 before your logbook submission or any assessment event.

Self-Check Question 1: You have received a signed project brief from a client. Your mentor tells you to prepare for a client consultation meeting. What should you do before the meeting, and why?

The answer is shown to learners enrolled in this module.