Introduction
This article suggests that the use of standard practices within a project is an indicator of low research investment and project maturity. Given project requirement heterogeneity, best practices for a given project are expected to typically vary from standard practices across all projects.
Best practices are those practices that have a number of symptoms, all of which jointly obtain from a given set of behaviors. Two of these are:
The maximization of firm profit, typically through the optimization of risk-adjusted labor productivity per spend.
The maximization of investor group return on investment.
For non-corporate analysis, focus on the second horn. An investor group might just be an individual investing their own time and effort. It might also be a commercial budget committee or the shareholders of a company. In both ideal and also usual cases, optimizing return on investment at each of these levels is in their mutual interest, and also in the interest of customers and the public.
This article has four sections, including this introduction. First, I make the case against standard practices, then I make a case in their defense. I close with a few anti-cases or pitfalls for standard practices.
The Case Against Standard Practices
Standard practices optimize for solving common historical problems. If you would like to reproduce or copy an existing product, it often makes sense to copy an existing implementation. This sort of business strategy is generally flawed, however, because competitive markets usually require differentiation for success.
Product differentiation in a positive direction is a kind of innovation. If you want to do something actually innovative, uncritically adopting existing implementations is extremely unlikely to be optimal for you. Particular elements of those implementations may be a great fit, but the distinction between wheat and chaff will be uncovered through critical examination. This is a planning and research effort.
Here is a list of practices that often improve research outcomes:
First, know thyself: Understand your resources on hand and your own goals.
Consider existing solutions: Both standard and non-standard practices. Think about these practices as transforming some heterogeneously distinct inputs into distinct outputs.
Try to determine abstract patterns in the existing solutions. To do this, you need to break down solutions into smaller elements and analyze the relation of those smaller elements to each other and to the whole. To do this is to understand a system at a deep level.
Based on your new understanding of existing solutions and their related goals, assumptions, and abstractions, try to come up with a novel solution tailored to your needs. Occasionally, you will still determine that an off-the-shelf solution works best. That’s great! Write down the specific justification for two reasons:
Things change over time and innovative teams periodically reflect on their current state. Awareness of the selection criteria for the current situation allows future teams to easily identify that something has changed, and therefore it may be time to change the implementation.
For something off-the-shelf to be optimal is rare. In a large team, you can rationally expect to have to repeat this information many times. So writing it down will help.
The Case for Standard Practices
I can think of four cases for standard practices.
First, I’ve already carved out an exception for the rare kind of business strategy that achieves business differentiation without product differentiation. I think using these strategies is rarely sustainable and effective, but they sometimes occur. Some examples:
A massive capital injection strategy. Your company will out-compete an existing company using essentially the same product simply by injecting tons of capital and scaling it faster.
A marketing strategy. Your company will do a better job of marketing a product.
A political strategy. Your company will use lobbying, lawsuits, patents, and other tools to make it easier for customers to buy from you than it is to buy from others.
I also previously carved out a second exception for cases when research has been done, and the standard solutions still seem to be the best fit. I argued that this is an unusual case, but we can generalize the situation and it will appear noticeably more common:
For some kinds of projects, researchers may not be able to access standard practices, or such practices may not yet exist.
For some projects, the research budget is extremely limited. This kind of budget refers to time and effort, in addition to plain cost. Limited research budgets may arise from short-notice meeting demand. Consider, for example, an ultimatum meeting with a high-stakes investor and no opportunity for rescheduling.
Many projects face a special kind of resource constraint at initialization time because the opportunity cost of work-blocking research is large.
This carves out a temporary exception where standard practices are fantastic for project initialization. Notice that even here, we can still use the presence of standard practices as a maturity measure. It’s simply not a concern for a new project to have a low level of project maturity.
Over time the actual implementation should be expected to move away from the starting point directionally.
Starting this way is even smarter when using a flexible and unopinionated tool instead of a strongly opinionated tool. A great degree of progress toward achieving results can be made with little time and effort using these tools. This also explains the victory of tools like React over tools like Angular in software development. Still, over time, mature projects will have little resemblance to their starter toolset, and team practices will optimally evolve in a similar fashion.
Optimizing research return on investment is different than maximizing research output quality. Overplanning and overinvesting in research are dangerous. Increased research work may create a better plan, but the marginal gain on the plan quality needs to have a value that matches or beats the increased cost.
Further, product enhancements are often discovered as the implementation is conducted, so we must distinguish between work-blocking research and parallel research, where work-blocking research should be relatively rare in an optimal situation. This is routinely considered in software development as a contrast between waterfall-style project planning and iterative, agile software development.
Standard Practice Anti-Cases
Finally, here are some anti-cases or pitfalls. One might think that standard practices are a good idea in these cases, but I would encourage a particularly thorough reflection:
With respect to short-notice meeting demand, notice that this doesn’t generalize to situations without a captive audience. Consider, for example, a surprise event such as a news event occurs, and the business must react quickly to leverage the event. Here, standard practices generally won’t allow the business to beat the competition. Instead, the business must have special preparations that allow them to react to such events with differentiated response speed and quality.
A research team that routinely defers to standard practice even with substantial time and financial allowance. They may simply have a lack of research talent. I earlier recommended that in this rare case, the research team should write down the justification and expect questions. I now suggest that the team employing that research team professionally investigate whether the team would benefit from the addition of senior staff or a change in senior staff.
A low-performing implementation team may not necessarily benefit from standard practices. Deducing this kind of causal result is a case of incorrect causal reasoning that ignores the team heterogeneity problem. Standard practices emerge from standard teams. It doesn’t follow that applying standard practices to existing teams will transform the existing team into a standard team.
Put in the jargon of investing disclaimers: “Past performance is no guarantee of future results.”
I recommend you solve your team performance problem through innovation (or perhaps a reduction). Return to the section on “The Case Against Standard Practices” where I describe how to come up with a novel solution tailored to the unique situation of your team.