Cost is more important than quality, but quality is the best way to reduce cost – Genichi Taguchi

This quote doesn’t just apply to projects or work. It certainly applies to all aspects of our life: whether it’d be something that we eat, we always tend to pick up the freshest produce we see; to online shopping, we often look at product reviews before checking the items out; to our relationship, there’s always that line of quality friends over quantity. It’s innate in people who want the best for themselves. If you lose quality in food, there’s a risk of getting sick if consumed. And for products, it tends to break easily in which you’ll have to spend more than what you paid for – that’s the price of poor quality.

For software, the importance of quality is monumental. An unstable product running in live production may lead to a loss in customer engagements, and while some projects run on the pre-production phase it also consumes a lot of time and resources. The more the build gets retracted from being pushed to live production, the higher the chances it creates more tension internally for the organization – which may then lead to it being discontinued.

As much as possible, we’d like to avoid that kind of situation as we have invested a great deal of time and money for a project to just go down the drain. And trust me, we’ve had a share of those experiences at work – some gains and losses. But a loss does not imply defeat; it just means we need to do better the next time the same problem occurs.

So here I’ve listed some of my thoughts on the important parts in supporting a project and its quality, which might be of use to some of you.

1. Clear Business/Project Goals – if you have an idea, you must be able to convey your plans and intentions to other people involved. Now, a project may not have all its core functionalities listed from the start; but it must have at least something specific it wants to do or deliver. You mustn’t allow developers to create the specifics from the start. It must come from the business/project manager else it will create a traction point, wherein developers will have to redo their work because it wasn’t the exact business/project requirement.
2. Planning – once goals have been established, a project should have proper planning (from documentations, wireframes, user stories, event storming sessions, DevOps infrastructure, API and data designs, logical flows, etc.) before starting the development and targeting deadlines/the timeline for teams. Everyone should be clear on what needs to be achieved.
3. Team Composition – as much as people hate being in a hierarchy, it creates an order for the organization. Teams must have a POC of who’s who to chase for when something related to a problem happens – from the project manager, backend/frontend lead, infrastructure to QA. Someone needs to be responsible for a role and must be able to manage the team and its optimal performance.
4. Communication – “In teamwork, silence isn’t golden, it’s deadly.” The information being relayed doesn’t need to be perfect it just needs to be addressed properly by the people in the organization. To effectively deliver a good output, everyone must be able to communicate goals, issues, feedback, and suggestions.
5. Infrastructure – it’s important to have a solid infrastructure setup as it is the backbone of projects and the most critical part when the project is running. It should be able to handle downtimes, traffics, log monitoring, service build updates, data events, etc.
6. Quality Gates – now, this doesn’t solely depend on the QA team, it is apparent in all departments: project managers need to ensure the requirements are correct and detailed, developers will implement their own sets of code testing, DevOps will have the error log monitoring, and most importantly QA will have a set of tests that will fit the project/feature both manual and automation. The gates will have to block an unstable build from being released as a final output for a deadline/push and must ensure a much stable version is delivered throughout each cycle.

The list above is not the perfect guide to achieve better project quality, but will give you a good idea of what should be expected as a criterion. It will always depend on how well the organization manages its processes, workflow, and teams. That’s why here at HOV, we’re continuously learning from one project at a time and developing better tools/processes to ensure we deliver the most ideal outcome for our ideas.

We’re working on an exciting test project to help the company fill missing gaps in ensuring better quality and transparency for internal projects this year. I look forward to sharing it in my next post! Fingers crossed 🤞