Actually, most companies reach a point where they need outside help to take their business to the next level. Usually the company is growing and has reached a stage where it needs help deciding which way to go next or the best way to grow profitably. For example, the Butler Business Accelerator works with mid-market companies, many of whom are trying to balance growing the company and keeping up with the day-to-day demands of the business.

Whatever the size of your company, consultants can be valuable for these five reasons:

Skills and methodology. If you don’t have in-house expertise in, say, sales process or strategy development, it’s much easier and more efficient to bring in an outside expert. If your consultant is the right kind of partner, you will learn those skills and be able to continue using those tools after he or she is gone.

An objective third-person viewpoint. Privately held companies may have family members that have worked together 20-plus years, with their business and family relationships intertwined. A consultant can come in and address the white elephant in the room without risking harm to the relationships. While methodology will differ, a good consultant comes in to listen, has no agenda, becomes a partner in the project and always understands the project is ultimately the company’s, not the consulting firm’s.

The ability to articulate opinions that others might be afraid to say. Some consultants have another term for this: “Call the baby ugly.” It’s the ability to question longstanding traditions and assumptions in a company without repercussions.

For example, a company might have the wrong people in certain roles—their skill sets don’t complement company needs—but other employees are reluctant to point this out because they will have to continue working with these people. A consultant can say this without worrying about facing the person on the job the next day.

Also, companies often have long-held assumptions that prove incorrect once the consultant gathers data from employees, customers, prospects and competitors. For example, a company might assume there is only one good way to communicate with customers, but a consultant’s research might suggest otherwise.

A climb up the resource mountain. As companies grow, there may be roles that you need, but not full time. For example, you may not need a full-time marketing officer, but you need someone to put the marketing strategy in place that your team can then enact.
Having a consultant allows you to bring in the skills you need on an “as needed” basis, a variable cost versus a fixed one.

Effective implementation. Without a consultant, you can make great plans—but do your employees have the time and inclination to implement? Aren’t they best at doing the job they were hired for? A consulting partner can help implement a new strategy and move things forward.

So how do you choose the right consultant for your company?

First, talk to other companies a prospective consultant has worked with. Ask questions about what projects involved the consultant, how the consultant worked and how he or she delivered and met expectations. This will give you insights into the consultant’s expertise and methodology.

Find a consultant you can trust. This will be the key to a productive relationship.

Make sure the consultant understands the sensitivities and uncertainties of your employees about an outsider. Because the recession has made employees more nervous about keeping their jobs, you should explain why you’re bringing in the consultant and that the person can be a good filter for employees’ thoughts and feedback. 

Finally, look for a consultant who is truly interested in your business and seeing it succeed.


Some people hate quality assurance. They enjoy the creative stages of a project, when they can map out storyboards or design ideas and turn policy-speak into friendly, accessible language. They don’t enjoy having to review that friendly, accessible language for typos.I have to confess though – and I’m sure this won’t surprise anyone who knows me even a little bit – that I do enjoy QA.

There’s definitely an editor inside me. I like QA-ing other people’s work most (because it’s much easier and more effective when you’re objective and not close to the content) but I’m pretty happy QA-ing my own work too, when I need to.

Regardless of whether or not you enjoy QA, however, it’s important and something that needs to be done. What’s more, it needs to be done properly – giving something a cursory once-over and ticking the QA box isn’t enough.

A thorough and reliable QA process will eliminate all avoidable errors or bugs before you send something out to stakeholders. This means that they can focus on content and design reviews and it’ll take fewer iterations to get to sign-off point. It also means you can rest assured that any rework required will be about improving and enhancing content and design, rather than fixing mistakes you missed the first time around.

Aside from the financial benefits, giving QA the attention it deserves helps you deliver high quality deliverables, which means happy customers who trust you. You’ll earn a reputation for integrity and excellence (either as an organisation or as an individual (and both matter)) and, because happy customers talk, you’ll benefit from recommendations.

There’s an internal benefit as well: a focus on QA helps to develop a culture of continuous improvement. Colleagues will help each other develop, challenging things and preventing complacency setting in and leading to carelessness. In my experience, high standards are infectious – if one or two members of the team set the right example and pick up even the littlest things, these good habits will spread and you’ll develop a true QA culture.

So I see six key benefits of a thorough and effective QA process and culture:

  • You’ll achieve sign-off more quickly.
  • You’ll reduce the time and money spent on rework.
  • You’ll build trust and respect.
  • You’ll earn a reputation for excellence.
  • You’ll win word-of-mouth business.
  • You’ll nuture ongoing improvement.
What’s not to like?


Businesses today use consultants more and more for a variety of reasons. The main reason is that every business will at some time come to crossroads and will not always be sure which direction to take.
Even though a person has been running a business for many years there always comes a time of uncertainty, caused by a decline in the business, or difficulties due to the economic climate.
Sometimes we all get a period in our life when we are drained of inspiration and new ideas and this is the time when an external consultant can be of great value.
Another reason for using a consultant is to get confirmation that what you are doing in your business is correct. This is a worthwhile exercise as it gives you renewed confidence in yourself and the knowledge that you are still doing a good job.
What a business consultant does is take a detailed look at a business without having the passion that often causes business blindness especially when harsh decisions are needed.
A simple analogy: how easy it is to tell another person their child is doing wrong when you can see no fault in your own child!
If you choose a business consultant who has experience in the business issues that concern you most then his advice should be helpful and put you in the right direction. Other types of consultants may be specialists in a particular industry, or in one particular aspect of a business.
Then there are general business consultants who have run a business and their knowledge differs because they know exactly what you’re going through, having been through the problems themselves when they were in business.
I have started, operated and sold many businesses in different industries. To me there is no difference in running a business irrespective of the industry as everyone has the same objective, to make money.
Business consultancy has grown rapidly over the years simply because they are providing a reality check, similar to having an annual health checkup to see that everything is working correctly.
Having a consultant look at your business is a worthwhile exercise; it is the checks and balances that every business should do from time to time.
Another way of using a business consultant is as a mentor. Many companies, after having an initial consultation period, use the consultant on a monthly basis either by an office visit, Skype, or telephone. Some even go further by making the consultant the chairman of the business so that he can give direction, not only to senior management but to the staff and overall business in all its operations.
Consultants bring with them not only their own business experience but the additional experience they gain on a regular basis from other companies they advise.
Using a business consultant is clearly a win – win situation for everyone.


There is never a good time for small businesses to swing and miss on a new product launch. But when companies are trying to survive a tough economy, owners must pay close attention to the process to avoid the psychological—and financial—toll of a failed launch.

A lot of business owners will never try something again if they have a first-time failure, says Andrew J. Sherman, author of Harvesting Intangible Assets and a partner with Jones Day, a law firm in Washington, D.C. “For a small company to try a new product or service and have it fail, and to not learn from the failure and try it again is a travesty.”

Follow these steps to ensure successful product development.

1. Build the right budget. Launching a new product might never happen without a reasonable budget at the outset of the project. Underfunded projects rarely make it to the launch phase, and overfunded projects can result in wasted time and money, Sherman says. Owners need to figure out the total costs related to a new product, set a realistic budget, and hold team members accountable for meeting those numbers. While numbers vary based on industry and company size, it’s not uncommon to allocate 20 to 30 percent of a company’s budget to new product development, Sherman says.

2. Focus on markets. For a product launch to be successful, owners should avoid “inventor syndrome” and focus on creating products and services customers want, Sherman says.

“What we have to avoid is entrepreneurs and small business owners who are looking for that invention to be their legacy instead of worrying about whether the invention is something customers want, need and will pay for,” he says.

3. Invite collaboration. Collaborative environments can lead to more successful product launches. The group responsible for putting together the launch should elicit feedback from salespeople or distributors, as well as potential customers, to find ways to improve key elements of the launch. Such elements could include the pricing and positioning of the product.

4. Eliminate wasted time. Sherman emphasizes the discipline owners must implement throughout the product launch. Those planning the launch should identify its key steps and indicate the stakeholders responsible for carrying out those steps. Steps in the launch-planning process include compiling a realistic budget, collaborating with individuals at all levels of the company and evaluating risk. 


 This blog post is part of an Atlassian blog series raising awareness about testing innovation within the QA community. You can find the other posts in this series under the QA Innovation tag.

The post is written by Bryce Day, CEO of Catch and the driving force behind the development of the highly successful QA management tool Enterprise Tester. Bryce has been involved in software testing since 1997.

Testers tend to talk testing. That means they want to know things like: the number of test cases, how many have passed or failed, which tests are assigned to who, and how many times has an issue been tested and retested. While all of these numbers provide interesting statistical analysis, they don’t provide the real oil that the management team need. In fact there is only one real measure that means anything and it’s a four letter word – Risk! A question I hear frequently is “what are the key statistics you use to manage your testing?” Look on forums and discussion groups and you’ll get a number of differing views on how best to manage your testing. I, too, have an opinion, but unlike many others I like to focus on what I consider the basics.

Forget everything else including all those fancy statistics, risk is the only thing that matters.

Not convinced? Well, let me change your mind.

Testing versus Quality All testers talk about testing their organisations product, but frankly who cares about testing? What they should be worried about is quality!

Quality is very different to testing. Sure, you can validate a products quality through testing but how many of you are called Quality Managers instead of Test Managers? Or how often do you hear in a team “how much more testing have you got to go?” instead of “what’s the current quality of this build?”

There’s no doubt about it. Measuring quality and understanding the quality profile of the product is the key to what we as testers do.

To me as a manager, quality is a reflection on how much risk I’m prepared to take. For example, I would want to buy a high quality car because my risk appetite for a car breaking down is low, but I’m willing to purchase a low quality $2 toy from a discount store because my risk appetite is much higher that it will break. How many of you reading this have had a discussion with your project manager or management team about companies risk profile around a product release? I would guess very few. So forget the current way of thinking about testing and think of it instead from a risk perspective.

How much is too much? The question now becomes ‘how much risk are we willing to take around this project/product/sprint?”

Agile guys might say that they bake quality into the process. Sure, sounds great, so do they actually know the risk profile of the project? My bet is that they know about as much as the waterfall or iterative methodology teams, which isn’t much.

The only way to understand the level of risk that the project is taking on is to understand the risk profile of the project, which is to say… you need to verify it or sample it.

Turning our attention to some theory:

Risk = Probability of Occurrence x Value of the Loss

So if I had a 50% probability of something occurring and if it occurred I’d lose $500 then my risk would equal $250. If we translate this into current testing speak:

Risk = Test Case Importance x Requirement Importance

In the QA space we can use estimates to achieve a similar thing. And the more we do, the better we get!

Taking the ‘value of the loss’ part of the risk calculation we could estimate this based on the level of importance associated with the Requirement. If a Requirement was critical then the value of the loss could be assumed to be higher than a Requirement rated as high. Turning our attention to Test Cases, since they are a step-by-step walk through of the process that has been derived from the basic path they can be used as an approximation of the ‘probability of occurrence’ part of the risk calculation. Risk becomes some form of Test Case Importance x Requirement Importance.

The ‘value of the loss’ factor is arguably the most important of the two, since a big loss is worth more to me than a small loss. Conversely, a small loss occurring frequently is just as bad if not worse. Using a weighting factor I can smooth the risk profile across the requirements and test case combinations we have. And this is what I’ve come up with:

Risk Rating Using this derived risk rating, as a Quality Manager, I can focus on reducing the risk level of the project to one that is acceptable to the management team.

A Polarising View? It’s interesting the discussions this has started, with both my team and others. Some think that this is just a new spin on an old idea, for others it contextualises something they have never been able to measure, and there are a few that find it too simplistic. For me though it provides something tangible that I can measure and discuss at a management level. It provides a yardstick against which I can measure all of our product development, and a common language for our team to discuss the risk profile of each of our products.

Quality Assurance and Quality Control are often seen as loathsome corporate entities, assigning blame, slowing down the production process with excessive control measures, and creating tons of “useless” documentation. This perception is unfortunately the result of years of bad corporate QA and QC implementation, where upper management groups impose policy (without process user input) to define adequate “Controls”, untrained or unqualified personnel leading QA and QC activities, and  poor communication about vision and goals. It is far too common for companies to approach QA and QC the wrong way, thereby spoiling their staff on the concept and limiting the benefits that can be gained not only for customers, but for internal quality of work environment. To effectively implement QA and QC, you must first properly define “Quality” and then the role that each (QA and QC) play in achieving quality.  There are two general views of Quality:

  • The Customer view of Quality: Is the external view that means that the product or service they receive satisfies their needs
  • The Producer view of Quality: Is the internal view that is based on whether or not a product satisfies the stated requirements
Quality Control QC focuses on the product produced. This focus is two-fold, ensuring that both customer and producer share the same vision of quality, and that work is objectively reviewed to eliminate defects.

Unfortunately the two views of quality (customer and producer) are not always in sync; therefore QC’s first goal is to reduce the “Quality Gap”, the gap between customer expectations (not necessarily stated) and the development team’s understanding of the explicit requirements. By minimizing the quality gap, QC ensures an end product that matches the customer’s needs and expectations.

The second goal of the Quality Control entity is to find defects before they reach the customer. This effort maximizes customer satisfaction when the product or service is delivered. In a perfect world, every requirement analyst and developer would objectively check their work and communicate efficiently, both with the customer and with each other. They would therefore produce a perfect product for the customer the first time. Real world experience shows that self-checks are insufficient tools for discovering and rectifying errors and that breakdowns in communication occur in even the most in-tune organizations. As a result, Quality Control serves as an objective 3rd party entity to execute the proper checks at each critical point of the development process, thereby providing sufficient feedback to the producer (Analyst, Developer, etc.) to correct defects and avoid a cascading effect of negative consequences. In a word, Quality Control is the second look, the “spellchecker,” that helps to ensure that work is on the right track from the start through the finish.

Quality Assurance QA focuses on processes and their continuous improvement. Its goal is to reduce variance in processes in order to predict the quality of an output (final or interim product), gather best practices for the company, reduce cost, and reduce time to market. QA is strongly linked to innovation and creativity. Quality Assurance neither imposes nor defines processes for other people, but it provides advice and support to the process owner, which leads to the ability to measure success and make decisions based on facts. A well-known approach to Quality Assurance is the PDCA (Plan Do Check Act) Cycle:

  1. Plan: Define the mission, vision, and goals to be achieved by an activity or a process. Identify the procedures, methods, and tools needed to achieve the goals. Define the measures to be used to check the results of the process.
  2. Do: Execute the plan, train users to methods, deploy products, and use tools to perform scheduled tasks.
  3. Check: Evaluate whether or not the goal has been achieved by using measures, metrics, and facts.
  4. Act: When gaps are defined, identify the origin of the problem and define an approach to correct or close the gap (Return to the Plan phase).
In conclusion, neither QA nor QC focus on people, as they do not care “whose fault it is” (although they do care when there is something valuable to be remembered!). The goal of a good QA and QC implementation, in any organization, is to make things better. It requires good communication between the QA/QC groups and process owners. It also requires QA/QC lead(s) to communicate and explain why, when, how, and what is being done. Key attributes for success of QA/QC implementation are:

  • Participation: Both process owners and users need to provide their expert input on how things “should” work, and define it. QA should be a support function for process related questions.
  • Transparency: Open communication and the ability to look at all aspects of the process are critical to fully understand and identify both what works and what doesn’t
  • Clear Goals: The entire team should not only know how QA/QC is implemented, but also the intended results