Updated: 2024/03/21 to include example requirements.
If you’re considering going to market for a timesheet, leave, award interpretation solution (or any software really), we hope the following will help.
All the councils we work with say the same thing: Tender processes can be time and resource-expensive. Which leads us to this, because time is something we care about a lot at elementTIME.
Here is a list of 8 things councils we have worked with tell us would have or did help make their tender process as efficient and effective as possible.
Regardless of your procurement processes or the solutions you are looking for, we hope the following will save you time if you are considering going to market for an awesome time sheeting, award interpretation, leave and workforce reporting solution – or any software solution at all.
Actually though before you read this if there is just one thing you are going to spend time on – Talk to other Councils using solutions and not just about the software they selected but the process they went through. They might have great ideas for avoiding pain in your procurement journey.
Note: This is not intended to be advice for your procurement process but should fit in with any procurement process to help make it less painful and more likely to have the best possible outcome for your council. Talk to your procurement officer/governance team to ensure you understand and align with your procurement requirements.
1. Establish the ‘what’s‘
Of course, everyone says the ‘what’ is important. There is a reason they do.
Before you do anything, define what the actual problems are and what you want to solve.
To start with this may just be you figuring out a problem statement. Don’t worry about getting it perfect but do figure it out. If you can’t do this then the process should be dead in the water. You don’t need a project team or a tender process if you don’t have a problem or drivers.
If you do have a problem then work out what it is quickly in a sentence or two. Be clear but don’t worry too much about getting caught in the weeds. The point of this step is to have something you can refer back to which helps keep the rest of the process on track. This will also ensure that the right outcomes are met to solve the problem
For example, saying “We need an award interpreter” is not anywhere near as helpful or accurate to providing a reference point for the rest of the project if the problem is actually:
“We spend too long manually inputting timesheets and related data, no one can see what is happening and we have inconsistent information all over the place. Our managers have no accountability and there is no transparency in our payroll business. Plus our payroll officers get up at 3 am on payday just to make sure the bank file will be on time.”
Work out what are the drivers and why you need to solve this problem.
We call them drivers but you can call them whatever you want. Drivers are what is probably causing you to read this in the first place. They may be as simple as, “Governance says we need more controls over the higher duty and excess time process to ensure managers are accountable and the process is transparent”, or the CEO stating, “I want online timesheets. I don’t care about anything else”, or finance saying “We are missing $1.6 million of plant costing in the last financial year.”
In the case of the above examples your drivers may be:
- We need to free up our staff time to be proactive, not rekeying data
- We need our process for submitting, approving, timesheets, excess time, and leave to be transparent with clear accountable workflows
- We need real-time visibility of all workflows
- We need entitlements to be automatically calculated
- We need to see accurate plant costing
- We need integration with our payroll and related systems
Whatever your drivers are, you need to make sure they are clear. They will be the key expectations you need to ensure are met by the solution selected at the end of the process.
See what we have done here? We now know what we need the tender to cover (our problem) and what outcomes we need to provide for (which will become our core requirements).
Why is this important?
Having a clear problem and understanding the drivers is critical. As well as helping clarify if you even need to go to tender, this will help keep you on task when you start down the process of putting together your project team and tender documents.
For the project team this is as simple as helping identify who you might need to involve in your project team. For example, if the problem involves rates billing you will probably want to include a finance revenue person at some point.
For the actual tender process, this helps ensure you cover off requirements that actually will help solve your problem and avoid tender inflation (where the scope of the tender inflates to a grab bag of items – more on this later), it also helps you with your evaluation and outcome stage review.
Common pitfall
Don’t feel like you need to overcook this stage. You should be concise and clear but also not perfect as you will nail this down in point three. Most importantly, don’t forget to be honest. If the main driver is because the CEO wants it or internal governance needs it, then those CEO wants or internal governance needs should become your priority requirements.
If you go through the whole process and don’t meet the drivers because you weren’t upfront about including them, then the project will be unlikely to succeed without changes to budget and/or time. Which is never fun.
Handy hint
If your driver is a CEO or Governance, get them to confirm this step once you have completed it but before you continue, this helps ensure they are aligned with what they asked for and what you are using for your foundation problem.
2. Establish the ‘who’
Work out who is involved internally and the role they are expected to play in the process.
Whether it’s as a subject matter expert helping with your requirement gathering or the person leading the project, create a list of who you need and why.
We recommend being very clear on what they will be required to contribute and the stages and time commitments they will have. Discuss this with them and ensure they can commit upfront. If they can’t or don’t have support to be involved, then find someone else or work on options to support them so they can be involved without needing to juggle priorities.
We find it is better to ensure the staff you need to involve are supported to meet the requirements for their involvement in the project through carving out dedicated time or backfilling their other tasks, in some cases being inventive with additional duties and secondments. By planning and being clear, you may also find staff are more likely to meet the deadlines and pay proper attention to their part(s) in the project ensuring a better quality outcome for council.
Why is this important?
Feedback suggests it is often the same staff members that get asked to be involved in processes. These are staff who are already over capacity and high performing. As such, relying on staff who have to fit their role in the tender process in with everything else sets the process up for delay at best, and bad outcomes and failure at worst. Staff may miss key details or feedback as they rush over content, or even cause meetings to be postponed if they are expected to fit their involvement with the process in with day-to-day and other demands.
All this can feed together creating delays, frustration, and gaps which in turn create more delays, frustration, and gaps, and so on. It seems many projects fall over at this stage or attempts are made to bring them back on track through engaging external resources, adding cost, time, and complexity to the project: see common pitfall below.
Common pitfall
It can be tempting to mitigate this risk by engaging outside resources to take the place of internal staff in a process. While this can work in some roles, ensure outside resources are put in the right role and the right controls are in place to incentivise efficient and effective involvement.
Getting this wrong can lead to a lack of ownership internally, increased costs, discontent with the outcome, and even delays in the process. This can have a long tail impacting the project far beyond the initial tender process.
Handy hint
If you allow staff to track the time they spend involved with the project and review that against your plan you will start to create solid data-based metrics for planning other tender projects and estimating the resource requirements. A quick aside: Awesome time sheeting software can help you do this.
3. Ruthlessly define the need
Look, we get it. Tender processes are costly and time intensive so it is easy to want to go as wide as possible in scope, not to mention that is just the nature of high achievers, right? Let’s solve everything! Unfortunately, councils tell us when it comes to tenders, this can be a case of less is better.
Use the problem and drivers you identified in step 1 to define your actual needs. Make them as tight and aligned to your problem and drivers as possible.
Use this alignment to define the ‘musts’.
This is not the grab bag or additional nice-to-haves, these are the things that ‘must’ exist in your selected solution for the tender to be successful – that is solve the problem(s) you identified and deliver the outcomes required by your drivers.
Ensure these are crystal clear and not open to interpretation. These become your go/no-go items in your tender requirements or, in tender speak, your conforming/nonconforming items.
We do this with our projects internally and we call this process establishing our measures of success (or MoS). For each ‘must’ we describe what success would look like. This allows us to challenge why a ‘must’ is a must and define what the ‘must’ must do. That is a lot of musts, right? But trust us, putting a little bit of extra time in here will make it so much easier.
So, unlike the paragraph above, be clear with your must items and even explain why they are your must items and your measures of success if you use them.
Separate them and put them up-front so people deciding to respond to your tender know if they should put the time in or not – the ‘musts’ ‘must’ be present.
Once you have the musts out of the way, define the other requirements. These might be standard (e.g., uses MS Graph for syncing leave requests to Outlook and SharePoint lists), or specific (e.g., provides for integrated higher duties and additional duties requests).
The other requests should be rounding out and adding value to the product, but should not be endless and they shouldn’t stretch the scope so far to cause a distraction. For example, if your problem and drivers are very deep around payroll, then stretching your requirements to cover recruitment and staff onboarding might create alternative priorities later in the process and cause the focus to shift to outcomes that do not address the problems and drivers you listed.
Why is this important?
As they say, “Not all requirements are a must, but the musts are musts”. This seems easy, but mixing this up can make evaluation and first rounds hard.
Establishing very clear in and out criteria means there is a clear gate allowing responses to get past the next step. It allows clarity to respondents as well – they won’t waste time responding or trying to convince you they meet your ‘musts’.
The broader your requirements the more time and analysis have to go into trade-offs, and the less time you and the team will have during the evaluation rounds to explore the functionality that is most important to you.
Common pitfall
Assuming the solution needed to solve a requirement. For example, ‘Solution must have OCR functionality to read data from timesheet and allow integration file to be produced for manual upload of timesheet data’. Yes, it does mean you won’t need to key the data, but it also might mean alternative ways to solve the problem that add more value are excluded.
We have come up with a common list of requirements we think provide a great start for looking for any online timesheet, leave, workforce award interpreter. You can download it here…<link to excel>
Handy hint
A great approach we worked with was where rather than defining what was needed for other requirements, the council requested a brief explanation of how the solution would provide for a required outcome. For example, ‘Our users need the ability to view who is scheduled to work on a particular day and also see who is away on leave. How can your solution meet this need?’
4. Ground-truth your requirements
Once you have your problem, drivers, and requirements defined, it’s time to utilise that awesome project team you have pulled together. Get them to test the requirements and match them to your problem and drivers. Build out and ground-truth your list items to ensure that if the requirements are met, the solution will meet your drivers, solve your problems, and provide maximum value (aka just generally be awesome).
Make sure your project team also reviews the list to include any areas that are important to their functional areas to ensure compliance requirements such as record management, system security, and finance will be met.
Even though you have your own drivers and problems to solve, don’t overlook standard organisation requirements or assessments against guiding policies such as strategic information technology plans. Ensure these are factored in.
Why is this important?
This is what your successful respondent will be using as their scope for their agreement with you. If you overlook or make assumptions that the respondent will understand what you meant even though you didn’t clearly state it, then you may find your respondent claiming out-of-scope changes. This may impact your budget and timelines.
Common pitfall
It can be really easy to fast-track this, get everything down, and then move on, especially as you will have multiple stakeholders providing input.
We once worked with a council that went to tender for a mobile permit and ticketing solution, only they never actually mentioned anything about mobility in the requirements. They just assumed the respondents would know. Worse, it was never brought up in the evaluations or demo stages. It was only after the decision was made that the requirement was made clear to the successful vendor who then promptly stated council would need to agree to a variation and relevant costs.
Handy hint
Identify other councils that have gone through a similar process or are using solutions already and talk to them. Ask them what they wish they had considered but missed and what lessons they learned. They may also provide context that can be used when assessing respondents allowing you to ask the hard questions, for example, “You say you could do this but XX says this was not able to be achieved. Please explain.” Most councils will be happy to share their experiences.
Additional resource: Time+Attendance+Award+Interpretation+Requirements
5. Lock in a timeline and stick to it
A tender process is effort, and all that effort is opportunity cost. If you don’t need a solution you shouldn’t have got this far, right? So let’s assume you do. The fact you have gone to tender should make it a priority.
This means taking the time to map out your timeline is important. Ensure you are realistic but also timely.
Map out the key gates: Requirements prepared > Tender docs finalised > Tender response window > Assessment > Shortlist interviews > Checks and balances, etc.
Ensure they are clear and have transparent go/no-go criteria for the gates, along with all preceding activities spelled out. Decide on your escalation path and options if ‘no-go’ decisions are made.
Why is this important?
Delaying, pushing out timelines, or dropping and then picking up a process again later sends the wrong signals internally and can be frustrating to all stakeholders, including your respondents.
If you have asked for staff to prioritise their time with assisting the project only to not provide an outcome, it can imply their time is not valuable, making it harder to engage in future projects.
Common pitfall
Failing to assess the tender timelines against other council pressures such as ERP upgrades, staff time off can cause stress on meeting key gates. Ensure these are also identified and planned. Your project team will have other pressures on their time, so be fair and reasonable in setting your goals alongside their other priorities.
Handy hint
If you do need to delay project gates, then communicate early including what the delay means, not only for that gate but for the rest of the project timeline. If you can be upfront about the reason (even if it is down to a planning oversight), if you are honest about the reason (and lets face it most people will know even if you don’t tell them) this will ensure people continue to trust the process and the transparency of the decisions being made.
6. Do some market work first
Before putting in too much time, do some work to ensure your cost estimates are current.
Use this to ensure the project doesn’t suffer from sticker shock when the responses come in and ensure you already have expectations agreed on budget. There is nothing worse than finding you will need to delay or even abandon the project because the responses have come in and the council is not prepared to meet the project budget required.
Why is this important?
The cost needs to be budgeted for. If the council does not have budget, then spending the time to get right through the process is not going to change that. Spend the time and effort you would spend on the tender process on something else (like an awesome business case that will get you budget).
Common pitfall
Missing this step and misaligning expectations on cost so the project is unlikely to be able to go ahead without finding more money is going to be no one’s idea of a good time. Unfortunately, sometimes there is a gap between business case research and tenders. Business cases can also focus on the OPEX cost and not account for related project costs such as implementation, integration, change management, and other items.
Handy hint
Wrap this up when talking to other councils. What did they spend? Were there any unexpected costs they didn’t account for upfront? Were they able to stay within budget and if not why and what was the impact? Answers to these questions will help you plan and understand possible budget implications you will need to plan for or consider.
7. Don’t judge based on volume or number of words. Focus on the relevance
Cut through the noise. Look for responses that are clear and concise.
Tenders are part of the machine but they shouldn’t be the machine. Many tender responses go for quantity rather than quality by relying on boilerplate and AI templates that can be recycled response after response.
While these are valid and part of the process, paying attention to responses that are clearly put together just for your tender may also help indicate whether the respondent is going to provide a solution for you, or fit you into a solution they already have.
Why is this important?
We could cover a whole article with thoughts on how procurement could adjust to focus on outcomes for the council rather than outcomes for the tender, and maybe we will do just that. In the meantime, consider this: Would you rather a company put effort into building a response from the ground up that is brief and to the point but obviously pulled together directly for you, or pages and pages of information that could be used for one of hundreds of responses? Neither view is right or wrong, but probably allows some insight into where a respondent puts their priorities.
Pitfalls
It can be easy to judge that brief responses are a sign of little effort. However, what should be assessed is the relevance. Whether concise or wordy, the relevance to your request is the important thing.
8 – Track and review
Once your process is over, hopefully, you won’t be going out to market for a similar solution any time soon. But that doesn’t mean there are no opportunities for learning.
Whatever your process and the decision, take time to review the process and what worked at the end of it. Share it with other parts of the organisation who might be preparing to go through a process.
This will of course make it easier to help other councils when they reach out and ask you for your thoughts on solving their timesheet, leave, and award interpretation solutions.