AI Project Manager
Training Program

Three explanations of your role. The department head, the architect, and the rank-and-file employee each get a different one. To the manager: you are the single point of contact and he no longer runs between contractors. To the architect: you take everything off him except technical decisions and bring information in a usable form. To the employee: you don't explain your role at all — you say what's about to happen and what's needed from him.

The employee is the hardest of the three. He sees his own stretch and doesn't understand how his actions affect everyone else. Before work starts he needs to be told that his stretch matters: otherwise he decides nothing depends on him and stops entering data.

What the role rests on. Not coordination and not translation, but ownership of the result — everything else follows from it. Coordination is secondary: it appears as a consequence of knowing what result has to come out.

The working philosophy. The solution has to be effective for the client. The point isn't the system, it's the result the system produces. This is the most fragile part of the job: effectiveness depends on the other side, and that's where it breaks most often.

Win them over first, then push. Always win them over first: if the client's team won't meet you halfway, an effective solution will never happen. But every act of winning over contains some pushing — when things need to speed up, or be done in a way that suits someone less. Projects that started out hard produce no result: there the team never got to the iteration stage and lost faith before anything began.

The sign of success without metrics. The solution is actually used. Not necessarily for the task it was built for — sometimes for a different one. If it's being used, it's solving something.

What has to be in the report. A project is handed over by document, not by conversation:

• the processes of every department and the managers' answers;
• the loss calculation and the baseline figures;
• the stakeholder map and the roles from the org chart;
• the order of departments: who gets audited first, who second;
• priority solutions, split into quick wins and big swings;
• what the company uses and what it doesn't;
• the return-on-investment calculation — the baseline figures the later measurement will be made against.

A good report reads like a book: afterwards you have no questions for the director. You write out the solution hypotheses, look at what exists on the market, and bring the architect only what you're unsure about.

What you study on your own before talking to the architect: industry law, the company's internal procedures, unfamiliar services. The architect also needs time to review — both of you come to the call prepared.

The category of questions the report won't contain. The director couldn't have foreseen they'd matter. The classic case: during the audit they mentioned the company has a CRM but doesn't use it. At the time that was irrelevant. Two weeks later it turns out a registry has to be built, and a registry can't be built without the CRM — and the question "why isn't the existing solution being used" becomes central. Which means there's a problem there, and it hasn't been unpacked. Such questions go back to the director, and a new session with that department is scheduled.

When the project goes back in full: there are gaps in the report — step two exists, three and four are missing, and it jumps to five; it's unclear whether the proposed solutions address the real problem; other contractors are working in the company in parallel and the scope depends on what they decide.

When returning it is mandatory. The solutions turn out to be substantially larger and more expensive than quoted — or substantially cheaper. This isn't a question, it's a notification: the project amount has to be renegotiated, and the director does that.

The communication structure after handover. The project manager sets the pace. If the director keeps stepping into the process, the plan falls apart: one does one thing, the other does another, and the client's side stops understanding who to go to. The rule has no exceptions: there cannot be two people leading in parallel. If the project has to go back to the director, it goes back whole — it isn't split.

The director stays above it — looking at the overall plan, surfacing additional processes, moving on to the next department. His actions in another department may indirectly affect your work, and that's fine: it's complementary, not interference.

He comes back in three cases: audits, a major problem or conflict, and reporting meetings with the owner. For a meeting with the owner the project manager prepares the report and the director delivers it — they speak the same language; the project manager and the architect are present and field the detailed questions. For day-to-day work the main point of contact for department heads is the project manager.

Project storage. A separate drive with folders by stage — contracts and invoices, audits, credentials and access, meetings, reports. The contract and the project invoices go in immediately.

Contacts. You ask the client for the contacts of the managers you'll be working through, or for one person — a secretary, administrator, or office manager — who will schedule those meetings for you. You explain what you need and by when, and from then on he works as your hands.

A dedicated mailbox. Ask for a separate address for subscriptions and services, one you have access to. Otherwise every login with two-factor authentication means asking an employee to forward the code, many times a day.

The welcome email. One email containing everything. Sent on day one:

• a calendar of actions: what happens and when;
• a list of materials with a hard deadline — three days maximum;
• an intro video: what we do and why;
• what to prepare before the first meeting.

The point of the video and the list is to avoid spending the first thirty minutes of the first meeting explaining why any of this is happening while people assemble their thoughts. They have a week: they'll work it out themselves, arrive with problems they've already identified, and the session will go deep instead of wide.

What's requested: the org chart with roles, the list of systems and services in use, access to document storage, access to calendars, company details for invoicing. If materials are scattered across different computers — a deadline for pulling them into one place.

The list of systems goes to the architect right away: he looks at what's technically possible before the sessions begin. If the company sits on a closed or very old system, that needs to be known in advance — then the decision to move to a different system is taken before the plan is built.

NDA. A checklist for the client: he marks what matters to him, and the agreement is assembled from those marks — rather than drafting the document from scratch for each client. Separately, what may be used in case studies: internal process problems — yes, without client names or personalized detail; financial figures — only in aggregate, as a calculation from metrics, never as an export from accounting.

The kickoff meeting. Before the first process session, one meeting with the owner and all department heads together. Its purpose: to explain to everyone at once who you are, what will happen, and in what phases. Plus to state the operating procedures and protocols — even if the company has none, with you they start working to a procedure, and that carries over into their own processes afterwards.

What this meeting is not for: starting audits or hearing complaints. It's explanatory and introductory — otherwise it turns into a four-hour recital of everyone's grievances, and no structure comes out of that.

The document that makes the project manageable. Its sections:

How to tell a separate project from part of the current one. By the problem it solves, not by technical proximity. A registry and a voice agent are technically linked, but the registry solves "stay inside the law and store data conveniently" — nobody's way of working changes. The voice agent solves "more calls, higher department efficiency, less administrative load." Different problems, different projects.

Success criteria is the critical section. Ask the client directly: at what result would you consider this system a success? If the answer is "three million more in profit," that isn't your criterion, and it has to be restated as something you're accountable for: share of deals closed instead of revenue, volume of documents processed instead of profit.

The formulation that explains this to a client: "I'm selling you a red square box with a white bow. If at the end you ask for a green round one, that isn't a missing result — that's a different order."

The core technique of the profession.

Why words don't work. The employee says: "I copy from this tab into that one." To him that's a description of an action. To the architect nothing follows from it — he needs to know to create a field with a text data type and a field with a numeric one, and that on transfer the data has to be converted.

Almost everything has to be translated. This isn't restating it in other words, it's describing the same process from a different vantage point — that of the person who will build it.

How it's done. You open the same programs and spreadsheets the client's employee works in and walk the process on screen — you do what he does while the architect watches.

That's when he starts asking questions: what's in the first field, what's in the second, how are they related. What matters to him isn't that data gets copied, it's that he sees the process and talks it through himself. Only then does he understand it.

When it can't be shown — a phone call, a note in a chat, something passed along verbally — the process gets drawn as a diagram together with the architect: the client called, the secretary wrote it down, passed it there. The diagram is drawn on screen, in pictures, not in text.

The rule: this is done every time. A small process, a large one, a whole department — with everyone. This is precisely what gives the project manager the most detailed possible understanding, and gives the client the chance to see that part of the work needn't be done at all.

The diagram works as a stencil. From a finished diagram you can see which data comes from where and in what type. The architect uses it as a map and spends no effort doubting whether he understood the process correctly.

That's why automations assembled from a diagram contain no critical errors: the main work was done before the code. The attention freed up goes into finding the solution rather than re-verifying understanding.

Level of detail. A diagram is finished when you can name every field, its type, and its source. If there's a step where it's unclear where the data comes from, there is no brief yet.

What the project manager brings besides the diagram. About half the time, examples of what similar automations are typically built on. Not as the solution, but so the architect has somewhere to start. He finds the rest himself.

The architect shows an infrastructure diagram, says data flows from here to there, that the models are connected. The client understands nothing, even looking at the picture.

The technique: return to the same visual process diagrams, but narrate them in the language of the business. Not "a query to the database," but "the client called, the employee took it, a message went out to the messenger." The technical diagram and the business diagram are the same picture explained two ways.

If it's still unclear, the phrasing gets simpler, the terminology comes out, and the visual explanation runs alongside the words. The simpler the sentence, the faster it lands.

When the two sides disagree. Business wants a solution, technology says there isn't one. So that neither side feels ignored, the client is kept inside the search: for a month or two platforms get tested, and he knows as it happens — we looked at this, it didn't work for these reasons. Sometimes he suggests checking an option from his own past experience, and it gets checked. Then by the time "there is no solution" is said out loud, the question "why doesn't it work" doesn't arise: everyone saw the volume of work that went in.

Fixed and flexible scope. A plan always has two blocks. Fixed — what gets done without question, per the owner's priorities. Flexible — solutions that will help eventually but can be moved.

There's no such thing as a scope that's only fixed or only flexible. Both always exist, and the flexible one is what you manage with when the schedule slips.

Phases and standard durations:

Key dates go into a calendar the team can see. You need access to the director's and the architect's calendars so you can plan without asking each time whether they're free.

Control points are the start and the end of each phase. Each has its own reporting format and its own substance of conversation.

Dependencies between departments surface in the very first week of sessions: the answers show which processes affect which. Managers usually already know who they're tied to and who they block — the problem isn't that they don't know, it's that they don't know how to fix it.

How it's estimated. In hours, by expert judgment. Technical difficulty and volume of work are different things: a hard solution can take an hour, a routine one three days. The sequence: the project manager gives the first estimate, the architect and the director give the final one.

The buffer. If the architect says two weeks and your instinct says four, the buffer gets added, and it isn't discussed with him. The rule: the committed date is always one to two weeks beyond the actual build. The exception is when the client needs it urgently, and that's a decision taken knowingly.

Calibrating a specific person's estimates. One is systematically optimistic, another pessimistic. It becomes visible from the amount of time you've spent working with the person, and from then on the correction is applied automatically.

High uncertainty. When the scope is unknown up front: a fixed price for an approximate solution the client believes he needs, plus a deposit. The deposit funds the audits, problem identification, and requirements study.

After that the contract is reassembled against reality: one service gets swapped for another, or it turns out the solution costs more than expected. Payments get split or blended with monthly support — however the client is comfortable paying.

Saturday is the best slot for that review: nobody is writing in chats, there's no one to coordinate with, and there's a whole week ahead to implement.

Protecting focus. The architect is kept out of everything where no technical answer is needed from him: audits, first calls, inter-department coordination, organizational detail. He joins a department call once — at the point where the first diagram takes shape, so he understands the company's level. Everything else gets worked through with him separately, over the diagrams.

The architect has no right to say "no" or "I don't know" in a first conversation. Three actions:

• "I'll check, I'll look at it from your side, I'll talk to a specialist."
• If he sees an alternative, he offers it rather than staying silent.
• Only then: a reasoned "no."

It's the same as in a shop: you can't say "I don't know." You can say "give me three minutes to check, let me call the warehouse, let me ask a colleague." The rule works both ways: the project manager also sees three options and also sometimes has to say "no, that doesn't exist."

Why the architect needs standing with the client. His contribution is acknowledged publicly — not out of politeness, but because he needs standing. When he says something can't be done, there should be no "why" and no "I don't believe you." With that standing he is a doctor to the client: if he said it, that's how it is. You remain the intermediary throughout: questions you can't answer, he answers; the decision about what's better, you make.

When you disagree with a decision. You don't have the technical expertise for a full assessment. A second opinion comes from a technical specialist on the team who isn't working on this project: he sees it from outside. Experience isn't always decisive — juniors sometimes see more options than seniors. The more novel the solution, the more valuable the second opinion.

When a decision is delegated completely: everyone agrees on the outcome, the architect has found the platforms, the client has confirmed it meets his criteria. Nothing further is needed.

The sign of overload that shows before anything breaks: initiative drops. The person stops searching, checking, and clarifying on his own — he only does what was asked. While he isn't overloaded he has the energy to poke into everything and look further, and that's the best state: in it he teaches himself and finds the best solutions.

Two or three projects is normal, four is a risk. Capacity is assessed by the senior technical specialist: a project manager can almost never assess technical work.

If there are two architects. The split follows the logic of the scenarios, not slices of one scenario: one builds the foundation, the other builds the automation chains. A voice agent is one logic and one person; an outbound campaign is a different logic. It's best when one person does a scenario end to end — otherwise they have to decipher each other's logic, which slows the work down.

In writing or on a call:

Legal matters go by call only: conveying your position and your doubts by voice is faster and easier than in text. You also demo the solution yourself: the client will test it his own way or won't understand how to test it at all.

What always gets recorded in writing: the course of the work; errors and delays with their causes; the small results; the outcome of every call — what was decided and why, briefly, so it doesn't have to be revisited; delays in paying for the work or the subscriptions, so there are no later questions about why the timeline stretched.

A client who discusses everything by voice. Every meeting is recorded, transcribed, and organized — you have all of it in writing. But that isn't enough: a decision taken gets confirmed by email. "Today we discussed, we decided to go with this, this, and this." Why: documentary confirmation from both sides that these actions really were agreed.

Reporting. From the transcriptions you assemble a weekly report for the client — chronological, covering what the project manager did and what the technical specialist did. The technical specialist sends his part at the end of the week. On top of that: a report after every delivered stage, immediately, without waiting for the end of the week. The internal report is separate: how many meetings this week, with whom, one line on each.

The form that usually doesn't exist. Every new requirement goes through it:

The project manager receives the form. The decision on price is the director's. Without the form, every change gets renegotiated from scratch, in the heat of the moment.

Early signs on the client's side. The team is slow to answer — the project will drag. The team answers quickly but communicates badly among themselves — it will drag too: just working out who is responsible for what takes about three weeks.

On your own team's side. A new industry or a new country — the schedule will slip, guaranteed: you don't know in advance what to tell the client to prepare, and finding that out takes two or three weeks. New models by themselves don't affect the schedule if the industry and the country are familiar.

What to do when the schedule has slipped. Most often the dates get revised: the volume of work has to be done regardless, it just stretches. If it stretches, the order changes: the foundation first, then the module the client cares about most, then the rest. If it's a team capacity issue, you add a person — bearing in mind that onboarding into a project takes about a month.

How to communicate it. The causes get described constantly, in every report: this delay for this reason, that one for that. Warn in advance; don't let it reach the point where everything is already bad. Remind regularly — otherwise they forget. If the client doesn't read the reports, schedule a meeting, pull up all the reports, and walk the whole calendar. After that there are no objections left: he sees the entire chronology.

The sequence before development starts: solutions from the audit are collected → feasibility is confirmed by the architect → legality is checked by your lawyer and the client's lawyer. All three green — only then does work begin.

If a solution is possible but doesn't clear the law, development is paused and a workaround is sought: how to give the client what he needs by changing the technical implementation.

A hard condition: every decision on a legal question is signed off by the client. Liability for violations is his, and that has to be on record.

The person who signs off on payments. Every company has one person through whom subscription and service payments pass. The role differs by company: sometimes the IT director, sometimes the commercial director, sometimes the CEO.

He has to be identified and worked with separately:

• materials prepared for him: which platforms need access, exactly how to grant it, with instructions and video;
• the estimated subscription amounts;
• reminders: either a dedicated card or a set balance kept on one;
• setting up automatic invoice delivery to his email — otherwise someone has to dig them out of every service by hand.

Access is requested against the technical specialist's accounts. The project manager usually doesn't need any.

The bottleneck on the client's side. The recurring scenario: one person holds payment and access approvals, doesn't respond, and the project stalls. Contractors wait for his confirmation, you wait for the contractors, and the client loses the customer he wanted to close.

Going around him through the owner works, but it's manual every time. The right fix is in the contract: a primary approver and a deputy, plus a response deadline after which the question escalates automatically. The director puts it in at contract stage, but you're the one who formulates the requirement, because it's your project that stalls.

The subscription budget. Calculated in iterations rather than months: 5,000 / 10,000 / 15,000 / 20,000 operations, and the client picks the volume. Budgets for testing, for the first month, and for subsequent months are sent in advance, before the first version is ready. Auto-renewal on every service, with a dedicated client card the payments are charged to directly.

How it's organized. The client gets demo access to the pilot or the first version. The feedback window is two days to a week, with the exact date agreed on a call.

Feedback is implemented within a few days. Critical changes take up to a week. If the feedback affects the architecture or the prototype, it needs a call, not correspondence.

If the client isn't using the system, acceptance is impossible. That isn't a delay, it's a signal: there's no point continuing with this client, and the project closes.

Three categories of error:

The third category is the most valuable: it's what brings the system to a working state.

Who tests what. On the team's side: 10–20 runs of every scenario by the architect before the client sees the system. On the client's side: 30–50 touches from live users are needed for the real problems to appear, and the project manager's job is to find the employee who will do that and extract his feedback. Separately, awkward and breaking inputs: empty fields, text where numbers belong, double submissions — the architect checks these, and the list is drawn up jointly.

What "done" means. The architect has his own criteria; the project manager has different ones. A task is closed when everyone who should be using it is using it and knows how; there are no technical errors; tests have passed and corrections are in; the system is producing first results — first answers, first numbers.

The decision to close the project is the project manager's, against the project description: all tasks closed, the client's team has accepted it, no open questions. Then the final reports and the sign-off.

Preparation. The date is agreed with the heads of the departments where the system goes live — they have to warn their people in advance. Go-live almost always means a change of working process: before you opened one thing, now you open another.

By that day: data migrated, access granted, questions resolved. Data migration happens outside working hours, when nobody is touching the system. The team moves over at the start of a working week.

Go-live checklist:

• technical readiness confirmed by the architect;
• training delivered;
• support processes configured: who takes questions, where they go;
• monitoring switched on;
• access granted to everyone and verified;
• 1–2 people inside the company trained to grant access themselves.

That last item saves the most time: otherwise every new account comes to you as a request.

Launch day. Reachable from the moment it goes live. There will be questions, guaranteed, and something will happen, guaranteed. If the client is in another time zone — reachable in his morning.

First check: does everyone actually have access. Somebody always didn't get it, and it comes to light at exactly the moment they try to log in.

First-day feedback is collected and implemented within two or three days, no later: otherwise people revert to the old way of working.

The first week is daily. People write constantly, clarifying things, running into things. Big questions go to a call, once or twice in the week.

An important shift: the first two weeks are not about the system, they're about how people interact with it. Are they understanding it correctly, are they entering data correctly, are they breaking anything. Even if the new system is simpler than the old one, it's still hard for them.

The number of questions depends on the team's age and technical level. A technically uniform team will barely ask anything. A team of mixed ages from different backgrounds won't just ask a lot — the questions will be wildly varied.

When support ends. Conditions for moving to business as usual: everyone has access, everyone has been trained, the platform is embedded in their work, and they use it.

After that a person on the client's side is appointed to own communication about the platform. His technical team receives basic rights and the documentation — they need about two weeks to get their bearings, and during that time they come with questions.

When it starts. If the company is far from technology — right after the first pass of audits, once the level of the people is visible. While the legal work is going on they're already learning, and by the time of the deep sessions with the architect they understand what's being discussed. Main training comes after the pilot is confirmed and the first version is rolled out.

How it works. A live session showing how to work with the system. Short, to the point, recorded.

Plus video instructions prepared in advance: how to use it, what the scenarios are, what to do in each. People watch these over the course of a week while poking at the system themselves.

The videos are embedded inside the platform — a dedicated "training" tab. Technical documentation for the client's technical team is separate. If the system is large, a full course on it, the same as any CRM or ERP.

Repeat training. New employees arrive. Clients who stopped using the system come back a month or two later and need to be shown everything again. This is a normal part of the work, not an exception.

Questions after training get collected. The recurring ones become a separate instruction or an additional video. That's cheaper than answering each person.

Training doesn't embed without verification. The mechanism:

Take the org chart and each role's job description. Define what a person in that role is supposed to do inside the system. For each role, a KPI: the operator so many records, the manager so many, the storekeeper so many.

In the first week, an exam on working in the system. For the following month department heads submit a report every Friday — not only what they did, but with their comments. "Today I did a hundred shipments; a month ago, without the system, I did three."

Two effects: the trajectory of change becomes visible, and responsibility for checking sits with the department head rather than with you.

Resistance. Almost everyone resists. Before turning on the instructions, the idea has to be sold: explain what's in it for them and what gets easier. It doesn't always work, but it has to be said — and beyond that it's the client's responsibility. If employees resist, the question returns to the company's procedures and culture: his people don't respect the authority of their own management. From your side you give maximum feedback and training; more than that cannot be given, and that's an honest boundary.

Training metrics. Did they actually start using it — the primary one: it tells you whether the training was comprehensible or not. The number of questions about the instructions: a lot of questions means you made it too complex and it needs simplifying. Both metrics depend heavily on the client's side: some companies need a day or two and everything is clear; others nothing will help, and then they're left to work it out themselves — you answer more slowly, or answer with a link to the video already recorded.

Measurement. The baseline figures were set by the director during the audit. The measurement uses the same formula, a month to six weeks after go-live, as a repeat pass across the departments.

What goes into the calculation: hours saved, money saved, level of adoption. Return on investment isn't only new customers — it's how much money was freed up across every resource: less paper, less time on processing, documents going out faster, money arriving faster, fewer people needed for the same volume.

A separate data source is the system itself: the activity log shows who logged in, when, and how many records they added. From it you assemble a report for department heads about their own people, and one overall report for the owner.

When the client says "it doesn't work." The hardest conversation in the profession, and it isn't won in the moment it happens.

If the success criteria were fixed in the charter in numbers, the conversation reduces to checking against them. If they weren't, it can't be won: the client is comparing against a picture in his head, and that picture shifted as the project went on.

What to do when there are no criteria: go back to the loss matrix from the audit, recalculate on the same formula, and show the difference department by department. It works less well, but it works.

What never works: technical metrics. "The system processed three thousand documents" is not an answer to "so where's the result."

The full handover package:

• access: accounts, password manager, keys;
• what the system is made of: which service is responsible for what;
• subscription cost per service;
• the architect's technical documentation;
• operational instructions: what was wrong, what was fixed, what exactly changed;
• training materials;
• all reports in a single file, not scattered;
• all project materials in one folder, organized by stage.

If the client has a technical team, it receives rights and documentation, plus a knowledge base over the system it can query. If not, handover is limited to documentation and the final report, and that's agreed in advance. Knowledge transfer takes a week to a month and a half.

Closure. Final reports, the sign-off. Separately: conclusions for the next project — what changed in the documents, which templates were improved, which decisions can be carried forward. The rule: always check the most recent project, because it's the freshest and it carries every previous layer.

Projects get handed over: people change, someone is overloaded, someone leaves. Entering a project already in flight is a skill of its own.

The first task isn't a week of preparation — it's working through the project's knowledge base: every transcription, every thread, every report. From those you reconstruct what happened, why the decisions were made the way they were, what the pitfalls were, and why things didn't work.

From which follows a requirement for how a project is run: the knowledge base has to be good enough for an outsider to enter through it. If the history of decisions can't be reconstructed from it, the project doesn't transfer — it restarts.