Project, job order and timesheet management: a complete guide to planning, resources and profitability

1. Project management, job orders and timesheets: what they are and how they connect

A project is the work to be done, with an objective, dates and a person in charge. A job order is the same initiative read as a profit and loss account: client, value, cost budget and the margin to be defended. A timesheet is the record of the time people spend on that work. Linked together, they make it possible to compare what was planned with what happened and to turn hours into costs and margins.

Project and job order

There is no shared formal definition of “job order” (commessa): industry sources use it with similar but not identical meanings, and this guide adopts the one just given. Within the project, the work is broken down into activities, collected in a WBS (WBS, Gantt and Kanban), and that is the level at which people record hours. The general methodological guidance is in ISO 21502:2020; the second edition is at an early draft stage (ISO 21502 page).

EcosAgile working model.

Example with invented figures: a fixed-price job order worth €24,000, with a budget of 40 days at an average cost of €400 a day, that is €16,000 of cost and €8,000 of expected margin. The project is delivered on the agreed date, but people have recorded 55 days: €22,000 of cost, a margin of €2,000. The plan showed no delays, yet the job order lost three quarters of its margin. The margin at completion is calculated as in Economic control.

The timesheet

A timesheet records each person's time on projects, job orders and activities, in hours or in days, and is linked to management accounting, invoicing and project cost (paraphrased from Wikipedia, “Timesheet” entry, CC BY-SA 4.0, accessed on 29 October 2026). Details in Timesheets.

Planning, recording actuals, control

Planning means setting hours, dates, costs and expected revenue in advance. Recording actuals means logging afterwards what happened. Control means comparing the two sides and deciding: correcting the plan, asking the client for a variation, moving people. Without a timesheet, the actual cost of labour is an estimate from memory, and the comparison comes when nothing can be changed any more.

Project timesheet and attendance tracking

EcosAgile working table; not legal advice.

The Court of Justice of the EU (Case C-55/18, 14 May 2019) ruled that Member States must require an objective, reliable and accessible system for measuring the daily working time of each worker, leaving the arrangements to them (text of the judgment). A project timesheet does not automatically coincide with that measurement: a sheet with only the hours attributed to projects may not cover the whole working day. Anyone wishing to use the same system to measure working time as well should check with an employment consultant and payroll that it meets the applicable requirements. The topic is covered in Attendance tracking: the complete guide.

In EcosAgile: the job order is a master record in its own right and can group several projects; the project carries budget, people and hours. The project timesheet is monthly, with day-by-day entry. Attendance, absences and the flow to the payroll bureau are in the Time module; project hours and costs are in Project & Timesheet.

2. The end-to-end cycle of a project

A well-governed project goes through eight phases: opportunity, budget and baseline, WBS and activities, staffing and capacity, execution, timesheet, economic control, closure. The first four take place before anyone records an hour and set the reference point against which reality is later measured. The last three produce the data that show whether the work is earning what was planned and what is worth correcting or remembering.

The phases are not a rigid waterfall: 5 and 6 run in parallel, and the control in phase 7 is repeated as long as the project is open. Who does what and what data arises in each phase can be read in the table; further detail is in the sections indicated.

Owners and data per phase are an EcosAgile working model, to be adapted to the organisation.

An example from opportunity to closure

Example with invented figures, a fixed-price job order for a consulting firm. (1) The client asks for a review of its reporting: 60 days are estimated and a value of €42,000 is agreed. (2) The budget is 60 days at an average cost of €350, that is €21,000, with €21,000 of expected margin; revenue, days and dates are saved. (3) The WBS has three work packages: analysis 12 days, development 36, testing and delivery 12. (4) Three people are assigned, and the four days of already approved leave of one of them are deducted from April's availability.

(5) Halfway through development, the client verbally asks for two more reports. (6) At the end of April the approved timesheets total 44 days: analysis closed at 15, development at 29. (7) The project manager estimates another 29 days of development, so 15 + 58 + 12 = 85 days at completion against 60: €29,750 of cost and an expected margin down from €21,000 to €12,250. While the job order is still open, the two reports can still be discussed with the client. (8) Once delivered, the days are 88, the cost €30,800, the margin €11,200. In the closing notes: reports requested verbally must be quoted separately.

Where the cycle breaks down

Without a baseline, that is, a copy of the budget and dates at the time of approval, control compares the actuals with a plan that changes every week. With timesheets completed at the end of the month, control always looks at last month. And a project that is not closed keeps receiving hours: closure is also there to stop postings.

In EcosAgile: the cycle documented in the manuals follows this order: Business Model, project with budget, allocations, timesheet, approval, Economics, invoicing instalments, Completed status. The Business Model assesses feasibility before the project, with resources by role at standard cost; a Completed project no longer accepts hours. A frozen baseline is not described in the manuals: changes to the project remain in a searchable history. See the Project & Timesheet software page.

3. WBS, Gantt and Kanban: planning the work

WBS, Gantt and Kanban answer three different questions. The WBS breaks the scope down into manageable, assignable parts: what must be delivered. The Gantt places the work in time, with durations and sequences: when. The Kanban shows the status of each work item and where work piles up: how it flows.

WBS: breaking down the scope

The WBS is a hierarchical decomposition of the scope into manageable components, built from deliverables and not from activities. Under the 100% rule, the children add up to the parent, with no work more or less; the lowest level is the work package, with a single owner (PMI article of 18 August 2026). ISO 21511:2018 is the guide to WBSs for projects and programmes (ISO 21511 page); as at 29 October 2026 the second edition has not yet been published: it is at the final stage, and the date given, December 2026, is not certain.

Example with invented figures: an order portal for a distributor, estimates in days.

• 1 Order portal (52)
  • 1.1 Analysis (10): interview minutes (4), approved functional specification (6)
  • 1.2 Development (30): customer master data and price lists (8), basket and order (12), link to the client's management system (10)
  • 1.3 Testing and go-live (12): test report (5), users trained (3), release to production (4)

Here the second level is by phase and the third by deliverable; the boundary between deliverable and activity (release to production, training) is decided within the project.

The branches add up to 10 + 30 + 12 = 52, and the work packages of each branch add up to the branch. Hours are recorded at work-package level: this is a methodological choice of this guide, not a PMI or ISO prescription.

Gantt: time, durations, dependencies

The Gantt is a bar chart: activities vertically, time horizontally, the length of the bar equal to the duration. In its original form it shows only durations; modern Gantt charts add dependencies and progress (Wikipedia). With dependencies you can see the chain that determines the end date, the critical path.

Kanban: flow and work in progress

Kanban is a visual method: cards sit in columns representing statuses, new work is taken on when there is capacity (pull logic) and work in progress, the WIP, is limited. It originated at Toyota in the late 1940s (Wikipedia). It gives no durations or deadlines. Further reading: the Kanban method (in Italian).

The table is an EcosAgile working model, not a standard. The parts on Gantt and Kanban are paraphrased from Wikipedia, the entries “Gantt chart”, “Diagramma di Gantt”, “Kanban (development)”, “Kanban” and “Work breakdown structure”, CC BY-SA 4.0, accessed on 29 October 2026.

Start from the WBS: a Gantt without a WBS orders activities without knowing whether they cover the whole scope. Then the Gantt, if dates matter and dependencies are known; the Kanban alongside it, if work arrives as a flow.

In EcosAgile: a project can have direct recording of actuals or “Phase / WBS Management”: groups, activities (Tasks) and milestones, with predecessor, budget in days and percentage of progress. Hours are recorded on the activities. With the WBS, the Gantt tab appears, with bars for activities and groups and a scale from day to year. The Gantt tab of Capacity by month and person also has Slack and Critical Path buttons and shows item, start date, owner, duration and total slack. Items (requests and backlog on a project) have a Kanban view with columns by status: it concerns items, not WBS activities. See the Project & Timesheet software page.

4. Timesheets: models, rules and approval workflow

A timesheet records the time spent on projects, job orders and activities; the model, daily, weekly or monthly, decides how often it is completed and submitted. The closer the recording is to the event, the more precise the data and the more discipline it requires; the further away it is, the more the last Thursday of the month turns into a reconstruction from emails. Whatever frequency is chosen, the data stays in order thanks to completion rules, reason codes, period locks and approval.

Three models compared

The table describes three methodological models and is an EcosAgile working model, not a standard; the pros and cons are our own assessments, not measurements.

Example with invented figures: in a month of 21 working days (168 hours), Marta works on two projects and on internal activities. Daily: on Thursday, 4 hours on A, 3 on B, 1 internal. Weekly, on Friday: 17 on A, 13 on B, 10 internal, 40 in all. Monthly, on the 28th: 70 on A, 60 on B, 38 internal, 168 in all. The totals match; what changes is the quality of the attribution and the moment at which the controller sees that B has already used up its budget.

The models can be combined: the research institute FBK, for example, recommends daily completion and closes by noon on the second working day of the following month (decision 09/2023). Our position: record every day or, at worst, every week, and submit at a fixed interval. A purely monthly timesheet holds up only when the data serves payroll and nothing else.

Four quality keys

• Completion rules: mandatory fields (project, activity, hours), units (decimal hours), when a note is needed. Few, and written down.
• Reason codes: few, each with a written meaning. Hours that cannot be attributed to a client go into an explicit line, so that they do not vanish from the total.
• Period locks: after submission the person does not edit; after approval it is reopened only with a trace; a closed project accepts no hours.
• Completeness: recorded hours are compared with expected hours (working time minus absences); the KPI is in Project and timesheet KPIs.

The workflow: employee, manager, controller, payroll

1. The person records the hours and submits by the deadline, with completeness checks.
2. The manager checks consistency with activities and budget, then approves or rejects with a reason.
3. Approved hours are frozen: corrections only through a traced reopening.
4. The controller uses the approved hours for costs, actuals and invoicing (economic control).
5. Payroll receives what it needs from the payroll process (integrations).

When a third party requires the timesheet

In programmes funded by the European Union, the rules change from call to call and are to be read in the call. For Horizon Europe, the Commission's annotated guide (version 2.0 of 1 April 2025, Article 20) allows a monthly declaration of equivalent days or another reliable system that records at least all the time worked on the action, with records signed at least monthly by the person working and by their supervisor (annotated guide; it is not the contract). For ERDF and ESF+, Article 55 of Regulation (EU) 2021/1060 allows, for staff working part-time on the operation, a fixed percentage of employment costs, stated in a document from the employer, without a separate hours-recording system. The rules of Italian programmes are checked by the controller.

The project timesheet attributes time to job orders and activities and does not automatically coincide with the measurement of working time, which has a different purpose: to use it for that purpose too, the requirements are checked with the consultants, starting from the guide to attendance tracking.

In EcosAgile: the timesheet is monthly, completed day by day (single entry or range) and also submitted mid-month. The statuses are Missing, In progress, Pending and Approved. The project manager approves the hours of their own project, or the team leader approves the whole timesheet, according to the logic chosen.

5. Job orders and economic models: Time & Material, Fixed Price, Turn Key

The economic model of a job order decides who pays for an overrun. In Time & Material the client pays the actual hours at agreed rates and the risk of extra costs falls mainly on the client; under a fixed price, lump sum or Turn Key, the fee is agreed in advance and every extra hour erodes the supplier's margin. The timesheet is needed in all cases, but for different purposes: in the first to invoice, in the others to know how much is being earned.

What distinguishes the three models

The three labels do not have uniform boundaries. In this guide, Fixed Price means a fixed fee for a defined scope; Turn Key the same fixed fee with, in addition, the supplier's responsibility for the complete and working result, at an agreed price and date. In the law of the works and services contract (appalto), “a corpo” (lump sum) and “a misura” (by measurement) have a meaning of their own, different from Time & Material: the contract is to be read by a lawyer.

The table is an EcosAgile working model, not a published standard: where sources are silent, the cell gives our own reading. On the allocation of risk see PMI, “Project contracts: vendor and buyer views” (2007); the rows on T&M and Turn Key are paraphrased from Wikipedia, the entries “Time and materials” and “Turnkey”, CC BY-SA 4.0, accessed on 29 October 2026.

Same job order, two contracts

Example with invented figures: a job order estimated at 100 days, selling rate €600 a day, standard cost €380 a day. At quotation the margin is €22,000 (36.7%). At actuals the days are 120, the cost €45,600. Under Time & Material the revenue rises to €72,000: margin €26,400, still 36.7%. Under Turn Key the revenue stays at €60,000: margin €14,400, 24.0%. The €12,000 difference is the revenue of 20 days that is not invoiced under Turn Key; the real cost of those days is €7,600 (20 × 380), and it is what brings the margin down from €22,000 to €14,400. With a change order at €600 a day for 15 days out of scope (€9,000), the margin returns to €23,400, or 33.9%. If instead, under Turn Key with no change order, 10 days were not recorded, the margin that shows rises to €18,200 (30.3%).

Under Time & Material an overrun does not affect the profit margin: the risk lies in the hours that the client disputes. Under Turn Key it all lies in the margin. Our position: a fixed price with no written scope and no planned change order is a gamble, and the timesheet is the tool that tells you each month how much of it you are losing. The margin while the work is under way is in Economic control, the formulas in Project and timesheet KPIs.

In EcosAgile: the project types are Turn Key (in the manuals “fixed-price or turnkey”, so both the Fixed Price and the Turn Key of the table, with revenue that accrues according to the percentage of progress), Time Material (revenue from selling rates per person or role), Recurring Fee (Canone), Ticket and Ticket-Hour Bank (Ticket-Monte Ore). The type governs the calculation of revenue: it is not a free classification. Hours on timesheets are recorded only on Time Material and Turn Key; for the other types the costs come from items or instalments.

In EcosAgile: on Turn Key projects, Change Orders can be recorded, that is, special revenues with scope, amount and status; for each project there are invoicing instalments with date, amount, phase and status (Planned, To invoice, Invoiced, Paid, Inactive). They serve to prepare and check invoicing data.

6. Project staffing: who works on what

Staffing a project means deciding which people work on which activities, in what role and for how long. The choice weighs together role, skills, availability in the period and cost, and is reviewed when the project changes. The word also has another sense, when it refers to an external partner supplying the team: here we are talking about assigning the company's own people to projects.

Who, how much and when

Staffing answers the question “who”; capacity answers “how much” and “when”. You start from the roles the plan requires (WBS and activities) and from the days the budget assigns to each, and only afterwards look for names. The expected cost of a person on a project is days multiplied by daily cost: with the person's own cost, changing the name changes the margin; with the standard cost of the role, it does not (economic control).

What to look at before assigning

• The role and skills the task requires, not the title on the org chart (skills).
• Hours not yet committed in the period, net of planned absences and other projects.
• The cost of the person or of the role.
• The effect on the person: overloading them or giving them tasks far from their skills harms both them and the project.

Who decides

The final name should not be left to the project manager alone. Someone who sees only one project will gladly assign the same good person to three projects at once, and none of the three plans shows it. The PM proposes; whoever sees everyone's workloads confirms, whether a resource manager or an HR contact. Every change of assignment leaves a dated trace, otherwise at the end of the project no one knows who did what. External people are brought in when, in the period, the group's remaining capacity does not cover the need and the skill cannot be built in time; cost and onboarding go into the budget.

From the EcosAgile webinar: in the EcosAgile webinar on people-centric HR processes, the speaker describes staffing as finding people with suitable skills, qualifications and experience and with unsaturated availability, for example five days next month and ten the month after; availability depends on working hours and planned absences (minute 03:03 (in Italian)). This is the speaker's position, not a standard.

In EcosAgile: the allocation links a person to a project with role, assignment date, release date, rate and budget days; without a release date it applies until the end of the project, and it refers to the project, not to the individual phase. Allocation can be made by group of people, which also takes in new hires, and a list shows people with no allocation. To record hours on a project, the person must be allocated. To find whom to assign, there is the “Resource Search” item of the Capacity plan menu, described in Skills-based project management; the view of workloads per person is described in Capacity planning.

7. Capacity planning: availability, saturation and workloads

Capacity planning compares the hours people can devote to projects with the hours the projects require, month by month. From the theoretical capacity of the calendar, public holidays and absences are deducted to give the net capacity; subtracting the work already allocated leaves the remainder. Saturation is the ratio of allocated hours to net capacity: it says how much a person is already committed, not how well they work.

The cascade, in five steps

1. Theoretical capacity: the Monday-to-Friday days of the month multiplied by the hours in the person's working-time profile. A part-timer at 4 hours a day has half of a full-timer at 8.
2. Public holidays: the hours of the holidays that fall in the month.
3. Absences: leave, time off, training already planned. What remains is the net capacity.
4. Allocated: hours planned on projects, plus a declared share for non-project work (meetings, support); if you leave it out, the remainder comes out larger than the real one.
5. Remainder: net capacity minus allocated.

Sources do not agree: some deduct public holidays and absences in a single step. Here there are two, because a public holiday is the same for everyone while an absence belongs to the person and sometimes moves. Formula adopted: saturation % = allocated hours ÷ net capacity × 100. The denominator is the net capacity, not the theoretical: leave and public holidays are not hours that anyone can assign. The utilisation rate (hours recorded over net available hours), with its variants, is in Project and timesheet KPIs.

Example with invented figures: a month of 22 Monday-to-Friday days, one of them a public holiday. Anna and Chiara are full-time (8 hours), Marco is part-time (4 hours). Anna has 3 days of leave, Marco 2 of time off, Chiara 1 of training. The team, on net capacity, is at 84.2%; on theoretical capacity it would seem to be at 72.7%. Same work, two figures: that is why the denominator must be written down.

What to read

Marco is over-allocated by 4 hours, and this cannot be seen from a single project: each of his two project managers asks him for 40 hours and no one adds them up. Look at capacity per person and per month, then move work, delay it or look for capacity elsewhere (shared resources). At the end of the month, compare the allocated hours with the timesheet hours: the distance measures the quality of the estimates, provided the timesheets are complete (timesheet). There is no threshold valid for everyone: online benchmarks (utilisation 70-85%) have no source or sample, and the useful comparison is with your own months, by role.

Headcount over several years is another level: workforce planning. Leave, time off and working-time profiles: attendance tracking.

From the EcosAgile webinar: in the webinar on people-centric HR processes, according to the speaker, capacity planning needs tasks and a WBS, but also leave, time off, work profiles and costs, and “fast and programmatic” recording of actuals (minute 03:03 (in Italian)). The speaker's position, not a standard.

In EcosAgile: the Capacity plan menu has three items: Resource Search, Capacity by month and person, and Capacity by month and org unit. Capacity by month and person has four tabs and filters for year, company, organisational unit, person, role and site; Planning and Gantt also have parameters of their own: Capacity plan, with Act/Plan, theoretical, absence and delta values for each person and month; Saturation, with capacity and saturation by month; Planning, with a grid by project, task, role and year, values from January to December, total, budget and delta, and the WBS status (Requested, Approved, Rejected, Inactive); Gantt, with the Slack and Critical Path buttons. Description taken from the screens of the development environment: availability in the version in use should be checked with EcosAgile. Act/Plan is the actuals from timesheets for past months and the planned figure for future ones, and depends on the completeness of the timesheets. Theoretical hours come from the working-time profile, which handles part-time and shifts. Leave and time off requested through ESS, once approved, end up in the timesheet. The saturation formula in this guide is a working model: before comparing figures, check the definition used by the Saturation tab.

8. Skills-based project management

A skills-based project chooses people also for what they can do, not just for their free hours. Each activity requires skills at a given level; each person has some of them; the remaining capacity says how much time there is. The choice lies in the intersection: who has the skill but not the time, who has the time but not the skill, and where it makes sense to pair up, train or look outside.

From task to skill

For each activity in the plan, write down what it requires, using a short scale: none, basic, independent, expert. Four levels defined in writing hold up; with ten, no one agrees on the difference between the sixth and the seventh. Data on people come from qualifications, certifications, training and experience. A declared skill that has never been verified weighs less than one confirmed by the line manager: the person who writes it and the person who confirms it are two different people, and it is worth saying so.

The skills-by-capacity matrix

The matrix is an EcosAgile working model, not a published standard; the scale of levels is our own proposal.

Example with invented figures, with the same three people as in capacity planning. The task: configure and test a data interface, 40 hours in the month. It requires data analysis at independent level and testing at basic level.

Possible solution: Anna 24 hours on the analysis, Chiara 16 hours on testing, 40 hours in all. Chiara is left with 24 hours of remainder, to use if needed to shadow Anna on the analysis and grow in that skill. Marco, the most experienced, is not touched: he is already over 100%.

Skill gaps and dependence on experts

The gap is closed through training or pairing when time allows; otherwise the skill is sought outside (selection and recruiting). A practical rule: every critical task has an expert and a shadow. Without this, the experts become saturated first, like Marco, and the project depends on two names.

What AI can do, and where it stops

A system can propose a ranked list of people for an activity; it remains a suggestion. The ranking is only as good as the profiles that feed it, and old or incomplete profiles produce wrong proposals with an air of precision. The project manager sees why a person is proposed, can reject them and answers for the choice; from time to time it is worth looking at who is always proposed and who never is. Data on skills are personal data: for privacy, the AI Act and human oversight see the section Privacy, GDPR and AI Act of the recruiting guide.

In EcosAgile: the “Resource Search” item of the Capacity plan menu looks for people based on requirements: type of assessment (for example self-assessment), year and month, role, minimum hours of availability in the year and one or more rows of area, category, skill and level of knowledge. The result is a list with a score, the matching skills and the hours available month by month against the planning on projects, with negative values highlighted; the search can be saved under a name. From the result you open the person's detail: skills with assessment, years of experience and last use, comparison with the skills expected for the role (radar), qualifications, CV, projects and allocation calendar; availability in hours has a legend from Excellent to None. Description taken from the screens of the development environment: availability in the version in use should be checked with EcosAgile. Data on skills are the subject of the Talent software.

9. Economic control: budget, actuals and margins

The economic control of a job order compares three pictures: the quotation (expected budget and margin), the actuals to date (hours, costs, revenue accrued) and the forecast at completion. What matters most is the margin at completion, because it says where the job order will close while there is still time to act. The margin to date alone does not say where the job order will close. Hours come from the timesheet, revenue from the type of job order.

From budget in days to cost

The budget starts as days by role and becomes cost through a daily cost. There are two routes: the standard cost of the role, the same for whoever fills it, or the cost of the individual person. For job order control, the standard cost is chosen: the margin does not depend on who did the work and individual costs do not circulate among project managers. The real cost is compared separately, in the accounts department; if the gap grows, the standard is reviewed. Hourly cost formula: KPIs.

Quotation, to date, at completion

Margin to date = revenue accrued minus costs incurred. Margin at completion = job order value minus costs incurred and costs still to be incurred. Margin delta = margin at completion minus quotation margin. The remaining cost is estimated by the project manager, role by role: if it stays as in the quotation, the margin at completion repeats the quotation and signals nothing.

Example with invented figures: a Turn Key job order worth €80,000, standard cost €350 a day, declared progress 50%. Quotation: 100 days and €5,000 of subcontracting. After four months: 62 days and €3,000 of subcontracting incurred; the project manager estimates 118 days in total and €6,000 of subcontracting.

EcosAgile working model, not a standard. Last column: plus = overrun of days and costs, minus = deterioration of the margin.

To date the margin is 38.3% against 50.0% in the quotation, but it is a partial value: it does not say where the job order closes. At completion the expected margin is €32,700, €7,300 less: 18 more days (€6,300) and €1,000 of subcontracting. This is the figure to bring to the job order meeting, with the cause alongside. If the invoiced instalments total €24,000, €16,000 of accrued revenue remains to be invoiced: two different figures.

Before trusting the figures

Actuals are only as good as the timesheet that feeds them: missing or unapproved hours push the margin up (the example is in Job orders and economic models), and the monthly closing of the timesheet comes before reading the margin.

The accounting treatment of work in progress, that is, how much revenue is recognised in the financial statements while the job order is open, is outside this guide: the method is agreed by the controller with the financial statements. Earned value is another way of reading the comparison between plan and actuals and requires a baseline: the value of the work done (EV), the actual cost (AC) and the planned value (PV) are compared. The cost variance is CV = EV − AC, the schedule variance SV = EV − PV; the indices are CPI = EV ÷ AC and SPI = EV ÷ PV, and the estimate at completion EAC = BAC ÷ CPI, where BAC is the total budget. PMI presents it as a useful method, not an obligation, including for small projects (PMI blog, 31 August 2026, accessed on 29 October 2026). For reference guidelines there is ISO 21508:2026 on earned value management, published in February 2026 in place of the 2018 edition; ISO 21512:2024 on implementation is still based on the 2018 edition (ISO 21508, ISO 21512); the texts of the standards are not free and this guide does not reproduce them.

In EcosAgile: the Business Model, before the project, estimates resources by role at standard cost and the revenue of services. In the project the budget is in days (8 hours) and cost is valued at the standard cost of the role, which is the default, or at the person's cost, chosen project by project.

In EcosAgile: Economics summary and detail show initial margin, margin to date and at completion, with delta and percentage. The data are updated every night (the previous day's position) and can be refreshed manually.

10. Project and timesheet KPIs

Project and timesheet KPIs are a few numbers, each with a formula, unit of measurement, frequency and an owner: people's utilisation, planned saturation, realisation, margin, variance of hours and costs, progress, hourly cost, timesheet timeliness. Sources do not define them in the same way, so the first step is to write down which definition is adopted. Below is that of this guide, with the variants and a worked example.

Where definitions differ from one source to another

• Utilisation. The denominator is, depending on the source, available hours, total hours or the sum of billable and non-billable hours. We adopt net available hours (theoretical minus public holidays and absences, the cascade is in Capacity planning), both for utilisation and for its billable version.
• Realisation. Three meanings: hours invoiced over hours worked; amount invoiced over amount at standard rate; amount collected over amount invoiced. We adopt the second, because it also works where the price is not per hour. The third is a collection rate and we call it that.
• Margin. Calculated on revenue. The mark-up, which divides by cost, gives a higher percentage on the same work and should not be confused with the profit margin.
• Variance. Actuals minus quotation, with a plus sign for an overrun. Earned value defines cost variance the other way round (earned value minus actual cost, plus = favourable): if the two methods are used in the same report, the sign must be declared in every column.

The KPI table

The table is an EcosAgile working model, not a published standard: the formulas, frequencies and owners adopted are proposals to be adapted.

Worked example: one person, one month

Example with invented figures: a month of 21 Monday-to-Friday days, 168 theoretical hours for a full-time person. Deduct 8 hours of public holidays and 16 of leave: net available hours 144. Hours recorded: 108 on projects with revenue and 12 on an internal training project; planned in the month: 130 hours. Utilisation: 120 / 144 = 83.3%. Billable utilisation: 108 / 144 = 75.0%. Planned saturation: 130 / 144 = 90.3%, remaining capacity 14 hours. With 168 hours as the denominator, billable utilisation would fall to 64.3%: same person, same month, a different number, which is why the definition must be written down.

“Healthy” values: why there are none here

Online there are circulating “right” or “healthy” ranges for utilisation and for margin, which vary from one page to another: for job order margin one finds both 25-40% and 55-75%, with different definitions of margin. The pages that report them state neither a sample nor the definition of the denominator, and we do not repeat them. The comparison that holds up is with your own previous periods, by role and type of job order, using the same definition; if the definition changes, the history is recalculated.

In EcosAgile: Actuals Analysis shows, by project and phase, available and remaining budget, days recorded, percentage of actuals and average planned and remaining FTE. Economics summary reports initial margin, margin to date and at completion; the Monthly Economics Analysis dashboard has tabs by project type, project, client and invoicing, the Timesheet Analysis one by month, people and clients, and the timesheet reports can be exported to XLS and CSV. The formulas in this section are a working model, not product fields: they are applied to the exported data or to the reports.

In EcosAgile: timesheet notifications are described in Workflow, mobile and collaboration.

11. Workflow, mobile and collaboration: ESS, MSS, reminders and approvals

Employee Self Service (ESS) is the space in which the person records their own hours, requests leave and time off and sees their own data; Manager Self Service (MSS) is the one in which the manager approves, checks progress and looks at the team's workloads. Mobile app, reminders and approval rules serve to shorten a single interval, the one between the work done and the approved data: every extra day is a day in which economic control works from memories.

ESS and MSS look at the same data

The separation of roles has a precise meaning: whoever enters does not approve, whoever approves does not edit. A manager who corrects a team member's hours by hand strips the data of its provenance, and sooner or later someone will ask who wrote it. It is better to reject with a reason and have the person who did the work correct it.

In EcosAgile: in ESS the monthly timesheet shows public holidays already valued and allows expenses to be entered and leave and time off to be requested from the same sheet. In MSS the manager sees ongoing projects, allocations, the check of resources' timesheets and the approvals of hours and expenses; you do not approve your own expenses, and the manager does not edit hours. For hours, the project manager approves those of their own project or the team leader approves the whole timesheet, according to the logic chosen (timesheet); a secondary approver can be named, in which case the approval of either one is enough.

Mobile: recording where you work

The app is for people who do not have a desk: consultants at the client's, technicians on business trips, anyone who spends the day between three sites. Recording on the spot avoids the Friday reconstruction. To be settled beforehand: if hours are written from the app and from the web, corrections must leave a trace in both cases.

In EcosAgile: the timesheet app allows work to be recorded on the move, choosing from the activities to which the person is allocated; the actuals entered from the app are recognisable in the timesheet and can be corrected from the “Work Recording (APP)” function.

Reminders and notifications: prompting the person who has the problem

A reminder that is the same for everyone is learned and ignored. Three moments work better, each addressed to whoever can act: at the start of the month to those who have not begun, at the deadline to those who have not submitted, after submission to the manager who has not approved.

In EcosAgile: there are three standard email notifications: completion absent or below 60% in the first part of the month, timesheet not submitted, timesheet submitted and not approved (to the manager). The company can modify or deactivate them.

Approvals: approving the exception

The risk is blanket approval, with “select all” and without looking. If the checks block obvious errors at submission (hours above the theoretical, empty days), the manager has time for what remains: a project that has already used up its budget, a new activity, an inconsistent absence. And if the approver is absent, the process must name their substitute before the deadline, not after.

From the EcosAgile webinar on people-centric HR processes: in the passage on time management beyond payroll, the speaker argues that a leave request must also reach the project managers and that the data should be entered once, not twice (payroll and projects) (minute 12:42 (in Italian)). This is the position of the EcosAgile speaker, paraphrased from the transcript, not a standard.

12. Integrating projects, HR, payroll, ERP and accounting

Integrating the project system with the others means deciding, data item by data item, which system is the owner and how it passes the data to the others, so that no one has to re-enter it. From HR come master records, absences and working-time profiles; from the project go out approved hours, job order costs and revenue; payroll receives attendance, absences and overtime; accounting, management control and BI receive job orders and actuals.

Which data, from whom, to whom

The table is an EcosAgile working model: the owner of each data item must be decided case by case, but there must be only one.

The exchange often breaks down on the job order code: accounts opens a new one, no one carries it over to the project, the hours end up on a wrong code or do not go through. What is needed is a mapping table, a log of exchanges and a person, with first name and surname, who looks at the rejected records.

Example with invented figures: at the end of the month the hours approved in the timesheet are 1,640 and those that reached management control 1,632. 8 hours are missing: the log of exchanges says they belong to a job order code not yet mapped, and the controller knows it before closing the month.

From the EcosAgile webinar on meal vouchers: an EcosAgile speaker explains that people record hours with job order and project detail and that meal vouchers are calculated on those same hours, even without going through attendance (minute 18:52 (in Italian)). It is an example of project actuals reused for another process: paraphrase of the speaker, not a standard.

Payroll, accounting and BI

What goes to payroll is not the project timesheet as it stands: it is attendance, absences and overtime in the format the payroll bureau accepts, and what counts is who checks the file before it is sent. Between the project and accounting or ERP pass job orders, cost centres, invoices and external costs, in one direction or the other. BI reads the actuals: the cleaner the codes upstream, the fewer pivots to reconcile by hand.

From the EcosAgile webinar on people-centric HR processes: according to the speaker, integration is needed above all on the processes with the most synergies, not on all of them, and open data that is interoperable through APIs is indispensable (minute 10:00 (in Italian)). Paraphrase from the transcript; on which data the APIs make available, ask EcosAgile.

Client case: NPO Torino replaced a recording system judged rigid with EcosAgile Project & Timesheet, starting from the Italian sites with the integration of attendance and absences into the group payroll, processed monthly; the system was subsequently extended to staff in the USA and Canada (case study (in Italian)).

Expense reports and project business travel

A project's expenses are a second flow: they must reach the job order and, if rechargeable to the client, enter invoicing. Reimbursement to the employee and business-travel rules remain in the guide to managing expense reports and business travel.

In EcosAgile: the payroll flow is in the Time module: from absences, attendance and overtime a scheduled job produces the file for the payroll bureau, downloadable via SFTP or from the “Payroll File Download” page. The manual lists export jobs for Zucchetti, TeamSystem and Essepaghe, as well as other formats. For master data there are APIs to insert and update projects, phases/WBS and clients, available in the API Library with accounts per module; timesheet reports can be exported to XLS and CSV.

13. More projects, more companies, more countries: portfolio and shared resources

When the same people work on several projects, it is not enough to know whether each one is on schedule: you have to decide which one gets the people when two claim them in the same month. Portfolio management is exactly this: a priority rule written before the conflict, a single view of shared people and, in groups with several companies or countries, clear rules on who bears the labour cost of whom.

Priorities and shared resources

The priority rule must be written when no one needs it. One possible criterion, to be adapted: first commitments with a deadline or penalty, then fixed-price job orders close to delivery, because their margin is the most exposed (Job orders and economic models), then time-based ones, and internal projects last. Without a rule, whoever calls first decides, and it is not always the project that matters most.

Within a single plan the conflict is not visible: each project manager has a sensible calendar, and it is the sum on the same person that overruns. Whoever arbitrates must see all the commitments of each person, month by month, against their net capacity (Capacity planning), not just the projects they follow.

The table is an EcosAgile working model, not a published standard.

More companies and more countries

In a group, a person from company A often works on a project sold by company B. The work goes to the project, the cost to whoever bears it, and the intragroup revenue must be removed when looking at the group, otherwise the same work counts twice.

Example with invented figures: B sells a project for €30,000. It is carried out by 10 days of B's people at €300 (cost 3,000) and 20 days of A's people at €350 (cost 7,000); A charges them to B at €500 a day, that is 10,000. For B the margin is 30,000 minus 13,000, that is 17,000 (56.7%); A is left with 3,000. For the group it is 30,000 minus 10,000, that is 20,000 (66.7%), the sum of 17,000 and 3,000. The intragroup charge is set by the controller and tax advisers.

With several countries, public holidays change, and therefore net capacity, as do local rules on working time, to be checked with those who know them. With different currencies, the controller sets the exchange rule first, and margins are compared afterwards. For headcount and organisational scenarios there is the guide on company org charts and workforce planning.

In EcosAgile: a project can be intercompany, with an external entity of the Intercompany type, and intragroup revenue is filtered out in the reports. A person from one company can work on a project of another; reports are filtered by company. Allocations can use groups of people, and there are the Current Allocations and People without Allocation views.

14. Documents, deliverables and project knowledge

Besides the work, a project produces three things: deliverables to hand over, documents that fix its terms (contract, order, variations) and knowledge that stays in people's heads until someone writes it down. All three need to be attached to the project and, when necessary, to the phase: a document whose job order is unknown has already stopped being useful. Signature and retention are another topic, covered on the Document & Signature page; here the project context is what matters.

Deliverables, versions and variations

A deliverable has a code, a title, an owner, the phase it belongs to and a client acceptance. For versions a minimum rule is enough: one current version only, recognisable by name or date; earlier ones remain available; it is known who approved what and when. The same applies to contract variations (Job orders and economic models): the signed variation sits next to the contract, not in an email from the client.

The table is an EcosAgile working model, not a published standard.

Knowledge and lessons learned

Closure (The end-to-end cycle) is the moment when knowledge is written down, because after that the team disbands. A short meeting with the team, and a six-field sheet: what happened, effect in hours or euro, cause, what to change, who needs it next time, where the document is. Numbers are not recounted from memory: they come from the comparison between planned and actual hours by phase (Economic control). Wrong estimates, with the gap, are the knowledge most reused in the next quotation.

History and access

History serves to understand how a figure was arrived at: who changed the budget, who reopened a timesheet, when an allocation was closed. Access follows roles: whoever works on the project sees the project documents, while the contract with its amounts is not for everyone.

In EcosAgile: the project has a Documents tab with two blocks: Knowledge management, for deliverables (code, title, material, attachment or link, phase, contacts), and Administrative Documents, for contracts and orders (name, attachment or link, entity, status). The Change Orders of Turn Key projects have date, scope, amount, status and documents. Changes to the project end up in a searchable history, and the system also records the submission and approval of timesheets, cancellations and changes to allocations. Items, that is, requests on a project, have Communications and Attachments tabs. Electronic signature and document management are the subject of the Document & Signature page.

15. How to choose project management and timesheet software

Project management and timesheet software is chosen by starting from your own way of working: what types of job order you sell, who enters the hours and with how much patience, what numbers control needs, which systems it must exchange data with. Before the demos, fix the essential criteria and the desirable ones, try the system on a real project and calculate the cost over several years, not just the subscription.

The author is a software vendor: read the criteria knowing that.

Start from the actuals, not from the Gantt: it looks good in a demo, but with wrong or late hours, margin and capacity are decoration. The criteria below put hours first.

Manual or integrated system

A spreadsheet and an email on Monday hold up as long as one person alone consolidates everything and the job orders are all of the same type. The limit comes with the first client who asks for detail or the first loss discovered at closing. If on the last Thursday of the month several people reconstruct the hours from their mail, you have passed it.

The table is an EcosAgile working model, not a published standard.

Checklist of 18 criteria

EcosAgile working model, not a standard. The division is a proposal: move the items according to your own model.

Essential (11)

• Real job order types (time-based, fixed price, recurring fee, ticket) with the revenue rule of each
• Job order, project and phases with budget
• Simple entry of hours for those who do it every day, including on the move
• Completeness checks and reminders
• Approval: who, when, how it is reopened
• Cost and revenue with declared rules (standard or actual, rates)
• Planned, actuals and margin in the same view
• External costs and rechargeable expenses on the job order
• Roles and permissions: who sees costs and margins
• Full export and exit from the system
• Cost over several years, not just the licence

Desirable (7)

• WBS and Gantt
• Capacity per person
• Skills and roles for assigning
• Integration with payroll, HR and accounting (files or API)
• Exportable reports, pivots and dashboards
• Multiple companies, languages and countries
• Set-up, training and support

Questions to ask in a demo (EcosAgile working list)

1. Bring a real job order and have the hours entered by the people who will actually enter them: count the steps.
2. Correct an approved timesheet: what happens, where a trace remains.
3. Margin to date and at completion of a fixed-price job order: with what formula and with data from when.
4. Test who sees costs and margins using the profile of a project manager and of a line manager.
5. Ask how data goes out and how payroll and accounting are connected: format, file or API, who maintains the link.
6. Get in writing what exists today, what is on request, what is planned.

The trial on a real project and the cost over time

Choose a project under way, two project managers and the controller, and write down beforehand what you want to see: correct hours, month-end closing without chasing, a margin equal to that in your spreadsheet. Explain every difference, even when the spreadsheet is right.

The cost is counted over several years: set-up and data migration, training, integrations, support, upgrades, exit. Staying where you are also counts: the hours of whoever consolidates the spreadsheets every month. There are no figures here.

Guide, product page and time-sheet.cloud

This guide explains method, formulas and criteria, valid even if you choose another product. The EcosAgile Project & Timesheet page describes the product. time-sheet.cloud is the website dedicated to the same product, to get to know it and request a demo.

In EcosAgile: the timesheet is monthly, with day-by-day entry, and is approved by the project manager or by the team leader. For each project the cost is the standard of the role or that of the person, and economics shows initial margin, margin to date and at completion, with data updated every night. For a comparison on one of your own projects: request a demo on your process or contact the team.

16. Frequently asked questions