Introduction

The client came to us with a request to create a system for their sales team. This system had several requirements, including a Know Your Customer (KYC) process, automated report generation, a purchasing system for products with multiple payment options, a commissions system with various payout options, an internal FAQ and downloads section, an internal ticketing system for customer support, and a monthly reward system, among other features. When we asked about the release date, they emphasized the urgency.

To address this, we initiated a discovery phase to clarify the requirements. As we delved deeper into the project, we encountered a number of challenges:

1. Tight Deadline — The client wanted the web app to be launched as soon as possible to start generating revenue.
2. MVP Focus — We recognized the importance of prioritizing the most essential aspects of the system and gaining a solid understanding of the user base and the overall business case.
3. Uncertainty — We had a strong sense that we would encounter unexpected changes as the project progressed.

Armed with this information, we proceeded to create a project timeline.

‍

Timeline

To ensure everyone on the team had a clear understanding of our goals, we decided to break the project into four phases:

1. Phase 0 (Design): In this initial design phase, we began creating the system’s design right away. We worked on it screen by screen, and as soon as the client confirmed a design, we proceeded to program it.
2. Phase 1 (MVP): The primary aim of this phase was to develop a functional system that would allow the sales team to start selling the client’s products as quickly as possible.
3. Phase 2 (Important Features): This phase focused on enhancing the existing system with detailed reports, a finalized dashboard, and the ability to switch between languages (English and German).
4. Phase 3 (“Candy stuff”): The objective of this phase was to incorporate ticketing functionality, improve the system to enable admin to upload documents, introduce a support user role, and address various minor functionalities.

‍

‍

Phase 0: Design

In the design phase, we initially inquired with the client about their preferences, including their desired colors and overall visual style. However, as is often the case in projects like this, we received limited input from the client.

In the absence of specific design guidelines, the client had provided only a logo. To address this, we took the logo as a starting point and developed a color theme for the project based on it. We then crafted a sample page to showcase our design direction, seeking the client’s confirmation before advancing to the subsequent stages of the design process.

The comment from our lead designer regarding the challenges:

In a platform designed for both end users and application administrators, it is important to find a balance in the design that drinks the water for both types of users. The platform has a unified design, with certain segments hidden according to the type of user. A scalable design system had to be developed to facilitate a more unified design and development.

Once we had v1 in place, all new features were then re-designed and developed relatively quickly as elements and components were reused. For the experience itself, the focus was on showing users the most important things and actions where they expect them. The overview of the figures needed to be easy and quick to access, and the focus was on the look of the tables, which we made easy to read.

‍

‍

Once the look & feel were confirmed we proceeded with designing each individual screen of the app. First was the registration process, followed by the home screen, then commissions, purchase of products, etc.

The work process for each Feature (screen) was:

1. Specification preparation
2. Design
3. Confirmation of design
4. Develop the feature

‍

‍

This process allowed us to deliver small, but complete increments of the system that delivered value to the project (and users).

‍

Phase 1: MVP Development

In parallel with the design preparation in Phase 0, we initiated the backend work and began working on the delivery of the MVP by writing the first lines of code. This involved configuring and setting up both the server and the development environment.

Once this setup was complete, we proceeded with the development of individual screens. We had multiple developers working on the project, and for each sprint, we created smaller tickets that needed to be completed.

Our development team operated in a self-managed manner, with developers taking ownership of individual tickets independently. Throughout the sprint, we utilized a ‘Kanban’ board to monitor the progress of our work. In situations like this, the question often arises: what kind of board setup should the team use? I’ll now explain what worked for us and the reasons behind our choice.

1. To Do: This column contained all the tickets that needed to be completed during the sprint. It served as the sprint backlog, outlining all the tasks that had to be accomplished.
2. In Progress: When a developer decided to start working on a ticket, they moved it to the “In Progress” column. We intentionally limited the number of tickets that could be worked on simultaneously to six. This restriction provided better clarity on the ongoing tasks and what was not being actively worked on.
3. Blocked: If a ticket lacked necessary information or faced any obstacles preventing progress, developers moved it to the “Blocked” status. It was the responsibility of the Project Manager to address these issues and take the necessary steps to resolve them.
4. Ready for QA: Tickets in this column were ready to be reviewed by the Quality Assurance (QA) specialist. The QA specialist checked this column twice daily to ensure that items were moving smoothly through the Kanban board.
5. QA Approved: After the QA specialist was satisfied with how a feature functioned and confirmed that it met our Definition of Done, they moved the ticket to the “QA Approved” column. For larger features, the Project Manager also conducted a review and had to approve or reject them.
6. Done on DEV: Once the Project Manager approved a ticket, it was moved to the “Done on DEV” column. This indicated that the feature was ready for production. At this stage, we also invited the client to test the feature and provide their approval for it to go live.
7. Done on Master: When a ticket was successfully released to production, it was moved to the “Done on Master” column, marking the task as closed and completed.

‍

‍

Certainly, while this approach was a good fit for our project, it doesn't necessarily mean it's the right fit for your project. However, it serves as a real-life example of what proved effective for us.

Our process was functioning well, and we simply continued to adhere to our development priorities and make incremental improvements to the product every two weeks.

‍

Phase 2: Important features

Phase 1 was successfully completed within the initially agreed-upon timeline. However, as we moved into the next phase, new requirements emerged, and the order of priorities shifted. In situations like these, it’s crucial to provide the client with a clear view of their options and when they can expect each feature to be delivered, allowing them to determine the priority order. You may assist them in this process by employing techniques such as RICE or MoSCoW.

To achieve this, we established a “Feature Priority Sheet” that we regularly reviewed every two weeks with the client. They had the authority to adjust the order of feature implementation as needed. While this led to multiple changes in the plan, it enhanced transparency in the project and empowered the client to decide the timeline for feature completion. Meanwhile, our team remained adaptable, accommodating changes every two to three days

In terms of feature development, we continued to work on several planned features. We began implementing multi-language support to cater to both English and German-speaking users, responding to user needs. Additionally, we introduced a News functionality, enabling the Admin to upload various news updates related to their system and activities. Furthermore, on the Dashboard, we incorporated a graph that visually represented a requested dataset.

‍

‍

The last item in phase 2 were reports, which is a page with a table where data for each individual day is displayed and explained.

Another important point to highlight is that we regularly released a change log at the end of each sprint. This change log was shared in the same Google Sheets document as the “Feature Priority Sheet,” and it was accessible to all project stakeholders.

‍

Phase 3: ‘Candy stuff’

In the “Candy Stuff” phase, we focused on the non-essential elements of the project that aimed to enhance the platform. One notable example is the ticketing system. Prior to its integration, customer inquiries were managed through phone calls and emails, which didn’t provide the best customer experience but allowed customers to communicate with the company. Additionally, reports were essential to provide users with a comprehensive overview of their data and assess the overall performance of their structure.

In this phase, we introduced additional functionalities such as the Downloads section, which empowered the admin to upload pertinent documents to the system for user access. We also implemented a FAQs section to address common user questions.

‍

‍

During this phase, we added a new feature: a pop-up for Admin users to easily add new FAQ questions. By this point, the system had been operational for several months, allowing us to identify the challenges customers were facing and make targeted improvements.

Our ultimate goal was to achieve full development completion, enabling the system to operate seamlessly without our ongoing involvement, and we successfully achieved this objective.

‍

Conclusion - why were we successful?

In conclusion, I want to emphasize the key factors that, in my view, contributed to the success of this project:

• Transparency — We were clear with the client about what we can do and what we could not do (at least in the given timeframe). It’s important to say NO and explain in detail why — and what we suggest.
• Goals — When working on something, promote a team discussion about what you are actually trying to accomplish. All involved parties should understand the concept and objectives at hand, which enables them to make better decisions.
• Keep it simple— We tried to keep things as simple as possible. Focus on what thing at a time, and ensure the goal (and expectations) are clear to the whole team. We had 2 weeks sprints, to go one step at a time.
• Visualise — We used FigJam do draw things while explaining. I believe this makes information less abstract and easier to understand (especially in a commission-based system). It also promotes discussion and even helps raise additional questions to identify potential edge cases.
• Retrospectives — Make time for them. Explain to the team what makes them essential and why they should actively participate. We held them every sprint.

If you are familiar with Agile working methodologies, particularly Scrum you might recognize some of its values above. We firmly believe, that following the practices helped us work better together and ultimately deliver a better product. Don’t think too much, just start and keep it as simple. Discuss with the team what went well and what went bad, improve and repeat.

Written by Peter Artenjak, PSM I Project Manager @ Cloud9devs.com

‍