How to Deliver Quality Products On Time And Budget using The RHHHK Methodology For Software Professionals

By April 28, 2019Productivity

Before we start getting into what is RHHHK and how can it ensure that you succeed every time, let me walk you through a situation, we all have experienced at some point of time in our career.

You are working on a project, where requirements are not clear. You work hard to build a module just to learn that it has got a number of change requests. This results in you missing your deadlines even while you overexert yourself while trying to meet the expectations of the client. The client starts screaming at you. You try to explain to your boss about this situation, but she says it is your fault, as you were not paying attention to the requirements while the client was explaining.

Sounds familiar, isn’t it? In such a scenario, what would you do? Would you like to just keep pushing yourself and try to meet the expectations of the client? Or would you like to resolve the conflicts, so that you can deliver a good product? I always opt for the latter.

To handle such situation, I have developed a methodology which I call “The RHHHK methodology” (and I pronounce it as R Triple H K). It has 5 action points to handle such situations:
Raise your guards and try to diffuse
Hit first
Hit fast
Hit hard
Knock Out

If you practice this methodology, you can get benefited by it from day one itself. So before wasting any more time, let me brief you about these action points individually. You can read my book – “How to Deliver Quality Projects On Time And Budget – The RHHHK Methodology For Software Professionals” to learn it in details.


Before beginning any project the primary objective to be done is for asking time to jot down detailed requirements… never shy away from doing it. Go into the details and document each and every requirement; no matter how obvious it sounds. Once the document is ready, make sure to get it signed by the client. By signing, I don’t mean signing it literally… even an email confirmation will do the job. This not only helps to avoid unpleasant situations, but this also helps in clearing the communication gap, if any.


Keep yourself actively engaged while defining the requirements. Try to foresee what all obstacles you might face. Make a list of dependencies. You should not wait for others to tell you what has gone wrong. Instead, train yourself instinctively to sense an upcoming hurdle and raise an alarm while remaining calm in front of a huge hurdle.


Deliver as frequently as possible. Don’t wait until the project to end. Release a build right after you complete a feature. Ask your client to review the build and provide you with feedback. If he/she comes up with changes, ask him/her how crucial these changes are from their business point of view. Tell him/her that you will be happy to implement these changes, but it will affect the timeline you have discussed earlier. In most of the cases, you will find that these changes don’t make any big difference to the product and the client will accept the build. But if you got to make a change that is required, you have the advantage of running an impact analysis on the upcoming builds and plan them accordingly in advance, rather than doing the rework at a later stage.


So as to genuinely “go hard and fast” and gain uncommon ground, you must make the decision at a core level to hold nothing back. You should investigate your line of actions and ensure that nothing is going to stand in your way of success.

You should ensure that the code you write should meet the requirements as documented. Keep an eye on the test cases while you write the code.
You should take proper precautions to ensure zero bugs in the build. Spare some time to unit test your code. Find an issue, fix it. Once you feel your code is bug-free, get it tested thoroughly by a QA professional.

Till now you have made the first strike, tailed it with quick and hard blows. Now the time has come to go for the knockout.


Plan your release.

Draft your release plan right at the beginning of the development process. Every time you fix a bug on production, that is related to the server environment, note in down in the release plan. Make a checklist of everything. Include everything starting from database migration to DNS mapping. include every single detail in your checklist. Your checklist should resemble a step-by-step approach to deploy your application.

On the D-Day, i.e the final deployment day, open that checklist and follow it. Don’t skip anything. Don’t rush. Stay calm and just follow the steps.
If you have mindfully validated it multiple times till now. You can’t go wrong. However, test it thoroughly after the deployment to check for any issues.

Now it is time for celebration. Give your victory pose and take a selfie with your team and post it on your social media. Well, that is not something crucial, but who doesn’t want to get flooded with likes and comments these days? Cheers. You have done it. So what was the most exciting step for you in this entire journey? Comment below.

This is just a brief of the enire process. If you really want to learn How to Deliver Quality Products On Time And Budget using The RHHHK Methodology, go and checkout my book from the below links. You can read it for free on KindleUnlimited.

Leave a Reply

%d bloggers like this: