Building a Timesheet system

It is no secret that I like working with php so I started this project with the idea of building a Timesheet system using Laravel 11. I quickly stumbled into issues where some of those new features in Laravel 11, features that are supposed to optimise the developers experience, actually just slowed me down. This is a me problem.

I still wanted to build the Timesheet system because I enjoy building new things and a Timesheet system is one of those systems that might seem simple on the surface, but the more you think about it, the more complexity can be added. In fact, this notion of adding complexity makes this a great project to think about, not only because we need to build functionality but also because we need to avoid building too much functionality as the first version of any product doesn’t need to be the best possible version it can be, so we need to find that balance between need and nice to have.

Complexity

A timesheet system needs to record the hours a person does or does not work, that bit is the simple bit. But who is the person, what type of work did they do, who is going to verify that work (who can verify that the person did the work) and how do we add these people to the system in the first place.

I think you can probably see how the complexity builds up.

Minimum Viable Product

The minimum viable product is a way to reduce complexity by focusing on the essential features, rather than building an overly complex product. So whilst we could sit down and think of every possible use case for this brand new timesheet system, we should instead focus on the essential features, get the product in the hands of some users and solicit feedback, we can use that feedback to add new features after the product hits some form of production environment.

Timesheet System Overview

We’re going to plan a relatively simple Timesheet system, an application that a small company may use to manage staff timesheets. We could also consider how this might integrate with other applications within an organisation, such as a HR system or Holiday planner, etc, but that would be future release kind of stuff and well beyond the scope of this project.

To clarify, this blog post isn’t about building the system, more the pre-build or more specifically, the planning stage. Before we can plan the project, we should first consider what we’re trying to build.

Purpose

A web-based system that allows organisations to track employee work hours, manage timesheets, and handle approvals efficiently. The system should be able to replace any manual timesheet processes with an automated workflow.

Key User Roles

We can imagine several different types of users, there will be team-members, team-managers and probably some kind of admin role.

Admin Users

• Manage staff accounts and permissions
• Create and manage time codes
• Override timesheet approvals when needed
• System configuration and maintenance

Managers

• Review and approve team timesheets
• Manage their team members
• View team reports and summaries
• Handle timesheet rejections with feedback

Team Members

• Submit weekly timesheets
• Track time against various projects/codes
• View their timesheet history
• Respond to rejection feedback

Key Benefits

We could consider building the business case as offering the following points;

1. Efficiency

   • Automated workflows
   • Reduced administrative burden
   • Quick approval process
   • Clear audit trail

2. Accuracy

   • Standardised time tracking
   • Validated entries
   • Proper record keeping
   • Error reduction

3. Visibility

   • Real-time tracking
   • Resource utilisation
   • Project time allocation
   • Management insights

Success Metrics

Projects are how we introduce Change into an organisation. Introducing change for the sake of it is never going to make you very popular and would usually not be approved by a budget holder, so along with a robust business case you would also be expected to describe what success looks like and how you might measure that success.

• Reduced processing time
• Improved accuracy
• User adoption rate
• Timely submissions
• Manager satisfaction
• Reporting capabilities

Core Features

Whilst we want to avoid complexity where possible, we should also aim to build some flexibility in from the begining, a timesheet might be as simple as ‘Worked 8 hours’, but it might be more complex in order to track individual projects etc. For example, a team-member might need to track time against a specific project or a specific client, etc.

However as builders of the system, it is not our role to consider every possible scenario, an easier way to allow for complexity without actually building complexity would be to allow the admin account(s) to define the complexity within the system. So a lot of our focus will be on enabling the system admin(s) to define the levels of complexity they require. I believe that is the easier path to take and should avoid something as heavy as a complete re-write for future revisions.

That said, we should set some MVP goals, something that might not work for everyone but will allow us to get a system out there and give the end users an opportunity to use and then provide feedback on what they’d like to change or what they’d like more control over.

Timesheet Management

1. Weekly Timesheets

   Not all companies will work Monday to Friday and not all will consider Monday to be the first day of the week, but we need to start somewhere:

   • Monday to Sunday format
   • Multiple entries per day
   • Save drafts or submit for approval
   • Comments for each time entry

2. Time Codes

   We can think of some simple time codes such as:

   • Project work
   • Vacation time
   • Sick leave
   • Training hours
   • Administrative tasks

   But actually a better way to manage this is to build a time code management element into our first version, deciding how complicated the administrator wants to make tracking time codes is their problem.

Approval Workflow

1. Submission Process

   • Staff submits completed timesheet
   • Manager receives notification
   • 24-hour review window
   • Automatic escalation if needed

2. Review Process

   • Manager reviews entries
   • Can approve or reject
   • Must provide feedback for rejections
   • Approved timesheets are locked

User Management

The admin is going to need to create users, we would want the timesheet administrator to be able to do this rather than calling in the developer everytime they have a change in staff or project code etc.

1. Account Setup

   • Admin creates user accounts
   • First-time login password setup
   • Role assignment
   • Team/manager allocation

2. Access Control

   • Role-based permissions
   • Active/inactive status
   • Manager-staff relationships
   • Ex-staff data retention

Staff / Manager relationship

Most organisations are hierarchical but this is rarely just one pyramid, it is usually a pyramid of pyramids. The company or organisation is divided into Divisions, the Divisions are divided into Departments, the Departments are divided into Teams:

This is one of those areas where we need to be careful, we cannot build a timesheet system that meets all organisation types and shapes but we can try to build some flexibility into the system to allow the administrator to define the structure as they go along.

For my version, I will aim for a system that divides staff into Teams, a Team can have a Manager and a Team can exist in a Department, but doesn’t have to. If there is a Department, then the Department will also likely need a Manager.

A flatter organisation wouldn’t need to define all of those teams and departments, my proposed system allows the administrator to decide how to structure teams etc.

Timescales

If I run all of that through a Project Plan, I’d be expecting a few weeks worth of work, but in reality, for the purposes of this series of blog posts, I won’t spend too much time on the pretty stuff, we’ll just aim for functionality.

Like all Project Plans, this will be a living document, we may need to come and revise scope etc as we move through the project.

Epic, Sprint, Story

I’m going to use a simple story planner for my application, I normally use GitHub Projects for things like this but today, I’ll use AirTable, it probably wont make it any quicker to be honest, but I just like to use different tools every now and then to see how they’ve changed and to make sure I still know how to do something with it.

So I’m going to make a high level plan, I’ll base it around sprints and define the stories within those sprints, I’ll then prioritise the stories in an individual sprint depending on when I’m working through them.

Having a plan gives me a way to keep focus on what I want to deliver, avoid getting lost in adding functionality I never planned for and divide the work up into related functionality.

Now I apologise to the Scrum purists out there, I am using some of your terminology but I am not using in the way you might normally expect me to, but heck, this is my project, I’m the only one working on it, so I’ll do it my way.

Epic

My Epics will be the 3 main phases, although I don’t plan to deliver much beyond phase 2 to be honest, well certainly not at the time of writing this. An Epic will contain a number of Sprints.

Sprint

The Sprints will be based on similar functionality and contain multiple Stories.

Story

The Stories may contain multiple steps within, but they each deliver a something. My Stories start at number 22 for some reason, not sure why, but this is a reason to revisit tools you’ve used before as I probably knew how to reset that counter the last time I used AirTable but now I can’t remember and also don’t really care.

Future Enhancements

I think this will be beyond the scope of this series of posts, but we can imagine features that might add further value:

Phase 2

• Leave management
• Holiday tracking
• Sick day monitoring
• Basic reporting

Phase 3

• Advanced reporting
• Payroll integration
• Project analytics
• Resource planning

In Closing

So that’s the project description, a little about how I will manage my project and where we might take this in the future.

The following articles in this series won’t take you through the entire build because I haven’t figured out how to tell that story without making my blog posts huge to be perfectly honest. So the posts will be about elements in the timesheet system and how we might go about building those elements.