Project operations where every blocked milestone reaches the person who can unblock it

Mi Retail is an operations center that manages the human work around your projects. Your project tool keeps the schedule, the work breakdown and the baselines; Mi Retail handles what happens when a project needs someone outside the plan to act — a document the client owes, an approval from another department, an escalation to the project owner, a decision between replanning and a change request. Each of those becomes an Operational Work Item with an owner, a state, a due date and evidence, and it moves between the project team, the owner, the PMO and other areas until it is resolved. The project manager stops chasing people between status meetings.

No, and it does not try to be. Mi Retail has no Gantt chart, no scheduling engine and no work breakdown structure: those belong in your project or portfolio management tool, or in the StoneOS Projects suite, and they stay the record. Mi Retail covers what the plan cannot: the work that crosses the project’s boundary. A milestone can show as late in the project tool, but the delay may depend on a client document, a legal approval or a sponsor’s decision that lives outside it. Mi Retail turns those dependencies into work items with owners, states and reasons, so they are handled instead of reported. Keep your project tool; Mi Retail takes over where the work leaves it.

The project manager marks the milestone’s work item as Blocked and records the reason — for example, the signed data mapping has not arrived — so anyone looking at it knows exactly what is missing and from whom. Follow-ups with the client are logged on the same work item. If the block persists, it is escalated to the project owner with the impact on dates attached, and the owner decides between a replan and a change request, with the reason recorded. The PMO rebaselines the plan in the project tool, the client lead communicates the new dates, and when the document arrives the milestone is unblocked and the exception closes with its full trail.

Escalating is not forwarding an email; it is moving a situation explicitly to the level that can resolve it. When a block exceeds what the project manager can solve, the escalation arrives in the project owner’s queue as a work item with the milestone, the reason, the follow-up history and the impact on dates and budget already attached. The owner sees it the day it happens, not at the next steering meeting. If the owner cannot resolve it either — a portfolio conflict, a contractual issue — it can escalate again to Executive Operations with the same context, so each level acts on facts instead of rebuilding them.

The decision is an approval work item in the project owner’s queue, with the options and their effect on dates, cost and resources attached. The owner chooses and writes the reason, and that decision stays linked to the blocked milestone, the escalation and the rebaseline that follows. If the choice is a change request, it can move into your change control process and, when the client is on Mi Retail, be sent to them as a derived work item for approval. Months later, when a steering committee or an auditor asks why the go-live moved, the answer is one click away instead of a search through meeting notes.

Projects depend on teams that do not work in the project tool: procurement buying equipment, legal reviewing a contract, finance releasing budget, IT granting access. In Mi Retail, each of those needs is a request work item that lands in the other team’s own queue, with the project context, what is needed and by when. The other team works it alongside the rest of its day, in its own My Work, and the project manager follows its state from My Requests without calling anyone. When a dependency is late, it shows as at risk before it blocks the milestone, so the project can act while there is still room.

Yes, when they have their own organization on Mi Retail. A document request to a client, a deliverable from a subcontractor or a delivery from a vendor can be sent as a derived work item that lands in the other organization’s own intake. They assign it inside their teams, and you follow its state, due date and result without seeing their internal work — and they do not see yours. When they complete it, your blocked milestone can move. If a client is not on Mi Retail yet, the request still lives as a work item with an owner on your side, so the follow-up never depends on one person’s memory.

A PMO does not need another status report. Operational Portfolio shows, across projects, the milestones blocked and why, the escalations waiting for a decision, the dependencies on other teams that are running late and the rebaselines in progress. Executive Operations surfaces only what needs portfolio-level attention: two projects competing for the same people, a client that blocks several projects at once or a decision that has been pending too long. The schedule and the portfolio roadmap stay in your project tool; Mi Retail shows the operational reality behind them, with the context attached, so the PMO acts on it instead of compiling it.

Every work item keeps who acted, when, what they decided and which documents supported the decision. For a slipped milestone, that means the original block and its reason, the follow-ups with the client, the escalation, the owner’s decision with its reason, the approved new baseline and the client’s confirmation, all linked to the same case. A steering committee sees why the date moved without a reconstruction exercise, and Control & Assurance lets an internal audit or quality team review those trails and record findings. Because the evidence is captured while the project runs, lessons learned start from facts, not from recollections.

Yes, it is the same product at both ends. In a small team where one person manages the project and talks to the client, the experience collapses to the essentials: one Today view with what is blocked, what is waiting on others and what is due this week, without a PMO layer that does not exist. In a large organization with dozens of projects, a PMO and several levels of sponsors, the same work items are distributed across project managers, owners, the PMO and the teams they depend on, each with its own surface, and escalations reach the right level. As the organization grows, the work is represented the same way.

The Projects suite of StoneOS brings apps for the domain work of running projects — portfolio, projects, work breakdown, resource planning, timesheets, project costs, project budgets, risks and issues, change control and profitability — on top of the Business Core apps every team uses, such as Docs, Sheets, Drive, Chat and Calendar. Those apps keep the depth of project management. Mi Retail is where the work they generate meets the people who must act on it: an issue that needs an owner, a change that needs approval or a budget overrun that needs a decision lands as a work item in the right person’s queue. If you keep your current project tool, it stays the record.

Start with the blockers, not with the plans. Pick one or two projects, create a workspace for them, invite the project managers, the project owners, the PMO and the teams they depend on most, and open the next blocked milestone or cross-team dependency as a work item instead of a line in a status report. Within a few weeks you will see where projects wait, which dependencies are slow and which decisions take too long. Then extend to the rest of the portfolio, connect the project tool you already use and, when it fits, add the Projects suite apps from StoneOS. Mi Retail is free to start, so you can prove the value before rolling it out.