When the resource request workflow is turned on:
if you’re requesting additional resource on top of demand that has already been allocated, it will be sent to the Resource Manager as a new request once saved.
if you’re requesting less resource than the demand that has already been allocated, the change is accepted automatically once saved.
Status | Meaning |
|---|---|
Requested | Resource has been requested but a Resource Manager hasn't reviewed it yet. This can be a brand-new request or extra resource on top of what's already committed. |
Soft Allocated | A Resource Manager has provisionally committed resource to the request. This counts against the available time. |
Hard Allocated | A Resource Manager has firmly committed resource to the request. This counts against the available time. |
Rejected | A Resource Manager has turned the request down. It doesn't count towards demand totals or use up any available time. |
How requests are raised on edit
Asking for more - entering a number higher than what's already committed, or adding a number where there was nothing before, creates a request on save. If resource is already committed there, the request sits on top of it, and that committed resource keeps counting until a Resource Manager deals with the request.
Asking for less - entering a number lower than what's already committed accepts the reduction straight away. The committed value drops to the new number, and any request still waiting on that period is cleared.
Reviving a rejected request - entering a number on a row that has rejected periods turns those periods back to Requested using the numbers already there, so they don't have to be typed again.
Nothing is sent until Save is pressed. Changes that are made and then discarded never go out.
Each resource can have one open request per initiative. A changed request looks different from a brand-new one, so the Resource Manager can see what's changed.
When the resource request workflow is turned on, a single period can show two numbers at once: the resource already committed to it, and a new request that's still waiting for a Resource Manager to review.
Row summary status
Each row shows one overall status, making it easy to see at a glance which rows need attention. Kiplot picks it based on the most pressing thing happening in the row:
If any period is still Requested, the row shows as Requested.
If none are Requested but any period is Rejected, the row shows as Rejected.
If neither of those applies but any period is Soft Allocated, the row shows as Soft Allocated.
If every period is Hard Allocated, the row shows as Hard Allocated.
Review and action a request (only applicable when the request workflow is turned on)
The Resource Manager permission is required to action requests. Resource Managers can action requests on any initiative in the portfolio.
A Resource Manager can soft allocate, hard allocate, reject, or change each request, either from the supply and demand overview or from the initiative's Resource Demand section.
Soft allocate provisionally commits resource to the request. It starts counting against the available time.
Hard allocate firmly commits resource to the request. This is treated as a final decision - to change something that's hard allocated, use the full edit flow rather than the quick decision action.
Reject turns the request down. A rejected value doesn't count towards demand totals or use up any time. Rejecting a request on a period that already had resource committed clears that period and removes the earlier commitment; past periods are left alone.
Simple decisions can be handled in a single step, from either the overview or the initiative. For more involved changes - such as reassigning work, or editing something that already has resource committed - Kiplot opens the full edit view so all the context is in one place.