Effectiveness Over Efficiency
Over the years, I have worn many hats in various roles. I have managed projects, products, processes, development, and testing throughout them. One requirement has always been to make our work as efficient as possible. While I see the business value of efficiency, bringing value to the development sphere while keeping costs down, I always look at effectiveness first.
I know there are similarities between the two concepts, not just because they are often misspelled, but because each word brings a different context to the focus used.
Efficiency means you are performing an activity without waste of time and resources. Value is derived through what you “did not” do to implement the proper results. Effectiveness refers to bringing the correct results. It isn’t hard to craft efficiency, but are you bringing effectiveness?
Example 1:
I was hired to bring efficiency to an organization through automated testing. When I asked what they wanted me to automate, they said, “Everything.” OK, I can do that. So I asked them what kind of tests they had documented so I would have a stepping stone to automate. The answer was, “Nothing.” This wasn’t my first time doing that activity, so I knew what to do next. We needed to build the test cases. This required a significant effort where the software was analyzed, test cases were built out, and then we could develop a roadmap for automation.
At first, the organization was worried that I was bloating the work. They wanted automation and not a bunch of work on manual tests. The benefits of having these tests would be that we could map test coverage and have something to tie the future automation into. It would also allow us to have a training platform for new hires. They could see how the application behaves. This didn’t just bring value to the testing department but also to the business and engineering departments. Once I had communicated this, I was allowed to continue (Thankfully, they were a patient group…not everyone is). As the manual tests were being developed, we could then automate them. We didn’t even have to wait for the manual tests to be created. We were able to implement the automation during feature development, as we also developed the regression test base. It also allowed the testing team to find standard regression tests they ran and pick them as candidates for automation.
If we hadn't done that, we would have created a bloated automation system. Many projects that automate without having a test base create duplicate tests. When the tests need to be updated (they will always need maintenance), there is a lot of overhead to ensure that every test is updated with the latest code implementation. This can be a logistical nightmare.
Example 2:
Another example is that I was asked to implement a Continuous Delivery/Continuous Integration (CI/CD) process for development operations. I looked at the deployment process and was astonished at what I saw. The code was being released after cherry-picking it. These release branches were tested, but not in an integrated unit. This meant that each time a release was done, bugs were being introduced, some of them quite extreme. Most of the releases were rolled back to fix issues. Hotfixes were performed often, which further hurt the code base.
I realize I might be introducing some concepts outside the normal project manager realm. Suffice it to say that bad stuff was happening in the code, the release process was not nailed down to ensure that adequately tested code was going out, and there was no way to guarantee a single release. We were running the risk of losing major clients.
We needed to get the code under control. We had to implement proper branching tactics, training on their usage, and process adherence had to be governed. We had to build an effective deployment process before creating an efficient one.
Thankfully, we were able to do all of that in a few months. Once we had that established and everyone was following along, we were able to start building efficiency into the project. This allowed us to drop the bug rate immensely while increasing the frequency of deployments. We went from a deployment every couple of months to twice a week. We could even do deployment in an on-demand scenario if needed. Later, while working with product, support, and release management, we were even able to automate release communications.
When doing all these things, the trick is to look at the process you are trying to make efficient. Ask yourself, your team, and even your organization the following questions:
Is it bringing value?
Can it bring better value?
Does focusing on making the situation more efficient or effective first make sense?
Sometimes, the answer is simple. Sometimes, the process is well-baked and can just be automated. Often, though, there is going to be room for improvement. I’m just saying, try to do the improvement part first. It will usually make efficiency easier in the long term.
