Whether you are working on a small website for a friend or a large application for a company, setting the right boundaries and expectations with regards to both parties involved, is critical to building and maintaining a good relationship with your client.
The following is a walkthrough on a non-exhaustive list of processes and practices to keep in mind during each step of the project development life cycle. The emphasis of this guide revolves around the earlier stages, when most of the communication with the client is being done.
Part I discusses the first stage of the cycle. It is written from the point of view of a freelance web-developer but most notions also apply to freelance UX/UI designers, working at a company or even working on an internal project
Generally speaking there are 5 phases:
Analyse
Design
Development
Testing/Quality Assurance
Deployment
(*The steps above are based on the standard development life cycle methodology (SDLC). Choosing the most suitable project management methodology can be a tricky one and depends on many variables such as the scope and complexity of the project, the client or working in a team. Depending on the context of the project, other project management methodologies such as Agile or Kanban may be required).
Outline a clear strategy
When you embark on a new project with any client, outlining a clear strategy going forward is paramount to your relation with the client as it establishes the direction and momentum of the entire project. The very first meeting with the client should entail a general overview of the project development cycle, explaining why each step is important and what is to be expected. By doing so you let the client know there is a flow and it makes you look professional.
“When you embark on a new project with any client, outlining a clear strategy going forward is paramount to your relation with the client as it establishes the direction and momentum of the entire project.”
Get Creative, putting pen to paper
The first step when building a website is not to write code but to talk about the discovery process. This means putting pen to paper with the client and writing down every idea and inspiration that comes to mind. It is like a brainstorm session where you throw everything out in the open, the good ideas and bad ones. It can be astonishing sometimes how companies do not know what they want, so make sure you cover this base well with the client.
You then relay back the gathered information with the client during a creative brief in a following session, defining the scope of work more in depth.
Getting input from all parties involved
In this early stage, it is the moment for everybody to speak up and get on board, especially if dealing with a bigger project when multiple parties are involved.
It could happen, for example, that the product owner asks the opinion of the head of different departments when the application is in development. Maybe someone from marketing is being showcased the application at the latest stage, and says “Why don’t we build in more social media authentication features?” You then find yourself stuck in a peculiar situation, having to choose between two bad options: letting the client know that the demands cannot be met because of the required deadline, or making the difficult position of going back to the drawing board to add those features, which costs time, money and might also mess up the core code structure. Whatever the reasoning of your decision may be, neither scenario really accomplishes the needs of your client. You do not want to reorganise databases down the road if it can be avoided.
Even if you are the only person involved in the project, you still want to get all the ideas on paper along with appropriate timelines so that everyone knows what is on the table.
Getting input from all parties involved
“When you embark on a new project with any client, outlining a clear strategy going forward is paramount to your relation with the client as it establishes the direction and momentum of the entire project.”
The scope of work is the heart of the analyse phase and the place where you put everything in writing and make it official. The right moment to discuss the scope of work is usually at the end of the analyse phase or at the beginning of the design process, when everybody agrees to continue with the project.
Its main function serves to clarify what is expected of the deliverables as well as the communication strategy it should be aligned with. And just as important, is to clarify what is not to be expected. Maybe some features that the client wanted are just not plausible within the required timeframe.
Let’s say for example that the client wanted to tie in some API (means Application Programming Interface for those among us that are not developers:)) that you did not see coming. Now you can point out the fact that it falls outside the scope of work and so you do not have to exclude yourself from the project.
See the scope of work as a collection of facts that preferably is put in to a contract, stating what the amount of work entails, the features to be built, the technology stack you are going to use and the informational architecture of the website. It should also include an instalment plan of timelines with regards to when certain features are going to be released and how to get paid.
Be specific but apt in your description on how you are going to accomplish those features. For example, what elements the homepage needs or how you are planning on integrating an external API onto a webpage. This way you are making sure that both parties know what it technically takes to build the project.
Knowing what to do ahead of time puts everyone in the right frame of mind and makes a GOOD web developer into a GREAT web developer because you come across as more organised and in the end will get you happier clients and increase your clientele.
“Knowing what to do ahead of time puts everyone in the right frame of mind and makes a good web developer into a great web developer because you come across as more organised.”
Be clear about your pricing
The pricing of the project, be it at a fixed hourly fee or rate based on the project, is the elephant in the room and depends on what features are going to be built. Not all features are created equal and if you do not know this upfront and set the price accordingly, chances are there will be a misunderstanding in the pricing of your work later on. As mentioned earlier, that is why you should put your pricing and an instalment plan in writing and that any additional features beyond what is required are going to cost extra. No payment? Well then good sir, I withhold myself to deploy the server live without payment, Believe me, it is amazing how all of a sudden this can create a cashflow for you get to paid.
