Clear Scope, Unclear Terrain

I am by formal education a systems engineer, which in some organizational models is the technical counterpart to the PM. The field of SE is largely involved in decomposing the problem into greater detail to remove ambiguity from the solution space. That is done by creating a number of architectural views that define the project outcome such as the formal requirements, the required functions, the operational view of how the product executes the intended functions, and the WBS among other things. How much additional definition is required varies by project, so I must work with the major stakeholders to determine how much ambiguity we can live with, and where additional clarity is needed.

Not all projects are high risk from day 1. The risk level is typically related to how much ambiguity is allowable. The higher the risk, the more structure needed. That is where both PM and SE were born. The US Department of Defense began developing more structured approaches to managing complex problems in the 1940-1950's to address the past issues of projects that went far over time and/or budget due to the lack of structure in large complex projects.