Project Managers and Take-off & Landing Pilots

Back in the days when you were allowed in the cockpit of a passenger airliner to meet the pilots; there used to be a well used gag where one pilot would explain his job was to fly the aircraft at take-off and it was his colleagues job to land the aircraft. At that point his co-pilot would turn to him and say "But I'm a take-off pilot too, not a landing pilot!" "What! Then who's going to land it then!?"
This analogy has got good mileage in our project environment in recent weeks, as we grapple with project resourcing. I hold a supernumary role as the LAN WAN Technical Project Group (TPG) Lead. One of my responibilities is to maintain a list of LAN WAN 'Practitioners' who could be deployed on high value projects.
Where our previous Networks project management group managed to achieve good results was to cast aside the heuristic that a PM really needs to be assigned through out the lifecycle of a project. We found that we were better able to target high-value skills by assigning senior resources as "Take-off Pilots", establishing the beachhead on an account, undertaking the scoping and estimating phase of the project/programme and getting the package of work into a recognisable form. Once this was established, then their role might evolve to being the Programme Manager of the work or they could be lifted out and replaced with a more junior resource that could deliver the project once the rudimentary framework was in place (aka the "Landing Pilot").
Having been the Take-Off Pilot PM/Programme Manager more than once myself, I found this an exciting way to work, as often the biggest hurdles were faced in the initial stages of the project and once things were in a Steady State, well, it got a bit boring to be honest. There is also an opportunity to retain this senior resource in a Governance role as the project continues through the lifecycle; so they retain close contact with the incumbent PM and any big issues which crop up.

The Holy Trinity of Networks: The Tin, the Service-wrap and the Design

I found myself in a situation the other day having to deliver an ad hoc brief on progress with a project I am running. Many years and many service providers later, it is a poorly designed and operated network.

Fair play to my technical colleagues, as they have sought to design a standards-based solution that is not beholden to any one single vendor and allows the widest possible technology roadmap for the client. However the incumbent's product, both hardware and OS, is dogged with problems and limitations, which in order to progress things along has meant that we have been forced to compromise at every turn.

So I had to broach the subject about needing to be look at a Vendor who we know we can do the 'business'. What I came up with was the best way of cataloging the current Vendor's shortcomings and what we felt were critical success criteria for us to recommend a Network Solution:

• The Tin - the hardware must meet the needs of the client and service provider in terms of business case and fitness for purpose (a naughty term but meant here to mean stability etc)
• The Service Wrap - the whole show that the Vendor puts around the pieces of tin they sell you. Pre-Sales, after sales technical support, new releases of firmware/software etc. Design support and general willingness to go the extra mile for you.
• The Design - what principles are we designing this network against and does the solution uphold them? Open Standards, Standards-based solutions, Resilience, Fast Convergance times, Scalability, Single-vendor vs Multi-vendor environments etc

It actually conveyed the point well and also found use as a framework for the technical team that were so busy testing every possible configuration, they couldn't tell me why they were testing specific scenarios. One example, was testing something that they could get to work, but was an unsupported feature from this troublesome vendor. It upheld the Design principles, but I told them if we can't have the Service-wrap with this solution, then it is not worth testing - they thought about it and had to agree.

So I think I will continue to push this 'Networks Trinity' on this project a little longer as a way of restoring some order in the thought processes of all involved.