Table of contents5 sections
One Project Manager keeps the budget in a spreadsheet. A second mainly controls deadlines and tasks. A third regularly analyses working time, but does not assign team costs to the project. A fourth reacts only when employees report overload or the client starts to question the scope.
Each of these people can run their own projects effectively. The problem starts when management wants to compare their results.
The data has a different structure, statuses mean different things, and information on costs and risks is collected at different moments. One project is considered at risk once it exceeds its hours budget, another only after its margin falls, and yet another on the basis of the Project Manager’s subjective assessment.
We know what it is like when project control depends on the experience of one particular person. As long as the company is small, the owner can personally ask about the most important matters. As the number of clients and the team grow, this model stops working.
That is why software house procedures should not be an elaborate set of documents that nobody reads. Their job is to unify key decisions, data and control stages, so that every project is assessed by the same rules.
One Project Manager keeps the budget in a spreadsheet. A second mainly controls deadlines and tasks. A third regularly analyses working time, but does not assign team costs to the project. A fourth reacts only when employees report overload or the client starts to question the scope.
Why do different ways of running projects make managing a software house harder?
Project Managers’ freedom can be a strength. Every client and project has its own specifics, so not everything can be unified.
The problem is not individual working style. The problem is the lack of shared standards for data, budget, risk and profitability.
Projects are not comparable
If every Project Manager uses different statuses, categories and reporting methods, management cannot quickly compare:
- budget utilisation,
- project margins,
- the cost of team work,
- the number of additional hours,
- the scope remaining to be delivered,
- the risk of delay,
- the amount of receivables,
- the cost needed to finish.
One report may show the number of hours, a second the percentage complete, and a third only a list of open tasks.
Each of them may be correct, but together they do not form a coherent picture of the company.
Problems are reported at different moments
An experienced Project Manager may notice a drop in profitability from several signals:
- a growing number of fixes,
- greater involvement of seniors,
- delays on the client side,
- estimates being exceeded,
- incomplete time reporting.
A less experienced person may notice the problem only once the project has used up its whole budget.
If the company does not set shared warning thresholds, the speed of reaction depends on the intuition and competence of a particular employee.
The owner has to collect information by hand
Without a standard, management often asks each Project Manager separate questions:
- How many hours have we already used?
- What is the current margin?
- What is still left to deliver?
- Has the client accepted the additional scope?
- How much has been invoiced?
- Have the payments come in?
- What costs will arise before the project ends?
The information is available, but it takes conversations, messages, spreadsheets and manual merging of data.
The owner is then not managing a portfolio of projects. They are busy collecting basic operational information.
Project Managers are hard to replace
If the way a project is run exists mainly in one person’s head, their absence causes chaos.
The person taking over the project must find out:
- what the individual statuses mean,
- where the current budget is,
- which arrangements with the client are binding,
- which changes have been priced separately,
- how many hours remain,
- which invoices have been issued,
- which risks require a response.
The lack of a shared standard increases the company’s dependence on individual employees and makes handing over projects harder.
The company cannot learn from its own data
If project data is collected differently, historical analysis is hard to carry out.
The company cannot say clearly:
- which types of projects are the most profitable,
- which stages most often exceed the budget,
- where scope creep appears,
- which clients require the most additional work,
- which estimates are regularly too low,
- which billing models deliver the best result.
Without comparable data, every new project is planned almost from scratch.
How to introduce software house procedures without creating bureaucracy?
Standardisation should not mean describing every possible situation. It is best to start with a few elements that have the biggest impact on the financial result and on delivery safety.
1. Set shared project stages
Every project should go through a similar cycle, even if its scope and technology differ.
Example stages:
- Qualification and pricing.
- Handover from sales to delivery.
- Budget and team planning.
- Delivery and ongoing control.
- Scope change management.
- Acceptance and invoicing.
- Closure and profitability analysis.
For each stage it is worth defining:
- the required data,
- the responsible person,
- the entry condition,
- the exit condition,
- decisions requiring approval.
This way a project does not move into delivery without a budget, an owner, a schedule and an agreed invoicing method.
2. Unify statuses and categories
A status should mean the same thing in every project.
You can introduce shared statuses, for example:
- planned,
- awaiting kick-off,
- in progress,
- waiting for the client,
- at risk,
- on hold,
- completed,
- financially closed.
It is also worth unifying time and cost categories in the same way:
- development,
- design,
- testing,
- project management,
- client communication,
- bug fixes,
- additional scope,
- internal activities.
This way, data from several projects can be put side by side without manually translating what local labels mean.
3. Define mandatory project metrics
Every Project Manager should regularly monitor the same set of information.
The most important metrics may include:
- contract value,
- amount invoiced,
- value of payments received,
- planned hours budget,
- hours used,
- actual labour cost,
- external costs,
- cost to completion,
- current margin,
- forecast margin,
- cash gap,
- value of additional scope.
This does not mean that all projects must have an identical budget. The point is that their result is assessed against the same parameters.
4. Set thresholds that require a reaction
A report alone does not protect a project. You need rules that define when a Project Manager should act or escalate the problem.
Example thresholds:
- 70% of hours used, but less than half of the scope completed,
- forecast margin has fallen below the minimum level,
- the client has not accepted a stage by the agreed date,
- additional work has exceeded the agreed buffer,
- a receivable remains unpaid while the team is delivering the next stage,
- the cost of seniors is higher than in the estimate,
- the project generates a negative cash gap.
Each threshold should have a reaction assigned to it, for example:
- a review of the remaining scope,
- stopping additional work,
- a conversation with the client,
- a new quote,
- a change to the team composition,
- a schedule update,
- escalation to the owner or the Chief Operating Officer.
How did we solve project standardisation at Administy?
While running agencies and digital projects, we saw that every Project Manager has their own way of working.
One person controlled time very carefully, but less often analysed the effect of external costs. Another managed the client relationship well, but updated financial data only periodically. Another kept an elaborate spreadsheet whose structure was clear mainly to them.
Every project could be run correctly, but the data was not comparable.
When we wanted to assess the whole portfolio, we first had to find out:
- where the current version of the data is,
- which costs were included,
- what a given status means,
- whether working time is complete,
- how the margin was calculated,
- whether cost to completion was taken into account,
- whether additional work is separated from the core scope.
So control depended on the experience of a particular person and on the quality of the report they prepared.
That is why at Administy we introduced shared:
- project categories,
- contract types,
- delivery statuses,
- control stages,
- cost categories,
- financial metrics,
- rules for assigning time and expenses.
Every project is analysed according to a similar scheme.
In one place we see:
- contract value,
- invoices issued,
- payments received,
- planned budget,
- team working time,
- the individual cost of specialists,
- subcontractor invoices,
- additional costs,
- current margin,
- forecast margin,
- cash gap,
- funds needed to finish the project.
Working time imported from the project system is converted into cost using the rates of specific people. Revenue and expenses are assigned to the correct project, and additional scope can be analysed separately from the core delivery.
This way every Project Manager works from a shared definition of the result.
A project is not considered safe just because tasks are being delivered on schedule. It must also meet the set financial criteria.
Standardisation helps us notice, among other things, that:
- a project delivered on time is losing margin,
- additional hours have not been priced,
- the team is using more expensive resources than planned,
- invoices do not cover the costs so far,
- a client is delaying payment, but delivery is still going on,
- the cost needed to finish exceeds the remaining budget.
Shared data also makes handing over projects easier. The new person does not have to reconstruct the previous Project Manager’s way of working. They receive a project with known statuses, metrics and control stages.
The most important change is moving away from the question:
“Does the Project Manager have the project under control?”
towards the questions:
- What is the current cost?
- What is the forecast margin?
- How much work remains?
- Which risks have crossed the set threshold?
- What decision does the project need?
The answers then do not depend solely on the opinion of the person running the project.
Standardise data and decisions, not the Project Manager’s personality
Good procedures should not take flexibility away from Project Managers. Clients, technologies and teams still require an individual approach.
What should be standardised above all is:
- the most important data,
- control stages,
- financial metrics,
- warning thresholds,
- escalation rules,
- the way a project is closed.
Software house procedures are meant to let the company compare projects, detect risk faster and keep control regardless of who is currently responsible for delivery.
Organise how all your projects are controlled
Administy helps connect working time, costs, invoices, payments, margin and cash gap according to a shared standard.
Book an Administy demo and see how to create a single project control model, without taking freedom of action away from Project Managers.
