The Fractal V Model described by Mark Staples has relevance beyond describing the project/development lifecycle. I found the multiple V's described in his article stimulated one's thinking .... especially the idea of V’s of different sizes.

Although not the intention of the original V-Model, with a little imagination some meaning can be attributed to the size and shape of the V itself. If time is viewed along the x-axis, the y-axis, or "depth of the V" relates to the level of solution abstraction.

The time dimension should not be contentious - after all, if we flatten a V we get the solution development lifecycle which results in an end-to-end project schedule. The Fractal V is a visually compelling representation that extends the single lifecycle, showing multiple iterations as multiple V's along a time-line. It works in well with my practice of depicting the V with a leading "flat-line" (Fig.1). I do that because I find that many project issues can be traced back to the poor scope negotiations, prioritization and/or estimating that is done prior to the project kicking-off. So it is important to look at what happens before the project starts or a Project Manager is even assigned – the activities conducted in the time before the V really begins!
 
It is this early, pre-project, business case phase - when the technical options are considered and the business benefits are being explored - that can set the course for what is to follow. This preparatory work is essential in traditional (more Waterfall) IT projects but also relevant in Agile projects before they get the approval to commence. Either way, the expectations set at this early stage can determine the success or otherwise of a project and I don't think we do enough to ensure this inception phase is managed adequately.

So, with the Fractal V Model in mind, I can now elaborate on my earlier depiction of the pre-project period. I now draw a "mini-v" for those early activities necessary for the planning of a project (Fig. 2). This recognizes the fact that, just to get an understanding of the scope (for a project or an iteration) , you need to step through the lifecycle phases at a high-level. After all, if you do not have a handle on the activities needed to execute each phase of the project, then you are unlikely to get a realistic plan or estimate; you are really just guessing.

To scope the project effort the kinds of planning questions one might ask include:
•    What of the business processes impacted?
•    What are the key features to be delivered?
•    What is an anticipated architecture and its components?
•    Which legacy systems are impacted?
•    And what new development is necessary?
•    What effort will be needed to integrate and test the system?
•    And last but not least, what resources will be needed for user acceptance? 

The level of planning required (and so the depth of the V) depends upon the degree of accuracy needed for the plan/estimate. After all, if you'll forgive me being facetious, traversing the complete project V and implementing the desired solution would give the most accurate estimate. To illustrate the possibilities consider the options of a deep versus a shallow mini-v, as shown in Fig. 3.

The deep-v would relate to the development of a prototype where all phases of the lifecycle are undertaken over a relatively short time; from analysis, design, code, integration and test. With such a mini-v we may investigate the feasibility of a technology and get a better understanding of what is necessary in the actual project.
 
The shallow-v represents the need to undertake a short analysis and high-level design phase in order to assess and estimate a proposed solution development. Here we may just want to better understand the business solution and determine the architectural components for estimation purposes. This would be the kind of activity that is necessary to come up with an estimated function point count for a project.
 
What the Fractal V model has provided me is a means of diagrammatically representing the inception and planning phases of a project which are often neglected. We have some choices on the level of detail we go to but we essentially undertake a mini-lifecycle as a part of that process. It highlights that estimation and planning are activities that should engage the specialist teams that will conduct these activities - and illustrates that the cost of an estimate goes up with the level of accuracy desired.
 
Finally, what the planning mini-v, shows us that as we create a plan for the delivery of a project, we make decision and set expectations for each phase. However, the thing that troubles me is that we usually do not record the concepts and design decisions made during this phase. That leaves the project team charged with executing the plans little option but to reinvent the wheel - which introduces the possibly of disappointing those who signed-off the original business case.

If we want our projects to be successful and come in on-time and within budget, maybe it is time to take the pre-project, planning-v a little more seriously.