Making IT work ("Process"): managing Design

But what form of approach?  "Waterfall"? "Iterative and Incremental"?  "Agile"?  "Do and fix"?...

My experience tells me none of these, in isolation.  And all of them have value.  But, overall, I'd plumb for a basic approach that blends "Waterfall" with "Iterative and Incremental".

• Part Waterfall, because I need to have a general sense of "Requirements" ahead of "a broadly based start to Design", feeding into more focuses activities leading to a hand off to "Detailed Design"
   
• Part "Iterative and Incremental" because only when I've done some design can I begin to clarify Requirements(*) and begin to work out what I can and cannot deliver - as well as those I have to!
   

(*)  Maybe the best I ever heard from a sponsor was "I don't know what I want, but I'll know when I haven't got it!", closely followed by "how big does it have to be to justify the business case?"

As such, I'd recognize the first phase, immediately following the project's kick-off meeting, as being the "Outline Design" Phase, covering the overarching design of the whole system and during which the "big hitting requirements are flushed out, clarified and agreed.  And, hopefully, this phase confirms the outline design included in the project's proposal!  Under no circumstances would I start with a "Requirements Analysis" Phase! (Do not ask - just remember "analysis paralysis"! (#))

(#)  We do NOT do, in our role as architects, "Requirements Specification".  This is the bailiwick of Business Analysts and others focused on those things that drive the solution "from the outside in" - as architects we need to be very careful in ensuring we look at those requirements "from the inside out".

"Outline Design" gives me the big picture that acts as the backdrop - the reference and co-ordination base point - for more specific "Macro Design" (MD) phases, each focused on a different part of the solution, revisiting requirements at a more accurate and detailed level and revising the design (and revising maybe re-negotiating those requirements too!)

Therefore, and while there is only one Outline Design phase in a project, multiple, pseudo-independent (^) Macro Design phases typically run in parallel (or maybe staggered), delivering the design for "their sub-system" back into the overall design model for hand-off to Detailed Design.

(^)  "Pseudo-independant:  able to work largely independently (because we got the "cohesion/coipling splits right in Outline Design) but towards a common goal, as guided by the overall outline design.


Or maybe Macro Design phases are focused on separate releases of the solution, i.e. they are then more likely to be running in a more serial manner for time-sequenced delivery to Detailed Design, Development and beyond.

Other specialised approaches may be adopted within certain aspects of the design activities, such as

• "Agile" for the Functional Aspect (assuming the operational aspect can tolerate the inevitable lack of focus on Non-functional requirements!)
   
• "Do and fix" for the Operational Aspect when determining the configuration of servers in a novel environment with no performance data to hand (and maybe with changing application performance characteristics. 

Sizing
Each and every one of these phases within a project do of course need to be sized, but not in a quantity surveyor style "add up the bits" sort of way - it needs the (mature) skills and knowledge of a senior project solution designer to do this; ahead of time (pre-sales budgeting and pricing), and during the project (to explain and negotiate the inevitable changes needed... OK, this is 99.9% of the time actually "overrun!").

And in order to maintain credibility whenever revision is needed - whether externally specified changed requirements, or internally generated design alterations or delays - it's a very good idea for the programme architect being the same person who proposed the solution design in the first place!