This is where the consultant and the client discuss the basic aim of the project and take notes on ideas that could make it into the project.
In this stage the consultant will organise the areas for the project in the form of diagrams that highlight the separate functionalities.
Technical Design Specification
This is where the consultant will gather the technical requirements in order to complete the project, this needs to be signed of by the client but can have baffling technical jargon. This should be accompanied with mock-ups of the interface and diagrams. The client does now need to know everything that is mentioned, just a check to see if what is spec’d out matches the basic idea for the project.
Customer Approval and amendments
The customer will then approve of the project, and highlight any missing features from the specification.
As this is a specification for the core (must haves) of the project, any ‘nice to have’ features can be pushed to a future iterative milestone (i.e. not in beta 1 but in beta 2). The milestone is can be scheduled for is based on the importance of the feature and is up to the client. It is important for the customer to know how to schedule the features, if it’s just a “nice to know” and implementing it took a significant amount of time at the beginning of the project then this is now good; those features should be schedules for a milestone where some feature could be dropped if time constraints become an issue or a better feature is naturally implemented in earlier stages of development.
This is the stage where the consultant will convert his vision into a working application, it is important to keep the features to a minimum for the prototype, but there must all be working as would be expected. Once the prototype is shown to the customer it should be stressed that it is not indicative of a milestone. This prototype is to give the client a better picture of the project and give him the chance to alter any features or move feature to different milestone or find usability issues that may need solutions to.
At this stage the customer has pointed out added changes to be put into the first milestone and once that is done user input can only after future milestones. This can be useful when the development is handled by a team of programmers and a project manager. New features can then be organised into a future milestone without interrupting the flow of the developer.
Features should be organised so that the next task to do is the next logical step in the list, so that client changes have less on an impact on completed tasks.
If a milestone takes a significant amount of time, there should be regular meetings with the client in order to reappoint features and tasks to another milestone or to make sure the customer requirements are still the same.
It is important to have a signoff of the next milestone and to start again from secure ground. once the customer is happy with the progress of the first milestone. further requirements can be gather before the next stage is taken up by the developer.
The client can be wrong or may make changes to designs at any moment, that is why it is important to gather as many requirements as possible and then organise the tasks into relevancy, that way you are still working on everything the client says but you are prioritising things and giving them time needed in order to make further changes to features or to realise the certain feature may not be needed any more due to natural feature being implemented in the application previously in the development process.