Chapter 3: To perform project monitoring

Project monitoring is a critical phase in software development project management, ensuring that planned objectives are met within the allocated budget and timeframe. In Kenya's dynamic tech industry, where startups and established firms alike face intense competition and resource constraints, effective monitoring safeguards project viability and stakeholder confidence. Among the key aspects of monitoring is tracking project costs, which helps prevent budget overruns and enables timely corrective actions. This chapter focuses on the principles and practical steps for tracking costs in software development projects, alongside the tools commonly employed in Kenyan firms.

3.1 Tracking Project costs

Tracking project costs means recording what the project actually spends, comparing it with the approved budget and acting when the two drift apart. In a software project a large share of the money goes on developer time, with the rest on cloud hosting, software licences, test devices and training, so a small overrun in one line can use up the contingency quickly. Regular tracking shows an overspend while it is still small enough to correct, and it gives the client and the sponsor figures they can trust.

3.1.1 Steps to Track Costs

Cost tracking follows a fixed cycle: fix the budget, record spending, compare, forecast, report and, when needed, correct. The team should agree at the start how often the cycle runs, which is weekly, every two weeks or monthly, and which measures it will watch. The measures usually include actual cost, cost variance and the cost performance index. Short cycles catch problems early but take more effort, so small projects often review weekly and larger ones monthly.

3.1.1.1 Set a baseline budget

The baseline budget is the approved budget, split by cost category and by time period, against which all later spending is measured. Without it there is nothing to compare actual costs with. Example: a software studio building an inventory app for a wholesale shop splits its budget into developer salaries, cloud hosting, software licences, test devices and training, and spreads each line across the months of the project.

• Cost categories: list personnel, licences, hardware, hosting, training and contingency separately so a variance can be traced to its cause.
• Time phasing: show how much is expected to be spent in each week or month, so that a mid-project check has a planned figure to use.
• Contingency: keep the contingency fund as its own line, and release it only through an approved change.
• Approval: the sponsor and the client sign the budget, and from then on it changes only through change control.
• Version control: store the baseline in one shared file or tool and keep old versions, so everyone compares against the same figures.

3.1.1.2 Record actual expenses

Actual expenses are the amounts really spent or committed, recorded as they happen and in the same categories as the baseline. Late or incomplete records make every later step unreliable. Example: a freelance team records developer hours from weekly timesheets, cloud charges from the monthly hosting bill and a test phone bought on a receipt, each under its own cost code.

• Timesheets: developers log hours against project tasks, and the hours are multiplied by the agreed hourly cost.
• Invoices and receipts: supplier invoices for licences, hosting and equipment are entered once and checked against the purchase order.
• Purchase orders: an order is recorded as a commitment when it is raised, so money already promised is not mistaken for money available.
• Cost codes: each entry carries the project and category code of the baseline, which allows exact comparison.
• Single record: all entries go into one spreadsheet or accounting tool, never into several personal files.
• Timing: entries are made at least weekly and checked by someone other than the person who entered them.

3.1.1.3 Compare planned vs. actual costs

Comparing planned and actual costs means calculating the variance, which is the planned figure minus the actual figure, for each category and for the whole project. A negative variance is an overspend and a positive variance is a saving. Variance as a percentage of the planned cost shows how serious the difference is.

Worked example: a web agency building an online booking system for a safari lodge compares the first three months with the baseline.

Calculation of the total: planned 450,000 + 60,000 + 80,000 + 40,000 + 30,000 = 660,000. Actual 480,000 + 54,000 + 80,000 + 52,000 + 25,000 = 691,000. Variance = 660,000 − 691,000 = −31,000, and −31,000 ÷ 660,000 × 100 = −4.70%.

The project is 4.70% over budget. The largest percentage problem is test devices (−30.00%), while the largest amount is developer salaries (−30,000). The team should find out why each happened before deciding on action.

3.1.1.4 Use Earned Value Management

Earned Value Management (EVM) measures cost performance against the work actually completed, not against the calendar. Comparing spending with the plan alone can mislead: a team that has spent less than planned may simply be behind on the work. EVM uses three values:

• Planned value (PV): the budgeted cost of the work that should have been finished by the status date.
• Earned value (EV): the budgeted cost of the work that has actually been finished.
• Actual cost (AC): the money actually spent on the work done so far.

The cost measures are:

• Cost variance: CV = EV − AC (negative means over budget)
• Cost performance index: CPI = EV ÷ AC (below 1 means over budget, above 1 means under budget)
• Estimate at completion: EAC = BAC ÷ CPI, where BAC is the budget at completion
• Estimate to complete: ETC = EAC − AC
• Variance at completion: VAC = BAC − EAC

Worked example: a software team building a delivery tracking app for a courier firm has a BAC of Ksh 1,200,000. At the status date its PV is Ksh 600,000, its EV is Ksh 540,000 (45% of the work is done) and its AC is Ksh 630,000.

• CV = 540,000 − 630,000 = −90,000
• CPI = 540,000 ÷ 630,000 = 0.857, so each shilling spent has produced about 0.86 shillings of planned value
• EAC = 1,200,000 ÷ 0.857142 = 1,400,000
• ETC = 1,400,000 − 630,000 = 770,000
• VAC = 1,200,000 − 1,400,000 = −200,000

If the present cost performance continues, the project will finish Ksh 200,000 over budget, and the manager has to act now. The schedule measures of EVM, which compare EV with PV, are used when tracking progress against the project plan.

3.1.1.5 Report cost status

A cost status report tells the sponsor, the client and the team how much has been spent, how this compares with the baseline and what is expected next. A good report is short, uses the same categories as the budget and leads with the figures that matter.

• Current position: the planned, earned and actual cost to date, with the cost variance and CPI.
• Forecast: the estimate at completion and the expected variance at completion.
• Causes: the reasons for the main variances, in plain words.
• Actions: the corrective actions proposed or already taken, and who owns them.
• Decisions needed: any approval the sponsor must give, such as a change to the budget or the scope.
• Format and timing: a one-page summary with a simple table or chart, sent on the agreed day of each cycle.

Corrective actions when costs exceed the budget

When the figures show an overrun, the project manager chooses from a few standard responses and records the choice. Options include reducing the scope by moving non-essential features to a later release, renegotiating supplier or hosting contracts, reassigning developers to the tasks that matter most, and using the contingency fund through change control. Example: a software house that finds its cloud bill running above plan may move test servers to a cheaper plan and switch them off outside working hours.

3.1.2 Tools for Tracking Costs

Cost tracking tools differ in cost, in how much work they remove and in how well they connect to the schedule. The choice depends on the size of the project and the skills of the team.

• Microsoft Excel: flexible and affordable, it lets a project manager build cost sheets with formulas that calculate variances and draw charts. It suits small teams and start-ups.
• Microsoft Project: it combines scheduling and cost, so costs can be assigned to tasks and resources, budget use monitored and expenses forecast. It suits larger software projects.
• QuickBooks: it joins invoicing, expense tracking and financial reporting, which helps a consultancy that runs several client projects at once.
• Jira with Tempo: the add-on records time spent on issues and converts it into cost figures, so agile teams see the cost of each sprint.
• Trello with cost Power-Ups: a simple board with cost fields suits freelancers and very small teams.

Whatever the tool, entries must be accurate and reviewed regularly, and linking the tool to purchasing and payroll records improves reliability.

Chapter Summary

This chapter focused on the essential practices for effective project monitoring to ensure successful project delivery. It began with tracking project costs, outlining steps such as setting a baseline budget, recording actual expenses, comparing planned versus actual costs, applying Earned Value Management, and reporting cost status, supported by various tracking tools. The discussion then moved to monitoring project deliverables and objectives, emphasizing the importance of defining key deliverables, establishing a monitoring schedule, tracking progress against the project plan, using performance indicators, reporting to stakeholders, and adhering to ISO quality standards. Monitoring project team performance was addressed next, highlighting systematic steps to evaluate and improve team output. The chapter also covered assessing project risks through identifying potential risks, evaluating their impact and probability, prioritizing them, and conducting SWOT analysis. Different types of risks were classified, including technical, schedule, budget, and resource risks. Finally, strategies for managing project risks were presented, detailing the steps needed to mitigate or respond effectively to identified risks throughout the project lifecycle.