The Project Is Dead, Jim

One of the publications to which I subscribe at work is CrossTalk: The Journal of Defense Software Engineering, published by the USAF (Air Force), DHS (Homeland Security), and the USN (Navy). The October issue is titled “Star Wars to Star Trek: Science Fiction Influencing Real World Technology”, and is quite fascinating, especially to a SF buf like me.

There are a number of articles in the issue, but the one I felt was worthy of note was Leadership, The Final Frontier: Lessons From the Captains of Star Trek.This article looks at the advantages and disadvantages in the approaches used by each Star Trek captain and how managers can use the lessons taught by the captains. It explores the different management styles of each captain, and what they did right and wrong. To give you some ideas of what is said (note: the author actually mispelled some names):

  • James T. Kirk. The first captain to appear on Star Trek was an energetic, hands-on leader. He led every crew excursion to new planets and took an active role in all interactions with new civilizations. Captain Kirk also relied heavily on his crew, especially his science officer, chief engineer, and doctor. He pushed them all to succeed but depended on their counsel to help him make decisions. His crew knew who was in charge, but responded to his call for their input and did their best to answer his needs. From Captain Kirk, managers can learn the power of involving and empowering their staff.
  • Jean-Luc Picard. Captain Picard commanded a new version of the same starship as Captain Kirk and led with a different style. Captain Picard was a more stoic commander. While he showed humor and compassion at times, he clearly held the position of authority on his ship. His approach made use of his resources in a different way than Captain Kirk. Captain Picard would send an away team to any encounters on new planets. His crew entered the dangerous situations and explorations. They would relay information to the ship where Picard could lead them based on what they provided. Picard showed managers how to gather and use data better than any other Star Trek captain. He would collect the data from his away team and then issue an order to make it so. That is not to say that Picard was uninvolved. He allowed his people to explore and deal with situations, but he always stayed informed and would act when the time was right. He was less likely to jump into a situation the way that Captain Kirk would but used his staff and information to their best potential.
  • Benjamin Sisko. The commander of the Deep Space Nine base found himself isolated from the mainstream of the Federation and was forced to deal with warring factions. Placed between the Cardassians and Bajorans, Sisko had to be well versed in diplomacy. Taking over the base from the Cardassians, Sisko dealt with the transition from the old rule to the new Bajoran independence. Managers can find themselves in this same situation as projects change over time. It is not unusual for existing software projects to convert to a new technology. This often means starting a project within a project. The old guard and the new project compete for the same resources and the same attention from the project manager. That manager could learn a lot from the way Sisko balanced the needs of the new Bajoran majority with the needs of the withdrawing Cardassians.
  • Katherine Janeway. The captain of the Voyager faced a unique situation in the Star Trek world. She found her ship and crew mysteriously transported across the galaxy to uncharted space. Her mission was to find a way home. Managers of new projects within an organization can feel this same way. This is especially true if the project is something new that the organization has never tried before. In the software world, this often happens with new development projects using new technology. Managers are forced to set their own direction. These projects usually depend on experts in the new technology. Their opinion often drives the course of the project. Managers need to focus this knowledge and expert opinion to meet the project’s needs. Captain Janeway relied on the expertise of her crew to deal with resource shortages, equipment needs, and unexpected challenges. She pushed the creativity of her staff to deal with problems.
  • Jonathan Archer. Chronologically, Captain Archer was the first Star Trek captain. He set out on the first Enterprise years before Captain Kirk. Archer faced a number of challenges similar to those of Captain Janeway. While his mission was more clearly defined, he was the first human captain to set out in a starship. He made a number of the rules that the later captains followed. Managers of projects dealing with new technology find themselves in this situation. New, cutting-edge technologies become stable, old technologies. The lessons learned in the first projects with new technologies were vitally important to future successes. All of the captains kept a log that contained their lessons learned in both success and failure.

Quite an interesting article. The theme continues in the Open Forum, where there is the article All We Need to Know About Software Project Management, We Can Learn From Watching Star Trek, wherein the author discovers The Gene Roddenberry Effect: Everything we do in software project management originated with Star Trek. He draws an analogy between the composition of the bridge crew on the starship Enterprise to that of current software teams:

TSP Roles Bridge Crew Role Bridge Crew Member
Team Leader Captain Krik
Customer Interface Manager Communications Uhura
Design Manager Science Officer Spock
Implementation Manager Chief Engineer Scott
Planning Manager Navigation Sulu
Process Manager Operations Chekov
Quality Manager Medical McCoy
Support Manager Science Officer Spock
Test Manager Chief Engineer Scott
TSP Roles Bridge Crew Role Bridge Crew Member
Senior Management Captain Picard
Team Leader First Officer Riker
Customer Interface Manager Security Worf
Design Manager Science Officer Data
Implementation Manager Chief Engineer LaForge
Planning Manager Navigation W. Crusher
Process Manager Operations Data
Quality Manager Medical B. Crusher
Support Manager Souncilor Troi
Test Manager Chief Engineer LaForge

He goes on to draw a number of lessons learned, including:

  • When push comes to shove, it’s always a computer geek who comes to the rescue!
  • Your greatest challenges can be the ones you thought you got rid of 200 years ago.
  • If everyone on your project is too happy, you probably are not accomplishing anything.
  • You cannot change the laws of physics, but you can bend them.
  • There is no such thing as a no-win scenario, especially if you change the conditions of the test.
  • Every successful project manager has both a good side and bad side and knows how to balance them.
  • Don’t feed the Tribbles or they will overrun you!
  • If you do not apply a lot of power to break away from your routine, you are doomed to repeat the same mistakes over and over again for eternity.
  • Some people can be very afraid of change.
  • Always multiply your estimates by a factor of four so that you will be known as a miracle worker.

(I personally live by the last one… oops, did I say that with my public fingers).

In any case, it is quite an interesting issue, and something I never expected to see in a USAF publication. Highly recommended.

Share