DEV Community

loading...
Cover image for How to set up a transparent process with clients when building web applications
Foretheta

How to set up a transparent process with clients when building web applications

Yassine Tounsi
I am an accomplished Project Management Professional (PMP), with +10 years of experience in software engineering.
Originally published at foretheta.com Updated on ・3 min read

Despite its significant advantages, some companies are not aware of the importance of transparency in business and still operate as a black box. The clients of these companies don't know the exact progress of work, how many people are effectively working on the project, what blockers and discussions are going on along the implementation processes, etc. Dealing with such companies is similar to hiring a taxi at the airport with no registration or licensing, and the result is ending up being tricked.

Transparency means always telling the customer the truth and communicating the good news and the bad. However, informing the prospects about this value during the pitching process is not usually a good idea to convince since every company pretends to be transparent and perfect at all levels. At Foretheta, we decided to share our working process publically to contribute to the industry's shared knowledge and inspire others to find ways to improve their processes too.

In the first few emails and calls, the client specifies the requirements of the web application. Then, we break down the prominent features into stories or tasks that should be small enough to be estimated and assimilated by developers. When all these features are listed out, we request the client's review and confirmation.

Next, we estimate the complexity of tasks and verify whether the client's deadlines are realistic or not. Projects with impossible deadlines are not accepted because they are deemed to fail. Usually, web applications go from a few weeks to several months, depending on the number of features and their complexity.

When it comes to the cost, we explain clearly how much the assigned developers can do. At Foretheta, we share our team's velocity with clients. For example, when affecting a team with a sprint velocity of 50 story points and the client's features were estimated at 150 story points, we inform the client that three sprints are required to reach the defined scope.

At this stage, we send our quote, or statement of work, with three essential information: scope, cost, and timeline. We use google docs to make it easy to get comments and feedback. Same to contract, we send a gdoc file. Once reviewed and confirmed, we use HelloSign for signature.

Practical work starts with drafting the web pages in the Balsamiq mockup. Once approved, we provide a proper UI using Sketch. After getting the client's feedback and reaching the final version, we can start the sprint.

At Foretheta, we give clients access to Github. Sometimes, clients request that their work is done in their repositories. We have found Github to be the perfect tool to foster communication with clients and let them be aware of all issues, technical tasks, bugs, regressions, and change requests. Similar platforms, such as JIRA or GitLab, can also play the same role.

For the validation process, Forethata creates two branches: development and production. When the project manager verifies a feature, the latter notifies the client to verify the development's expected feature. Once validated, it will be pushed to the production branch. This way, the client will be sure about the quality of our delivery. This, of course, doesn't exclude the necessity and the importance of maintenance.

These are the things that have worked for us. Embracing transparency isn't easy. Letting the client see unfinished work can feel uncomfortable at first, but that transient discomfort will disappear as soon as good results show up.

Discussion (0)