One of the biggest challenges facing any organization is the balancing act between short and long-term goals. Every facet of our lives tends to be a juggling act between these two competing forces. Whether in QA, or just business in general, as humans, we all want things right-now and struggle to balance the demands of the present with our long-term goals and objectives. Sadly, since these two perspectives are usually at odds with one another, we end up choosing one over the other.
Fortunately, there are a few things you can keep in mind that will help you maintain a healthy balance between your long and short-term goals.
Get TestRail FREE for 30 days!
The Differences Between Short and Long-Term Goals
Before we dig in too far, let’s examine a few differences between short and long-term planning. A short-term goal can be anything that is expected to happen quickly, or in the near future. The actual time frame could be anything from a week, to a month, or even a year. Conversely, a long-term goal is typically a result of several short-term goals coming together, or where the results may not be fully known or understood for quite some time.
Another key distinction between them is that long-term goals or objectives are rarely defined enough to have actionable output. They are typically more of an overarching concept or idea, such as “implement performance testing for the organization in 2017”. While you know what the desired result is, you do not have enough information available to know what needs to be done to get there. A short-term goal, on the other hand, can be more along the lines of the tasks that need to be done to get performance testing implemented. An example of this would be “identify and compare performance test platforms” or “create a job description for performance test role”. These are the steps you need to take on your way to getting performance testing up and going.
A final difference between them is that you can have a short-term goal or objective that is a stop-gap solution, while you work on building out a more longer-term solution. This difference is the one area where a lot of people and organizations get tripped up, especially when it comes to automation. In their rush to get something up and going, they often wind up with a solution or platform that is limited in scope or extensibility. Without a roadmap for where you are going, it can be incredibly challenging to stay on the right path.
Understanding Your Goals and Using the CRAWL Method
So, if avoiding wasteful stopgaps and missteps is important, how do we identify those goals that are leading us astray? Because this is a situation that is encountered quite often, I came up with the CRAWL method. This simple mnemonic is designed around the five key questions you can use to help determine potential outcomes. As you ask yourself each question, it will guide you through deciding whether a given approach makes sense, and if it will enable you to achieve your longer-term goals.
C
Complexity – How difficult will it be to implement? You may have an idea of what makes the most sense, but until you figure out how to deliver it, you won’t know for sure. This piece can drastically alter any plans you may have come up with if you don’t do your due diligence first. Building out a full automation platform that integrates with your CI/CD pipeline sure sounds like a great idea, but if your plan is based around a proprietary or difficult to maintain automation framework, that effort may be considerably more difficult.
R
ROI – What is your return on investment? Just because your short-term solution got you going right now, it doesn’t always mean it was the right way to go. What if you have to change it in a few weeks, or a few months? While, for example, Selenium IDE-based automation sounded like a great idea initially, if you were not able to reuse those scripts for your future platform, was the time you spent on them wasted?
A
Adaptability – Can you pivot if necessary? So you decided to go the long-term route, and it is taking way too long to implement due to [insert reason here]. Can you quickly pivot and go in a different direction? Are you too locked into a particular platform or direction to change? When building out your automation strategy, you should always be looking to future-proof as much as possible. With the speed at which technology and platforms change, if you invest heavily in a proprietary tool, you could be looking at a lot of time and effort to switch if necessary. In addition, you should also be fully prepared to walk away from a strategy or project if they aren’t working out. Walking away may be hard to do, especially if you have invested a lot of time and resources up to that point, but you also need to be realistic about it. If it isn’t working out, it’s better (and cheaper) to acknowledge that sooner rather than later, and pivot to another approach.
W
Worth – Does it add value? One of the easier questions to ask, but not always the easiest to answer. If you are trying to implement a long-term goal or plan, you should make sure that by the time you get to full implementation, it will still be worth the cost of getting there. If it is not, you might be better off looking at something that can you can implement more quickly, while you work on a better long-term strategy. Building out an amazing automation platform is a noble goal, but if it is outdated by the time it is usable, then that time would have been better spent on something less amazing, but more useful.
L
Longevity – What is its lifespan? This one is very similar to #1, but is primarily focused on the length of time that you can reasonably expect to be able to make use of the deliverable. If you implement a short-term plan, will that plan be viable for a long enough period to justify implementing it? Using a stop-gap approach can be useful to help you get up and going, but if it will only apply to the MVP version of the product, and not the long-term solution, can you justify the cost of building it out?
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Creating a Healthy Balance Between Short and Long-term Goals
Now that we have a solid understanding of what your various goals and objectives are, it’s time to put it all together in a cohesive roadmap. By taking the time up front to fully define where you are trying to get to, you will have a clearer picture of what needs to happen, and what potential roadblocks you might encounter.
Start by identifying your long-term goals, and what value they are adding. This list will be the start of your high-level prioritization. Once you have put together your overall objectives, start with the top of your list, and begin fleshing out what needs to occur, and when. As you work through this process, you may come across deliverables that need to be further broken down, and that is ok. By working through this ahead of time, you will save yourself a lot of headache in the future. Once you finish working through your roadmap, you will have a much better picture of where you are going, and what you need to get there. You will also have a pretty good idea of what your most important items are, and where you can cut or scale back if needed.
One final thing to keep in mind is that no matter what plans you make, or how far along the path you are, always be open to change. That change may be unavoidable, or a great new tool came out that makes a lot more sense in your environment. Regardless of the reason, just know that change will be necessary at some point, and being prepared for it will make it much easier to absorb.
Utilizing the CRAWL approach has worked out well for me to this point, and has helped me make the tough decisions between building something grand, or scaling it back into a smaller objective What you will often find is that you should look at your short-term goals as the stepping-stones to a much larger plan. That way you can start small, and then build up to the grand crescendo. The key is making sure that big crescendo is going to make sense at the end, and is not just a bunch of noise.
This is a guest posting by Jon Robinson. Jon has helped build and lead a wide variety of teams across all aspects of QA over the past 11 years, and recently launched The QA Consultancy, which specializes in helping organizations improve their overall Quality. Having worked with organizations like HomeAdvisor, ScrippsNetworks, and Victoria’s Secret in the past, Jon has battle-tested his sometimes unique approach to QA in some incredibly demanding environments. He is based out of Nashville, TN, where he lives with his wife and kids, and is a huge fan of the World Champion Chicago Cubs. He can be contacted on Twitter @jumpmancol or by email at jon@theqaconsultancy.com.
