We break projects down into a work breakdown structure, make resources and capacity visible, and put budget and actuals side by side. Milestones, risks and decisions sit in the same record; management reads the whole portfolio from a single dashboard and discusses which work comes first by looking at data.
In a factory, capital projects run alongside daily production and are usually entrusted to the same people. A new line, a building extension, equipment for a second shift, automation or a system migration. The plan for this work usually sits in a file, while its real status sits in a verbal update at the weekly meeting. The budget accumulates in accounting, the quotes in purchasing, the task list in a messaging group. Nobody is withholding information as the project moves; simply because the information is never gathered in one place, a delay is only noticed after the schedule has already slipped. Ask anyone and they know the status of their own piece; nobody knows the status of the whole. And the gap between the status discussed in the meeting and the plan in the file is usually never written down anywhere.
For project-based companies the picture is a little harder. A machine builder, a contracting firm or an engineering team runs many jobs at the same time, and all of them draw on the same pool: the same foreman, the same machine tool, the same project engineer. Looked at one by one, every project has a plan; looked at all together, the same person appears full-time on three separate jobs. The deadlines given to customers usually slip because of this invisible clash. What is missing here is not the project plan but capacity visibility across projects; that is, the information that says when a job can actually start. Without that visibility, every deadline given is no more than a well-meaning guess.
At this point two concepts need to be separated. A project management system (PMS) runs a single project: the work breakdown structure (WBS), task dependencies, milestones, assignments and progress. Its question is this: how is this project going? Project and portfolio management (PPM) looks at the projects as a whole: which project should be started, where resources should go first, which job should be deferred or stopped, where the portfolio's total budget stands. Its question is this: are we doing the right projects, and is our capacity enough? The two can live in the same system, but they serve different screens and different meetings; confusing them ends with the project manager's working screen being shown to management as a report.
To be honest, these systems do not deliver the plan; they only make deviation visible early. Nor does the data enter itself: if nobody updates tasks, the dashboard stays empty and before long nobody looks at it. Another reality is progress percentages. Saying eighty per cent complete is a statement, not a measurement; that is why we recommend tying progress to completed deliverables. The resource plan is a forecast too, and it will not hold in the first few months; it becomes more accurate as forecast and actual accumulate side by side. We say all this up front, because most project software is abandoned not for technical reasons but because it is never filled in. Whether the system survives depends on how easy data entry is and on management's habit of looking at the same screen.
Plants that run work such as a new line, a building, a capacity increase, automation or a system migration alongside production. In these projects the cost of delay is not measured directly; but as the commissioning date slips, planned production slips with it. A one-page project scorecard is the first concrete benefit in these plants.
Firms whose work is a project rather than an order: machine building, steel structures, contracting and engineering. Every job has its own plan, team and budget. If profitability is only understood once the job is finished, the chance to intervene has already gone; plan and actual have to be compared while the project is still running. The system is set up to show the direction of work in progress, not the profit on work already finished.
Teams running several jobs at once with a limited number of engineers, technicians or specialists. The real problem here is not the plan of a single project but the total load on individuals. When capacity is visible, the question of when we can start this job is answered with a calendar rather than a guess. Over time this view also changes the way the sales side makes promises.
Companies whose budget is approved but which can only see actual spend at the month-end accounting close. Because orders that have been placed but not yet invoiced are invisible, a budget overrun is noticed late. A commitment record posted the moment the order is placed closes most of that lag. The owner of each budget line is also defined in the same record.
The project is split into deliverables and the work beneath them; dependencies, durations and milestones are defined between tasks. The approved plan is stored as a baseline and later changes are recorded as revisions. That way the argument about schedule slippage leaves memory; which commitment was given on which date is read from the record. Who changed the plan, and on what grounds, sits in the same place.
People and teams are assigned to projects by percentage or by hours; the system shows a person's total load across all projects. If the same person appears at full capacity on several jobs at once, a clash warning is raised. When a new job can be started is discussed through this view. The capacity plan is a forecast, but it is a shared and visible forecast.
The project budget is split into lines; orders placed are posted as commitments and incoming invoices as actuals. Actual spend on the accounting and ERP side is read through integration, not keyed in a second time by hand. When budget, commitment and actual sit side by side, an overrun becomes visible without waiting for the month-end close. Remaining budget by line is read at a glance when a new spending request arrives.
In every project, risks, open issues and decisions taken are recorded separately; each is tied to an owner and a deadline. A notification goes out when a milestone is approaching and when it is late. The decision log is especially valuable on long projects: months later, the answer to why something was done this way stays in place, together with its date and the person who took the decision.
Project requests are collected on the same form and assessed against common criteria such as benefit, cost, duration, resource need and risk. Approved projects are tied to stages and gates; at each gate a continue, revise or stop decision is taken and the reason is recorded. A new project is therefore started only after being compared with those waiting in the queue. Rejected requests also stay on the list together with their reason.
Task owners report progress from a short screen: complete, in progress, waiting, and the reason if there is a blocker. Mobile use is supported for site and field teams, with photos attached where needed. The simpler the entry, the more current the data stays; that is why the reporting screen is deliberately kept plain. Tasks with no report are chased up with their owner.
Every project in the portfolio appears in a single list with its status, deadlines, budget variance and open risks. A one-page status report is generated automatically for each project, so preparing a presentation by hand before the meeting disappears. The screen management looks at and the screen the project team works on are fed by the same data, so two separate versions of the truth do not form.
We put every job currently running and every one waiting in the queue into a single list. In practice this list is longer than expected in most organisations, and the first benefit is the list itself. Which work counts as a project and enters the system, and which stays outside as routine work, is decided at this stage. The first true picture of the portfolio emerges with this list.
We decide how projects will be broken down, how far into detail to go and what progress will be measured against. A breakdown that is too deep cannot be kept up to date; one that is too shallow measures nothing. Deliverables are defined concretely; the completed deliverable is taken as the basis instead of a progress percentage. The way of measuring is put in writing at this step.
Teams, roles and capacities are defined; budget lines are set up. We determine how actual spend will be read from accounting or the ERP and build the integration. Posting purchase orders as commitments is also connected at this step; how realistic budget tracking is comes directly from here. Details such as currency and tax treatment are settled here too.
The system is first run on a single real project. The plan is entered, a weekly update rhythm is established and the first status report is produced. During this period, which usually takes 4-8 weeks, the number of fields and the meeting structure are simplified. If the pilot is skipped, the system usually falls out of use by the third month. The decision to roll out is taken together at the end of the pilot.
The remaining projects are brought into the system; the portfolio dashboard and the approval gates go live. Which meeting runs from which screen, and who reads the report and when, is left in writing. How a new project request enters the system is described as well. After go-live we provide usage support and continue development for new requirements.
Largely yes, but let us state the limit as well. We bring planning, resources, budget and progress tracking into a single system, and existing plans can be imported. Against that, we do not rewrite every resource-levelling and complex scheduling feature of specialist planning tools; if that is genuinely what you need, we say so during discovery, leave that tool where it is and set up data exchange. In most organisations what is really missing is not advanced scheduling but a plan that is never kept current and a budget that sits somewhere else.
It depends on who you work for. PSA, that is professional services automation, manages service work sold to a customer: the chain running from time recording to progress billing and invoicing, resource utilisation rates and project profitability all sit there. PPM mostly manages your own internal projects and investment portfolio; its question is not the invoice but priority, capacity and budget. In some project-based firms both are needed; in that case we build two layers in one system and make clear which data lives on which side.
The task owner enters it, and taken on its own it is a statement. That is why we tie progress to completed deliverables as far as possible: a job has either been accepted or it has not. For intermediate states we use a small number of clear options. Beyond that, as planned and actually spent time accumulate, how well the statements hold becomes visible over time. A percentage field nobody looks at soon turns into a field filled in out of habit.
Not if the direction is set. The financial record stays in the ERP: the invoice, the accounting entry and the cost are created there. The PPM side holds the plan, the resources and the status; it reads actual spend from the ERP. Entering the same data by hand in two places is the most common mistake and one of the reasons systems like this get abandoned. Project codes are kept common, the mapping is done during discovery, and which information lives where is put in writing.
No; let us say plainly that this falls outside the scope of the work. Software does not put in place a management discipline the organisation does not have. A project with no clear owner, whose deadline nobody takes responsibility for, is not managed simply because it has been entered into the system; its delay only becomes visible earlier. If there is a need on the process side we say so openly during discovery and phase the rollout accordingly. But we do not claim to provide methodology training or project management consultancy.
A project portfolio gathered in a single list; project plans with a work breakdown structure, dependencies and milestones, and stored baselines; a capacity view by person and team with clash warnings; a comparison of budget, commitment and actual; risk, issue and decision logs; portfolio prioritisation with approval gates; automatically generated status reports and a management dashboard. The source code, the data and the documentation belong to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We design and build internal systems and subscription-based SaaS products that run in the browser, sit behind secure sign-in and show content according to role and permission. We shape them around how your business actually works, and we share the source code with you.
Details →We bring your field, sales and customer-facing work into a single app. We design iOS and Android applications around your needs, build them with offline mode and push notification infrastructure, and publish them on the App Store and Google Play.
Details →Desktop applications that keep going even when the internet drops, connect directly to barcodes and local hardware, and run fast on the shop floor and in the office. For Windows and macOS, with the source code yours.
Details →Web applications that are installable, work offline and meet the Core Web Vitals thresholds. Measured speed, a solid technical SEO foundation and an experience developed specifically for your brand.
Details →Custom API and integration development that gets your ERP, CRM, marketplace, e-invoice and production systems talking to each other, with a two-way, secure and traceable data flow.
Details →We set up electronic data interchange with retail chains and major buyers alongside your ERP. We turn incoming orders into your records, your shipments into despatch advices and your invoices into the message the buyer expects; a faulty message is never lost — it lands in a queue, gets corrected and is sent again.
Details →
