Project management at IMC.
A 3-session course built around what your teams actually said in the survey — not generic PM theory.
Over the next three sessions we will build a shared way to run cross-functional projects at IMC. The course is anchored on a single observation from the survey across BD, R&D, Production, and International Market Development:
The teams agree on what is broken — scope changes, unclear roles, plans that do not match reality, and information that does not flow between functions. The disagreement is only on what to do about it.
This course gives you one answer to "what to do about it." Not the only answer. Not a complete answer. But a shared starting point we can pilot, measure, and improve.
What you will leave with
- A shared vocabulary across BD, R&D, QA, Production, and International — same words for the same things
- A 1-page operating model that describes how projects should run at IMC
- Four lightweight tools you can use Monday morning: project charter, RACI, risk log, status cadence
- One real project picked as a pilot — with named owner, sponsor, kickoff, and a 30-day check-in
What this course is not
- It is not PMP exam prep. We use the global standard as a map, but we are not teaching the syllabus.
- It is not a software training. No tools to install, no licenses to buy.
- It is not a consulting engagement. The pilot project is owned by IMC, not by the trainer.
If this is your first visit, read Why this course end-to-end before each session. The session pages assume you have read those three pages.
2026
How to use this
This site is the durable artifact of the course. The slides and discussions go away. This stays.
Three ways to use it
Before each session
Skim the session's overview page and the sub-pages. You do not need to memorize anything — but going in cold means you spend the first 30 minutes catching up instead of contributing.
During the session
The site is open during sessions. If you are referenced to a tool or template, the link is here. Worksheets used in activities live under each activity page.
After the course — the part that matters most
Once the sessions end, the room disperses. The pilot team uses this site as their reference. The 30-day check-in uses this site as the agenda. New PMs joining IMC after the course will be pointed here on day one.
Sessions are delivered in Vietnamese. Materials are in English so that key terms — RACI,
Project Lead, heartbeat, spine, dials — become shared
vocabulary across IMC. Do not translate these terms in conversation. Using the English term consistently
is what creates shared meaning.
What the survey told us
Four teams answered the same questions independently. The pattern is the lesson.
Before the course was designed, BD, R&D, Production, and International Market Development each filled out the same survey. They could not see each other's responses. The questions covered short-term and long-term goals, recent satisfactions, root causes of friction, and what they would change if they could redo a recent project.
What came back was striking — and the same observation in four different voices.
The pattern across all four teams
| Team | Their words (paraphrased) |
|---|---|
| Business Development | Standardize the BD–R&D–QA–Production workflow. Clarify roles and timelines. Cross-functional coordination is reactive, not designed. |
| R&D | Control content and schedule. Make sure each person knows what they own and how to do it. Decisions need to be based on data, not individual experience. |
| Production | Document what to do. Do what is documented. Build standardized KPIs. Apply PDCA at the team level. |
| International Market Dev | Pre-project assessment is weak. Information across departments is not transparent. We need leadership to name a project lead and a framework. |
The five root causes — checked by every team
- Initial plans don't match reality
- Scope (objectives) change mid-project
- Resources are insufficient — people are spread across many projects at once
- Cross-functional coordination is not smooth
- Projects get abandoned when priorities shift
One of the four teams added a sixth: "Unclear who owns the decision — which delays everything."
You came in worried this is an IMC problem. It is not. Every cross-functional product organization in the world has a version of this list. The good news: it is a solvable problem. The next three sessions are about how.
Where IMC is today
A manufacturer becoming an innovation hub — which means project work is no longer a side activity. It is the work.
For 20+ years IMC has built a strong position in health supplements, cosmetics, and nutritional products through GMP/ISO-certified OEM and ODM manufacturing. That work is largely operational — repeatable, well-understood, with known partners and known processes.
The strategic direction is now different. IMC is positioning as a multi-sector innovation hub: microbiology and biotechnology, water and environmental solutions, high-tech agriculture. The 2030 stated goals include exporting 100+ products to global markets and building a network of 500+ international partners.
What this means for project management
Two kinds of project work coexist at IMC right now:
Regular OEM/ODM work
Known customer, known formulation type, known production line, known regulatory path. The risks are mostly schedule and coordination — the work itself is familiar.
New-field exploration
New technology, new partners, sometimes a new market entirely. The risks are about the work itself — the team may not yet know whether the technology works, whether the regulatory path exists, whether the market wants it.
These two kinds of project look superficially similar. They are not. Treating them the same is one of the most expensive mistakes a project organization can make. We will return to this in Session 3 as the two dials.
The 2030 vision implies more new-field work over time, not less. The team's ability to recognize and run new-field projects is what determines whether the next 5 years of strategic projects succeed.
PM is a discipline, not a department
If you run cross-functional work, you are doing project management — whether or not the title is on your card.
The most common misunderstanding about project management is that it is the responsibility of a person called the Project Manager. In a small or single-function project, that may be true. In a cross-functional product organization like IMC, it is not.
Cross-functional projects have multiple people doing project management work simultaneously:
- The sponsor shapes the why and unblocks at senior level — that is project management
- The project lead coordinates day-to-day and owns the outcome — that is project management
- The function lead (BD, R&D, QA, Production) commits resources and coordinates within their team — that is project management
- The contributor who flags a risk early or asks "who owns this decision?" is doing project management
This is why the course is for both PMs and department heads together. If only one of those groups attends, the operating model will not stick — because the work is not done by one group alone.
What this means for participants
If you are a PM
Your job is not to do project management for the team. It is to make project management visible and shared so the team can do it together. The tools we cover (charter, RACI, risk log, cadence) are how you do that.
If you are a department head
Your role in projects is not "make the PM's job easier." It is to be a function lead — own the resources and decisions of your function within the project. The model in Session 3 names this role and what it requires.
Session 1 — Foundations
The session opens with your own words. We use the survey to name the pattern, then build the foundation everything else rests on.
Outcomes
- The room sees its own data and the pattern across teams
- Shared definition: what is a project, what is operations
- Shared list: the 5 universal causes of project trouble
- Shared mental model: the 5 things every project needs
- First exposure: regular vs. new-field project types at IMC
Agenda
| Time | Block |
|---|---|
0:00 – 0:15 |
Welcome and ground rules |
0:15 – 0:35 |
The survey, in your own words |
0:35 – 1:05 |
Project vs. operations + why projects fail |
1:05 – 1:20 |
Break |
1:20 – 1:55 |
Activity A: A project that blew up |
1:55 – 2:20 |
Group share-out |
2:20 – 2:50 |
5 things every project needs + IMC project types |
2:50 – 3:00 |
Wrap and what's next |
Project vs. operations
A confusion that sounds academic but causes real damage when teams treat one as the other.
Both are work. Both have outputs. Both consume resources. The difference is in the shape of the work and what kind of management it needs.
| Project | Operations | |
|---|---|---|
| Goal | Deliver a unique outcome | Sustain a steady output |
| Lifespan | Has a beginning and an end | Continuous |
| Team | Often cross-functional, temporary | Usually within one function, stable |
| Success | Outcome delivered, project closes | Performance held against KPIs |
| Examples at IMC | New product development, factory build, customer-driven OEM project, market entry | Daily QA testing, weekly production runs, monthly financial close |
Why this distinction matters at IMC
Projects fail when they are managed like operations. The team uses operational rhythms (steady weekly meetings, repeating KPIs, function-level reporting), but the project has a unique outcome that needs different management — explicit scope, named owners across functions, risk anticipation, and a clear close.
Operations also fail when managed like projects. Adding gates, milestones, and project roles to repetitive work creates ceremony without value.
Pick something you spent time on this week. Ask: did it have a unique outcome with an end date, or was it
a steady output that will continue next week? Most teams have a mix. The mistake is not noticing which is
which.
Why projects fail
Five universal causes that show up in every cross-functional product organization. IMC is not an exception.
The 5 causes
1. Initial plan does not match reality
The plan was made with optimism, with too little discovery, or with people who did not know the work. By week 4 the timeline already does not hold.
2. Scope changes mid-project
The customer asks for one more thing. Marketing notices a gap. Leadership has a new idea. Each change individually seems small. Together they reshape the project — without reshaping the timeline or the resources.
3. Resources are insufficient
The same people are committed to multiple projects at once. Officially each project has the resources it needs. In practice, no project has the people for the time the work requires.
4. Cross-functional coordination is rough
Each function does its work well in isolation. The handoffs between functions are where the project loses days, weeks, sometimes the whole quarter. Information that one function has does not reach the function that needs it.
5. Priorities shift, projects get abandoned
A more urgent thing comes up. The project does not get formally cancelled — it just stops. Months of work sit half-finished. When priorities shift back, the team starts from scratch because the partial work is no longer current.
Why these are not IMC's fault
These five causes show up in every cross-functional product organization in the world — startups, multinationals, government programs, university research, manufacturers. Naming them does not change them. Designing the work so they have less room to operate is what changes them.
The next sessions are about that design.
5 things every project needs
Strip a project down to its minimum viable structure. There are five things — not six. If any are missing, you will see the symptoms.
1. A goal — the why
One sentence. What outcome are we trying to deliver, and why does it matter? If two people in the project answer this differently, the project does not have a goal yet — it has a slogan.
2. A scope — the what and the what-not
Most teams write the "what." Few write the "what-not." Both are equally important. Naming what is out of scope prevents the slow drift into a different project.
3. An owner — who decides
Not who works hardest. Who has the authority to decide when there is conflict, ambiguity, or trade-off. One owner per decision. If an owner is not named before kickoff, decisions will be made by whoever is loudest in the room.
4. A plan — how
Not a Gantt chart. The plan answers: what are the major work streams, what is the rough sequence, who owns each, what could go wrong. A 1-page plan is enough for most projects.
5. A heartbeat — how we know we are on track
The cadence of meetings, status updates, and decision points that keep information flowing. Without a heartbeat, the project goes quiet — and quiet projects fail in silence until someone notices.
Before kickoff of any project at IMC, write a 1-page document that answers these five things. If you cannot write the document, you do not have a project — you have an aspiration.
IMC's project types
Five recognizable shapes of project work at IMC today. Each has a different management profile.
The 5 things every project needs (previous page) apply to all of these. But the how changes a lot depending on the shape.
Customer-driven OEM/ODM
A customer specifies what they want. IMC formulates, tests, manufactures, and delivers. Cross-functional: BD-led intake, R&D formulation, QA validation, Production. Mostly familiar territory. The risks are usually scope creep (customer changes spec) and timeline.
Internal new product development
IMC develops a product on its own initiative for a market it has identified. Same functions involved, but no external customer driving timeline. Different risks: market validation, prioritization against other internal projects.
New-field exploration
IMC enters a domain where the technology, partners, or regulatory path are not yet known — biotech, water tech, agritech. The risk is fundamental: we may not know whether the work is feasible. Treating this like an OEM project is the most common and most expensive mistake.
Capability projects (factory build, system rollout)
The output is not a product but a capability. Different success criteria, longer timelines, different stakeholders. Mentioned in survey by the Production team.
Market entry
Taking an existing product into a new geography or channel. Mostly BD and International Market Development. Different from OEM in that the deliverable is not a product but a market presence.
Across these five types, two variables matter most: how certain we are that the work will succeed, and how familiar we are with the work itself. We will turn these into a tuning tool in Session 3.
Activity A — A project that blew up
In small mixed-function groups, reconstruct one project that didn't go as planned and find the root cause together.
Format
- 4–5 groups of 5 people, mixed across departments
- 30 minutes group work + 25 minutes share-back
- Roles per group: scribe (writes), timekeeper, reporter (presents)
Group instructions
- Pick one project from the last 6 months that did not go the way you wanted. Small or large — does not have to be a disaster.
- Scribe writes the project name and a one-line summary at the top of the worksheet.
- For 15 minutes, answer: What was the moment it went off-track? Be specific.
- For 10 minutes, answer: Which of the 5 universal causes applies? Is there a cause we missed?
- Reporter prepares 90 seconds. The room will ask 2 minutes of questions.
What to bring back
- The project name and a one-line description
- The off-track moment
- The root cause(s) — from the 5 universal list, or new ones you discovered
- One thing you would change if you could re-do it
Not blame. Not solutions. The point is that across 4–5 unrelated projects, the same patterns appear. That recognition is the foundation of everything that follows.
Session 2 — The toolkit
Reframe the role of the PM, place the global standard in context, and learn four lightweight tools that punch above their weight.
Outcomes
- Reframe of what a PM does — from "scheduler" to four jobs (Clarify, Coordinate, Anticipate, Communicate)
- Map of the PMBOK 8 standard — used as orientation, not as material
- Four tools you can use Monday morning: project charter, RACI, risk log, status cadence
- A real RACI built for a real IMC project — and the role conflicts that surface in the process
Agenda
| Time | Block |
|---|---|
0:00 – 0:10 |
Recap of Session 1 |
0:10 – 0:35 |
The 4 jobs of a PM |
0:35 – 1:05 |
PMBOK 8 wall walk + 4 IMC-relevant domains |
1:05 – 1:20 |
Break |
1:20 – 1:50 |
Toolkit teach: charter, RACI, risk log, cadence |
1:50 – 2:35 |
Activity B: Build a RACI for a real project |
2:35 – 2:55 |
Cross-group RACI challenge |
2:55 – 3:00 |
Wrap and between-session work |
The four sub-pages below have key ideas drafted but body content will be expanded after the sponsor call between Session 1 and Session 2 — when we know which IMC examples to use throughout.
The 4 jobs of a PM
A PM is not a scheduler. A PM does four things — and the team is responsible for the rest.
1. Clarify
Make the goal, scope, and decisions explicit. Write down what the team is leaving implicit. The output of clarify work is a 1-page document that the whole project team can point at.
2. Coordinate
Hold the cadence. Run the heartbeats (team weekly, project bi-weekly, portfolio monthly). Make sure handoffs happen on time. The output is a project that is in motion at a known rhythm.
3. Anticipate
See what is coming before it arrives. Maintain the risk log. Surface dependencies between functions. Notice when the plan is no longer matching reality. The output is fewer surprises and earlier escalations.
4. Communicate
Translate up and across. Status to sponsors and leadership. Decisions across functions. Bad news early — bad news late is what creates IMC's stated frustrations. The output is a project where stakeholders are informed at the right level.
What is NOT the PM's job
- Doing the work of the function leads
- Being the only person responsible for the outcome — that is the sponsor's job
- Approving every decision — that is what the RACI prevents
- Knowing every technical detail — function leads own that
Add: short story or example for each of the 4 jobs from real PM experience. Add: typical IMC anti-patterns when each job is missing.
PMBOK 8 as a map
The global PM standard exists. It has 40 processes and 8 performance domains. We use it as orientation. We do not teach it line-by-line.
The Project Management Institute (PMI) publishes the PMBOK Guide — a shared body of knowledge for project management worldwide. The 8th edition organizes the discipline around 8 performance domains and 40 processes.
Ricardo Vargas, a past PMI chair, publishes a 1-page visual of the entire PMBOK 8 process flow. We use it as a wall map during Session 2.
Why we don't teach it line-by-line
- This room is mixed PMs and department heads. Memorizing 40 processes is not the goal.
- The survey is clear about IMC's biggest gaps — they map to 4 of the 8 domains, not all 8.
- Line-by-line PMBOK teaching is what PMP exam prep is for. This course is something different.
What to take from the map
- The discipline is broader than what you do day-to-day — but you don't need all of it
- The domains and processes provide a vocabulary for things you already do informally
- If a future project gets bigger or more complex, you have a map to find what you are missing
The full PMBOK 8 is available through PMI membership. Vargas's 1-page poster is on his website at
ricardo-vargas.com. Both are linked in the Reference section of this site.
What matters for IMC
From PMBOK 8's 8 performance domains, four are where IMC's stated pain lives. We focus there.
The 4 we focus on
Stakeholders
Who is involved, what they need, how we keep them informed. The survey shows IMC's stakeholder coordination is reactive — communication does not flow consistently across BD, R&D, QA, Production. This is where the most direct improvement is available.
Planning
Defining the scope, plan, and resource needs before commitment. Survey teams universally said "initial plans don't match reality" — that points here.
Project work
The day-to-day execution: how the team coordinates, how decisions get made, how progress is tracked. The heartbeats live here.
Uncertainty
Risk management, dealing with what we don't know. Particularly important for IMC's growing new-field work — where uncertainty is the dominant variable.
The 4 we de-prioritize for now
Team, Development Approach, Delivery, Measurement. These are important — but not the biggest gaps right now. Future cohorts can deepen here.
Add: 1-paragraph definition of each of the other 4 domains, and the IMC-specific reason we are de-prioritizing each. Discuss with sponsor before finalizing — the choice itself signals what IMC is and is not ready to address.
Lightweight tools
Four tools that are deliberately small. Big enough to work. Small enough that nobody has an excuse not to use them.
1. The 1-page project charter
One page. Five sections matching the 5 things every project needs: Goal, Scope (in/out), Owner, Plan (work streams), Heartbeat (cadence). Written before kickoff. Reviewed at the first project meeting.
2. RACI
A grid of decisions/deliverables on rows, roles on columns. Each cell is R (Responsible), A (Accountable — only one), C (Consulted), I (Informed). Built once at project start, revisited when scope changes.
3. Risk log
The simplest version that works: a table with risk description, likelihood (H/M/L), impact (H/M/L), owner, mitigation, status. Reviewed weekly at the team heartbeat.
4. Status cadence
Three meetings, three different audiences, three different time horizons. Team weekly (30 min, blockers), project bi-weekly (60 min, decisions), portfolio monthly (90 min, priorities). The full design is in Session 3.
The most common failure mode is treating these tools as paperwork. A charter that nobody reads is worse than no charter — it creates a false sense of clarity. A RACI that no decision references is just a table. The tools work only when they are used in conversation, in real time, in the project.
Linked from the Reference section. Each template is a single page. None require special software.
Activity B — Build a RACI for a real project
The activity looks like a RACI exercise. The actual purpose is to surface role conflicts that already exist — productively.
Format
- Same groups as Session 1, mixed across departments
- 30 minutes group work + 15 minutes cross-group challenge
- Each group picks one current IMC project they all have line-of-sight on
Group instructions
- Pick a current cross-functional project. It should have at least 3 functions involved.
- List the 6–8 most important decisions or deliverables on the rows.
- List the roles on the columns: Sponsor, Project Lead, BD Lead, R&D Lead, QA Lead, Production Lead, others as needed.
- Fill in the RACI letters: R, A, C, I. The rule: only one A per row.
- If you cannot agree on who the A is — write "CONFLICT" in red and move on. The conflict is more valuable than a forced decision.
Cross-group challenge
Each group hands their RACI to the next group clockwise. The receiving group has 5 minutes to find:
- Anywhere with two A's (rule violation)
- Anywhere with no A (gap)
- Anywhere they think the A is in the wrong role (judgment)
Then 10 minutes of cross-group reporting on what they found.
The conflicts found across groups are real — they exist in real IMC projects right now. We do not resolve them in the room (that is hierarchy's job). We make them visible, name them, and bring them to Session 3 as inputs to the operating model design.
Session 3 — Apply it
Less teaching, more commitment. The session ends with one real IMC project picked as a pilot.
Outcomes
- The IMC Project Operating Model — spine + two dials — understood and stress-tested
- Heartbeats designed: team weekly, project bi-weekly, portfolio monthly
- Lessons-learned mechanism that survives past project close
- One real project named as the pilot, with named owner, sponsor, kickoff, and 30-day check-in date
Agenda
| Time | Block |
|---|---|
0:00 – 0:10 |
Recap of Session 2 |
0:10 – 0:25 |
The operating model spine |
0:25 – 0:40 |
The two dials |
0:40 – 1:15 |
Activity C: Stress-test the model |
1:15 – 1:30 |
Break |
1:30 – 1:50 |
Heartbeats |
1:50 – 2:05 |
Lessons that stick |
2:05 – 2:40 |
Activity D: Pilot commitment |
2:40 – 2:55 |
Open Q&A |
2:55 – 3:00 |
Close — the 30-day check-in is the next milestone |
The operating model
One spine. Four roles. Three heartbeats. No gates.
Three things to notice
Roles are named, not titled
Sponsor, Project Lead, Function Lead, Contributor. These are roles within a project, not job titles. The same person can be a Function Lead in one project and a Contributor in another. The vocabulary survives reorgs and is portable across project types.
Phases are vocabulary, not gates
Initiate → Plan → Execute → Handover. No formal sign-offs, no go/no-go decisions, no paperwork at boundaries. The phases give people a shared way to say where they are. "We are still in Initiate" is a useful sentence. It tells the room the work is not yet planned, no one should be asking for delivery dates.
Heartbeats are the real product
The single highest-leverage element of the operating model is the cadence — Team weekly, Project bi-weekly, Portfolio monthly. If IMC adopts nothing else, the heartbeats alone solve most of what the survey complained about: information not flowing, decisions delayed, priorities shifting silently.
The two dials
Same spine, different tension. Regular OEM/ODM and new-field exploration are not the same kind of project — and treating them the same is expensive.
The two mistakes
Treating new-field work like a regular project
Heavy templates, fixed scope, predictable timeline — applied to a project where the team does not yet know whether the technology works. When the project reveals its uncertainty, the team blames each other for "scope creep" or "missed deadlines." The project did not fail. The dial was wrong.
Treating regular work like an exploration
Endless meetings to discover requirements that are already known. No scope discipline. Drifting timelines. This is how known work becomes expensive — and frustrates customers.
The thinking tool
Before picking tools and templates for a project, ask:
- Certainty: Do we know what success looks like and how to get there?
- Familiarity: Have we done work like this before?
High certainty + high familiarity → dial up rigor and standardization. Low certainty + low familiarity → dial up exploration and risk-checking. The same spine runs in either mode.
The strategic direction implies more new-field work over time — biotech, water tech, agritech. The team's ability to recognize and run new-field projects is what determines whether the 2030 goals are reachable.
Heartbeats
Three meetings, three audiences, three time horizons. The rhythm that keeps information flowing.
Team weekly — 30 minutes
Run by the project lead. Attendees: project lead + key contributors. Agenda: what is in motion this week, blockers, risks. Output: a 1-page note summarizing decisions and next actions.
Project bi-weekly — 60 minutes
Run by the project lead. Attendees: project lead + function leads (BD, R&D, QA, Production). Agenda: cross-functional decisions, scope changes, timeline updates. Output: a decisions log.
Portfolio monthly — 90 minutes
Run by the sponsor. Attendees: sponsors + project leads of all active projects. Agenda: priorities, resource conflicts, projects to escalate or stop. Output: a priority list for the next month.
Why three, not one
One meeting cannot serve three time horizons. A weekly meeting that tries to also resolve cross-functional decisions (project bi-weekly) and align portfolio priorities (monthly) will be 90 minutes long, attended by too many people, and resolve nothing. The three-tier design separates scope so each meeting is short, focused, and decisive.
Run the three heartbeats consistently for one quarter — then assess. Most of the survey's complaints can be solved by this alone. Skip the heartbeats and the rest of the operating model will not stick.
Lessons that stick
Most "lessons learned" documents die in a folder. The mechanism that works: turn lessons into rules in the next project's charter.
The failure mode
At project close, the team gathers. They list what worked and what did not. Someone writes a document. The document goes into a shared folder. Nobody reads it. The next project has the same problems.
The mechanism that works
At project close, the team picks three things from the lessons-learned that should change how the next project is run. Not 30 things. Three. Each becomes an explicit rule in the charter of the next project that fits the same shape.
For example, after a customer-driven OEM project where the customer changed the spec four times: "In every customer-driven OEM project, the BD lead documents the customer's stated goals at intake and confirms in writing before R&D starts work." That rule lives in the next OEM project's charter — visible, applied, real.
Why three, not 30
Three rules can be remembered. Three rules can be enforced. Thirty rules become a binder nobody reads. The discipline of selection is what makes the lesson stick.
Activity C — Stress-test the model
A real scenario walked through the model. Where it works. Where it strains. Where it breaks.
Format
- Same groups as previous sessions
- 25 minutes group work + 10 minutes share-back
- Operating model spine + dials posters on the wall
The scenario
A customer-driven OEM project is in Execute phase. Three weeks before delivery, the customer requests a formulation change that requires R&D rework, new QA validation, and a production line reschedule. BD wants to keep the customer happy. R&D says the timeline is impossible. QA wants more time. Production has another customer's run already booked.
Group instructions
- Walk this scenario through the operating model. Step by step.
- Identify: where does the model hold? Where does it bend? Where does it break?
- Be specific. Name the role, the heartbeat, the phase, the dial setting.
- Reporter prepares one of each: holds / bends / breaks.
What we do with the breaks
Anywhere the model breaks is a finding. We write all breaks on a flipchart titled "Model upgrades for the pilot." These become explicit improvements to incorporate into the pilot project's design — and to revisit at the 30-day check-in.
The model needs to survive contact with reality before it can be trusted. If it survives without modification, you weren't trying hard enough to break it. Real findings here are gifts.
Activity D — Pilot commitment
The end of the course. One real project picked. Named owner, sponsor, kickoff, and 30-day check-in.
Format
- Plenary, structured pick
- 2–3 candidate projects pre-shortlisted between Session 2 and Session 3 by the trainer + sponsor + 1–2 dept heads
- 35 minutes total
How we pick
Three structured questions, each answered by the room with show of hands or quick verbal:
- Of these candidates, which has the clearest cross-functional friction right now? Where would the operating model help most?
- Which has a sponsor in this room willing to back the pilot publicly?
- Which kicks off in the next 60 days?
The project that scores best across the three questions is the pilot.
What gets named on the day
- Pilot project: the chosen one
- Project lead: who runs it
- Sponsor: who backs it at senior level
- Function leads: for each function involved
- Kickoff date: when work starts under the new operating model
- 30-day check-in date: when we review what worked, broke, and changes
- Dial setting: regular or new-field — agreed up front
- Model upgrades: from Activity C, the breaks we agreed to address
What does NOT get decided on the day
- Whether the operating model is "approved" for IMC company-wide. That's the 30-day check-in's job.
- Whether other projects should adopt the model immediately. The pilot proves or refutes that.
If the room won't commit on the day, we leave with a 48-hour timeline: 1-page proposal sent within 48h, sponsor confirms by end of week, kickoff and 30-day check-in dated. The activity doesn't fail because the room is cautious — it fails only if there is no commitment by the end of that week.
Glossary
English terms used in the course, with short definitions. Use the English term in conversation — that is what creates shared vocabulary across IMC.
| Term | Definition |
|---|---|
| Charter | A 1-page document written before kickoff that names the project's goal, scope, owner, plan, and heartbeat. |
| Contributor | A team member doing work in a project, reporting through their function lead. |
| Dial | An adjustable setting in the operating model — Certainty and Familiarity. Used to tune the model for regular vs. new-field work. |
| Function lead | The lead of a function (BD, R&D, QA, Production) within the context of a specific project. Owns resources and decisions of their function for that project. |
| Gate | A formal go/no-go decision point. The IMC operating model deliberately does not use gates. |
| Heartbeat | A recurring meeting that keeps information flowing. Three of them: team weekly, project bi-weekly, portfolio monthly. |
| Phase | A named stage of a project: Initiate, Plan, Execute, Handover. Used as shared vocabulary, not as a formal gate. |
| Pilot | The first real IMC project to run under the new operating model. Selected at the end of Session 3, reviewed at the 30-day check-in. |
| Project lead | The person who owns the project's outcome day-to-day. Coordinates across functions, runs the heartbeats, escalates to the sponsor. |
| RACI | Responsible, Accountable (one only), Consulted, Informed. A grid mapping decisions/deliverables to roles. |
| Spine | The core of the operating model: roles + flow + heartbeats. Constant across all project types. |
| Sponsor | The senior leader who funds the project, sets the strategic intent, and unblocks at senior level. One per project. |
Templates
Single-page templates for the four core tools. Each is deliberately simple. Resist adding sections.
Templates to attach as downloadable single-page PDFs:
- 1-page project charter
- RACI grid
- Risk log
- Status report (team weekly + project bi-weekly + portfolio monthly variants)
- 30-day check-in agenda
Will be drafted between Session 1 and Session 2 — alongside the IMC examples confirmed in the sponsor call.
PMBOK 8 cheat sheet
For curiosity, not for memorization. The full standard is available through PMI.
The 12 principles
PMBOK 8 organizes project management around 12 principles — guiding ideas that apply across every domain. They include things like Be a diligent, respectful, and caring steward, Engage stakeholders, Demonstrate leadership behaviors, Tailor based on context, Build quality into processes and deliverables, and Embrace adaptability and resilience.
The 8 performance domains
- Stakeholders — who is involved and how they are engaged
- Team — how the project team is structured and led
- Development approach and lifecycle — predictive, adaptive, hybrid
- Planning — defining scope, schedule, resources
- Project work — day-to-day execution
- Delivery — outcome quality and value
- Measurement — KPIs and metrics
- Uncertainty — risk, ambiguity, change
The 40 processes
The PMBOK organizes specific processes (e.g. "Identify Risks", "Plan Communications Management", "Lead the Team") under the 8 performance domains. The Vargas 1-page poster shows all 40 in a single visual.
Where to go deeper
- PMI membership at
pmi.org— full PMBOK 8 download - Vargas process flow at
ricardo-vargas.com - PMP certification — for PMs with 3+ years of experience who want to formalize
Recommended reading
A short, deliberately curated list. More reading is not the goal — applying what is here is.
Suggested final list — to confirm with you:
- The Phoenix Project by Gene Kim — fiction, but the most clarifying book on cross-functional work and bottlenecks
- Making Things Happen by Scott Berkun — practical PM, written in plain language
- PMBOK Guide 8th Edition — the reference
- Vargas process flow poster — the visual
- One blog/newsletter recommendation per month from Anh's own reading — to keep the site alive
30-day check-in
The most important meeting of the entire engagement. Without it, the course is training. With it, the course is an intervention.
When
30 days after the pilot project's kickoff. Date set during Session 3.
Who attends
- Pilot project lead
- Pilot sponsor
- Function leads of the pilot project
- Trainer (this is part of the engagement, not a separate consulting ask)
Format — 90 minutes
| Time | Topic |
|---|---|
0:00 – 0:10 |
What we set out to do — quick recap |
0:10 – 0:35 |
What worked — be specific, name the moments |
0:35 – 1:00 |
What broke — what we'd change |
1:00 – 1:20 |
Decision: roll out, adjust, or stop |
1:20 – 1:30 |
Next steps and dates |
Output
A 1-page memo, written by the trainer within 24 hours of the meeting, sent to all attendees and the original course participants. Three sections: What we learned, What changes for the operating model, What we are doing next.
Roll out: the pilot worked. Pick the next 2–3 projects to adopt the model. Schedule the next check-in for 60 days.
Adjust: the pilot mostly worked, but specific things broke. Modify the model. Run another 30-day pilot.
Stop: the pilot did not work. Document why. Decide whether to redesign or shelve. This is a legitimate outcome.
Office hours
Between Session 3 and the 30-day check-in, the trainer is available for short conversations on applying the model.
Decide:
- Cadence: weekly drop-in vs. on-demand booking
- Format: in-person, video call, or async (Slack/email)
- Who is eligible: pilot team only, or all course participants
- Time-boxing: 30 min sessions, max 2 per week
The choice signals how much hand-holding IMC expects vs. how much they want to internalize.
— end of the field guide —
Slide Deck
Import slides exported from PowerPoint, or switch to Edit mode and paste / drag images anywhere on the page.