I've worked off and on in aerospace over the past few decades. I started our of graduate school as a programmer on radar and sonar systems. Moving from there to design, then management, then commerical products when aerospace crashed in the late 80's in southern California. I'm back again from the commerical world of IT to Program Management in aerospace.
In a recent forum disucssion a poster "called me out" saying that the world I work in may be unique to the general project management domains. He is right and at the same time possibly missing some of the learnings I accumlated along the way that can be applied outside of building spacecraft. First our world might be considerde unique in that many of the suggested approachs to improving project management for IT already exist:
- Project management, systems engineering, and most other disciplines are considered professional, with PE behind the name on a business card.
- Software systems are usually mission critical in ways not normally found in the commerical world, except in ERP, document management, regulatory systems, process control and embedded systems.
- Personal preferences and desires are pretty much moot. It's the program and the success of the program and your measurable contribution to that success that counts.
- Projects have fixed dealines, usually a lainch date. This launch culture permeats everything. No excuses for delays. Everyone gives 110% when needed and 100% all the rest of the time.
The lessons from this environment that can be moved to general projects - software or other - include:
- Set aside the self actualization as a prime objective – focus instead on the mission, the mission delivered by the team.
- Have zero tolerance for failure, zero tolerance for not doing it right. Tjis doesn't mean perfect or doing it right the first time, but in the end right is the only way to success.
- Ask “how can I do this in the fastest, safest, cheapest way?”
- "How can I do my job better so someone else has a easier time doing theirs," since we’re on a fixed budget and fixed schedule.
- “How can we help the customer figure out what is really needed? Rather than what ‘could’ be built?” – In many cases better is the enemy of good enough.
- Come in every day with the attitude that this is one more day to be knocked down on the way to success.
- Focus on outcomes first – “what have you done for me lately” Forget the discussion of principles if you can’t tell me about the practices as well. Principles don’t fly, practices build things that do.
- Connect project performance with personal performance through measurable outcomes. Assign lead engineers to these deliverables. Let them organize their teams, but assign a single person to be accountable for the success of the deliverable. The team can get their picture in the paper, but the leader of the team is standing in the middle of the group. The caption usually reads “Mike Dwyer and his software development team delivered … on time on budget for the launch of …”
- When things go in the ditch – which they will do every day or so – have a plan B, and a plan C. Focus on getting out of the ditch as soon as possible and back on schedule. Take good notes to avoid the problem in the future.
