Written answers to the questions buyers actually type. Each one opens with a summary that stands on its own, and is dated so you know how current it is.
An assumption you cannot test on a given morning is not an assumption. It is a sentence you will lose an argument about in week nine.
An assumptions register only protects you if a broken assumption is detectable without a judgement call. That takes four fields per entry: the condition stated as a measurable event, an owner, a date or threshold, and the consequence priced in advance. This piece is the method behind the assumptions section of a scope document, plus what happens to the register after signature.
What clients call fixed scope is usually a fixed price and a fixed date. Those are far easier to honour.
The supposed conflict between agile delivery and fixed-price contracts comes from fixing the feature list. Clients rarely want a feature list; they want a defined outcome by a defined date for a defined price. Write the contract so the outcome, price and date are fixed and the implementation path is explicitly variable, then use the iteration boundary as the point where variation is agreed. The mechanism is a written trade at every boundary, not a change clause nobody invokes.
One page, enforced, beats twelve pages nobody has read. The obligations underneath it are not optional.
A small agency does not need a long AI policy. It needs a one-page document answering four questions: what client data may be sent to which tools, who approves output before it ships, when use must be disclosed, and what is recorded. The obligations underneath those answers come from Canadian privacy law rather than from vendor terms, and the Privacy Commissioner has published named principles that map cleanly onto a short internal policy.
The build is the cheap part. The bill arrives in month fourteen, when an API version is sunset and the person who wrote it has left.
Writing a connector to an ad platform takes a competent developer two to five days. Keeping it working takes a few hours a month forever, plus a rework every time the vendor deprecates an API version. Those recurring hours are the entire decision, and almost nobody puts them in the spreadsheet. Priced properly at your own internal rate, buying usually wins for standard platforms and building usually wins for the one source nobody sells you.
Every other kind of software gets a review before it reaches users. Dashboards get republished over lunch.
BI content is software: it has logic, dependencies, breaking changes and users who depend on it being right. Almost no mid-market deployment gives it the release process software gets. The minimum that works is three stages with a defined promotion path, a rule that production content is never edited in place, an automated promotion step, and a rollback that restores a known-good version rather than reconstructing one from memory. Both major platforms ship the mechanisms for this, and most teams have never turned them on.
Logic in a chart is fast to write and impossible to govern. Logic in the warehouse is the opposite. The line between them is not a matter of taste.
Every number in a client report is calculated somewhere: in the chart, in the Looker Studio data source, or upstream in the warehouse. The three places have different rules about who can edit them, whether they can be reused, whether they work on blended data, and how many times they are recomputed. Put a definition in the wrong one and you get either a metric nobody can find or a metric everybody has quietly forked. This sets out what each layer can and cannot do, the aggregation trap that catches most people, and a placement rule you can apply in ten seconds.
A spreadsheet of event names is not a specification. It is a wish list with column headers.
The data layer is the contract between the site and the tag manager, and it is written by an analyst and built by a developer who has never opened Tag Manager. A specification that works names the trigger in the user's terms, gives the exact key, the type, whether it is required, a real example value, and where in the page lifecycle it must be pushed. A specification that fails lists event names and assumes the rest is obvious.
Sending the parameter and being able to report on it are two different jobs, usually done by two different people.
A GA4 custom dimension makes an event parameter or user property reportable. Registration is a separate act from collection, it is not retroactive, and data collected before the dimension existed never appears against it. The three scopes, event, user and item, each have their own quota and their own correct use, and choosing the wrong one produces a dimension that is technically populated and analytically useless.
Isolation is not a promise you make to a client. It is a property of where the grants sit.
BigQuery permissions are additive and inherit downward, so a grant at project level reaches every dataset inside it and no lower grant can take it back. That makes the project the isolation boundary for agency work and the dataset the boundary for day to day grants. Grant to Google groups and service accounts rather than named people, use authorised views only when a client needs a genuine subset, and judge the whole design by how few actions it takes to revoke everything.
Every account is eligible. That is not the same as every account having enough data for the model to say anything.
Google states that all conversion actions are eligible for data-driven attribution regardless of volume, and separately recommends at least 200 conversions and 2,000 ad interactions in a 30-day period for the model to perform well. Those two sentences are doing different jobs, and the gap between them is where most mid-market accounts sit. This works through what the recommended volume costs in real spend, what happens below it, and what to do instead.
The first thirty days is the most expensive month of the engagement and the one most agencies give away.
Onboarding is real delivery work with a real cost, and waiving it converts the start of every engagement into an investment with a payback period. Compute that period explicitly: setup cost divided by monthly contribution tells you how many months a client has to stay before you are whole. Then decide deliberately whether to charge, amortise, or absorb, rather than defaulting to absorb because a competitor's website says onboarding is free.
Nobody decides to waste bench time. It gets wasted because no decision was made while it was happening.
Bench time is capacity you have already paid for, so it cannot be saved, only spent. The failure is not that it exists, it is that the spending decision is made by default and after the fact. This article prices a bench day from your own cost base, ranks the realistic uses by what each one actually returns, and sets out the rule that keeps a short bench from becoming a long one.
The client said yes on a call. That covers none of the four things you were about to do.
Publishing work is governed by three separate permissions that agencies routinely collapse into one: naming the client, stating a result, and quoting a person. Each has a different approver and a different standard. Naming is a marketing decision, stating a result is a claim that has to be supported by a test done beforehand, and quoting a person involves their personal information. Ask at the right moment, in writing, and record what was actually approved.
The banner is not the implementation. The banner is the part everyone can see.
Consent mode communicates a visitor's consent choices to Google so tags can change what they do. Version two added two advertising parameters to the original storage ones. The decision that matters is basic against advanced: whether tags are blocked entirely until consent, or loaded in a restricted state that still allows modelling. Most failures are not policy failures, they are ordering and scoping mistakes in the implementation.
A gate nobody can pass in under a week is a gate teams learn to route around.
Regulator guidance asks organisations to assess privacy risk on all new projects involving personal information and on any new collection, use or disclosure, and to build a review and approval process that involves the privacy officer when new initiatives are designed. Translating that into a delivery workflow means one gate, a fixed set of questions, a named approver and a service level, placed before build rather than before launch.
The product data specification lists dozens of attributes without ranking them. Working through it top to bottom is how a feed project takes six weeks and still gets disapproved.
Google's product data specification marks attributes as required, it depends, or optional, and that is the only ranking it gives you. In practice the attributes divide into three tiers by consequence: ones whose absence stops the item serving at all, ones whose wrongness gets the item disapproved after it has already been submitted, and ones that only affect how well the item competes. Fix them in that order, because the second tier is where the expensive surprises live.
Most agencies who build against this API did not need to. Most who needed to waited two years longer than they should have.
The Microsoft Advertising API is well documented and genuinely usable, which makes it easy to build something you did not need. The decision turns on a small number of things: how many accounts you touch, whether the work is reporting or writing, and whether anyone will maintain it in eighteen months. There is also a hard platform date now in play, because the SOAP interface has a published retirement schedule, and that changes the arithmetic for anyone already integrated.
The problem with a seasonal account is not the season. It is the eight months of nothing that sit in front of it.
A business that advertises for one season a year has a structural problem no always-on account has: every campaign restarts from a long gap, and the conversion data that automated bidding needs is months stale before the season opens. The fixes are structural rather than tactical. Keep the learning boundary alive where you can, plan the ramp as part of the season rather than as a preamble to it, and know what seasonality adjustments are actually built for, because it is not this.
The keyword question and the ad copy question have different rules, and most arguments about this conflate them.
Bidding on a competitor's name involves three separate decisions that people routinely treat as one. Google's advertising policy allows trademarks as keywords but restricts them in ad text. Canadian law is not concerned with the keyword at all, it is concerned with whether the representation your ad makes is false or misleading in a material respect. And the commercial question, whether the traffic is worth what it costs, is usually the one that decides it. This is an operational read of the three, not legal advice.
You do not need to read ABAP. You do need to know why a two-line change takes three weeks.
A delivery lead on an SAP programme does not need to write ABAP, but needs enough literacy to test an estimate and hear a risk. Four concepts carry most of that: what ABAP actually is, why transports rather than deployments move code, what a release contract means for whether SAP can break your extension, and what the code quality tooling tells you about the state of a custom estate.
Both can do the job. Only one of them can be changed by the person who will be here when it breaks.
Apex triggers and Flows overlap heavily, and the capability comparison is the least useful way to choose between them. The decision that matters is who maintains the automation after the person who built it has moved on, plus a second consideration nobody plans for: when both fire on the same object, the interaction is hard to reason about and harder to debug. This gives concrete criteria, the ordering problem, and a rule for mixed estates.
The first surprise bill is never caused by a missing budget. It is caused by somebody believing a budget was a limit.
Azure gives you budgets, cost alerts, tags and the ability to pause a capacity, and only one of those four stops money being spent. Budgets notify, they do not cap, and they evaluate on a cycle slow enough that a runaway job can spend for a day before anyone hears about it. This piece separates the controls that inform from the controls that act, works through what the evaluation delay actually means for a small team, and sets out the three decisions that change an analytics bill: allocation you can read, a schedule for anything periodic, and an owner who sees the number.
Most charters are read once, by the person who wrote them. That is a format problem, not a discipline problem.
A project charter exists to record the decisions that authorize a project: who sponsors it, what it is for, who can say yes, what is explicitly out, and what success will be measured against. A charter that runs to twelve pages of background is a document nobody consults under pressure. The version that works is one page, written as decisions rather than narrative, and signed by the person who controls the budget.
Every chart Jira draws is a rendering of one configuration choice. Most teams have never seen the screen where it is made.
Estimation in Jira is configured in one of two different places depending on the project type, and every sprint chart is a rendering of that choice. Three details cause most of the confusion: estimating and tracking are separate settings, subtask estimates are excluded from the velocity and burndown charts, and changing the method mid-engagement produces a chart with a step in it that nobody can explain later.