A customisation is developing your own unique software
Very few people have ever embarked on a software development project before; so, it is important we explain how customisation projects work upfront.
 

1. We follow the modern industry standard - Agile
2. The Zeald process
3. We charge for all customisations at an hourly rate
4. Its impossible to predict everything upfront
5. Balancing features, budget & polish
6. Determine Minimum Viable Product (MVP)
7. Variations - You are buying time, not functionality
8. Bugs
9. Testing
10. Ongoing maintenance
11. Ongoing support
12. Platform updates and customisations
13. The customer representative

Famous analogy shows how software projects go wrong

1. We follow the modern industry standard - Agile

• Modern software development approach that has replaced the waterfall software development approach throughout most of the IT industry.
• Software is created in small, easily understood chunks.
• You continually evolve the specification - as we both learn more about how you want the software to work
• The budget, timeframe and scope are all flexible
• Agile software development has three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns

 

---

2. The Zeald customisation process

---

3. We charge for all customisations at an hourly rate

Customisations are quoted as a separate job from the production of your standard website.

• We provide a breakdown of the various components that make up a customisation: planning, design, build, testing, documentation
• We then work to that budget, delivering as many features as possible within that time.
• We provide a T&M (time & materials) estimate for how long we think it should take.
• We will let you know along the way how we are going with that budget.
• You are buying time, not functionality.
• You can help to keep your project on track.

 

---

4. Its impossible to predict everything upfront

When we scope a customisation, it is very difficult, if not impossible, for everyone to understand what is required at a concept stage. 
Building a custom piece of software is not like buying a product “off the shelf”.  We are building something new that has never existed in the world before.

It is impossible for us to predict everything upfront and estimate how long it will take to do something no-one has ever done before.
  

So why don't we quote 43% more?

• Because, with discipline, most clients can stay within budget.  
• Adding every feature and every piece of “polish” you can think of will always make a customisation go over budget - no matter what the budget. 
• Instead, we find it is better to iteratively deliver, ensuring a working solution within the budget.  But if you want far more than that, it will obviously take more money.  We never quote a figure that won’t build a viable solution to your requirements.

 

---

5. Balancing features, budget & polish

Where do you sit on the project management triangle?

The more time we spend planning, designing, building and testing, the better the finished result will be.
But the more polish and features we add, the more cost we add.

You can’t have all three sides “Polish”, “Budget” and “Features of the project management triangle.  ie. to achieve a low budget & polish, you’ll need to compromise features.

It’s often difficult for people to know where they sit on the triangle, most people want all three things.  Zeald generally quotes based on a compromise of all three that we think is most appropriate for your budget.  

We generally estimate based on a compromise of features and polish that we think is most appropriate for your budget. 

Project’s go over budget when we design a minimal, low-budget solution to fit a small-medium business, but as the project evolves, the requirements and level of polish exceed that solution.

 

 

 

---

6. Minimum viable product (MVP)

We break your project into features and prioritise them. The most important at the top and least important at the bottom.  The most important features  with the most important being the minimum viable product (MVP) which has just the features we need to deploy, and no more.

Once you have a MVP, you will have a better understanding of which extra features are the most important. After releasing an MVP, you look to continually improve it with the features that will deliver the most value - this iterative process may well go on forever.

backlog (most important features on top, least at the bottom)
So the time they "brought" will get features on the back log done, but the more time we soent on the MVP features (polish time), the least of the bottom features we will complete if the budget isnt flexible
 

What features do you really need?

The 80:20 rule. In typical software systems 64% of features are never or rarely used in reality.  Only 20% are commonly used.

 

 

 

Good design is as little design as possible - Less, but better

Because it concentrates on the essential aspects and the products are not burdened with non-essentials

Dieter Rams German industrial designer

---

7. Variations - You are buying time, not functionality

We follow the modern industry standard for developing software known as the agile software development approach. This means that as the project develops, it is expected and normal, for requirements, or at least everyone’s understanding of them, to change. With the agile software development approach, the specification is continually evolving as we both learn more about how you want the software to work.

We will discuss any variations with you. If a variation is deemed to be a “must have” we will provide an estimate and seek your acceptance before proceeding.
The most important features are prioritised at the top of the to-do list and the least important are backlogged.
You can choose to invest more time polishing the MVP features or use it to complete more features on the backlog or top up the budget to acheive both.

With agile the budget, timeframe and scope need to be flexible.

---

8. Bugs

• A bug is not a mistake or an error - it is simply what happens when anyone develops software
• All developers write code with bugs, no matter their skill or care taken
• Bugfixing is an expected and necessary part of the software development process
• To write 1000 lines of code, you *will* write 15-50 bugs

We will endeavour to help you reserve at least 20% of your budget for finding and fixing these issues.

You make the call on each bug as to whether it is a high priority.  Consider return on investment when prioritising what bugs you want to fix with your budget

---

9. Testing

• Alpha & beta releases
• You maybe familiar with the alpha and beta release process that Google and Apple follow to test their products.
• Alpha release - Shortly after development your customisation is ready for testing by developers, your nominated customer rep, and maybe a few selected employees or friends/family members. The aim is to search and destroy bugs. 
• Beta release - This is "real world" testing using customers, sometimes just a limited number, to gain feedback about all aspects of the product. Bug fixes/modifications are made where necessary.
• You should not organsie a mass promotion before the software has been pressure tested with a few select customers.
•  
• We will perform an appropriate level of testing, based on your budget to try to find and eliminate bugs before release
• 50% can be detected during testing in a cost effective manner
• It’s generally not cost-effective to try to detect more than that, as it becomes progressively harder to detect each bug.  
• A significant number of bugs will be found after the customisation is delivered.
• Best practice website management involves ongoing testing. You should test the website and customisation when it is delivered and ongoing. 

• ie. There are 200 different browsers, and we could spend hours testing on each - in reality, it is only cost effective for Zeald to test only the most popular.
• We encourage you to reserve at least 20% of your budget for the bugfixing phase of your project.

---

10. Ongoing maintenance

• Your own customisation, is your very own custom software and so you are responsible for paying for the maintenance and bugfixing yourself.
• You could pay for these costs as a monthly retainer, but since bugs usually happen rarely, it is more fair for you to pay for them on a flexible time and materials (T&M) basis if or when they arise.
• If you require more advanced support, bug fixing, questions; we can provide support and ongoing training if required on T&M basis via our technical projects team.
• Bugs will continue to surface in any customisation forever, such as
  • Changes with external technology IE. web browsers, devices or third party software connections.
  • The way you use the customisation may change, exposing weaknesses that weren’t previously apparent during initial testing.
  • Other customisations or changes to the website may conflict with your existing customisation - eg redesigns or upgrades to your website will often require changes to your customisation.  
  • In all such cases you will need to pay to fix these bugs if you deem it to be cost-effective and necessary to do so.
  • The cost is difficult to estimate and depends on how complex and large your project is. Most of this occurs in the first year after release

 

---

11. Documentation & support

• Budget is required for documentation
• Documentation provides a reference for how your software works and how to operate it now and into the future
• We can provide support for your customisation, bug fixing, and training on time & materials basis
• Good documentation will save you customisation support and training costs
• Support for customisations is charged on a T&M basis.

 

---

12. The "customer rep"

• You have the business interests in mind for your project to ensure that value is delivered back to your business
• You are responsible for identifying features and prioritising these throughout the development
• Projects flounder with lack of input and alignment with business needs
• In Agile there is only one person who serves as the Customer rep and has the final authority
• You also need to  commit a lot of your own time
   

You  work closely with our team of specialists

Developing custom websites is a complex business. It requires an expert team of specialists not a single jack-of-all-trades. So as the project gets into more detail, be ready for things to change and to work closely with different people.
All customisations within Zeald are produced by our customisations department.  The customisation project will be managed as a separate project to the production of your standard website

---

13. Platform updates & customisations

• In order to remain secure, your website platform software needs to be kept up to date.  Unfortunately, these updates can break customisations without notice.  Restoring a backup and withholding updates can be a temporary fix, however this isn’t safe in the long term.  We can provide you an estimate on request to update your customisation to work with the new platform.
• With the ZEST the platform is more secure. We will often "disconnect" a custom function  from the base platform to ensure that future platform upgrades do not break your customisation.

 

---

Learn more

Please read and understand the Zeald Terms of Trade. particularly sections: 3. Project Changes & 4. Testing & Bug Fixing
If you would like we would be happy to explain this process to you in further detail

If you ever have reason to question whether we are meeting our promises, we want to know, so please contact us as soon as possible.