Craig Brown has a nice post titled Sketches go a long way in generating understanding. But where's the Sketch of the Project's flow? In the Integrated Master Plan paradigm, the increasing flow of maturity of the deliverables of the project is represented by a diagram that looks like this.
What this diagram tells us is what is the "value flow" for the work effort. Each chunk of work activity "Pilot" with "Data" gives us a deliverable that can be assessed for its maturity. By maturity I mean a general term. This can be usefulness. It can be verification of the concept. It can be a test of the willingness of the funders of the project to proceed.
Agile would call this an iteration or maybe a release. But what is shown here is the end to end map of the project. In this case an ERP system for insurance claims processes. The Vision of DONE in just that DONE. The senior management of the insurance copy can see to the end of the project. They can see what it means to be DONE. As well the work flow to get to DONE is there as well.
We need to have some data and a pilot before enrollments are developed. This "dependency" structure is part of the Planning process. And of course the Planning processes results in an Integrated Master Schedule. Not for the whole project. That would be nonsense, no one can see that far into the future.
But we do have a Plan for the future and this is it. We need to do these big chunks of work in the order they are planned for the business to receive the planned value from this project. Oh yea at or near (within agreed variance) for the planned cost, since we asked the Board of Directors for the budget we needed and they approved it and put that cost in the GL as an obligation and that obligation got reported in the 10-K for the stock holders to see that 100's of millions are being committed of their money.
Is there a home agile development in this approach? Sure at the work package level that is 3 to 4 levels down. This there a home for Earned Value? Absolutely, that's how progress to plan is measured down at that work package level. This progress to plan is progress against the planned budget, the Budgeted Cost of Work Scheduled (BCWS). BCWS times Physical Percent Complete = Earned Value. We "earn" our budget, if we show up on time, don't over spend, and the thing we're building actually does what we said it was supposed to do. What a concept. No hand waving, no whining about this or that. Do what you planned to do, once that plan is agreed to and baselined.
Emergent requirements? Absolutely. Plans change. Requirements change. That stuff on the right is way out there in the future, it depends on the success of the stuff on the left. No one in their right mind woudl commit to a cost and schedule for stuff that has not been vetted through "past performance" and verification of capabilities.
Just don't commit to this beyond your ability to actually make them appear. This is called rolling wave. It's the basis of Earned Value, it's the basis of enterprise project management, DoD 5000.02, and just plain olde good Project Management.
But if you consider things like detailed planning of current rolling waves, applying Earned Value to measure physical percent complete against cost and schedule "hog wash." Then try doing this and not explaining to senior management how much it's going to cost in the end, when are we forecasting completion (within a variance), how many people are needed (300 or so to start), and what is the sunk cost along the way that can be compared to the expected business return.
Try doing this without those and many other "measurement" processes, and your career as a PM will be short lived. Try doing this without measures of performance based on budgeted cost, physical percent complete, and planned percent complete and if you can, then you'll be very close to Earned Value.