> For the complete documentation index, see [llms.txt](https://portavi.gitbook.io/portavi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://portavi.gitbook.io/portavi-docs/intake/requesting-new-work.md). # Requesting new work **Intake** is where new work starts. Instead of a project, programme or portfolio appearing because someone created it, it arrives as a request: what the problem is, what should be different afterwards, roughly what it costs and where it would sit. The PMO screens it before anything is set up. Intake is a feature a PMO manager switches on under **Settings → Features**. It is off to start for workspaces created before it existed. ## Raising a request Anyone in the workspace can ask for new work, executives included. Open **Intake** in the navigation and press **Request new work**, or choose **Request new work** from the **Create** menu on the Overview.

First choose what you are asking for: a **project**, a **programme** or a **portfolio**. Programme requests appear only while Programmes is switched on, and portfolio requests only on plans that include portfolios. Every request has: * **Title**, **problem or opportunity** and **expected outcome**. These three are required to submit; everything else can be left blank and filled in later. * **Sponsor** and **proposed owner**. The owner list shows the people who can own that kind of item. * **Desired start**, **needed by**, an **estimated cost** with a note on how sure it is, a **size** and an **urgency** with the reason behind it. * Up to ten **links**: a business case, a brief, a ticket. The rest depends on the kind: * A **project** says where it would sit: **inside a programme**, **standalone in a portfolio**, or **not attached**. Inside a programme, you pick which of the programme's benefits it would serve; standalone in a portfolio, which of the portfolio's objectives. It can also suggest a category, a priority and a delivery type. * A **programme** sits **inside a portfolio** or is **not attached**. Inside a portfolio, you pick which one and which of its objectives it would serve. It lists its expected benefits and any standalone projects it would group. * A **portfolio** names its primary value driver and strategy cycle, drafts its objectives, and lists the programmes and standalone projects it would contain. **Save draft** keeps the request private to you. **Submit** sends it to the PMO, and every PMO manager is notified. ## Screening A PMO manager opens a submitted request and does one of three things:

* **Accept for assessment** moves it to **In assessment**. You, the sponsor, and the owners of the programme or portfolio it is aimed at are notified. * **Decline** closes it, with a reason (a duplicate, out of scope for the PMO, the work already exists, or other) and an optional note. You and the sponsor are notified, and the note travels in the notification. * **Needs more information** hands it back to you as a draft, with the PMO manager's question shown at the top. Edit it and submit again. While a request is in assessment, you and the sponsor can still edit it. You can **withdraw** your own request at any point until it is decided. ## Scoring While a request is **In assessment** it is scored against the workspace's scoring model. Every PMO manager can score it, and so can the owner of the programme or portfolio it is aimed at (or of the portfolio above that programme). Open the request and find **Assessment**. Each criterion takes a score from 1 to 5; where the PMO has written what each step means, that text appears beside the score you pick. **Clear** removes a score. The request's score is its weighted total as a percentage of the most it could reach, counting only the criteria that apply to its kind, and the panel shows how many of them have been scored.

When a project names the benefits it would serve, or a programme or portfolio the objectives, those appear above the criteria with their current status. They are evidence for whoever scores alignment, not a score of their own. Each criterion shows the last person to score it and when. A request that has been decided keeps the score it was decided on, even if the model changes later. ## Deciding Once a request is scored, the people who decide it are asked for their decision. They're set under **Settings → Intake criteria** and, by default, are: * for a project inside a programme, the programme's owner and the owner of its portfolio; * for a standalone project or a programme, the owner of the portfolio it would join; * and any one PMO manager, for every request. Portfolio requests, and requests with nothing above them, go to the PMO only. Each approver opens the request and chooses **Approve**, **Defer** or **Reject**, with an optional note. The request is approved when every approver has approved. One rejection rejects it, and one deferral defers it. Someone who holds two of the roles decides once for both. Nobody decides a request they raised, PMO managers included.

**Approve** stays unavailable until every criterion has a score, unless a PMO manager switches that off in Settings. Reject and Defer are always available. **Defer** asks for a date to look at it again. On that date the request comes back to **In assessment** with the same scores, and its approvers are asked afresh. The requester and the sponsor are told the outcome, with the note. The score at the moment of the decision is kept with the request, so changing the scoring model later doesn't change why something was approved. Requests waiting for your decision, requests to screen, approved requests waiting to be created, and your own requests sent back for more information all appear in **My Focus**. ## Creating it A PMO manager opens an approved request and chooses **Create project**, **Create program** or **Create portfolio**. The matching setup wizard opens, filled in from the request: the name and description, dates, the estimated cost as the budget, the proposed owner, category and priority, and the kind's own details, such as a program's expected benefits, a portfolio's draft objectives, and what it would group.

Nothing is skipped: you still walk every step, because the request didn't cover the tool, the type or health. If the proposed owner can no longer own this kind of item, or the program or portfolio it was meant to sit in has been archived, the wizard says so and leaves that part for you. When you create it, the request is marked **Converted** and links to the new item, which goes where the request asked, and the requester, sponsor and new owner are told. The new item's header shows **Created from request**, which opens the request it came from. A request becomes one item only. If it turns out to be several projects, create a program.

You can still create projects, programs and portfolios without a request. ## The scoring model A PMO manager sets the model under **Settings → Intake criteria**. A new workspace starts with six criteria: strategic alignment, value, urgency, risk of not doing it, effort and confidence. Each criterion has a name, an optional question for the scorer, a **weight** from ×1 to ×3, the kinds of request it **applies to**, and optional text for what each score from 1 to 5 means. **Score inversely** is for cost or effort, where 5 means cheap or easy, so a higher score is still better. Drag a criterion by the grip at its edge to set the order scorers see them in. From the keyboard, focus the grip, press Space, move it with the arrow keys and press Space again. A model holds up to ten active criteria. **Archive** retires one: nobody can give it a new score, but scores already given still count on their requests. **Restore** brings it back. An archived criterion can also be **deleted**. That removes its scores from requests still in assessment, while requests already decided keep the score they were decided on. Deleting can't be undone. Both archive and delete ask you to confirm on the criterion itself. Changing a weight, the kinds a criterion applies to, archiving or deleting one recalculates every request still in assessment.

## The Intake page **Pipeline** shows every open request. As a **board**, it has one column per stage: **Submitted**, **In assessment**, **Deferred** and **Approved**. On the board you can drag a request forward: from **Submitted** to **In assessment** accepts it, and from **In assessment** to **Deferred** or **Approved** opens the request on that decision, where you add the note and, for a deferral, the date. While you hold a card, the columns it can go to are outlined in violet, and the ones it can't go to are outlined in gray with the reason. You can only drag the moves you could make from the request itself, and **Approved** waits for a full score when the workspace requires one. As a **list**, you choose how it's grouped (by status, by kind, or not at all) and sorted (by score, estimated cost, urgency or date, either way round). Requests without a score, cost or urgency always sort last. On a phone you get the list, with the stages as chips above it when grouped by status. Search works in both views. Your own drafts sit above the pipeline, and only you see them.

To rank requests, set the list to **No grouping** and sort by **Score**. Above the list is the estimated cost of everything in it, so you can weigh it against the budget you hold. The total is there to read; nothing stops you approving past it. **Closed** keeps every request that has finished, whether converted, rejected, declined or withdrawn.

The cards above the tabs count the open requests and how many wait at each stage. ## Comments and activity Once a request is submitted, its preview has a **comments** thread at the bottom, as projects and change requests do. Mention someone with **@**: they're notified if they can see the request. Whoever raised the request follows its thread from the start. Above the comments, **Activity** lists what has happened to the request and who did it: submitted, edited (which fields), accepted, declined or returned for more information, each score given or changed, each approver's decision, withdrawn, back from a deferral, and the item created from it.

When your own request is rejected, deferred or declined, it appears in **My Focus** for a week with the reason given, and for a deferral the date it comes back. ## Who sees what PMO managers and executives see every submitted request. Everyone else sees the requests they raised, the ones they sponsor, and the ones aimed at a programme or portfolio they own. A draft is visible only to the person writing it. ## Switching Intake off Switching the feature off declines every open request, and each requester is told why. Drafts are kept. Switch it back on and they are there to submit again.