Pillar 8 · Cluster 1
Project management fundamentals for GBS
Understanding the boundary between BAU and projects, managing scope, and maintaining RAID logs are the baseline project management skills every GBS professional needs when transformation work begins.
triple constraint, project lifecycle, RACI matrix, project charter
Sound familiar?
Topic 01 · Definitions
Project vs BAU — defining the boundary
Projects and BAU run on different clocks, different success measures, different rules. Confusing them burns out SMEs and stalls projects. The model is in THE FIX.
Two kinds of work.
Two different rulebooks.
PPriya’s calendar: month-end close on one side, migration workshops on the other.
BAU rewards zero surprises. The project rewards fast decisions and change.
She keeps applying BAU instincts to project questions — and the project keeps waiting.
"I was running two jobs with one rulebook."
She feels split — until she names the difference.
You bring BAU caution to project decisions and project chaos to BAU stability.
Same person, two operating modes — switch consciously.
She labels every calendar block BAU or project. The right instincts start showing up at the right meetings.
Project vs BAU in depth
If everything is a project, nothing is a project. The distinction matters because projects have different governance, funding, and success criteria than ongoing operations.
Characteristics
- Ongoing, recurring work with no defined end date
- Success = consistency, SLA compliance, quality maintenance
- Funded through operating budget (Opex)
- Managed by team leads and process owners
Characteristics
- Temporary, unique work with defined start and end
- Success = delivering defined scope on time and budget
- Funded through project budget (may be Capex or Opex)
- Managed by project managers with dedicated governance
Triple constraint — scope, time, cost, quality
Label tomorrow’s calendar: BAU or project, per block. Notice where your instincts mismatch.
Two modes named. Projects also have a clock — learn its phases.
Topic 02 · Framework
The project lifecycle — initiation to closure
Every project moves through the same phases: initiate, plan, execute, close. Knowing the phase tells you what matters right now. The model is in THE FIX.
Every project has seasons.
Know which one you are in.
KKlaudia joins her first project mid-flight and pushes for scope additions.
Cold reception. A colleague explains: planning closed a month ago — the team is deep in execution.
Her idea was good. Her timing was a season late.
"Right suggestion, wrong phase, no impact."
She feels out of step — a map would have fixed it.
You act without knowing the phase — and good contributions land as disruptions.
Four phases, four different questions being answered.
Her next suggestion arrives during planning — and shapes the project instead of bouncing off it.
The project lifecycle in depth
Every project follows the same fundamental arc: define what you are doing, plan how to do it, execute the plan, and close properly. Skipping phases creates downstream problems.
Initiation
Define the project purpose, scope boundaries, key stakeholders, and success criteria. Produce a project charter. Get formal approval to proceed.
Planning
Break down work (WBS), estimate effort and duration, identify dependencies, assign resources, and define the communication plan. Baseline the schedule and budget.
Execution
Deliver the work packages according to plan. Manage scope changes through formal change control. Track progress against baselines. Conduct regular status reporting.
Monitoring and Control
Compare actuals to plan. Manage RAID items. Escalate blockers. Adjust resource allocation. This runs in parallel with execution, not after it.
Closure
Formal acceptance of deliverables. Lessons learned documentation. Resource release. Handover to operations. Celebrate and recognize contributions.
Project lifecycle — initiate, plan, execute, monitor, close
Name your current project’s phase. Check your last three contributions against it.
Phases carry risks. RAID is where professionals park them.
Topic 03 · Control Mechanism
RAID logs — managing risks, assumptions, issues, dependencies
RAID — Risks, Assumptions, Issues, Dependencies — is the project’s shared memory. Contributing to it is how SMEs earn trust. The model is in THE FIX.
You saw the risk coming.
Saying so in the hallway does not count.
PPriya mentions a data-quality risk to a colleague over coffee. Weeks later it detonates.
The project manager asks why nobody flagged it.
She did — in the one place that does not exist on any record.
"If it is not in the RAID log, you never said it."
She feels unheard — and learns where hearing happens.
You voice concerns in hallways and lose both the protection and the credit.
RAID is four lists, one habit.
Her next concern goes in the log, dated and owned. When it materializes, the record shows who saw it first.
RAID logs in depth — with template structure
A RAID log is the single most important project management artifact. It is where you track everything that could go wrong, everything you are assuming, and everything you depend on.
- Risks — events that have not happened but could impact the project. Each risk needs a probability, impact rating, mitigation plan, and owner.
- Assumptions — things you believe to be true but have not confirmed. Unvalidated assumptions become risks. Validate early.
- Issues — problems that have already occurred and need resolution. Each issue needs an owner, target resolution date, and escalation path.
- Dependencies — external inputs or decisions your project depends on. Track the source, expected delivery date, and contingency if the dependency fails.
RACI matrix — responsible, accountable, consulted, informed
Log one risk you have only ever said out loud. Likelihood, impact, suggested owner.
Logged risks stay contained. Unlogged wishes become scope creep.
Topic 04 · Scope Control
Scope management — preventing creep
Scope creep kills more projects than bad execution. Every "small addition" is a trade — make the trade visible. The model is in THE FIX.
"While we are at it…"
Famous last words.
KKlaudia’s tidy improvement project. Week 2: "Can it also cover entity B?" Week 4: "One extra report?"
Each addition: reasonable. Sum: a project twice the size, same deadline, same team.
Week 8: everything half-built, nothing delivered.
"We said yes five times and failed once."
She feels swamped by kindness — her own.
You accept additions one by one because each is small. Projects die by accumulation, never by one blow.
Scope defense is one sentence and a process.
Request six meets the sentence. The sponsor drops it in ten seconds — the trade was never worth it once it was visible.
Scope management in depth
Scope creep is the leading cause of project failure in GBS. It happens when changes are accepted without assessing their impact on timeline, budget, and resources.
- Define scope in writing before execution begins — if it is not in the scope statement, it is not in scope
- Change control process — every scope change requires impact assessment (time, cost, risk) and formal approval before implementation
- Trace every deliverable to a requirement — if a deliverable cannot be traced to an approved requirement, it is scope creep
- Say no with evidence — "This change adds 3 weeks and $50K to the project" is more effective than "no"
- Distinguish scope change from scope clarification — clarifying an ambiguous requirement is not a change; adding a new requirement is
Answer the next addition with the trade it costs. Let the requester choose.
Fundamentals set. Cluster 2: pick the method that fits.
- The RACI matrix is the single most underused tool in GBS projects. Every time I see a project struggling with unclear ownership, missed handoffs, or duplicated effort, the root cause is the same: nobody defined who is Responsible and who is Accountable. One "A" per task — no exceptions.
- Project charters are not bureaucracy. A charter that takes 30 minutes to write saves 30 hours of scope creep arguments later. If your sponsor cannot articulate the problem, the success criteria, and what is out of scope in one page, the project is not ready to start.
Reference
Glossary
Full glossary at the GBS Insider Club Field Guide.
- PMI — A Guide to the Project Management Body of Knowledge (PMBOK), 7th Edition
- PRINCE2 — Managing Successful Projects methodology
- McKinsey — Delivering large-scale transformation programs, 2024
- Standish Group — CHAOS Report on project success rates, 2024
Knowing the frameworks is the entry ticket. Applying them — visibly, at your actual job — is what gets you promoted.
The GBS Insider Club Career Playbooks turn this theory into a guided 90-day program for your role: self-assessment, practical exercises, templates, and Julian's unfiltered practitioner playbook.
Explore the Career Playbooks → Back to Projects and Transformation