Lesson 4.4: Planning, operations and code help prompts

Learn prompts for project plans, risks, procedures and small scripts, with a critical-path example and safe habits for running code you did not write.

By the end of this lesson you will be able to use an assistant to break a project into tasks and dependencies, give estimates as ranges, list risks with their expected cost, turn a messy process into a clear procedure and test it, and get small scripts and formulas that you understand before you run them. You will work out a project's critical path by hand and see how much of the schedule can slip without delaying the end, rank three risks by expected loss, and estimate when a small automation pays for itself. You should have read Lessons 3.2, 3.4 and 4.3, since planning prompts use chains and critiques, and code help depends on the verification habits from the analysis lesson. You do not need to be a programmer, and every code example is explained in plain words.

Planning, operations and light coding are the parts of work where an assistant can feel like a very fast junior colleague: it produces a structured first version in seconds, lists the things you forgot and writes the tedious formulas and scripts. It is also a colleague with no knowledge of your organisation and no consequences if the plan fails, so the output needs the same review you would give to anyone's first draft. This lesson gives prompts for each job and the checks that go with them.

Planning: from goal to tasks

A plan answers four questions: what must be done, in what order, by whom and by when. An assistant can draft the first two well, because they depend on general knowledge of how such work usually goes, and cannot answer the last two without you, because they depend on your people and your constraints.

Break down the work

Start by asking for the tasks, grouped into stages, with the dependencies stated.

text I am planning to migrate our customer support tickets from tool A to tool B. We have 6 weeks, 3 people (one of whom is part-time), and cannot have more than one hour of downtime.

List the main stages and the tasks in each. For every task, say what it depends on and what its output is. Do not give durations yet. List any task that is easy to forget.

The last line is worth keeping in nearly every planning prompt. Experienced planners know that projects fail on the forgotten tasks: access requests, approvals, training, data clean-up, a rollback plan. An assistant has seen many plans and often remembers them.

Dependencies and the critical path

A plan is not a list but a network, because some tasks cannot start until others finish. The critical path is the longest chain of dependent tasks, and it sets the shortest possible duration of the project. Delay anything on it and the end date moves. Tasks off the path have slack: time they can slip without effect.

Take four tasks. A takes 3 days. B takes 5 days and needs A. C takes 4 days and needs A. D takes 2 days and needs both B and C. There are two paths from start to end: A, B, D takes 3 + 5 + 2 = 10 days, and A, C, D takes 3 + 4 + 2 = 9 days. The project takes 10 days, the critical path is A, B, D, and task C has 1 day of slack.

You can ask an assistant to find the critical path from a task list, and it will usually succeed on small plans. Check it yourself on anything real, by adding up each path, as above. The value of knowing the critical path is practical: put your best people and your closest attention on those tasks, and protect them from interruption.

Estimate in ranges

A single number for a task's duration hides uncertainty, and people tend to give the number they hope for. Ask instead for three: the best case, the likely case and the worst case. A common way to combine them is the three-point estimate: (best + 4 × likely + worst) ÷ 6. For a task with a best case of 3 days, a likely case of 5 and a worst case of 11, the estimate is (3 + 20 + 11) ÷ 6 = 5.7 days. The worst case pulls the figure above the likely one, which is the point: estimates are skewed, because tasks overrun more than they underrun. An assistant can generate the three numbers for each task from general experience, but they are guesses until you adjust them with what you know about your team. Ask it to show its reasoning for each range, and edit those you disagree with.

Predict first: you ask an assistant for a project plan for the migration with no further details. What will it give you, and what will it be missing? Decide before reading on.

It will give a tidy list of generic stages with durations that sound plausible, and it will be missing everything specific: who is on leave, which approvals take two weeks in your organisation, which system has no export function. The plan looks complete and contains none of the facts that decide whether it works. The fix is not a cleverer prompt but supplying your constraints and then checking the plan against them.

Find what could go wrong

Assistants are good at generating risks, because they have seen what goes wrong in similar projects. Two prompts are especially useful.

A premortem: "Imagine it is six weeks from now and the migration has failed. List the ten most likely reasons, in order of likelihood, and for each give an early warning sign." A risk register: "For each risk, give a probability (low, medium, high), an impact in days or rupees, an owner and one action to reduce it."

Once you have numbers, rank the risks by expected loss, which is probability times impact. Suppose three risks: a vendor delay with a 30 per cent chance costing ₹8 lakh, a data-quality problem with a 20 per cent chance costing ₹5 lakh, and staff leave with a 10 per cent chance costing ₹3 lakh. The expected losses are 0.30 × 8 = ₹2.4 lakh, 0.20 × 5 = ₹1.0 lakh and 0.10 × 3 = ₹0.3 lakh. The vendor delay deserves the most attention, even though the data problem sounds more alarming.

Treat the probabilities and impacts as the assistant's guesses unless you provide data, and replace them with your own judgement. The structure is the useful part: it forces each risk to have an owner and an action.

Operations: writing procedures that people can follow

Operations work lives on procedures: step-by-step descriptions of how something is done, such as refund handling, account closure or month-end reconciliation. They are often missing, outdated or held in one person's head. An assistant can turn rough notes, a recorded walkthrough or a messy email thread into a clean draft, which a person with the knowledge then corrects.

A strong procedure prompt asks for the parts that make a procedure usable.

text Turn the notes below into a standard operating procedure for processing a customer refund.

For each step give: who does it, what they do, what they need (inputs), what they produce (outputs) and what to do if something goes wrong. Number the steps. Mark with [CONFIRM] any step where the notes are unclear or incomplete, and do not fill the gap with a guess.

End with a checklist of five items the approver should verify before signing off.

Notes: """ [PASTE] """

The [CONFIRM] marker is the important instruction. Without it, the assistant fills the gaps in your notes with reasonable-sounding steps, and the procedure then describes a process that nobody follows. With it, the gaps become a list of questions to put to the person who knows.

Test it by role-play

A procedure that reads well can still fail a newcomer. Test it before you publish by asking the assistant to play a new joiner: "You are a new team member on your first day with only this procedure. Go through it step by step and list every point where you would be unsure what to do, every term you do not understand and every step that seems to be missing." The list is a cheap usability test, and it often finds the missing steps that experts do not notice because they know them too well. Then have a real newcomer try it, since the assistant is a stand-in.

Other operations documents

The same pattern works for checklists, runbooks for handling an incident, handover notes, meeting agendas with time boxes, a RACI chart showing who is responsible, accountable, consulted and informed, and decision logs. In each case, supply your real facts, ask for a gap marker instead of guessing, and have the owner approve the result. For anything that affects customers, money or compliance, a procedure the assistant wrote is a draft until a responsible person signs it.

Code help for people who do not write code

You do not need to be a programmer to benefit from code help. Many everyday office jobs are small programming tasks in disguise: merging fifty spreadsheets, renaming files, cleaning a column of messy dates, extracting numbers with a pattern, or running the same query every week. An assistant can write these, explain them in plain words and help fix them when they break.

What to ask for

Spreadsheet formulas and macros, as in Lesson 4.3. SQL queries for a database you can query, with the table layout described. Small scripts, often in Python, for jobs such as combining files or cleaning columns. Patterns, such as a regular expression that finds a PAN number or a date in text. Explanations: "Explain this script line by line for someone who has never programmed." Debugging: paste the error message and the code, and ask what is wrong. Tests: ask for example inputs and the output expected for each.

A good prompt describes the task, the input and the output, with an example of each.

text Write a Python script that reads all the CSV files in a folder called "branches" and combines them into one file called "allbranches.csv".

Each file has the same columns: branch, month, due, collected. Add a column called "sourcefile" with the name of the file each row came from. If a file is empty, skip it and print its name.

Explain the script in plain words, step by step. Then tell me how to run it, and give me a small example of input and the output I should expect.

Habits that keep you safe

Code can do damage that text cannot, so these habits matter more than the prompt.

1. Understand before you run. Ask for an explanation, and read it. If you cannot say what a script does, do not run it. 2. Work on a copy. Run scripts on duplicates of your files, never on the only copy or on a live system. 3. Start with a small test. Run it on two or three rows or files and check the result by hand, as you test a formula. 4. Ask what it could break. "Does this script delete, overwrite or send anything? What happens if it fails halfway?" 5. Keep secrets out of prompts. Never paste passwords, access keys, tokens or customer data into a tool. Replace them with placeholders such as YOURAPIKEY. 6. Follow your organisation's rules. Company code and data may not be allowed in an unapproved tool. 7. Be wary of commands you do not recognise, especially anything that deletes files, changes permissions or installs software. Ask for the safest alternative. 8. Keep what works. Save the script with a note on what it does, and the date, so you can run it again.

When something breaks, give the assistant the full error message and the exact code, and say what you expected. "It does not work" gives it nothing to go on. A good debugging prompt includes the code, the error word for word, the input you used and what you wanted to happen.

When does automation pay?

A script takes time to get right, so it is worth asking when it pays off. Suppose a weekly job takes 20 minutes and you do it 10 times a week across your team. That is 200 minutes, about 3.3 hours a week. If an assistant helps you build and test a script in 3 hours, it pays for itself in about 0.9 of a week, and over 46 weeks it saves roughly 150 hours. If the job is done once a month, the same script would take years to pay back, and a checklist may be the better tool.

Worked examples

Example 1: a migration plan. A support manager supplies the constraints (six weeks, three people, one hour of downtime), asks for stages and tasks without durations, then asks for best, likely and worst cases for each task and for the critical path. She adds the two approvals she knows take two weeks, which the assistant had not mentioned. The premortem adds three risks she had not thought of, including an export limit in the old tool. She keeps the plan, assigns owners and checks the critical path by adding the paths herself.

Example 2: a refund procedure. An operations lead pastes rough notes from the person who has done refunds for years. The assistant produces eleven numbered steps with six [CONFIRM] markers. The expert answers them in ten minutes, one of them revealing an approval step that no one else knew about. A role-play as a new joiner then finds two undefined terms. The final procedure is signed off by the head of operations and filed with a version number.

Example 3: a script to merge files. A branch analyst receives 40 monthly files and wants one. She uses the prompt above, reads the explanation, runs it on three files in a copy of the folder, and checks that the row count equals the sum of the three files' rows. It does. She then runs it on all 40, and checks again that the total matches. It is off by one: one file had a header repeated in the middle. She pastes the issue back, and the assistant adds a line to skip repeated headers. The work took 25 minutes, against the two hours of manual copying she would have done.

Common mistakes

Accepting a generic plan. Supply your constraints and check the plan against them. One-number estimates. Ask for best, likely and worst cases, and combine them. Never checking the critical path. Add up the paths yourself on any real plan. Risks with no owner or action. A list of worries is not a register. Procedures with gaps filled by guesses. Use a gap marker, and have the expert confirm. Publishing without testing as a newcomer. Role-play, then test with a real person. Running code you do not understand, on the only copy of your data. Understand, copy, test small. Pasting secrets or customer data into a prompt. Use placeholders, and follow your organisation's rules.

Key takeaways

For planning, supply constraints, ask for tasks with dependencies and outputs, and ask for the tasks that are easy to forget. The critical path is the longest chain of dependent tasks and sets the project length. In the example the path A, B, D is 10 days and task C has one day of slack. Ask for estimates as ranges and combine them with (best + 4 × likely + worst) ÷ 6. Rank risks by expected loss, probability times impact. For procedures, ask for who, what, inputs, outputs and failure handling, mark gaps with [CONFIRM], and test by role-playing a newcomer, then a real one. Code help suits small jobs. Understand the script, work on a copy, test on a few rows, ask what could break, and keep secrets out of prompts. Automation pays when a task is frequent and the build is short. A job done monthly may be better served by a checklist.

Check yourself

1. What is the critical path of this plan: A (2 days), B (6 days, needs A), C (3 days, needs A), D (1 day, needs B and C)? A, B, D takes 2 + 6 + 1 = 9 days, longer than A, C, D at 6 days. The critical path is A, B, D and C has 3 days of slack. 2. What is the three-point estimate for a task with best 2, likely 4 and worst 12? (2 + 16 + 12) ÷ 6 = 5 days. 3. A risk has a 25 per cent chance and an impact of ₹12 lakh. What is its expected loss? 0.25 × 12 = ₹3 lakh. 4. Why mark unclear steps with [CONFIRM] in a procedure? Otherwise the assistant fills gaps with plausible guesses, and the procedure describes a process no one follows. 5. Name three safe habits before running a script you did not write. Understand it, run it on a copy, test on a small sample, ask what it could break, and keep secrets out of prompts.

Try this

You need an assistant and about fifty minutes.

1. Choose a real small project or process in your work. Write the constraints: time, people, limits and anything fixed. 2. Ask for stages, tasks, dependencies and easy-to-forget tasks. Add the facts the assistant could not know. Then ask for best, likely and worst durations for each task. 3. Work out the critical path by adding the paths yourself, and use the plan simulator on a four-task version to see the effect of changing one duration. 4. Run a premortem and build a short risk register with probability, impact, owner and action. Rank by expected loss. 5. Choose a process you know and write rough notes. Ask for a procedure with [CONFIRM] markers, answer them, and run the new-joiner role-play. 6. Pick a small repeated job, such as merging files or cleaning a column. Ask for a script with an explanation and a test example. Run it on a copy, on a small sample, and check by hand. Use the payback simulator to see whether it was worth building. 7. Fill in this table. Item · What the assistant gave · What you added or correctedTasks and dependencies · · Duration ranges · · Top three risks · · Procedure gaps ([CONFIRM]) · · Script test result · · A good result is a plan whose critical path you verified, a ranked risk list with owners, one tested procedure and one script that you understand and have tested. This completes Module 4. You can now use an assistant for the main jobs of professional work, and you check each kind of output the way it deserves. Module 5 moves from using prompts to engineering them for products: testing and comparing them, choosing models, grounding long documents and designing structured outputs and agent instructions.

Tags: Prompt Engineering Planning Operations Code help Intermediate