The five process groups of a project, and where AI fits into each one

I first taught this seminar in 2021, inside a bank, with a real collections project on the table. Five years on, the method has not moved a millimetre: a project is still a temporary effort with a beginning, an end and deliverables, and it still runs through the same five PMI process groups.

What did change is the toolbox.

There are tasks that took me an afternoon in 2021 and take twenty minutes today. And there are others — the ones that decide whether the project gets approved, whether the scope holds, or whether to stop — where the tool helps not at all, and where delegating is exactly the mistake you cannot afford.

This article closes the seminar through module 3. First the full map. Then, phase by phase, what I hand to an AI, with what instruction, and where I keep my hands on the wheel.

The map, on one page

Before the five process groups there is a distinction almost nobody draws properly, and half of all failed projects start there: not everything you are handed is a project.

That third row is the one that matters. If what you were asked for has no end, produces no deliverable different from yesterday’s, or is simply business as usual under more pressure, it is not a project — and managing it as one only adds ceremony.

And once it is one, the full path is this:

Problem or opportunity → idea for a solution → assessment → business case → approval — and only then does the life cycle begin. The five process groups happen after approval. Everything before that is called an initiative, and confusing the two is why so many people “start projects” that never had a budget.

Before the project: the initiative and the business case

There is no project here yet. There is a problem, an idea, and someone who has to convince a committee.

The business case is the document that makes that conversion. It carries the problem with its cause and impact, the solution and why it would work, quantified benefits, the financials — CAPEX, OPEX, ROI, NPV, IRR, payback, projected over six years from a year zero — and an execution plan with milestones and risks. The executive summary goes first and is written last.

Where AI fits. In three things, and none of them is “write my business case”.

The first is ordering what you already know. You know the problem; you have lived it. What costs you is turning that disordered knowledge into the structure the committee expects. You hand over your raw notes — what fails, who it hurts, what occurs to you — and ask for them to be laid out in the seven sections of a business case, explicitly flagging which sections came out empty.

“Organise these notes into a business case with these sections: executive summary, problem, solution, benefits, financials, execution and risks. Do not invent data. Where information is missing, write exactly what is missing and who in the organisation would have it.”

That last sentence does the work. What comes back is not a business case: it is the list of what you still have to find out, which is far more useful at that stage.

The second is finding the holes in your own idea. Ask it to act as the committee that will say no.

“You are the committee that approves or rejects this case. Ask me the five most uncomfortable questions you will put to me in the presentation.”

In my experience three of those five are the ones you actually get. It is the cheapest rehearsal there is.

The third is writing the executive summary once everything else exists. It does that well, because it is summarising a text that is already there.

What you do not hand over: the numbers. Quantified benefits, CAPEX, OPEX and assumptions come from people in your organisation who know the real costs. An AI will produce figures that look perfectly reasonable and are invented — the worst possible outcome in a document whose entire purpose is to get someone to commit money.

1 · Initiating

Two processes, and one of them happens exactly once in the life of the project.

The project charter is the document that formally authorises the project to exist and gives the manager authority to apply the organisation’s resources. It carries the purpose, the measurable objectives and their success criteria, the high-level description and the boundaries, overall risk, the milestone schedule, pre-approved funding, key stakeholders, who decides whether the project succeeded, the exit criteria, and the name and authority level of the manager and the sponsor.

Much of that is already in the business case. The charter is not written from scratch: it is translated.

Identifying stakeholders is the other one, and it sinks more projects than any other when it is rushed. Listing names is not enough: a useful matrix carries, for each stakeholder, their interest in the project, their level of influence, what they will contribute, and where they will resist. That last column is the one almost nobody fills in, and the one that explains half the blockers of the following months.

Where AI fits. Turning the business case into a charter is a format translation, and it does that well:

“Convert this business case into a project charter with these fields: [the list]. If a field cannot be filled from what is in the document, mark it as pending instead of completing it.”

And for stakeholders, the use that has served me best is not having it list them — you know those — but having it point out the ones you forgot:

“This project changes the payment application process in collections. Give me a list of roles and areas that are usually affected by a change like this and that people forget to include: control functions, support, whoever receives the complaint when something fails, whoever maintains the system afterwards.”

What comes back is categories, not people. You supply the people. But the category “who maintains this after the project closes” is precisely the one missing from everyone’s first list.

What you do not hand over: the influence and resistance analysis. Who holds real power in your organisation, who owes whom a favour, and who will quietly block the project in committee is political knowledge, not documentary knowledge. It is not in any text the tool can read.

2 · Planning

The largest group, and the one that decides whether the rest can be managed at all. Five blocks, in order, because each feeds the next.

Requirements. What has to be gathered from every source: business requirements, stakeholder requirements, solution requirements — functional and non-functional — and project requirements. Before entering the baseline they must be unambiguous, measurable, testable, traceable, complete and consistent. In agile approaches this is the backlog: epics, user stories, acceptance criteria.

Scope. Where your work starts and where it ends. And it is written SMART: specific, measurable, attainable, relevant, time-bound. A scope you cannot read and tell whether it has been met is not a scope, it is an intention.

WBS. The hierarchical decomposition of the work into packages. The most-broken rule: a WBS is built from deliverables, not tasks. The work package is the lowest level at which you can still estimate cost and duration.

Activities and schedule. Now the tasks: define, sequence, estimate duration. With zero-duration milestones, predecessors and dependencies, and resource levelling.

Costs and budget. Two formulas that fit on a napkin and settle 90% of cases:

Execution cost = resource cost × task duration
Budget         = procurement + execution cost

In the seminar this is done by building a room: bricks, cement, sand, paint, a window, a door and a roof on one side; two contractors at 16,000 pesos an hour on the other. Procurement comes to 1,489,800 pesos, execution to 8,960,000, and the budget to 10,449,800. It is deliberately domestic, because the method is identical on a fifty-billion-peso project.

Where AI fits. This is the phase where it saves me the most time, by a distance.

Decomposing the WBS. You give it the scope and ask for the first level of decomposition. What comes back is never the final WBS, but it is a draft to think against, which is much faster than a blank page:

“This is the project scope: [text]. Propose a three-level WBS, organised by deliverables and not by tasks. For each work package at the lowest level, say which deliverable it produces.”

The “by deliverables and not by tasks” condition has to be explicit, because by default you get a list of activities — which is precisely the classic mistake.

Finding what is missing from the WBS. Better still: hand over the WBS you built and ask for the gap.

“This is my WBS. Which deliverables typical of a project like this are missing? Think about training, documentation, data migration, testing, go-live and post-launch support.”

Turning packages into activities and proposing an initial sequence with predecessors. The schedule that comes out is wrong, always. But it is wrong in a concrete way you can correct, and that is faster than building it from nothing.

Rewriting the scope as SMART. Hand over your paragraph and ask what it lacks to be specific, measurable and time-bound. Here it is good: this is a review of form against a clear criterion.

What you do not hand over: the estimates. Neither duration nor cost. An AI does not know how long your team takes, does not know your system’s technical debt, does not know that the vendor is always two weeks late or that December does not count. It will give you numbers that sound right and are fiction — and a baseline built on fiction is worse than no baseline, because it gives you false confidence for months.

Estimates come from the team that will do the work, from historical data, or by analogy with projects you know. All three require someone who was there.

3 · Executing

Directing and managing the work: assigning resources, implementing approved changes, producing the deliverables, and managing project knowledge. And the part that is always underestimated: communications.

Project communication is not sending emails. It is a strategy — who needs to know what, how often, in what format — and then the execution of that strategy. The central instrument is the PSR, the project status report, which carries quantitative information, qualitative information, and the project’s specific issues.

Where AI fits. Here the saving is hours per week, and it is the least glamorous and most profitable use.

Writing the same update for three audiences. The project status is one thing, but the steering committee, the technical team and the end user need three versions. That translation is mechanical work:

“This is the project status this week: [notes]. Write it in three versions: a paragraph for the steering committee focused on risks and dates; a list for the technical team focused on blockers; and three lines for the end user about what will change and when. Do not add information that is not in my notes.”

Summarising meetings and pulling out commitments. From a transcript or your notes, extract what was decided, who owns what, and by when. Ask explicitly for a separation between what was decided and what was left open — that separation is what makes minutes useful.

Drafting the difficult message. The “the date has moved” email has a shape that works: the fact first, the cause second, the action and the new date last, without adjectives. Asking for three versions and picking one is faster and comes out better than writing it first time while annoyed.

What you do not hand over: the decision about what to communicate and to whom. Holding back a delay or announcing it a week early is a management decision with consequences. The tool drafts; you decide.

4 · Monitoring and controlling

It runs throughout the project, in parallel with execution. Compare actual performance against the plan, judge whether preventive or corrective action is needed, verify risks, feed the status report and the forecasts, and — the one most often forgotten — make sure the project is still aligned with the business need that created it.

Two concepts worth keeping straight, because they get confused constantly:

• Risk: a problem that has not materialised and could affect the project.
• Issue: a risk that has materialised and is causing damage.

And the most used health indicator is RAG — red, amber, green — measured separately against each constraint: scope, cost and time. Amber is precisely the territory of risks: it has not happened yet, but it is heading there.

Where AI fits. The best use in the whole methodology is here, and it is the least mentioned.

Spotting the deviation before it is obvious. Hand over the baseline and the actual progress, and ask it to compare and flag where they are separating, with the size of each gap. Not to decide: so that none of them slips past you.

“This is my schedule baseline and this is the reported progress. Give me every activity where the difference exceeds 10%, ordered by impact on the critical path, and say which of them have successors.”

Turning the tracking into the PSR. You already have the data; the PSR is giving it shape. It does that well and fast.

Checking your own traffic lights for consistency. A use I like a great deal: paste in the finished PSR and ask whether the colours match what the text says. It is remarkable how often one marks cost green and then describes an overrun three paragraphs below.

What you do not hand over: setting the colour. RAG is a management judgement, and it is political as well as technical. Marking a project amber has consequences — committees activate, explanations are demanded — and that call belongs to whoever answers for the project. An AI that “calculates” the light from thresholds will give you green the day before everything collapses, because the thresholds do not know the one critical vendor just resigned.

5 · Closing

The group most often skipped, and the one that leaves the most value for the next project.

Closing means: verifying that the completion or exit criteria were met, having every document and deliverable updated and every issue resolved, obtaining formal acceptance from the client, assigning all costs to the project, closing the accounts, reassigning staff and equipment, disposing of surplus material, producing the final reports and holding the closing session.

The important word is formal. A project that “is finished” but whose deliverable nobody accepted in writing is still open, and you will keep receiving requests about it for months.

Where AI fits. Here it does something that in practice almost nobody manages to do well.

Lessons learned, for real. The lessons-learned session is normally run from memory, at the end, when everyone is tired and only remembers the last two weeks. But the project left a complete record: minutes, weekly PSRs, the change log, the risk and issue log. Handing all of that over and asking for the pattern is a use with no reasonable manual substitute.

“These are all the PSRs and the change log for the project. Which type of deviation repeated most? In which phase did the issues appear? Which risks did we identify at the start that never materialised, and which ones hit us without our having seen them coming?”

That last question — what hit us unseen — is the lesson that genuinely helps the next project, and the one that never comes out of a meeting run from memory.

Drafting the final report from the charter and the accepted deliverables, comparing what was promised against what was delivered.

What you do not hand over: the acceptance. The client’s signature is an act, not a document.

The four where I would not use it

If you take one section away from all of this, make it this one.

1. Estimates nobody will validate. The biggest risk of all, because the output looks right. An invented duration or cost becomes the baseline, and you will measure the project against that baseline for a year.

2. Scope decisions. What is in and what is out is the most expensive decision on the project and it depends on negotiation with stakeholders, budget and strategic priority. The tool can draft the scope you decided; it cannot decide it.

3. Confidential data in public tools. Client names, unpublished figures, contracts, personal data. This is not a style preference: in Colombia personal data sits under Law 1581 of 2012, and a tool being convenient does not change the regime. Before pasting anything, the question is whether that text could leave the company by some other route. If the answer is no, then not by this one either.

4. The relationship with stakeholders. It can draft the email. The difficult conversation with the sponsor who wants more scope on the same budget, it cannot. That is the job.

The pattern, in one sentence

The same thing repeats across all five phases: AI is good at transforming information that already exists, and bad at producing information that does not.

Translating a business case into a charter, turning notes into a PSR, reorganising a WBS, summarising fifty documents into a pattern: all of that is transformation, and it pays off. Estimating a duration, setting a traffic light, deciding a scope, quantifying a benefit: all of that is producing new information about a world the tool does not know, and that is where it does harm.

The judgement to tell which is which is not learned from the tool. It is learned by running projects.

The module challenge

Build and present the PSR for a project. With its quantitative information, its qualitative information, the specific issues and the RAG for each constraint.

If you want to use AI, use it the way it works: assemble the content yourself and ask for the three versions for the three audiences.

Where this goes next

This article closes module 3 and with it the five process groups. What remains of the seminar is the module on agile methods, and the full piece to camera.

The earlier modules:

• How a project is born — module 1: the difference between process, initiative and project, and how to build a business case that clears the committee.
• How to choose a project life cycle — module 2: predictive, iterative, incremental, agile and hybrid as points on one scale.

A note on how this was written

Worth saying, because not saying it would be incoherent: this article was written using exactly the method it describes. The structure, the order of the phases and the limits come from the 2021 seminar notes and from twenty years of professional experience, more than fifteen in the financial sector. The drafting and the organisation were worked through with an AI tool.

What was not delegated: what goes in and what stays out, which examples are honest, and the four warnings above. That is the content, and content cannot be delegated.

The collections case that runs through the seminar is real, and the project’s figures are not published: the 300-million-peso fine is already part of the story I tell publicly, but the benefits, the CAPEX and the returns belong to the bank where it happened.

Sources

• PMBOK Guide, 6th edition — Project Management Institute
• Project Management seminar notes, modules I, II and III (2021)