What role did NASA’s culture play in the Columbia disaster

On February1, 2003, after 16 days in space, the Space Shuttle Orbiter Columbia on its STS-107 mission with a seven-member crew on the board during entering the Earth's atmosphere broke apart. The investigation of the disaster has shown how NASA's culture had influenced the process of handling the problems that occurred before and during Columbia's final mission.

The concept of the shuttle as a reusable vehicle was created in 1970s as a result of NASA's budget cutback. The implemented technologies were experimental, revolutionary and innovative, but there was pressure to make it look routine to buy-in customers. NASA's promises of the reliability, efficiency, and safety of the shuttle had provided substantial funding for the program, but funding still was not enough for the complex design specification. So, some important safety features like an escape system for the crew were not part of the design. Driven by the schedule demand, the final steps of the Columbia's development, including tiles mounting, were not done in the manufacturing facility in California but at the Kennedy Space Center in Florida by engineers. The testing regiments were deviated and analytic models were used to verify the entire system. That was not a normal procedure. Only after the disaster proper tests did identify the technical problem of the Columbia's final flight.

A variation of this problem occurred in the very first of Columbia's flight in 1981 and repeated in every flight since then. It was the foam debris strike during the liftoff that would lightly damage Shuttle's tiles. For all these 22 years this damage became systematic and was not treated by NASA as a serious issue requiring an immediate resolution. Over the time, the defect turned into an accepted risk and a maintenance item after every flight and was treated as a routine. I think this was one of the reasons that it was so hard to hold anyone accountable for the tragedy.

The disaster of another Shuttle, Challenger, in 1986 was caused by a similar constructional issue. The shuttle with 7 crew members aboard perished. The lesson still was not enough for NASA to prevent Columbia's tragedy. NASA's cultural practices of playing “Russian roulette” and the cultural approach of “prove to me that there's something wrong,” instead of “prove to me that it is right” became a crucial barrier for any action to handle the existing foam debris strike damage risk as an elevated severity issue. In the 2002 Atlantis's flight, the foam damage was the “most severe of any mission yet flown”. This didn't strike NASA's management attention and didn't lead it to conduct some serious investigation or at least to install better tracking video cameras to observe and document the damaging events as a source for engineers to better understand the impact of the damage. The pressure to follow the schedule for subsequent mission flights has prevailed over any safety concerns when the Shuttle Program decided to fly Columbia. Sad enough is the fact that the values of the mission's scientific experiments was not high or critical and even was criticized by describing as “childish and elementary”.

The better images of Columbia's left wing taken from the military satellites could have help significantly in assessments of the damages happened during the liftoff. Unfortunately, requests for these images had not followed official procedures and were canceled because of miscommunication. Even from looking at the not very clear existing NASA's own images, engineer Rodney Rocha was very alarmed and concerned about the possible consequences. Despite the fact that event was classified as “out of family”, i.e. not previously experienced, it ended up in the log documented by Mission Evaluation Room managers as a “low concern”. The written guidelines for the “out of family” events were to form the high efficient, well trained Tiger Team to work with agency contractors to analyze the situation. Instead of that ad-hoc group, Derbies Assessment Team (DAT), was formed. This group had a very vague charter and was not familiar with the established procedures of escalation to handle the situation and in particular to make requests for additional data. DAT did not report to the Mission Management Team (MMT), who was making all important decisions, and there was no direct contact between these two teams. Unfortunately, the analysis of possible damages provided by Boeing after using a mathematical tool called Crater had a historical exaggeration in prediction and was discounted by the DAT. The MMT didn't follow the Space Shuttle procedure of meeting daily during the mission. I think this fact is important in the puzzle of all organizational issues NASA experienced. Management's adherence to the schedule for the upcoming flights, the lack of communication, and lack of Shuttle's crew involvement to analyze the situation were the biggest factors in making the wrong decisions. NASA's defensive reaction that there was nothing that they could do is very disturbing and is proof of culture of ineffectiveness and negligence created in the agency.

Refernces; Richard M.j Bohmer, Amy C. Edmonson, Michael A. Roberto. Columbia's Final Mission. Harward Business School.

HBR Case Study – Hewlett-Packard: The Flight of the Kittyhawk (A)

In June of 1992 Hewlett-Packard (HP) announced the company's newest innovation, the smallest (1.3 inch) drive disk in the world named Kittyhawk. The drive was developed by Disk Memory Division (DMD) and had a smaller capacity then the industry's currently existing smallest disk drive. After two years, the effort to achieve substantial sales of this device was not successful.

Prior to the Kittyhawk project DMD had a very profitable position in this established markets. Its high-performance products within 5.25-3.5 inch drives were very competitive due to their drivers having a higher megabytes capacity than the industry norm. The division was making plans for the new 1.3 inch drive disk based on the existing market trends and treating it as a sustainable innovation. The company's plans were to expand its computing market share and make HP a major player in the disk-drive industry.

The main causes for Kittyhawk's failure were as follows:

• The company had failed to recognize the new product as a disruptive innovation that was not ready to compete in the existing market
• The DMD picked the wrong target customers and built the wrong product because corporate expectations left no other choice
• The product could not storm any other emerging market in as short a period of time as was expected
• Positioning on the market was done not based on realistic market opportunities but by the company's aggressive revenue expectations
• Existing computing market trends were driven by capacity and cost per megabyte, not by size. Kittyhawk didn't offer any value for the established markets
• Even having a substantial opportunity in emerging markets, DMD attempted to please customers in established markets, where performance expectations were high. It included features that made Kittyhawk too expensive to satisfy customers in emerging markets.

To avoid Kittyhawk failure HP needed to put into consideration that disruptive innovations often see failure before success. Flexibility is critical to survival. The company could be more flexible by initially focusing on a low-cost drive whose requirements would satisfy the lowest common denominator. This way, breakthroughs in manufacturing and design could still be leveraged in the event that the product architecture needed to be redesigned for higher-margin products.

What could HP have done differently to support the Kittyhawk development team, and implement the marketing strategy to introduce the Kittyhawk product?

• Attract and retain resources experienced in developing new architectures or cultivating emerging markets
• Take into consideration the history of HP's average cycle time for a new disk-drive development time of 18 months and align the project schedule accordingly
• Don't make a statement that this product will be the company's future
• Not try to analyze markets for this product. Markets did not exist yet
• Use in-house manufacturing to provide flexibility while market demand is formed and until the right product is developed.

Symptoms of Ineffective Governance occurs in both IT Governance and PMO organizations. How are they similar in both, and how are they different?

Having an effective governance in IT Governance and Project Management Office (PMO) helps an organization to get the right people to make decisions and improve performance. Both of them have a two-way nature of their functions: IT – Business and PMO – Business. Assessment of the competency, capability and maturity for both governances would demonstrate signs of inefficiency.
Symptoms of ineffective governance are usually listed as follows, first, IT Governance, and then PMO, if there are similarities.

• Senior management senses low value from IT investments.

In situations like this, there is confusion regarding how IT decisions will be made and who will make them, and there is an inability for executive management to access information on the performance of IT investments. Similar to that in PMO, the symptom would be a perception that PMO is costly and useless.

• IT is often a barrier to implementing new strategies.

IT limits market opportunities for the business. IT becomes an order-taker and builds a separate application instead of being the platform for the company's strategic vision. Every application requires it's own infrastructure. Integration between different applications is missing. The implementation of new business initiatives is very slow and delayed in comparison with competitors due to the incapability of the infrastructure to provide the fast solution.

• Mechanisms to make IT decisions are slow or contradictory.

Problems in the decision-making process are often evidenced by circumvention of established rules for IT. One common manifestation of this problem in big organizations is when operating departments set up their own IT functions because centralized IT is perceived as unresponsive and/or ineffective. Decentralization may be a viable alternative,but organizations often jump to this solution rather than fix some of the underlying problems inherent in the existing IT decision-making or implementation processes. For PMO, some of the technical or business units do not address all the needs associated with an effective project management and devise their own methodologies and approaches.

• Senior management cannot explain IT governance.

Managerial incompetency in articulating and understanding IT Governance as a whole and as an enterprise architecture in particularly constrain business processes.
Senior management is not supporting a standard project management methodology and PMO policy.

• IT projects often run late and over budget.

Effective IT governance requires consistent project management, which is one of the main objectives of PMO. Ineffectiveness in IT projects that are shown either by running over budget or not on schedule, thereby raising issues in both PMO and IT Governance.

• Senior management sees outsourcing as a quick fix to IT problems.

If outsourcing is a result of frustration with IT, this is a strong symptom of IT Governance inefficiency. Looking for a fast fixes in IT due to lack of value is not a good problem-solving method in IT.

• Governance changes frequently.

If every change in business strategy or business processes causes a change in IT governance, this demonstrates that it is not effective. A significant organizational change will have impact on PMO, its structure and it's role within an organization. Likewise, successfully implementing or restructuring a PMO will inevitably have an impact on the organization. A co-evolutionary process is in play whereby PMO and the rest of the organization interact and evolve together. If this process is broken, it means PMO is low-performing.

Additionally, PMO weakness will be propagated by evidence of any of the following factors: cross-functional teams are not efficient and productive; stakeholders are not involved and are unaware of the expectations of the project; project management is not valued in the organization; there is lack of consensus regarding the value of the PMO to the organization; the organizational PMO maturity is not evolving.
The competency of personnel is a key issue for PMO performance. The inability to attract and retain competent people is a strong symptom of PMO inefficiency.

Resources:

• Peter Well and Jeanne W. Ross. (2004). IT Governance. How Top Performers Manage IT Decision Rights for Superior Results. Boston, MA: Harvard Business School Press
  

Developing Talent

"Why try to teach a chicken to climb a tree, when you can hire a squirrel?"
- Lyle Spencer -

Quality & Performance

According to Watts S. Humphrey, an expert on software quality and Fellow at Carnegie Mellon's Software Engineering Institute, developers must be responsible for providing error-free code at each stage of testing. Top Management must support developers by letting them self-direct their work. Programmers need to be motivated and exited to do high-quality work and have some control over how they do it. 1

DeMarco and Lister in their study found that there are no correlation between productivity and programming language, years of experience, or salary. Their study showed that providing a dedicated workspace and a quiet work environment were key factors in improving productivity. They suggested that top management must focus on workplace factors to improve productivity. 2

1 Eisenberg, Bart, "Achieving Zero-Defects Software," Pacific Connection ( January 2004)
2. DeMarco, T & T. Listner, Peopleware: Productive projects and Teams. new York: Dorset House, 1087.

Project Management Software

Open Source:

http://www.dotproject.net

http://taskjuggler.org


Low-end:

http://business-spreadsheets.com

Collections:

1. www.projectreference.com : Site created by former Columbia University instructor with lots of great links
2. www.allpm.com : The Project Manager's Resource Center
3. www.4pm.com : Project Management Control Tower
4. www.pmblvd.com : Project Management Boulevard
5. www.tenstep.com : The Tenstep Project Management Process Methodology
6. www.projectsatwork.com : Projects @ Work
7. www.chiefprojectofficer.com : Chief Project Officer
8. www.gantthead.com : Gantthead.com
9. www.pmforum.org : Project Management Forum
10. www.projectnet.co.uk : ProjectNet
11. www.cpbonline.com : The Center for Business Practices
12. www.irnop.org : The International Research Network on Organizing by Projects
13. www.maxwideman.com : Max's Project Management Wisdom
14. www.infogoal.com
    

1.Why selecting a systems development approach is an important business decision? Who should participate in the selection process?

Selecting a system development approach is an important business decision because it can have a big impact on the the time, cost, and end product of the systems development. Depends on the willingness and capability of the organizational change that can be involved in system development different level of risk and return should be taken into consideration. Businesses today required to build applications rapidly to stay competitive. This involves a lot of different departments in requirements gathering and most of cases produces the need of business processes change during identification of pain points and deciding which way to go to resolve problems. Managers should be aware of the different ways of approaches, evaluate and choose the right one depending on the type of organization, it's own resources and desired controls over the process. All stakeholders should participate in the selection process.
During the Business Process Reengineering the first step of identifying which business processes need improvement and have a highest priority requires a strategic analysis and pain points determination by Senior Management. Identifying and describing existing processes, understanding the process costs and process duration bring to the next step of decision how to improve these processes and can involve different layers of organization and even multiple companies if they are part of the shared processes.

2.Some have said that the best way to reduce system development costs is to use application software packages. Do you agree? Why or why not?

If the organization doesn't have internal resources and have pretty standard business processes that can easily be set up in the application software package, it is a good way to go in case of right choice of the best vendor solution. Some vendors are specialize in industry preset solutions for their systems. If organization has an unique requirements, then customizing the packages can be very costly and create a hassle for the future software upgrade and maintenance.