Projects tend to vary for each client but the process goes as follows:
- I’ll send you an invoice for a 50% down-payment to cover for the start-up costs.
- You’ll receive log-in details to our project collaboration site. This will show some initial project time-scales and check-lists of what needs to be done.
- We’ll schedule your work as soon as we receive your down-payment remittance.
From experience with many other projects, I now generally do not specify timescales for the stages in the initial work agreement or invoice. There are several reasons for this:
- For the majority of projects, the original timescales end up changing part way into the work. The reasons vary, such as a change of focus, new ideas for features and as is often the case with start-ups, an evolution in the business priorities.
- The stages themselves are not fixed and sometimes we end up running them concurrently, starting early or delaying them.
Instead, we work towards some broad milestones that are set by our clients. The milestones are set on our project collaboration site and are adjusted depending on how the project evolves.
Testing is another area where we differ slightly from some other web companies.
In my opinion, the best people to test the site are the clients themselves; you know better than anyone else how you expect things to work. We’re then guided by your observations.
This process helps keep our fee low because I don’t need to hire dedicated testers or get expensive programmers to do the job. It also skips the time intensive (and expensive) test specification documentation what would be necessary if we were to perform the tests thoroughly.
Testing is therefore more of a collaborative process with you.
For us, testing starts very early on in the project. The usual procedure many web companies follow is to give access to the site towards the end of the development process, only when things are ‘ready’ for the client to view.
I believe that it helps to let you loose on it early on because it gives you a realistic expectation of how things are going all the way through our work together. It also gives you a chance to ask questions and steer things in the right direction while we develop the site.
Because of the above, I find that specifying a testing period in the contract usually isn’t very flexible.
It’s also quite difficult to stick to the period specified. For many clients, the website, while important, isn’t the only thing they must deal with in their business. In my experience, things nearly always come up that prevents them from dealing with the task during the allocated time.
For example, let’s take a client’s suggestion of a testing period of two days after delivery. I find what happens in practical terms is that if I deliver, say, on Monday, the client would have a meeting on the Tuesday, then a series of calls for Wednesday and so on. Thus the testing period expired but the client was still unable to even look at the site.
Again, this is another reason why we actually start the testing process near the beginning of the project.
Of course, if you prefer to have the period specified in the contract, we can do our best to meet it but with the caveat that things might not turn out that way.