A Big Hairy Audacious Goal (BHAG) is a clear, compelling vision that is intended to serve as unifying focus and catalyst for team spirit, volunteerism, and discretionary efforts. Such goals typically have long-term horizons, clear finish lines, and sufficient clarity to motivate participants to establish and sustain the commitments required to achieve the desired outcomes. Synergy often plays a role in pursuing such BHAGs, as sharing of assets (both knowledge and physical), coordination of strategies, and pooling & integration of resources and components are brought to bear in ways that would not otherwise arise from 'normal' market forces. Several notable examples of such BHAGs come to mind.

Since November, 2000, we humans have permanently occupied outer space (though only in low earth orbit) in the International Space Station (ISS). This endeavor, and its goals of supporting sustainable space exploration, are clearly a BHAG. The International Space Station Program established the endeavor, and coordinated the efforts required to achieve these goals, and establish obligations and rights between the affected partners. The program was launched in 1993 in an agreement between the United States of America and the Russion Federation; both already had independent efforts to launch their own permanent facilities in space, and saw benefits in collaboration; Japan, Europe, and Canada were added by agreement in 1998. Since then, the UK has withdrawn from participation, and 6 other nations have joined. The dynamics of this collaboration have evolved over time, and the US has played an increasing role as financier, rather than builder, of the capabilities, in an attempt to broaden international participation.

The ISS in orbit assembly began in 1998, and was originally to have been completed by 2003. It is now expected to be completed in 2011. Two of these eight years of delays can be attributed to the Space Shuttle Columbia accident. Yet upon this 'completion', only 10 of the 14 modules that were originally envisioned for the station will actually be integrated into the final system. These reductions significantly diminish the ISS's usefulness as a platform for scientific experiments. While many experiments have been possible, approximately 85% of the time our astronauts spend on board the station today is spent on assembly and maintenance, rather than performing the experimentation that the station was originally intended to be used for. Planning for future experiments is complicated by the fact that the Space Shuttle, the primary means of accessing the ISS, is scheduled to be retired in 2011; its replacement, the Ares I/Orion launch capabilities, will not be operational before 2014 at the earliest. As a result, the ISS has diminished capability and capacity, and may only be operational through approximately 2015.

Estimates of costs for the ISS program vary, but $100B appears to be a conservative lower bound for the total investments that will have been made by all countries, upon deorbit anticipated in 2016. Determining the actual expenditures across partner nations can be very difficult, since contributions are rarely transparent, and conversions into an equivalent financial basis over time are impractical. Despite this, the risks of such development and operations were clearly  underappreciated. Additionally, such total costs must include the infrastructure required to support launches for the Shuttle program and companion Russian Roscosmos capabilities, ground support, etc, which extends these numbers considerably. Benefits realized from such investments are even more difficult to evaluate, though the magnitude and contribution to spinoff benefits are generally disputed, 

When the $100B figure is compared with the original budget projection of $8B, it becomes clear that none of the 3 areas of focus for project managers - functionality, cost, and schedule - were successfully realized. This is despite considerable oversight, extensive application of best practices, and numerous changes in scope, plans, and strategies.The tragedy is it appears any notion of value is entirely missing from such considerations - tragic since the opportunity cost can have significant impacts beyond the space program itself. As National Air and Space Museum historian Roger Launius has noted, “It’s always easier to draw these things than to build them.”

It is generally accepted that bringing all areas - cost, schedule, functionality, and quality - together at once is nearly impossible for anything but the smallest of projects. Most successful projects make a concerted effort to target just one of these factors, 'aim' at the second, and 'adjust' the third. The prioritization of these factors is a crucial part of any development strategy, but must be considered even more important, when the participants operate under different political, cultural, and economic systems and constraints.  It appears the ISS's project management strategy may have originally been to target functionality, only aim at schedule, and adjust cost accordingly. The ISS is the poster child for the challenges of managing complex projects, since legal, political, and financial aspects of the program are highly interrelated, and included ambiguous roles and responsibilities regarding ownership of modules, how the station was to be utilized by participating nations, and who was responsible for station maintenance, operations, and resupply.  Since the space station became a collaborative effort of many different countries, these scenarios and the constraints imposed by each of the cooperating partners - funding, technology, capabilities, and political commitments - impacted the ability of the collective enterprise to develop and utilize the facility as originally intended, and in turn, eroded the value that was realized from the overall program (though even those goals are still seriously debated).

On a much smaller scale, these factors mirror my own experience with another BHAG, the center of excellence established by 14 aerospace companies at the Software Productivity Consortium. The SPC (now known as the Systems and Software Consortium) was formed in 1986 to provide solutions which would close a perceived gap between the supply and availability of software talent within its member companies. Such consortia typically sponsor activities of member companies which pool their resources to pursue a common goal.

The SPC's original scope was focused on software-intensive systems, with an emphasis on large, complex, mission-critical systems, and a belief that there were innovative solutions 'out there', just waiting to be discovered and implemented. A team of 100 people was recruited to form the consortium, a large percentage of whom were from academia, and were attracted by the opportunity to see their prior research efforts applied more broadly within industry. Tool development, reuse, process improvements, and architecture received special emphasis within the consortium's annual technical planning efforts. However, by the time the SPC had distributed their resources across multiple projects, and developed insights about the state of practice within member companies, it became quite a challenge to lay out a roadmap that was appealing to a majority of the SPC's members. While SPC had a 'honeymoon period' of about 3 years, they knew they had to deliver enough value to justify each of the member's ongoing annual fees of one million dollars. As a result of this pressure, projects were unrealistically scoped, ambiguously defined, and teams were constantly being pulled in multiple directions by the consortia leadership and advisory boards, as producers and consumers tried to extract value from this collaboration.

It quickly became evident that even with their 'annual endowment', it was difficult to structure projects that provided common benefit, since member companies were actually quite heterogenous themselves. Further, member companies needed to invest considerable additional resources in order to influence, evaluate, and tailor deliverables so that these deliverables were 'production-ready' for real-world applications within these member companies. Since the different member companies had a range of capabilities both within their businesses, and across the companies, it became evident that SPC would be most successful by positioning their offerings in the middle of this spectrum, since that was where the broadest applicability was. However, it was also the area in which they were least prepared to deploy, since the number of people and projects at member companies was far greater than what the consortium could directly support by themselves, and since there was no reliable support plan in place across member companies. Additionally, their mid-range focus often meant that they were offering knowledge that was already available (somewhere) within significant parts of the member companies themselves. As a result, it became evident that putting SPC in the middle of either technology development or knowledge transfer was not a sustainable or scalable business model for them, or for member companies.

Over time, founding members lost patience with what capabilities were actually being delivered by SPC.  As members began to drop out, approximately 5 years after its founding, SPC attempted to simultaneously change their business model (adding smaller 'affiliate members'), and expanded their mission to include both systems engineering and software engineering, believing that this would broaden their appeal. Unfortunately, it also diminished their product stream. Simultaneously, they sought to provide methods applicable to both embedded systems and information technology applications. Unfortunately, both of these tactics eroded the future value perceived by existing, premium-paying, 'founding members', since once you had a deliverable, you no longer needed to keep paying $1M per year to use it. Over time, the consortium's survival itself, rather than a well-designed value proposition to the member companies, became the primary focus of the teams. Today, although much of the content originally developed remains available through subscription, the SSCI's product stream is no longer attractive, and continued operation is only possible through annual subsidies from government sponsors.

The pattern seen here in the SPC/SSCI case is similar to what was observed in the space station. First, an ambitious goal is established. Then, a pool of shared (but inadequate) resource allocations is provided. Next, a changing mission and participation dilute the value proposition as it was originally defined and communicated to those making the business investments. Over time, this results in a growing gap in competitiveness with alternatives, until the effort can no longer service the most critical needs of the customers it was originally created to support.

In hindsight, I have always found it fascinating that SPC's original mission envisioned collaboration, reuse libraries, tools, and processes. In parallel with SPC's pursuit of their mission, a parallel industry movement was emerging at the same time, which adopted and exploited open source software. One only needs to examine the number, size, and impact of such projects on our industry to recognize that many of the original SPC themes - reuse, tools, methods, and architecture - were exploited within the open source movement. Such changes did not arise 'top down', but rather emerged 'bottom up', and have had the kind of sustainable effects which were envisioned when SPC was founded.

From these two case studies, I believe the following observations can be made:

1. You should not commit to schedules until obligations and rights of the endeavor are well defined
2. You should be realistic about what it will take to accomplish project goals, while remaining open to adjusting those goals over time
3. You should have a clear focus on the realistic service life of assets and technologies which will be required for success
4. You should have a credible business model that provides for a sustainable delivery and support of what is valued by customers over time
5. You should recognize and manage the risks that politics and the broader economic environment may have on the project
6. You should not hesitate to redirect investments when they no longer make economic sense
7. You should tie continued participation to continued value delivery as participants evolve over time