Moonshot Projects

A little over 50 years ago Apollo 11 successfully returned from the moon, splashing down in the northern Pacific ocean. Days later, young me, a 14 year old Air Force “brat”, watched with my family as the Navy unloaded the isolation trailer containing the three astronauts from the USS Hornet. We weren’t watching on TV because we were there, in person, at Pearl Harbor.

Shortly thereafter, my family unit rushed next door to Hickam Air Force Base. A family we knew living on base had invited us to a get-together to watch the astronauts ride by on the perimeter road. We were rewarded shortly after arriving when the truck carrying the Apollo 11 isolation trailer with the crew on board drove by. We could see the astronauts waiving through a large, square window at the back of the isolation trailer.

The recovery of the Apollo 11 crew marked the successful completion of the first landing on the moon. It was the first “moonshot” project. While humans aren’t tromping around on the moon in person now (robots do it instead), we’re still taking on “moonshot” projects.

A moonshot, in a technology context, is an ambitious, exploratory and ground-breaking project undertaken without any expectation of near-term profitability or benefit and also, perhaps, without a full investigation of potential risks and benefits.

The truly amazing thing about Apollo 11 was the sheer size and complexity of the project to put a man on the moon and return him safely to earth. As the project team had a hard deadline (“before this decade is out”), it could not afford to fully investigate potential risks. For example, the Air Force wanted the Saturn V to use solid propellant rocket motors which were highly experimental at the time. Instead, the team settled on tried-and-true liquid fueled rocket motors.

Coordinating all of this activity took a lot of time and a huge number of people. Computers of the day simply weren’t up to the task. During a tour several years ago at the Johnson Spaceflight Center in Houston, a docent told me and my fellow space tourists that there weren’t any computers installed in Mission control during the Apollo 11 mission.

While mission control may not have used computers, the Apollo mission did. The Apollo guidance computer aboard the command module was one of the first integrated circuit computers (you can read more about the Apollo Guidance Computer here on Wikipedia). It would be interesting to know how computers supported managing the Apollo project.

For example, the US Navy used the Program Evaluation and Review (PERT) technique developed in the 1950s to identify the critical path in a project schedule for the Polaris missile project. Presumably, PERT started off as a manual effort, but I’m sure that down the road the process was automated (perhaps by IBM, which was a major contractor on Apollo?).

In any case, the true star was the Apollo launch system and spacecraft and not so much the project activities that put Apollo on the moon. But you can get a pretty good idea of the program/project management aspects of Apollo in NASA’s Project Apollo: A Retrospective Analysis.

Managing the Moonshot

Most of us will never have the opportunity to work on a moonshot-type project like Apollo. This is especially true with a project like Apollo because it was a national priority and had the personal involvement of the US President.

But what we can, and sometimes, do is turn a project into a moonshot. In this case, the “moonshot” isn’t delivering a ground-breaker product like Apollo, but making what should be a straightforward effort and complicating it to the point where it becomes easier to go to the moon than to complete the project at hand. To that end, I offer these four pointers designed to prevent a project from becoming a moonshot:

  • Alway keep the goal in mind.
  • Not everything is one, big project.
  • Let the experts do their job.
  • Have the courage to say no.

I’ll expand upon these points in the rest of this article.

Always Keep the Goal in Mind

If you’ve read The Seven Habits of Highly Effective People by Steven Covey, you’ll recognize this as Habit 2 – “Begin with the end in mind”. For Apollo 11, the goal was to put a man on the moon and return him to earth safely before the end of the 1960s (to paraphrase John F. Kennedy).

From a project management perspective, we have a lot to work with to scope-out our moonshot project:

  • Send at man to the moon and bring him back alive. This defines our scope.
  • Return the man to earth no later than December 31, 1969. This defines our schedule.
  • Return the man safely to earth. We don’t want to kill our astronaut in the process of sending him to the moon and back, so this gives us our quality parameters.

The only thing we are missing is a cost parameter, which isn’t specified in the goal statement. We do know that we have to beat the Russians in getting to the Moon and back, so the “sky is the limit” budget-wise.

Generating an estimate with any reasonable precision in 1961 for accomplishing the Apollo goal was expecting too much. However, as the project team became more knowledgeable about building moon rockets, they revised and refined their estimates and reduced the “cone of uncertainty”.

Note that I’m not talking about “accurate estimates” because they don’t exist. You don’t know how “accurate” your estimate is until after the full scope of the project is successfully delivered.

I know of one contractor (on a time and materials type job) that had “very accurate estimates”. Just about every job they did cost exactly what they originally estimated, no matter how long it took them to do it, even with unexpected changes added mid-stream. What was really happening is the contractor had built a risk reserve, based on their extensive earlier experience, into their estimate which was enough to cover most scope and schedule slippage situations.

Getting back to Apollo, while there was a lot of uncertainty in the estimated cost of accomplishing Apollo 11 in 1961. By the time 1968 rolled around, the team had much more information to feed into their estimates on what was needed to complete the job.

It also helps that we have a very clear goal statement for the project to base our estimates upon. It’s really hard to estimate how much something will cost if you can’t define what is being bought. This is especially true in IT projects. In the absence of a clearly defined feature list, much less a solid scope, one shouldn’t expect an estimate with low uncertainty.

When an estimate does come in with a range, say +/- 30%, hanging your hat on the low range in your budget request a risky way to go. When the boss says she doesn’t want you low-balling the project, don’t low-ball the project. It’s not your job to decide if the project is too expensive to undertake. Making the project more palatable by low-balling the cost is undermining the boss’ ability to decide if the project is affordable.

It’s not Always One, Big Project

The best way to manage a big project is to chop it up into a bunch of smaller, more manageable projects. You do this by identifying the logical components of the big project and the dependencies between the components. This exercise also helps with sequencing the “mini-projects”, ensuring that the completion of one project facilitates the initiation of next project. It also identifies potential bottlenecks cause by budget and resource constraints.

Now that you’ve chopped things up into smaller projects, you need a mechanism to coordinate the projects and manage the resources associated with each project. Chances are the projects are not going to unfold sequentially – there will be overlaps and handoffs between projects.

This is where program management comes in to play. Unlike a project manager or SCRUM Master, who’s single focus is on their project or product, the program manager has to keep the bigger picture in mind. For example, if there is a limited number of project personnel available to all of the projects within the program, somebody needs to monitor how the resources are being used on each project and other non-project activities.

Obviously, there’s going to be problems if a resource is committed 100% on two concurrent projects. The solution is to hire another resource (provided there’s enough lead time to hire) or schedule the work on the projects in such a way to not overburden the resource. Critical Chain Project Management (see this article at is a methodology for “leveling” resources across tasks within a project and between multiple projects.

By the way, Agile doesn’t alleviate all resource constraint issues. This is especially true if Agile team resources are used on other efforts within the program or in the case of Agile-hybrid efforts.

The point is that the bigger and more complex the project, the harder to manage. Breaking down big projects into smaller projects makes those smaller projects more manageable. The size and complexity of the program (a collection of related projects, operations/maintenance, and other supporting activities) where the project “lives” determines how much program management is needed.

Let the Experts do Their Jobs

Project Management Professional, Certified SCRUM Master, Federal Acquisition certifications, Certified Business Analyst, and a host of other professional certifications have been available for years. This “alphabet soup” of certifications are an attempt by industry and government to promote knowledge of and experience with different bodies of knowledge that, when properly applied, are designed to reduce risk and improve the probability of success.

Back in the days of Apollo, we didn’t have the professional certifications we do now. Indeed, the software engineering field was in its infancy and much more of an art than it is now (at least for organizations with modern, mature software development and maintenance processes). However, given the requirement to keep the crew alive during the mission dictated that no matter how badly someone wanted to work on Apollo, they at least had to have the requisite knowledge and experience to perform on the job.

That’s not to say that everyone working on Apollo performed flawlessly. Because it was a human endeavor, there were incidents of the wrong person being assigned to a task over their head. Accidents did happen, and people were seriously injured and some killed (the three Apollo 1 astronauts).

One way to add risk to an already risky project is to ignore professional certifications and experiences and assigned well-meaning but unqualified individuals to the project.

For example, on one high profile business analysis project, management allowed an staff member with deep program experience to take over the project despite the fact they had little business analysis experience. The resulting requirements document was a case study in how not to write requirements. Instead of stating the requirements in a straightforward, unambiguous manner, a document more suitable for a policy proposal (befitting of the writer’s experience) was the end result.

The original intent was to include the business requirements document as an attachment to a request for proposals (RFP). The organization had to pay contractor business analysts to convert the document into a set of professionally written, coherent user stories. Combined with the lateness of completing the requirements and the mandated planned completion date of bringing the new solution online, the RFP option was abandoned. The project shifted from the possibility of commercial off the shelf acquisition to custom development.

After not learning from this project, management allowed the same individual to continue on as the de facto project “lead”/solution architect for the development effort. (Management shouldn’t be assigned all the blame for this – the project postmortem was very poorly done. Perhaps a subject for a later post?) Eventually, the project team did deliver a solution, but six months late and nearly ten times over budget.

Unfortunately, there were several design deficiencies “baked” into the system because of technical design decisions made by the project lead. Having an experienced solution architect on the project team would have avoided these deficiencies. Instead, the system will eventually require expensive reengineering, if not replacement, to address these design deficiencies.

A more damaging situation can arise when supervisors are assigned (or self-assigned) to a project team. What can go wrong with that?

If your organization is the kind that takes its best technical people and promotes them into management, then that approach may work. But usually it doesn’t happen that way. Instead, the technical people who are best at managing people (or best at convincing management that they can manage people) rise up to the supervisory ranks.

The problem with having a supervisor on a project team is it undermines the ability of the team to coalesce as a self-organizing, self-motivating entity. Instead of being a “team of equals”, it becomes a team led by a supervisor.

Consider the situation where there is a disagreement on the project team regarding a technical decision and the supervisor on the team expresses their opinion as a decision. If the other team members disagree with the opinion/decision and express their disagreement, are they insubordinate?

What if the supervisor’s “opinion” drives a decision with serious down-range consequences on system design and efficiency? Worse yet, what if the supervisor just “doesn’t get” a fundamental aspect of the system? Is the system revised to fit the supervisor’s notion of the system, regardless of the consequences? Sounds improbable, but I’ve seen it happen.

This kind of situation leads to my last point.

Have the Courage to say No

Conflict is uncomfortable and stressful, so most people try to avoid it. However, conflict, when effectively managed, is a powerful tool for combating groupthink.

Groupthink is a psychological phenomenon that occurs within a group of people in which the desire for harmony or conformity in the group results in an irrational or dysfunctional decision-making outcome. Group members try to minimize conflict and reach a consensus decision without critical evaluation of alternative viewpoints by actively suppressing dissenting viewpoints, and by isolating themselves from outside influences.

A classic example of groupthink is the Abilene Paradox, where a west-Texas family decides, as a group, to take a 53 mile trip to a diner on a hot day in a car with an inoperative air-conditioner. Upon returning home, the family discovers that nobody really wanted to make the trip, but each agreed to it because they thought everyone else wanted to go.

Apollo 1 was supposed to be the first of several manned test flights before the Apollo 11 moon mission. While working on a prelaunch test in the command module, a fire broke-out, killing the three astronauts on board.

Two years before the fire, NASA knew there were problems, but did nothing about it. Using pure oxygen instead air for the atmosphere in the command module was a big risk. Combined with all of the flammable materials in the capsule compounded the risk. The astronauts complained about communications (especially Gus Grissom), but no action was taken.

A big driver in this situation was the severe schedule pressure the project was under. Taking time to fix all of the issues with the command module might have pushed the moon landing out beyond the end of the decade. The risk of having a catastrophic fire in the command module was apparently acceptable compared to the risk of landing on the moon in 1970. 

Most of us work on projects that, as long as we don’t mess-up, don’t immediately kill anyone. But your project may deliver a defective system or product having a defect potentially fatal to the user or a stakeholder. Or, like the example I gave above, deliver a technically deficient system that could take years to fix. Or it could result in never delivering a system at all.

The best way to avoid groupthink is to create a safe environment where team members are encouraged to express their opinions are are not punished for it when they do. It also means everyone should leave their ego at the door. What may be perceived as an objection could be an early warning that something is about to go wrong, like Gus Grissom complaining about the pure oxygen atmosphere in the Apollo capsule.

My first complex project involved upgrading the federal judiciary to a new financial management system. After forming the project team, the project sponsor required that every team member watch the Abilene Paradox video. He wanted everyone to understand what groupthink was and that he wasn’t tolerating it on his project.

Small Steps and Giant Leaps

Eagle, the lunar excursion module (LEM) touched down on the Sea of Tranquitily on July 20, 1969. Like millions of others, young me watched it happen “real time” on television. On July 24, 1969, Apollo 11 splashed down about 900 miles southwest of Hawaii. 

Project Apollo had delivered on its scope. It sent three men into lunar orbit, landed two that walked on the moon, and returned all three safely to earth. Despite the setbacks and the sacrifices (some too great), Apollo, the iconic moonshot project, was a success.

One huge advantage (in addition to being a national priority) the Apollo project had is that it was already a moonshot project, it didn’t have to be made into one. But most project that seem like moonshots really aren’t if you take the time to understand the project goal. If the goal is too big to manage, break it down into smaller goals and design projects around them.

After determining the dependencies between the smaller projects (are they sequential or do some need to run in parallel?), identify the knowledge, skills and abilities the project team will need to complete each project. Assign the best people available to the project and define their roles and responsibilities. Make sure they (and you) understand exactly what they are supposed to do as a project team member.

Define the role of the managers and supervisors on the project, which should be limited to organizational support and advice. Anything more, and chances are they will undermine the project manager’s authority over the project team and override expert opinion.

Don’t forget to define the roles and responsibilities of each project team member. There’s nothing as discouraging as when someone asks you what you do on a project and you can’t give a straightforward answer.

Learn to recognize the “early indicators” of groupthink by educating the team members about what groupthink is and how and why it can happen. Create a project culture where team members feel safe to share information, give feedback, and critically analyze project situations. When tough decisions have to be made, document the alternatives and the rationale for the final decision. Be prepared to seek outside expertise if the team can’t make a decision.

Lastly, sometimes it’s necessary to make a distasteful decision and remove someone from the project team and replace them. Doing so may cause a short-term negative impact on the project, but then again, it may prevent the project from becoming a moonshot.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: