The influence of Technical Authority on the Project timing can often cause tension with the Project Manager. This somewhat traditional battle is usually because the Technical Authority looks for answers that are the cleanest, elegant and most technically correct, whereas the Project Manager is usually looking for solutions that will give him the best position in a negotiation with the customer (usually time, cost or scope reduction) and the business.
If there was nothing technically challenging to a programme, there would be no risk, no need for a technical authority and the project manager would only need to progress chase the various packages of work, their cross-feeds and dependencies, externally supplied equipment, subcontracts or services. But if you’ve ever done an objective 3-point estimate on a software programme, you will recognise that the ‘ahead of time, on content, below cost’ area is very close to the ‘on-time, at cost’ marker …and all too frequently that tail programme (post the nominal ‘should-cost’ point) could run to two or three times nominal duration (or of you are in a Nuclear programme, probably 6 to 10 times!).
As a Technical Authority you want the Project Manager to help ‘manage’ the customer’s expectations, stop the customer making changes and generally damp his volatility. Additionally you want him to actively manage all your supply chain feeds, so that any dependent material or service arrives on time, is appropriately validated and commissioned, fully functional and well supported. You also want him to manage the department politics, reporting and any other administrative distractions, like presenting the product architecture a 100 times! Contingency for you is tolerance for dealing with things you might have overlooked, or due to the summing errors of a myriad of low-fidelity component costs.
As a Project Manager you want the Technical Authority to clearly identify the risks in the programme, how his product (solution) architecture mitigates, or accommodates change (brought about by those risks… and any reasonable change that the customer might want), and that all the quality attributes (cost, performance, safety, etc) have been thoroughly reviewed, by an appropriately skilled peer group, to give you that warm confident feeling. You want to see that all the disciplines (electronics, software, firmware, testers, etc) are aligned in their technical understanding, are clear on the product partitioning (and implicitly the boundary of their work and explicitly its interfaces) and in agreement on the ability to deliver their part against the programme dates. Contingency for you is your margin (against the Technical Authority’s failure) to ensure success at appraisal.
So why the tension between these senior positions? Surely their objectives are the same? Well… yes, but no… I’d also refer you back to an earlier instalment on personality types in ‘Managing Engineers’.
In being assessed against his objectives the Project Manager will likely be judged on Quality, Cost and Delivery; Cost and Delivery he controls by virtue of programme duration and resources (which he owns) irrespective of the technical impact; and quality… well that’s up to the Technical Authority to deliver… and it’s pretty subjective anyway (in the way a Project manager reports it!). Project Managers tend to be like teenagers, they know the price of everything, but the value of nothing. In short they are driven by praise from their seniors and its promotional connotations.
The Technical Authority will be judged on how well the solution meets the customer’s current expectations (not necessarily the specification!) including all those changes, how robust it is and how pleasant the final system is to use. (Note that none of this assessment will care about how technically pure the architecture was, or how clever some particular feature of the design or implementation is executed, that the solution is ideally placed for future extension, or that its creation was severely hampered by being denied sufficient capacity and capability of resource at the appropriate times as defined in the plan). In short, he will be judged in the same way that most consumers judge books or wines, by their covers or labels… and the price, whilst affordable.
The key to ensuring cohesion, is to use the Change Control process equably for both Technical and Programme changes, peer reviewing the impact, and making PROJECT decisions (both Technical and Programme) for ALL change… as there is no such thing as a No-Cost change! This ensures that programme changes are NOT entirely at the disposal of the Project Manager, and Technical changes are NOT entirely at the disposal of the Technical Authority.
___________________________________________________________________________
Let us help you maximise the business potential of your product and its software
Email me on stuart.jobbins@sofintsys.com
Visit our website, or follow us on your preferred Social Media for our latest views. 
___________________________________________________________________________