Where project management breaks inside an organisation

Sayed Yousef, ApprovedFlow

A project plan is easy to draw. It breaks where the organisation touches it: another department owns the people, the client sits outside, the vendor invoices in another currency, and the approval that unlocks the invoice lives in someone's inbox. Below are the nine points where it breaks most often, and what ApprovedFlow does at each one.

  1. Levels: company, department, project
  2. Shared resources across projects
  3. Scattered teams and people who never sign in
  4. Several locations, calendars and time zones
  5. Tracking what actually happened
  6. Client approval with proof
  7. Invoicing and collection
  8. Variance: plan against reality
  9. Change management
  10. Vendors in the same picture

1. Levels: company, department, project

The challenge. Rules are set at the top and ignored at the bottom, or every project invents its own. Who approves, which rates apply, how hours are recorded: each project answers differently.

How ApprovedFlow handles it. Every rule is a setting with one inheritance: company default, department, project. A department overrides the company; a project overrides the department; a lock at any level stops the one below. The project manager sees each setting with its source, so he knows what he inherited and what he changed.

2. Shared resources across projects

The challenge. The same engineer is on three projects. Each manager plans him at 100%. Nobody sees the overload until the dates slip.

How ApprovedFlow handles it. A person on a task carries two figures: his share of the task's hours and the share of his day he gives it. The plan computes his days from both, caps everyone at the task's planned hours, and shows what is still unassigned. A task that grows re-spreads the people by their shares; a person who shrinks never silently shrinks the task.

3. Scattered teams and people who never sign in

The challenge. Consultants, vendor staff and client representatives do real work on the project but will not open another system. Their approvals and updates arrive by email and get lost.

How ApprovedFlow handles it. A contact holds a project role without an account. He receives his task by mail, updates it or approves it through a signed link, and the decision lands on the task with his name. If he signs up later, the same role follows him. For the team that does sign in, My tasks shows only their own work, with a timer that writes the timesheet.

4. Several locations, calendars and time zones

The challenge. The head office works Sunday to Thursday, the London branch Monday to Friday, the Cairo site has its own holidays. A plan drawn on one calendar is wrong on the others.

How ApprovedFlow handles it. Each branch has its own working week, hours, holidays and time zone; a person can carry his own schedule. The planner moves tasks by working days on the calendar of the people on them. A reminder reaches each person inside his own working hours, never at 3 a.m.

5. Tracking what actually happened

The challenge. Progress is a feeling. Hours live in a spreadsheet, status in a chat, the plan in a tool nobody updates.

How ApprovedFlow handles it. Hours are recorded on the task, by hand or by a timer, and roll up to the phase and the project. Progress is proposed from recorded hours against planned hours. The plan, the hours and the status are one record, so the dashboard shows what was done, not what was said.

6. Client approval with proof

The challenge. "The client approved it" is a sentence in an email thread. A month later, nobody can find it, and the invoice is disputed.

How ApprovedFlow handles it. A task, a deliverable or a timesheet goes to the approver the chain names: the project manager, the department head or the client. The client approves on screen or by replying to the mail; the decision, the document version and the date are kept with the work. A deliverable the client rejects comes back with his comments on the same task.

7. Invoicing and collection

The challenge. Approved work and the invoice line are two different worlds. Finance invoices late, or invoices what was not approved, and collection is a separate chase.

How ApprovedFlow handles it. Approved hours and completed vendor milestones appear on the project's Finance tab with their cost at frozen rates. From there the invoice for approved work is prepared and followed until collected. Money and the work behind it stay on the same page.

8. Variance: plan against reality

The challenge. The plan said 40 hours; 60 were spent; nobody re-planned, so the end date is a fiction.

How ApprovedFlow handles it. The time engine shows planned against recorded hours and the expected total at the current pace, per task and rolled up. A change of a task's length recalculates its hours and moves its dependants by itself, with the result shown in place and an undo. Baselines are saved deliberately and kept, so the variance is measured against a real baseline.

9. Change management

The challenge. Scope changes arrive as a Word document from the client. They are agreed verbally, done, and never priced or planned.

How ApprovedFlow handles it. A change request is a document on the project or the task, versioned, with its approval chain. The project manager applies its impact to the plan through the same planner, so new tasks, moved dates and added people follow from the request instead of surprising the budget.

Vendors in the same picture

A vendor's purchase order, its milestones, its percentage payments and its people's hours sit inside the project, in the vendor's currency and in the company's base currency. Paying a milestone is a request, an approval and a record, not a reconciliation at month end.

See where your own project management stands. The Project Operations Assessment reviews these points for your organisation and recommends process steps first, then changes to the systems you already use, and additional software only where a need remains.

Start the assessment