From employees through managers to CEOs and business owners, we all focus on the company's performance. There is nothing more frustrating than investing time and money into work but not seeing much progress. When it comes to such areas as sales, as an example, the annual results are influenced by many factors and not always dependent on the efforts and commitment of employees.
However, when we talk about IT and building software or product development, factors such as the problematic situation on the market can’t be taken under consideration in terms of work progress. What can be done to fix performance? Continue reading to learn more about the unusual but effective use of the Pareto Principle in IT.
Let's assume you are building a SaaS product. You went through market analysis and validated your idea. You know your product requirements and have an MVP (minimum viable product). You cooperate with the in-house development team, so you talk with your professionals and determine how your software will be built (in what programming language, tools, platforms, cloud environment, etc.).
Along this way, some challenges and obstacles probably appeared, but you went through it, and your team is working. However, deadlines are getting closer, or you have exceeded them already because there are still errors and bugs. Overall, your team is progressing, but project development is not going smoothly, and everyone is tired and frustrated. From the above, it should be clear that having devised a brilliant strategy that will enable your product to most appropriately meet the expectations placed upon and drafting a work plan is not enough.
Software development is by far the most challenging phase. The truth is that your team members might be missing some crucial skills, so even if they work hard, there might not be any expected results. More and more IT positions require workers with independent judgment, more profound expertise, and better problem-solving skills. In software engineering, 80% of the program's functionality comes from 20% of the developer's efforts (the 80/20 rule), but you need the right people on board.
In our earlier article, you can find out how to properly match a remote developer to the project.
Before Vilfredo Pareto, an Italian economist, born in 1848, came to this conclusion which may be applied to work, he first noticed the 80/20 rule in nature. It is believed that Pareto observed that 20% of the pea plants in his garden generated 80% of the healthy pea pods and it led him to consider uneven distribution.
Later, he analyzed various industries and found that 80% of production typically came from just 20% of the companies. He introduced the concept of Pareto efficiency and helped develop the field of microeconomics.
The second father of "Pareto Principle" is Joseph M. Juran, a Romanian-American engineer. In 1941, he stumbled across the work of Vilfredo Pareto and began to apply the Pareto Principle to quality issues (for example, 80% of a problem is caused by 20% of the causes). He was the one who, in the early 1950s, took the Pareto Principle and translated it into business - introduced the distinction between the "vital few" and the "useful many."
If you are a SaaS product company or want to build any software, you can apply the Pareto Principle to your development team. It would be best if you started by rethinking what constitutes IT employees' performance. Find out the most skilled people on your development team - focus on individuals who are a step away from average. 20% of your best people from the company may generate 80% of results because they know how to do their work well.
As an executive, you're undoubtedly faced with the constant challenge of limited resources. If your product development team is small, it probably won't be possible to pull out the best 20% of its members – one or two people cannot pull the whole company forward; it must be teamwork. In such a case, there are two options.
Option 1: Pareto Principle is about a complete understanding of a specific situation. Think about the most important goals of your company and the product, and then decide which specific tasks your team needs to focus on to align with those goals.
If you want to apply Pareto Principle in the context of software development, determine 20% of the most important features of your SaaS product and put the most team's effort into it. It will result in an 80% output. You can show your product to potential buyers or investors and meanwhile work on the rest which is missing.
Option 2: The efficiency problem for most employees in the company is more of an organizational issue. Development teams often lack a sufficient number of specialists to build a digital product on time and of good quality. The solution is simple – it's usually enough to outsource IT experts from a company with top developers who can quickly push the project forward.
Time, management energy levels, and workforce are not infinite, so it is worth giving some thought as to the best solution to fruition within an acceptable time frame. At Blue House, we can build an entire dedicated team who will act as an extension of your company. We bring together Europe's best IT talent who focus effort and attention where it is going to have maximum impact.
If you want to find out if a dedicated team is the right solution for your project, read also this article.
You might think if 80% of the work can be completed by 20% of your employees, what is the point of keeping the rest. The right solution definitely is not firing everybody else. If a large enough department in an organization decided to end cooperation with 80% of the less effective employees (assuming that we are generally able to say with certainty who they are), the same principle (80/20) would appear in the rest of the structure.
The best way is to find out what abilities less productive employees have. Some of your employees might simply not engage and show their full potential because there are more visible personalities on the team, and they don't want to compete with the rest. However, it doesn't need to mean they aren't good enough to be incorporated into the project.
Approach this issue by delegating tasks fairly. You can also divide the entire team into smaller groups, and your "best players" can lead each of them. The best 20% are still generating the most outcomes. However, the rest are supporting leaders by being responsible for tasks that still need to be done but don't significantly impact the final result of product development.
Such a move will influence how each person feels about their input – they are still a part of the team and contribute to your product's biggest piece. It can help ensure they are equally responsible for their part of the equation.
The Pareto Principle is an observation, not a law. However, it does have its confirmation in real scenarios. Joseph M. Juran, in his Juran Trilogy: Quality Planning (Quality by Design), Quality Control (Process Control & Regulatory), Quality Improvement (Lean Six Sigma), wrote about an approach to cross-functional management and the cost of poor quality (COPQ) which drives from Pareto Principle.
In the 1960s, the well-known American corporation IBM decided to look closer to COPQ and studied its quality costs. As a result, they tailored the concept for IBM’s own use - which states that investment in detection and prevention of product failures is more than offset by the savings in reductions in product failures.
When you put everything together, you may notice that the 80/20 rule influences three aspects of product progress:
1. Performance If you build a high-performing team that consists of 20% of your best people, they will be working towards shared goals for the greater good, which positively affects the pace of the software and product development process. Their experience and skills make them more independent and help eliminate potential errors much faster.
2. Quality “It is most important that top management be quality-minded. In the absence of sincere manifestation of interest at the top, little will happen below. (Joseph M. Juran).” If your dedicated team is quality-oriented, fewer bugs will appear while working on a project. Quality also goes hand in hand with experience.
3. Cost As mentioned above, the cost of poor quality is what you additionally need to pay for mistakes done during software development. If you implement Pareto Principle and have highly skilled IT professionals on your team, then they keep defects from happening rather than deal with costly issues after they have occurred.
Research suggests that talent-performance profiles in many areas (...) look more like power-law distributions. (...) One 2012 study concluded that the top 5%of workers in most companies outperform average ones by 400%. (Industries characterized by high manual labor and low technology use are exceptions to the rule.) The sample curve emerging from this research would suggest that 10 to 20% of employees, at most, make an outsized contribution. (Source: McKinsey)
Think about what skills of your development team members are necessary to meet all project requirements and help you meet all deadlines. Such a dedicated team will be more independent, which links with project development performance. You, on the other hand, focus more on building than tracking what needs to be fixed. If you aren’t able to or don’t have time to build such a team contact us. At Blue House, we work with IT experts who have different backgrounds with varied skill sets.
You may also want to read:
Don't miss out on any content that will help you to achieve desired outcomes and smoothly run IT projects.