The team contributions and their organizational consequences to the success of a project are usually modeled in Bell Curves (top- average- and under-performers under the law of average and standard deviation). But this does not work well for performance measurement systems, because dependencies make a project much more complex (Quants- Racers at Critical Paths).
Variability matters - every project, every team and every member is different. To work on averages promotes mediocrity.
Scaling teams not the individuals will ensure that there is more cohesion and team dynamic.
But scaling teams and their methods and tools is even a better way.
Which models do methods and tools support?
In traditional software projects you usually utilize general purpose methods and tools that cover a vast variety of project fields and transform them into special purpose solutions (purpose width vs depth) often automated (automation width vs depth). And it is expected that you lose width for depth (as pointedly shown in the picture).
Say, you use a financial instrument pricing and calibration library, develop a portfolio-across scenario analytics library with it, add counter party exposure modeling (for CVA/FAVA/DVA calculations, VaR, … special portfolio composition and what have you.
The "higher" you go the more you hide the foundations, if you apply traditional compile link and go techniques. The one-click-does-it-all solution works very well for very specific set ups only.
Projects for extensions are usually quite "new" in such a framework.
A fractal project model
A fractal is a pattern whose parts echo the whole. In a software development cycle it will not only cover the reuse of code pieces but complete project "structures".
This is enabled by a symbolic language that is specializing in cascades, but never hides expressions of the underlying layers, you start with mathematics, statistics, data analysis, visualization, …expressions and extend them to derivatives pricing, instrument building, portfolio across scenario analytics, counter party exposure modeling. VaR methodologies, portfolio composition …
In each layer your language becomes richer and richer and the development and runtime automation increases. This does not only shorten development cycles significantly it becomes increasingly easier to predict, evaluate and review project efforts and milestones.
The UnRisk Financial Language drives an innovative spiral in a fractal model - good for quant developers of our clients and good for us.
