Thursday, January 31, 2008

The Demise of Apollo 1


Ad Astra per Aspera
(A rough road leads to the stars)


A seminal event in the history of human spaceflight occurred on the evening of January 27th, 1967, at Kennedy Space Center (KSC) when a fire ignited inside a spacecraft during ground test activities.

The 100% oxygen atmosphere, flammable materials and a suspected electrical short created a fire which quickly became an inferno.

Virgil Grissom, Edward White II, and Roger Chaffee (the prime crewmembers for Apollo mission AS-204 – later designated Apollo 1) perished in the flames before the hatch could be opened.

***

On that Friday afternoon, the crew entered the spacecraft to perform an important launch countdown rehearsal test.

For the next three hours, the crew and ground personnel performed tests.

Tragedy struck at 6:30 pm, about 5 ½ hours after the start of the simulated countdown, when a significant transient in the AC Bus 2 voltage was observed. The transient indicated a major short circuit somewhere in the CM wiring.

A crew member, speculated to have been Grissom, exclaimed “Fire! We’ve got a fire in the Cockpit!” another voice, thought to have been Chaffee, whose job it was to maintain communications in an emergency, said “We’ve got a bad fire – let’s get out. We’re burning up!”

Before he could finish his sentence, the pressure inside the spacecraft had built up to more than two atmospheres. The spacecraft ruptured, and the cabin filled with toxic fumes.

Rescue teams, fighting the fire and smoke escaping the cockpit, were able to remove the hatch door within 6 minutes. But by then, the entire crew had been lost.

Cause

The report of the Review Board stated that “the fire was most probably brought about by some minor malfunction or failure in equipment or wire insulation… This failure, which most likely will never be positively identified, initiated a sequence of events that culminated in the conflagration.”

Underlying Issues

The Review Board identified a number of underlying control weaknesses that lead to the tragedy:
  • Vulnerable design and material choices for wiring, atmosphere, cabin materials, and an inward opening hatch door.
  • Poor quality control and workmanship. KSC Quality Inspectors cited multiple deficiencies concerning equipment, parts, procedures, workmanship and contamination.
  • Inadequate provision for emergency response, rescue and medical assistance. There were no contingency preparations or procedures for internal Command Module fires. Emergency equipment was not designed for the high levels of smoke and fire experienced. Fire, rescue and medical teams were not initially in attendance when the fire started.
  • Budget and schedule pressures resulted in the over-prioritization of speed to completion. Cost overruns and schedule delays were acknowledged as contributing factors to the design, manufacturing, and quality control process issues.

Lessons Learnt

  • Past successes do not obviate the need to continually reassess the rationale for accepted risks. NASA had “successfully” logged over 1000 hours of flight time under the same conditions before the Apollo 1 fire.
  • Expertise in materials properties throughout a defined and understood range of operating conditions is crucial. Teflon may have been the correct choice for insulation and fire resistance, but it was the wrong choice for resistance to deformation and damage, leading to a string of cascading failure modes and effects.
  • Isolate failures and prevent them from cascading into system failures. The faults in using mechanically soft insulation to protect against an electrical spark in a 100% oxygen atmosphere in a sealed room full of flammable material with an inward opening door can only be seen through a systems mindset.
  • Don’t let today’s solution become tomorrow’s problem. The inward hatch design was a direct response to an earlier failure in the outward design.

Friday, January 25, 2008

The Largest Fraud in Investment Banking History


This was a lone man who built a concealed enterprise within the company and who had the intelligence to escape all control procedures.

This morning in Paris, Société Générale (SocGen) – one of the pillars of French finance – announced a €4.9bn (US$7.2bn) fraud – the biggest fraud in investment banking history.

The fraud was committed by a 31 year old Frenchman Jerome Kerviel – an employee of SocGen since 2000.

The fraud is five times the amount lost by Barings trader Nick Lesson.

SocGen described the fraud as “exceptional in its size and nature”.

It noted “aided by his in-depth knowledge of the control procedures resulting from his former employment in the middle office, he managed to conceal these positions through a scheme of elaborate fictitious transactions.”

SocGen have been forced into an emergency €5.5b cash call on shareholders.

Kerviel – on a salary of £75,000 – appears to have acted alone and did not profit personally.

The CEO of Soc Gen and his depute offered to resign but this was rejected by the Board. They have both given up their salaries until June 30 to take responsibility for the losses.

Kerviel and up to six people in the chain of command above him have been sacked.

The current whereabouts of Kerviel is unknown.

***

What He Did

Kerviel risked billions of euros on equity derivatives – in effect betting on future movements in European stock markets – and created elaborate fictitious hedging positions to cover his tracks in a covert scheme.

It has been estimated that to lose such a large sum Kerviel must have had open positions of up to US$50 billion.

Kerviel was not employed to make educated guesses on which markets would go up or down.

He was supposed to look at the bank’s portfolio and bet in the opposite direction, to minimise risks for the trading book. So if SocGen’s other traders had bought in the equity markets, expecting a rally, he was responsible to hedge some of this risk through trading index futures.

His job was to neutralise risk.

SocGen said it had no indication that the trader — who joined the company in 2000 and worked for several years in the bank’s French risk-management office before being moved to its trading desk in Paris — “had taken massive fraudulent directional positions in 2007 and 2008 far beyond his limited authority.”

SocGen was first alerted to the fraud late last Friday, following a whistleblower report from another trader.

SocGen have been criticised for covering up the fraud for three days before the announcement and have been criticised for not involving the police at the first available opportunity.

How He Did It

SocGen have filed a compliant with Paris prosecutors accusing the trader of falsification of banking records, use of such records and computer fraud.

Kerviel appears to have built up his losses over a short period of time, with the bank saying that he used other employees’ accounts and password.

The Internal Control Breakdown

The problem in this instance appears to be that the trader was formerly a risk controller who knew his way around the system.

Following Barings, there are three standard control levers to mitigate the risk of rogue traders:
  • Cash flow – all transactions are monitored and the flow of cash traced.
  • Straight through automated processing – no dealer can operate autonomously from their own desk. Every trade automatically goes into the central system and is registered in accounting, cash management and risk control. Every transaction is stored on the system in real time.
  • An independent middle office – where the risk controllers sit. Risk controllers are the gate keepers who monitor the cash flow and clear any trades or requests handled by dealers.
    Kerviel had formerly been a risk controller.

His knowledge of the control systems equipped him with the imagination to get round both the first and second levels of controls.

SocGen’s principal failure was allowing a risk controller to become a trader.

Commentators have suggested that the fraud revealed bigger weaknesses in the risk management system of the bank.

“One person could engineer it, but how could one person finance it” asked the Chief Executive of Cantor Fitzgerald. “The question for the risk management department is: How was this kind of fraud financed? Where did that Money come from?”

The Fraud in Perspective

To put the amount of the fraud in perspective, the amount of losses could:

  • Fund the building of the London 2012 Olympic site at its original estimate.
  • Is bigger than the gross domestic population of Honduras
  • Would have bankrolled Britain’s first three years involvement in the Iraq conflict.

Monday, January 21, 2008

Anatomy of a Hack Attack


This isn't a great situation to be in. They've opened the back door but now they've also got a key to the front door as well.

Monday, 9am

Blackjack, a hacker working from an internet cafe in Melbourne, is about to launch an attack on a major government agency. His aim is to cause maximum disruption and embarrassment.

Blackjack has spent weeks researching his target, identifying names of employees, partners and current projects.

He has identified a potential way into the network through People Inc, a staffing agency that provides temporary workers to the public sector and which has direct links to the government agency's website and HR database.

Using tools that are available online, Blackjack is able to identify People Inc's web server and database server and then uses a simple technique to gain access to the web server.

This is a relatively common and simple hacking technique.

Basically, the attacker uses the existing interface but, rather than entering information, they write a command for the back-end database.

For example, rather than entering a username, you command the database to send back a list of usernames and passwords.

Monday, 12pm

By lunchtime, the hacker has gained access to People Inc's web server, and he is able to access usernames and passwords which will gain him full network access. At this stage, there's a good chance People Inc won't even notice that its systems have been compromised.

Most corporates spend money on firewalls and intrusion-detection systems but they don't do anything to prevent web attacks.

Very few have application layer gateways, so attacks on websites are very easy to miss.

With full network access, Blackjack is able to easily identify the connection to the government agency and quickly access the server that runs its payment website.

Within minutes, he has identified an open port and used it to access the payment server, where he runs a malicious script to trick the server into revealing the usernames, passwords and payment histories of thousands of users.

Monday, 3pm

The government agency has more sophisticated firewalls and intrusion-detection systems than People Inc, and the IT security team is alerted by a series of odd characters and sequences that something is happening on the web server.

However, it's not immediately apparent that the system has been compromised, and no alerts have yet been triggered.

When you go in as an attacker during a penetration test, it's relatively easy to be undetected, providing you don't start changing or deleting data.

Monday, 4pm

The hacker's next step is to create a new administrator account on the server — he knows the likelihood of this account being deleted in future is slim, even if staff don't recognise the name associated with the account.

With this account, he copies some data from a database table and deletes a series of security profiles — eventually triggering the government agency's IT security systems.

When the IT manager on duty sees the alert from both the firewall and intrusion-detection system, he realises an attack may be in progress.

He immediately asks for copies of any logs that are available, including the web server, database, firewall and intrusion-detection system. These logs should reveal what requests were made to the database and web server, and help to locate any attack scripts. This job should be overseen by a security specialist, as it can be hard to locate scripts created by an experienced hacker.

Completing this audit before disconnecting any machine from the network is absolutely vital.

If you panic and simply pull the plug out of the wall, you will lose a good deal of evidence because of volatile memory footprints.

You also lose any track a hacker may have left of what they have accessed or changed, and it makes it much harder to see what they are doing if there are no active processes running.

Moreover, if you don't know what's happened, there is no guarantee the hacker isn't still hiding on the network.

Back at the government agency, the logs reveal that the agency's web server has been compromised and, more seriously, the database server holding web-payment records and user IDs for thousands of citizens has been accessed and some records deleted. The user IDs and passwords of the database administrators have been accessed.

Monday, 4.30pm

Now that he has a clearer idea of what has been compromised, the head of IT calls the chief information officer, who immediately informs the chief executive of the security breach. The chief information officer also informs the police.

Informing the authorities is often a regulatory requirement, but it's also important to give them the chance to help identify and track down the culprits.

The chief information officer and the chief executive decide to delay issuing a public statement until there is more information about the security breach itself.

It is important to inform the authorities early on in an attack situation, before all evidence that might trap the hacker is lost.

Although it's often a very slight chance that a hacker could be identified and caught, it's important to warn the police before you do anything that tips off the hacker you know about him.

It's also important they can come in before the audit trail is lost.

Monday, 5pm

The head of IT meets the chief information officer and IT security specialists to devise a plan of action.

The agency has a well-established policy for dealing with security breaches, which means staff are less likely to panic and make poor decisions in a crisis.

While the action plan is being formulated, the agency uses an automated tool to block the IP address of the hacker. An automated tool is often the best option in this situation, since, as soon as you block a hacker's IP address, he will often switch to another IP address within seconds.

Monday, 5.30pm

One team of IT staff is dispatched to examine the web server, the server is temporarily taken offline, and a "closed for essential maintenance page" is posted on the website. The clean-up team runs a full antivirus check on the web server and uses the previous day's backup disk to verify that nothing on the server has been deleted or amended.

The head of IT realises that just rebooting the system isn't an option, since it would compromise evidence but could also prevent the clean-up team from easily seeing what has been done while the machine was running.

Auditing the logs and examining the requests made to the server reveals that the hacker exploited a known vulnerability in the server operating system to gain access to the system, and this weakness is immediately patched.

The clean-up team also ensures that all other patches to the server have been applied, and that there are no other known vulnerabilities that could result in the server being attacked again. It's important not to apply patches or make any system changes until this investigation is complete. Making untested or ad-hoc changes to an application could just add further vulnerabilities.

This is a real danger if a hacker is determined to target your organisation.

The ultimate goal for many hackers is to take a server offline within minutes of it going back online. So it is vital not to reboot a server unless you are absolutely confident you know what the problem was and that it has been fixed. Otherwise, you'll be up and down for three days trying to sort it all out.

At the same time, a second team is examining the compromised database server. The database is relatively complex and has links into multiple other agencies and systems. After examining the logs and audits, the investigation team realises the hacker has created a false administrator login to the machine.

From here, the hacker accessed a number of user IDs and passwords, then moved on to look at financial records and security documents, and deleted some records altogether.

The priority is to discover which records have been accessed and to compare the database with the most recent backup to look for changes or deletions. Since it is possible that credit-card and direct-debit details may have been accessed, the chief information officer immediately informs the relevant banks of the potential breach.

Monday, 8pm

A subsequent scan of the server for malware or other scripts shows a number of scripts and programs have been added, including rootkits that could be used to further compromise the network. At this point, the head of IT makes the decision that cleaning up the machine will be too time-consuming, and decides to simply install a new server in place of the affected machine.

Monday, 10pm

The next task is to update all the organisation's security patches and run a complete check for malware, viruses or other attack scripts.

The firewall and intrusion-detection system are updated, and a team of forensic computing experts arrive from a specialist consultancy to begin checking the logs and audits to see if any other systems have been altered or accessed. This team will be able to spot modifications or potential attack scripts far more easily than a general IT specialist.

Tuesday, 8am

After overnight testing and a comprehensive patch update, the web server goes back online, along with the new database server. Although there seem to be no problems, the systems and all logs are closely monitored for any sign of attack or irregular behavior.

The team are also closely monitoring the internet for any sign that the credit-card numbers accessed have been posted online, or offered for sale.

As an added precaution, all payment facilities are unavailable during the following 24 hours, until the team is certain the new servers are functioning properly and are fully secure.

Tuesday, 8.30am

Once the systems are back online, proceedings in the aftermath of the attack begin.

First, the chief information officer meets with the chief executive and other senior government officials to discuss what information was taken, who needs to be notified of the attack and how the organisation might be affected.

In this case, since the information accessed includes payment records (including credit-card numbers), it is decided that the agency should issue a public statement explaining what information has been accessed and what the potential consequences of this might be. Consumers are instructed that they will be issued with new user IDs and passwords for the website, and banks will cancel and reissue credit cards for consumers affected by the breach.

Telling people the bad news is tricky but, if you want to retain their trust, it makes good sense. It also makes sense because, if people are aware of the danger, it limits the scope of the damage, by putting them on their guard.

And then …
Once these initial response steps are completed, anyone recovering from a hacking attack should:

  • Review the attack with relevant IT staff: what happened; how can we be sure it won't happen again?
  • Ask what vulnerability was exploited and what others might exist that are unknown
  • Audit the IT security systems to see whether you need new firewall/intrusion-detection/antivirus technologies, or whether an application layer security device would prove worthwhile
  • Ensure that your policies and procedures are kept updated, and incorporate any lessons learned from this attack into a policy for future incidents

Monday, January 14, 2008

The Corrupt Boss

The fraud resulted in a loss of position and reputation and he was subjected to substantial ridicule and humiliation.

Brian Quinn was appointed the Managing Director and Chief Executive Officer of Australia’s (then) largest retailer – Coles Myer – in February 1983.

In 1987 he was appointed as Chairman – a position he held until October 1991and ceased to be Chief Executive Officer in July of 1992.

Quinn was named Businessman of the Year by Australian Business in 1988, recognizing him as a leader in the Australian business community.
Even by today’s standards, Quinn was well remunerated.

In 1988/9 his salary was more than $1.4m. He received a $5m bonus for his efforts in relation to a major merger with Myer and $850,000 under a restraint agreement. When he ceased to be Chairman and Chief Executive Officer he became entitled to receive an additional $5m from the company.

His fraud on Coles Myer remains one of Australia’s most blatant and extravagant abuses of power, position and privilege.

***

In January 1985 Quinn bought a large property at 6 County Terrace in Templestowe, Victoria.

Beginning in late 1985 and continuing until late in 1988 renovations were made to the property that became the source of great public notoriety for its extravagance and wastefulness.
Covering the equivalent of five suburban blocks, his hilltop house had four bedrooms, four bathrooms, a family room, a billiard room and a four-car garage even before its renovations, which added a tennis court and tennis pavilion, a cricket pitch, swimming pool and spa house, a grand entranceway, several chandeliers, marble in the bathrooms and granite in the kitchens and increased the garage to accommodate eight cars for Quinn’s Bentley, Ferrari and Mercedes.

Remembering that the dollars that follows were in the currency of more than 20 years ago – the cost of painting the residence: $1.1m; the cost of air-conditioning: $240,000; a security system: $44,000; a brick drive and gates $157,000; a chandelier: $38,000; mirror glass for the kitchen: $15,000; kitchen cupboards: $43,000 and the re-glazing of a single bay window: $110,000.

Of the $6m or so spent on the renovations all but about $74,000 was fraudulently paid for by Coles Myer.

The fraudulent payments were of two kinds.

Most of them were false invoices, showing the work as done or to be done on some property other than County Terrace – usually it mentioned the Coles Myer headquarters.

There were many other invoices, which, while directed to the company, correctly identified the site of the work as County Terrace.

Quinn had directed Graham Lanyon – the National Controller of Maintenance at Coles Myer – to “bury” away from prying eyes the true circumstances behind the costs of the renovations.

***

It was not that the Board of Coles Myer was not made aware of the irregularities – or at least should have been made aware.
The Managing Director of the air-conditioning contractor became concerned that there seemed to be irregularities in documentation and wrote to the Coles Myer Board via the Company Secretary.
Remarkably the letter was never brought to the attention of the Coles Myer Board or to any individual director other than Quinn. Nothing that could properly be described as an internal investigation was ever carried out by Coles Myer.

Quinn told the Managing Director of the air-conditioning contractor that he had committed “commercial suicide” by raising his concerns and that “it was a pity we couldn’t have handled it in club”.

***

Quinn was found guilty of conspiracy to defraud and was sentenced in 1997 to four years’ imprisonment with a non-parole period of two years and six months.

Quinn would conclude his business career in jail making deck chairs to be sold to Kmart – a subsidiary of the entity that he used to oversee.

Monday, January 7, 2008

NASA's 100 Project Management Lessons Learnt


The seeds of problems are laid down early. Most failed projects are disasters well planned to happen from the start.

The Goodard Space Flight Center (GSFC) – just outside of Washington DC in Greenbelt, Maryland – is a major NASA space research laboratory established on May 1, 1959 as NASA’s first space flight centre.

GSFC is a major US laboratory for developing and operating unmanned scientific spacecraft. GSFC conducts scientific investigation, development and operation of space systems, and development of related technologies.

Amongst its 10,000 employees is John Mather who shared the 2006 Nobel Prize in Physics.
Engineers at the GSFC have come up with a list of 100 lessons learnt from NASA’s projects over the last 48 years:

1. There is no such thing as previously flown hardware, i.e., the people who build the next unit probably never saw the previous unit; there are probably minor changes; the operational environment has probably changed; and the people who check the unit out will in most cases not understand the unit or the test equipment.



2. Most equipment works "as built," i.e., not as the designer planned. This is due to layout of the design, poor understanding on the designer's part, or poor understanding of component specifications.




3. The source of most problems is people but damned if they will admit it. Know the people working on your project, so you know what the real weak spots are.



4. A manager who is his own systems engineer or financial manager is one who will probably try to do open heart surgery on himself.



5. NASA programs compete for budget funds -- they do not compete with each other, i.e., you never attack any other program or NASA work with the idea you should get their funding. Sell what you have on its own merit.



6. Contractors respond well to the customer who pays attention to what they are doing, but not too well to the customer that continually second-guesses their activity. The basic rule is: a customer is always right, but the cost will escalate if a customer always has things done his way, instead of the way the contractor had planned. The ground rule is never change a contractor's plans unless they are flawed or too costly, i.e., the old saying, "better is the enemy of good."



7. A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work, and the best proof is for the manager to visit them and see first hand what they are doing.



8. Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you cannot.



9. Wrong decisions made early can be salvaged, but "right" decisions made late cannot.



10. Never make excuses; instead, present plans of actions to be taken.



11. Never try to get even for some slight by another project. It is not good form -- it puts you on the same level as the other person--and often ends up hindering the project getting done.



12. You should instil an attitude on the project whereby your personnel know they can tell you of wrong decisions.



13. One of the advantages of NASA in the early days was the fact that everyone knew that the facts that we were absolutely sure of could be wrong.



14. Managers who rely on the paperwork to do the reporting of activities are known failures.



15. Not all successful managers are competent and not all failed managers are incompetent. Luck still plays a part in success or failure, but luck favors the competent, hard-working manager.



16. If you have a problem that requires the addition of people to solve, you should approach recruiting people like a cook who has under-salted, i.e., a little at a time.



17. A project manager must know what motivates the project contractors, i.e., their award system, their fiscal system, their policies, and their company culture.



18. Other than original budget information prior to the President's submittal to Congress, there is probably no secret information on the project -- so don't treat anything like it is secret.
Everyone does better if they can see the whole picture, so don't hide any of it from anyone.



19. Contractors tend to size up their government counterparts, and staff their part of the project accordingly. If they think yours are clunkers, they will take their poorer people to put on your project.



20. Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have been, and what the reality is. Documents are normally a static picture in time which is outdated rapidly.



21. Remember who the customer is and what his objectives are, i.e., check with him when you go to change anything of significance.



22. In case of a failure:
· Make a timeline of events and include everything that is known;
· Put down known facts -- check every theory against them;
· Don't beat the data until it confesses, i.e., know when to stop trying to force-fit a scenario;
· Do not arrive at a conclusion too rapidly. Make sure any deviation from the norm is explained;
· Know when to stop.



23. Remember the boss has the right to make decisions, even if you think they are wrong. Tell the boss what you think but, if he still wants it done his way, do your best to make sure the outcome is successful.



24. Don't be afraid to fail or you will not succeed, but always work at your skill to recover. Part of that skill is knowing who can help.



25. Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.



26. People have reasons for doing things the way they do them. Most people want to do a good job, and if they don't, the problem is they probably don't know how or exactly what is expected.



27. The boss may not know how to do the work, but he has to know what he wants. The boss had better find out what he expects and wants, if he doesn't know. A blind leader tends to go in circles.



28. A puzzle is hard to discern from just one piece, so don't be surprised if team members deprived of information reach the wrong conclusion.



29. Reviews are for the reviewed and not the reviewer. The review is a failure if the reviewed learn nothing from it.



30. The amount of reviews and reports are proportional to management's understanding, i.e., the less management knows or understands the activities, the more it requires reviews and reports. It is necessary in this type of environment to make sure the data is presented so that the average person, slightly familiar with activities, can understand it. Keeping the data simple and clear never insults anyone's intelligence.



31. In olden times, engineers had hands-on experience, technicians understood how the electronics worked and what it was supposed to do, and layout technicians knew too-but today only the computer knows for sure, and it's not talking.



32. Not using modern techniques like computer systems is a great mistake, but forgetting the computer simulates thinking is still greater.



33. Management principles are still the same. It is just the tools that have changed. You still should find the right people to do the work and get out of the way so they can do it.



34. It is mainly the incompetent that don't like to show off their work.



35. Whoever you deal with, deal fairly. Space is not a big playing field. You may be surprised how often you have to work with the same people. Better they respect you than carry a grudge.



36. Mistakes are all right, but failure is not. Failure is just a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.



37. You cannot be ignorant of the language of the area you manage or with that of areas with which you interface. Education is a must for the modern manager. There are simple courses available to learn computerese, communicationese, and all the rest of the modern ese's of the world. You can't manage if you don't understand what is being said or written.



38. Most international meetings are held in English. This is a foreign language to most participants such as Americans, Germans, Italians, etc. It is important to have adequate discussions so that there are no misinterpretations of what is said.



39. A working meeting has about six people attending. Meetings larger than this are for information transfer.



40. Being friendly with a contractor is fine -- being a friend of a contractor is dangerous to your objectivity.



41. The old NASA pushed the limits of technology and science; therefore, it did not worry about "requirements creep" or over-runs. The new NASA has to work as if all are fixed price; therefore, "requirements creep" has become a deadly sin.



42. Cooperative efforts require good communications and early warning systems. A project manager should try to keep his partners aware of what is going on and should be the one who tells them first of any rumor or actual changes in plan. The partners should be consulted before things are put in final form, even if they only have a small piece of the action. A project manager who blindsides his partners will be treated in kind and will be considered a person of no integrity.



43. All problems are solvable in time, so make sure you have enough schedule contingency -- if you don't, the next project manager that takes your place will.



44. The number of reviews is increasing but the knowledge transfer remains the same; therefore, all your charts and presentation material should be constructed with this fact in mind. This means you should be able to construct a set of slides that only needs to be shuffled from presentation to presentation.



45. Just because you give monthly reports, don't think that you can abbreviate anything in a yearly report. If management understood the monthlies, they wouldn't need a yearly.



46. Abbreviations are getting to be a pain. Each project now has a few thousand. This calls on senior management to know a couple hundred thousand. Use them sparingly in presentations unless your objective is to confuse.



47. Occasionally things go right--the lesson learned here is: Try to duplicate that which works.



48. Running does not take the place of thinking. For yourself, you must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.



49. Sometimes the best thing to do is nothing. It is also occasionally the best help you can give. Just listening is all that is needed on many occasions. You may be the boss but, if you constantly have to solve someone's problems, you are working for him.



50. Remember, it is often easier to do foolish paperwork than to fight the need for it. Fight only if it is a global issue which will save much future work.



51. Know your management -- some like a good joke; others only like a joke if they tell it.



52. Integrity means your subordinates trust you.



53. You cannot watch everything. What you can watch is the people. They have to know you will not accept a poor job.



54. Next year is always the year with adequate funding and schedule -- next year arrives on the 50th year of your career.



55. The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.



56. External reviews are scheduled at the worst possible time: therefore, keep an up-to-date set of technical data so that you can rapidly respond. Having to update business data should be cause for dismissal.



57. Hide nothing from the reviewers. Their reputation and yours is on the line. Expose all the warts and pimples. Don't offer excuses -- just state facts.



58. Knowledge is often confounded by test. Computer models have hidden flaws, not the least of which is poor input data.



59. Today one must push the state of the art: be within budget, take risks, not fail, and be on time. Strangely, all these are consistent as long, as the ground rules, such as funding profile and schedule, are established up front and maintained.



60. A scientific proposal takes about 9 months to put together. It takes NASA HQ about 9 months to a year to select the winning proposals. Then, it takes 3 to 4 years to sell the program. This means 5 to 6 years after the initial thoughts, the real work starts. Managers, for some strange reason, do not understand why a scientist wants to build something different than proposed. Managers are strange people.



61. There are rare times when only one man can do the job. These are in technical areas that are more art and skill than normal. Cherish these people and employ their services when necessary as soon as possible. Getting the work done by someone else takes two to three times longer, and the product is normally below standard.



62. Software now has taken on all the parameters of hardware, i.e., requirement creep, high percent-age of flight mission cost, need for quality control, need for validation procedures, etc. It has the added feature that it is hard as hell to determine it is not flawed. Get the basic system working and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world the newer version works. It is necessary to have contingency plans for software.



63. History is prologue. There has not been a project yet that has not had a parts problem despite all the qualification and testing done on parts. Time and being prepared to react are the only safeguards.



64. Award fee is a good tool that puts discipline both on the contractor and the government. The score given represents the status of the project as well as the management skills of both parties. The Performance Measurement System (PMS) should be used to verify the scores. Consistent poor scores require senior management intervention to determine the reason. Consistent good scores, which are consistent with PMS, reflect a well-run project, but if these scores are not consistent with the PMS, senior management must take action to find out why.



65. A project manager is not the monitor of the work but is to be the driver. In award fee situations, the government personnel should be making every effort possible to make sure the contractor gets a high score, i.e., be on schedule and produce good work.



66. There is no greater motivation than giving a-good person his piece of the puzzle to control but a pat on the back or an award helps.



67. Morale of the contractor's personnel is important to a government manager. Just as you don't want to buy a car built by disgruntled employees, you don't want to buy flight hardware built by them. You should take an active role in motivating all personnel on the project.



68. People who monitor work and don't help get it done, never seem to know exactly what is going on.



69. Never assume someone knows something or has done something unless you have asked them. Even the obvious is overlooked or ignored on occasion -- especially in a high-stress activity.



70. Don't assume you know why senior management has done something. If you feel you need to know, ask. You get some amazing answers that will dumbfound you.



71. If you have someone who doesn't look, ask, and analyze, ask them to transfer.



72. Bastards, gentlemen, and ladies can be project manager. Lost souls, procrastinators, and wishy-washers cannot.



73. A person's time is very important. You must be careful as a manager that you realize the value of other people's time, i.e., work you hand out and meetings should be necessary. You must, where possible, shield your staff from unnecessary work, i.e., some requests should be ignored or a refusal sent to the requester.



74. A good technician, quality inspector, and straw boss are more important in obtaining a good product than all the paper and reviews.



75. The seeds of problems are laid down early. Initial planning is the most vital part of a project. Review of most failed projects or of project problems indicates that the disasters were well planned to happen from the start.



76. A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management.



77. Remember, the President, Congress, NASA HQ, senior center management, and your customers all have jobs to do. All you have to do is keep them all happy.



78. Always try to negotiate your internal support at the lowest level. What you want is the support of the person doing the work, and the closer you can get to him in negotiations the better.



79. Whoever said beggars can't be choosers doesn't understand project management. Many times it is better to trust to luck than to get known poor support.



80. Remember your contractor has a tendency to have a one-to-one interface with your staff; so every member of your staff costs you at least one person (about a 1/4 of million) on the contract per year.



81. There is only one solution to a weak project manager in industry -- get rid of him fast. The main job of a project manager in industry is to keep the customer happy. Make sure the one working with you knows that "on schedule, on cost, and a good product" -- not flattery -- is all that makes you happy.



82. Talk is not cheap. The best way to understand a personnel or technical problem is to talk to the right people. Lack of talk at the right levels is deadly.



83. In the rush to get things done, it is always important to remember who you work for. Blindsiding the boss will not be to your benefit in the long run. Over-engineering is common. Engineers like puzzles and mazes -- try to make them keep their designs simple.



84. Never make a decision from a cartoon. Look at the actual hardware or what real information is available, such as layouts. Too much time is wasted by people trying to cure a cartoon whose function is to explain the principle.



85. False starts are normal in today's environment. More than ever, in this type of environment, one must keep an ear open for the starting gun and be prepared to move out in quick and orderly fashion once it is sounded. In the past, too many false starts have resulted in the project not hearing the real starting gun or jumping off and falling on its face.



86. There are still some individuals who think important decisions are made in meetings. This is rarely the case. Normally, the decision-makers meet over lunch or have a brief meeting to decide the issue and than (at a meeting called to discuss the issue) make it appear that the decision is made as a result of this discussion.



87. In political decisions, do not look for logic -- look for politics.



88. In dealing with international partners, the usual strategy is to go 1 day early, meet with your counterpart, discuss all issues to be brought up at a meeting, arrive at an agreeable response (or a decision to table the issue for later discussion), and agree not to take any firm positions on any new issues brought up at the meeting. This makes it appear to the rest of the world that you and your counterpart are of one mind and that the work is in good hands. All disputes are held behind closed doors with the minimum number of participants.



89. Gentlemen and ladies can get things done just as well as bastards. What is needed is a strong will and respect -- not "strong arm" tactics. It must be admitted that the latter does work but leaves a residue that has to be cleaned up.



90. Though most of us in our youth have heard the poem that states "for want of a nail the race was lost," few of us realize that most space failures have a similar origin. It is the commonplace items that tend to be overlooked and thus do us in. The tough and difficult tasks are normally done well. The simple and easy tasks seem to be the ones done sloppily.



91. Meetings, meetings -- A Projects Manager's staff meeting should last 5 minutes minimum -- 1 hour max -- less than 5 minutes and you probably didn't need the meeting -- longer than 1 hour, it becomes a bull session.



92. Taking too many people to visit a contractor or other government agency puts them in the entertainment business -- not the space hardware or software business.



93. You should always check to see how long a change or action takes to get to the implementer -- this time should be measured in hours and not days.



94. Let your staff argue you into doing something even if you intended to do it anyway. It gives them the feeling that they won one! There are a lot of advantages to gamesmanship as long as no one detects the game.



95. Some contractors are good, some are bad, but they seem to change places over time, making the past no guarantee of the future; thus, constant vigilance is a project requirement.



96. It is rare that a contractor or instrumentor does not know your budget and does not intend to get every bit of it from you. This is why you have to constantly pay attention to the manpower they use and to judge their activities in order to assure that they are not overloading the system.


97. There are some small companies that make the same subsystem correctly every time because the same people do it. There are some large companies that can never make the same unit correctly every time because different people do the work each time. Heritage should be questioned when the people doing the work all have peach fuzz on their faces.



98. Too many project managers think a spoken agreement carries the same weight as one put in writing. It doesn't. People vanish and change positions. Important decisions must be documented.



99. Make sure everyone knows what the requirements are and understands them. You have to have the right people look at requirements. A bunch of managers and salesmen nodding agreement to requirements should not make you feel safe.



100. The project manager who is the smartest man on his project has done a lousy job of
recruitment.