Our website uses cookies to enhance your browsing experience.
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS‑Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

close form
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

close form
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

close form
check circle
Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Selling to decision makers

Selling to decision makers

Feb 25 2013

If you are doing test-drive of PVS-Studio for your organization, and you liked the software and services we are offering the next big step is convince decision makers in the organization that static code analysis for C++ projects based on PVS-Studio product is effective investment.

Note: if you are decision maker yourself you might still benefit from reading this article as you might find few interesting facts about PVS-Studio that you didn't know before.

So first thing you need to understand is who is /are decision makers for purchasing of new software and implementing significant changes to the development process (which obviously introduction of static code analysis is).

  • In case of rather separated or one-off projects it might be project lead or project manager
  • When a larger development organization is in place these decisions are usually approved by top manager in charge of the whole development organization
  • In the large technology-oriented companies there might be separate organization that controls selection, purchase and provides maintenance and customization of development tools

Next step is to understand who potential stakeholders of this product are. These are the people who are directly or indirectly are affected by introduction of the software. Usually they see additional tools as a more support burden, but we have to be proactive in presenting benefits of these changes:

  • Quality Assurance will definitely get a lesser number of issues to deal with, and overall product quality should improve also. There is a high chance that some of these 'uncatchable' bugs will be caught with static analysis, and less of such bugs will be introduced
  • Build engineers. As integration of PVS-Studio into the development process require some efforts and support from Build engineers it will definitely make their life easier in the long run due to lower number of emergency rebuilds, late night fixing shifts etc.
  • Peer developers. Sometimes developers have a strong feeling that static analysis is put in place to highlight someone's failures. Of course it heavily depend on organizational culture, but when talking to other developers you need to stress that management sees this tool as an early error prevention not as a way to blame and point fingers.
  • Senior management usually sees static code analysis tools as an additional line in the budget, however the main goal is to show that introduction of this tool leads to decrease of the cost paid for each feature, and also to overall increase in product's quality. Currently it is rather hard to estimate return on investments (ROI) into the static code analysis tool (like PVS-Studio) but numerous studies shows that it is definitely positive.

After all stakeholders are identified it is a good chance to engage with each of them informally and discuss their vision on static analysis, understand who supporters of this change are and who will be objecting. It is important to understand their objections and be prepared to address them during the management presentation.

Next big step is preparation of the presentation. You might want to use our template presentation of PVS-Studio static analysis tool as a base line that should be enriched with the detailed results of your trial.

Also on this stage do some homework and be prepared to address objections of the people who do not like the idea of introduction of static code analysis tool into the process.

Please note that our presentation of PVS-Studio doesn't concentrate much on exact errors it might detect - this of course depends on the particular project, rather it highlights other benefits of having static analysis tool in place.

Then time comes for the big presentation. Make sure that all decision makers are able to attend the meeting and all stakeholders are invited too as optional attendees.

Hint: talk to main supporters of this project to make sure they could attend the meeting.

There should be no major problems - by the time you do the presentation you already know most of the objections people have about this kind of software and PVS-Studio in particular.

As usually the most important outcome of this presentation should be either a final decision on starting this project or set of open discussion points.

Please feel free to contact us if you need help addressing questions you face on static analysis or PVS-Studio functionality.

Popular related articles

Comments (0)

Next comments next comments
close comment form