[{"data":1,"prerenderedAt":362},["ShallowReactive",2],{"blog-\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams":3,"blog-surround-\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams":343,"blog-related-\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams":351},{"id":4,"title":5,"audience":6,"body":10,"cluster":308,"date":309,"description":310,"draft":311,"extension":312,"factCheckedAt":313,"faq":314,"featured":324,"language":313,"meta":325,"navigation":324,"order":326,"originalAsset":313,"path":327,"pillar":328,"primaryKeyword":329,"relatedProject":330,"releaseScope":313,"reviewCycle":331,"reviewStatus":332,"reviewedBy":333,"searchIntent":334,"seo":335,"sources":313,"stem":336,"tags":337,"type":195,"updated":341,"__hash__":342},"blog\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams.md","Project Intake Process for Finance and Engineering Teams",[7,8,9],"engineering-manager","product-lead","finance-transformation-lead",{"type":11,"value":12,"toc":297},"minimark",[13,21,24,29,40,44,53,59,63,66,93,97,100,138,142,145,171,178,182,189,200,203,217,221,247,251,258,271,274],[14,15,16,20],"p",{},[17,18,19],"strong",{},"A project intake process is how a team receives, shapes and decides on incoming work — before it commits people to it."," It captures the raw request, clarifies the problem, outcome, scope and owner, and then makes an explicit decision: commit, shape further, pause or decline. Its whole purpose is to turn vague demands into decisions, so teams commit to clear work instead of starting on a half-understood ask and discovering what it meant in delivery.",[14,22,23],{},"For finance and engineering teams — where requests arrive constantly and each looks urgent — a good intake is the difference between a roadmap you chose and a queue that chose you.",[25,26,28],"h2",{"id":27},"what-a-project-intake-process-is","What a project intake process is",[14,30,31,32,36,37,39],{},"Intake is the step ",[33,34,35],"em",{},"before"," delivery and ",[33,38,35],{}," commitment. A request comes in; intake makes sure it's understood well enough to decide on, and then decides. Done well it's fast — minutes, not meetings — and it produces two things: a shaped, decision-ready version of the request, and an explicit decision about it.",[25,41,43],{"id":42},"why-teams-need-one","Why teams need one",[14,45,46,47,52],{},"Without intake, this is the default flow: a request lands as a one-liner, someone says \"sure, we can do that,\" and a nod becomes a commitment before anyone knows the scope, the owner or what success looks like. The bill arrives weeks later as rework, a scope fight, or a slipped date — and it traces straight back to that first thirty seconds. (I've written about exactly ",[48,49,51],"a",{"href":50},"\u002Fblog\u002F05-commit-before-clear","why teams commit before the request is clear",".)",[54,55,56],"pull-quote",{},[14,57,58],{},"The purpose of intake isn't bureaucracy. It's to make the shaping and the decision explicit and fast — so \"yes\" is a choice, not a reflex, and \"no\" happens on purpose, not by neglect.",[25,60,62],{"id":61},"the-stages-of-a-good-intake","The stages of a good intake",[14,64,65],{},"Three stages, each quick:",[67,68,69,81,87],"ol",{},[70,71,72,75,76,80],"li",{},[17,73,74],{},"Capture."," Record the request as it actually arrived — the Slack message, the email, the hallway ask — so nothing is lost or paraphrased away. (",[48,77,79],{"href":78},"\u002Fblog\u002F06-slack-request-to-initiative","Turning that raw ask into something decision-ready"," is the core skill.)",[70,82,83,86],{},[17,84,85],{},"Shape."," Clarify the few things that make it decidable — with the requester, not in isolation. This is where a vague request either becomes clear or reveals that it isn't ready.",[70,88,89,92],{},[17,90,91],{},"Decide."," Make one of four explicit calls (below). The output isn't \"it's on the backlog\"; it's a decision.",[25,94,96],{"id":95},"the-fields-that-make-a-request-decision-ready","The fields that make a request decision-ready",[14,98,99],{},"You don't need thirty fields. You need these, filled honestly:",[101,102,103,109,115,121,132],"ul",{},[70,104,105,108],{},[17,106,107],{},"Problem"," — what's actually broken, not the solution someone jumped to.",[70,110,111,114],{},[17,112,113],{},"Outcome"," — what's true when this is done; how you'll know it worked.",[70,116,117,120],{},[17,118,119],{},"Scope"," — what's explicitly in, and just as importantly, out.",[70,122,123,126,127,131],{},[17,124,125],{},"Owner"," — one name accountable for the outcome. If it's a team, it's ",[48,128,130],{"href":129},"\u002Fblog\u002F07-cost-of-unclear-ownership","no one",".",[70,133,134,137],{},[17,135,136],{},"Open questions"," — the things you don't know yet. This field is the point; a request with none usually hasn't been looked at hard enough.",[25,139,141],{"id":140},"the-four-decisions","The four decisions",[14,143,144],{},"A healthy intake has four outcomes and picks one on purpose:",[101,146,147,153,159,165],{},[70,148,149,152],{},[17,150,151],{},"Commit"," — clear, owned, worth doing now. Commit with real scope and a real date.",[70,154,155,158],{},[17,156,157],{},"Shape further"," — matters, but not ready; an open question is big enough to change the plan.",[70,160,161,164],{},[17,162,163],{},"Pause"," — a good idea at the wrong time; park it honestly with a revisit date.",[70,166,167,170],{},[17,168,169],{},"Decline"," — the problem isn't real, isn't worth the cost, or is someone else's job. Say no early, with a reason.",[14,172,173,174,177],{},"The discipline is ",[33,175,176],{},"forcing the choice",", instead of \"yes by default, no by neglect.\"",[25,179,181],{"id":180},"the-intake-one-pager-steal-this","The intake one-pager (steal this)",[14,183,184,185,188],{},"Everything above fits on one page. This is the whole template — copy it, paste the raw request at the top, and fill the rest ",[33,186,187],{},"with the requester",". If you can't complete it in a short conversation, that's the signal the request isn't ready to commit to.",[190,191,196],"pre",{"className":192,"code":194,"language":195},[193],"language-text","Raw request:  \u003Cpaste the Slack message \u002F email \u002F hallway ask, verbatim>\n\nProblem:      \u003Cwhat's actually broken — not the solution someone jumped to>\nOutcome:      \u003Cwhat's true when this is done, and how you'll know it worked>\nScope — in:   \u003Cwhat this explicitly includes>\nScope — out:  \u003Cwhat it explicitly does NOT include>\nOwner:        \u003Cone name accountable for the outcome>\nOpen Qs:      \u003Cwhat you don't know yet — the field that earns its place>\n\nDecision:     Commit  |  Shape further  |  Pause  |  Decline\nReason:       \u003Cone line — why this decision, on purpose>\nRevisit:      \u003Cdate, if Paused or Shape further>\n","text",[197,198,194],"code",{"__ignoreMap":199},"",[14,201,202],{},"Six fields and a decision. Anything more is intake theatre; anything less isn't decision-ready.",[204,205,207],"callout",{"type":206},"tip",[14,208,209,210,216],{},"Prefer to fill it in on screen? Use the free ",[48,211,213],{"href":212},"\u002Ftools\u002Fproject-intake-one-pager",[17,214,215],{},"intake one-pager generator"," — type into the fields and it builds the one-pager live, ready to copy or download. Nothing you enter leaves your browser.",[25,218,220],{"id":219},"what-usually-goes-wrong","What usually goes wrong",[101,222,223,229,235,241],{},[70,224,225,228],{},[17,226,227],{},"No intake at all."," Requests become commitments in the moment they're received.",[70,230,231,234],{},[17,232,233],{},"Intake theatre."," A heavy form no one fills in properly, so it's bypassed and you're back to one-liners.",[70,236,237,240],{},[17,238,239],{},"Yes by default."," Everything is accepted onto a backlog, and \"no\" never actually gets said — it just rots.",[70,242,243,246],{},[17,244,245],{},"Shaping in isolation."," Guessing the problem and outcome without the requester, so the shaped version is as wrong as the original.",[25,248,250],{"id":249},"making-it-lightweight","Making it lightweight",[14,252,253,254,257],{},"Intake fails when it's heavy. Keep it to the few fields that make a request decidable, shape ",[33,255,256],{},"with"," the requester, and make the decision explicit and quick. The goal is decision-readiness, not documentation — a five-minute shaping conversation that saves a six-week wrong build.",[14,259,260,261,265,266,270],{},"This is exactly the problem ",[48,262,264],{"href":263},"\u002Fproducts\u002Fdelivery-sheet","Delivery Sheet"," is built for: capture a raw request and shape it into a decision-ready one-pager — problem, outcome, scope, owner, ",[48,267,269],{"href":268},"\u002Fblog\u002Fraid-log-risks-assumptions-issues-dependencies","open questions"," — so you decide with eyes open instead of committing to a sentence.",[272,273],"hr",{},[14,275,276],{},[33,277,278,279,283,284,286,287,291,292,296],{},"Part of the ",[48,280,282],{"href":281},"\u002Ftopics\u002Ffinance-systems-delivery","Finance Systems Delivery guide",". See also ",[48,285,51],{"href":50}," and ",[48,288,290],{"href":289},"\u002Fblog\u002Fwhy-delivery-sheet-has-four-decisions","why Delivery Sheet has four decisions",". The ",[48,293,295],{"href":294},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern, product decision or build lesson every two weeks.",{"title":199,"searchDepth":298,"depth":298,"links":299},2,[300,301,302,303,304,305,306,307],{"id":27,"depth":298,"text":28},{"id":42,"depth":298,"text":43},{"id":61,"depth":298,"text":62},{"id":95,"depth":298,"text":96},{"id":140,"depth":298,"text":141},{"id":180,"depth":298,"text":181},{"id":219,"depth":298,"text":220},{"id":249,"depth":298,"text":250},"intake","2026-07-23","How a team receives, shapes and decides on incoming work before committing people — the stages, the fields that matter, and four honest decisions.",false,"md",null,[315,318,321],{"question":316,"answer":317},"What is a project intake process?","A project intake process is the defined way a team receives incoming requests, shapes them into something clear enough to decide on — problem, outcome, scope and owner — and then makes an explicit decision: commit, shape further, pause or decline. It sits before delivery and before commitment, and its job is to turn vague demands into decisions rather than letting work start on a half-understood ask.",{"question":319,"answer":320},"Why do teams need a project intake process?","Because without one, requests arrive as one-liners, get an informal 'yeah, we can do that,' and become commitments before anyone knows the scope, owner or success measure. That drives rework, scope fights and slipped dates. A good intake makes the shaping and the decision explicit and quick, so teams commit to clear work — or decline it early — instead of building against a guess.",{"question":322,"answer":323},"What should a project intake process capture?","At minimum: the raw request as received, the problem it's really solving, the outcome that defines success, what's in and out of scope, who owns the outcome, and the open questions. Those few fields are enough to make an honest decision. The goal is decision-readiness, not a thirty-field form that no one fills in properly.",true,{},1,"\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams","finance-systems-delivery","project intake process","delivery-sheet","annual","reviewed","Tan Gravam","informational-commercial",{"title":5,"description":310},"blog\u002Fproject-intake-process-for-finance-and-engineering-teams",[338,308,339,340],"delivery","process","finance-systems","2026-07-26","dl2ksIutlDxM49342ZhBWwg-v1SGj-EOcyuGziQp7nI",[344,348],{"title":345,"path":346,"stem":347,"type":195,"language":313,"draft":311,"children":-1},"Problem Statements vs Solution Requests","\u002Fblog\u002Fproblem-statements-vs-solution-requests","blog\u002Fproblem-statements-vs-solution-requests",{"title":349,"path":268,"stem":350,"type":195,"language":313,"draft":311,"children":-1},"RAID Logs: Managing Risks, Assumptions, Issues and Dependencies","blog\u002Fraid-log-risks-assumptions-issues-dependencies",[352,354,358],{"path":346,"title":345,"description":353},"A solution request tells you what to build; a problem statement tells you why. Converting solutions back to problems is the highest-leverage move in intake.",{"path":355,"title":356,"description":357},"\u002Fblog\u002Fhow-to-define-a-measurable-outcome","How to Define a Measurable Outcome","A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity. How to write one, and the traps.",{"path":359,"title":360,"description":361},"\u002Fblog\u002Fhow-to-write-scope-in-and-scope-out","How to Write Scope In and Scope Out","Scope defines what work includes and — crucially — excludes. The 'out of scope' list is the half that prevents scope creep. How to define it from the outcome.",1785182341926]