BookingLive are a professional booking system development agency and we understand the importance of planning a project well whilst maintaining a strong relationship with the client.
We are fortunate to have an experienced and dedicated team. Combined with realistic objectives, this ensures a project runs smoothly. I will however now make a bold statement: Estimates are always wrong.
Unless we agree a small timeframe and a small scope, a technical project such as a booking system, is almost never completed within the original number of hours estimated.
Why? Essentially it comes down to scope creep and a client not knowing exactly what they want, often until they see it. Similarly, our technical team at BookingLive often won't know exactly how they will deliver the requirements until they are deeply immersed in the booking system development.
From a client's perspective, you need an idea of how much a booking system will cost, so you can make decisions about ROI and compare against other suppliers. You also want a vision of the project deliverables, how it will look and feel and whether it will meet the business requirements. I have yet to meet a client who appreciates agile software development (to allocate a set budget and work through requirements until the budget runs out) but have met many clients who exude pressure to deliver a quality booking system within scope, on time and as cost-effectively as possible. This is known as the triple constraint and in most projects, the client should expect to sacrifice one of those 3.
From BookingLive's perspective, clients instinctively say “we expect everything we talked about at the beginning” which can create a very stressful situation for all involved. This is why more often at BookingLive, we propose an upfront scoping process before agreeing the exact scope, time and cost for the booking system.
Nowadays, if the client doesn't buy an 'off the shelf system', we only commit to a project when a fixed scope and budget has been agreed, and the client understands there needs to be contingency for when out of scope change requests occur. And they will occur.
A fixed scope, with the appropriate technical documentation, supporting wireframes and existing booking system development for reference, gives a sense of security and helps manage risk. With IT projects notorious for going over budget (BBC Click recently reported 4 in 5 IT projects go 200% over budget), we feel our booking system development process works for both client and supplier and helps prevent this.
As the leading sales manager within our organisation, I often receive new enquiries like this:
Client: ‘I want a booking system’
Me: ‘Okay, what type of booking system do you need?’
Client: ‘Something like ticketmaster or airbnb but better.’
Me: ‘That won't be possible unless you have a long timeframe and a large budget.’
Client: ‘My new website is coming soon so I need it asap and you will get paid when I sell tickets.’
This is an extreme example but I’m sure you get the idea. When we receive a new enquiry with an undefined scope, we actively encourage clients to come back when they have clearly defined requirements. Without this, we cannot estimate and provide a quotation. To help this process we've prepared a scope analysis template and a scope requirements template to help you create a requirements document.
Our expertise is online booking systems and we only take on such projects. And if the business requirements are well defined, we can make good estimates and assumptions. Even so, there will always be ambiguity in projects of any kind. I have experienced clients providing 150-page specifications, thinking this would give accuracy and clarity, only to have it fall over on day one, when some basic assumption is proven incorrect.
Both client and supplier need to agree on one thing: an estimate is a baseline to start a project, based on information and risks we understand on day one. On day two, it will change and will continue to change until the project is complete.
As a client, the best you can do is:
If you can work openly and honestly with our team, keeping an eye on the original goal, then you will have a successful delivery.
Thank you for reading this post. If you wish to understand more about how our process works, please contact your account director.
In this post I take great inspiration from Diana Hennessy at Silverstripe who has worked in many diverse roles including project management, business and marketing.
We are fortunate to have an experienced and dedicated team. Combined with realistic objectives, this ensures a project runs smoothly. I will however now make a bold statement: Estimates are always wrong.
Unless we agree a small timeframe and a small scope, a technical project such as a booking system, is almost never completed within the original number of hours estimated.
Why? Essentially it comes down to scope creep and a client not knowing exactly what they want, often until they see it. Similarly, our technical team at BookingLive often won't know exactly how they will deliver the requirements until they are deeply immersed in the booking system development.
From a client's perspective, you need an idea of how much a booking system will cost, so you can make decisions about ROI and compare against other suppliers. You also want a vision of the project deliverables, how it will look and feel and whether it will meet the business requirements. I have yet to meet a client who appreciates agile software development (to allocate a set budget and work through requirements until the budget runs out) but have met many clients who exude pressure to deliver a quality booking system within scope, on time and as cost-effectively as possible. This is known as the triple constraint and in most projects, the client should expect to sacrifice one of those 3.
From BookingLive's perspective, clients instinctively say “we expect everything we talked about at the beginning” which can create a very stressful situation for all involved. This is why more often at BookingLive, we propose an upfront scoping process before agreeing the exact scope, time and cost for the booking system.
Nowadays, if the client doesn't buy an 'off the shelf system', we only commit to a project when a fixed scope and budget has been agreed, and the client understands there needs to be contingency for when out of scope change requests occur. And they will occur.
A fixed scope, with the appropriate technical documentation, supporting wireframes and existing booking system development for reference, gives a sense of security and helps manage risk. With IT projects notorious for going over budget (BBC Click recently reported 4 in 5 IT projects go 200% over budget), we feel our booking system development process works for both client and supplier and helps prevent this.
What should a client do?
As the leading sales manager within our organisation, I often receive new enquiries like this:
Client: ‘I want a booking system’
Me: ‘Okay, what type of booking system do you need?’
Client: ‘Something like ticketmaster or airbnb but better.’
Me: ‘That won't be possible unless you have a long timeframe and a large budget.’
Client: ‘My new website is coming soon so I need it asap and you will get paid when I sell tickets.’
This is an extreme example but I’m sure you get the idea. When we receive a new enquiry with an undefined scope, we actively encourage clients to come back when they have clearly defined requirements. Without this, we cannot estimate and provide a quotation. To help this process we've prepared a scope analysis template and a scope requirements template to help you create a requirements document.
Our expertise is online booking systems and we only take on such projects. And if the business requirements are well defined, we can make good estimates and assumptions. Even so, there will always be ambiguity in projects of any kind. I have experienced clients providing 150-page specifications, thinking this would give accuracy and clarity, only to have it fall over on day one, when some basic assumption is proven incorrect.
Both client and supplier need to agree on one thing: an estimate is a baseline to start a project, based on information and risks we understand on day one. On day two, it will change and will continue to change until the project is complete.
As a client, the best you can do is:
- Provide a detailed requirements specification
- Listen to us - we are the experts afterall
- Identify potential risk change and continually mitigate that risk
- Have a contingency plan/budget for scope creep
- Be honest and maintain trust with your client/supplier relationship
If you can work openly and honestly with our team, keeping an eye on the original goal, then you will have a successful delivery.
Thank you for reading this post. If you wish to understand more about how our process works, please contact your account director.
In this post I take great inspiration from Diana Hennessy at Silverstripe who has worked in many diverse roles including project management, business and marketing.