Manage subcontracts

Two thoughts here:
1) if there are many subcontracts and deliverables due a different times/stage of the project applying EVM to that work may still have some value. You may be able to identify slippage and impact on the ultimate deliverable.
2) why would you not use EVM on the internal work? You may want to show that you are being effective in-house as well as identify any impact on your subs and suppliers. On a $1 m project you may be able to do the exercise mentally but a $20 m project your internal work represents $2 m.

I would expect each of your major subs to have some sort of EVM system as they should want to monitor their performance against what they planned and effort applied.

Peter,
I think I answered your question via my response to Keith while you were writing your reply.

just to clarify, some of our supplier's contracts end up with changes to those contracts, without a corresponding change to our Customer's contract.. Some of those changes are increases in costs, some sometimes are reductions in costs. The EVM (methodology?) is able to give us an overall blend of cost / schedule..
Oh, what a joy to be a project manager!

There is a hybrid method which requires managing different subs differently.

On aircraft projects, I have many types of suppliers. Structural parts will generally be build-to-print and we take credit for EV when we release the drawings to create purchase orders. Those may go to several suppliers and I don't even know who they all are.

Other more complex parts such as electronics are defined under specification documents of some type where the supplier has their own development effort to design HW or SW to the specs. In those cases, we usually have multiple planned events in our own WBS related to supplier activities. Releasing the spec to the supplier, PDR & CDR, reviewing supplier engineering, test plans, & test results, first article inspection at the supplier are all things we can take credit for incrementally.

In some cases we do have suppliers who are making changes up to the last minute, and we are mostly flying blind as to what they are doing until we get their product. Those are a big source of problems that we learn just before delivery, or after we receive the product.

My current responsibilities include process improvements for integrating the many supplied parts. In the case where we are mostly flying blind, we are often left with 2 choices: 1) Earlier delivery dates so we have time to fix the problems. 2) Better visibility so we can plan for issues rather than just react to them. 2) Requires contractual changes.

I hear you. I was lucky in that my early project experience predates today's technology. We used pencil and paper, talked to each other and developed simple ways to keep track of stuff. From there the payroll and costing ledgers got computerised but all data was manually collected and handled. Reporting remained a headache as upper management wanted reports based on the costing spreadsheets which were months late and somewhat misleading. Scheduling was a scroll in the field office (not portable and barely readable). As project managers we spent a lot of our time stalling, feeding bullshit up the line and trying to steer a ship with no connection between the steering mechanism and engines. As the project management industry evolved (computers, theoretical models, professional associations, etc) some of us thought that things would be easier. However, it seems that every advancement is accompanied by increased expectations and complications - more forms, quicker response, stakeholder expectations, legal complications.

"Oh, what a joy to be a project manager".
Is it really all that different?
A ride I'm glad I didn't miss.

Keith,
Wow. Yes, almost same as many of the scenarios we deal with! and same kind of remedies.
Roland

Sounds like risk management to me. Identify what could go wrong, determine possible impact and develop mitigating measures which, in this case, would include processes to gage progress. I say processes in the plural as different situations may require different responses. Sometimes we are looking for an all encompassing simple solution where one does not exist.
As noted in earlier comments, sometimes the mitigating measures reduce the risk of occurrence (contract changes) and sometimes the measures reduce the impact (earlier delivery dates).

There is a 3rd mitigation method at the project level: Limiting the number of suppliers in the exception group of little to no progress visibility.

If you can measure the progress of most suppliers, you may be able to accept a few issues and handle their occurrence by planning for surge capacity near the point of scheduled delivery. Those suppliers must be exceptions though (80/20 rule). If everyone sees that accepting issues is the norm, then everyone tries to move into the exceptions group, and the 80% become the problems at which point you run out of people to manage the inevitable wave of crisis management.

This is easier to manage top-down. A CEO can demand there will be no exceptions without explicit approval. It's harder to manage up and explain to the exec level that unless they maintain schedule discipline, everyone will expect a free pass and plan accordingly.

After all, if there is no accountability, who cares if you're on time?