The main point of starting a newsletter is to communicate with your team about the project, but if all you are communicating is dry facts, you're not using this tool wisely. Programs usually have other means of sharing facts. Your newsletter should extend beyond the boundaries of the program. For instance, you can talk about what clients feel, what upper management feels. Most often it's just the program manager or the people at the top that are interacting with clients and upper management. By sharing this information with the team, you are breaking down silos and giving everyone a stronger sense that we are all working together. I would suggest you send the newsletter to your contractors too, as they are also part of the larger team.

To build trust, you must demonstrate your own trust in others. If you share your feelings about the project openly, eventually everyone will do the same. Moreover, trust is built when you make yourself vulnerable to others. People ask me why I do this. I tell them, "Because leaders lead by example."

Procedure

• Take one hour each month to sit at the computer and write an informal open newsletter to your team. Include your thoughts, feelings, fears, hopes and wishes.

JASSM NEWSLETTER, 25 February 1999

Need for Better Inter-Team Coordination
During our last staff meeting I highlighted the fact that communication among the team needs improving. What I want to do to improve this situation is to start holding coordination meetings among the team leads twice weekly. For now I want Tim to chair the meetings, with Jim A. as the alternate. We will start the meetings on Tuesday morning @ 0800 and Friday afternoon @ 1400. Someone from the F-group may attend, but the meetings are really for the team leads. Each team lead should be prepared to spend a few minutes telling everyone else the three top issues that their IPT is working on, and, for the Friday meeting, the upcoming events for next week. The meeting should last no more than an hour and the team leads should be responsible for communicating relevant information to the other team members. I expect full attendance (i.e., if a team lead is not available there should be an alternate).

Improvisation
I have found that one of the keys to innovation is to be willing to improvise. That is, if something seems at first glance to make sense to do, then the best thing to do is to try it and see if it works. If it works, great. If not, then try something else. Fear of making mistakes is paralyzing to progress. For virtually everything we do, making a mistake has no permanent consequences.

Requirements Creep
I recently learned that there is work underway to have a field-installable Test Instrumentation Kit (TIK). I have a simple question. Why? Maybe it's more convenient? Maybe it will make the operational testers happier? Maybe, maybe...

Where is the requirement and who is going to pay? We have a requirements control process. So far as I know, this has never been vetted by that process. Everyone on the Government side had better get used to the fact that yours truly is going to deal very, very ruthlessly with requirements growth, irrespective of where it comes from and how reasonable it may appear. We have neither money nor time to deal with growth in requirements now. Maybe later. Not now.

JASSM NEWSLETTER, 28 March 1999

Disappointment at Launch Delay
Like you, I was quite disappointed at the delay of our first launch. I am unclear on the exact reasons for the delay, but I presume that there were some good reasons for it. I am certain that we will soon be in a position to resume the launch. The occasion of the delay gives me an opportunity to reiterate a point that I have previously made and will continue to make. Schedule is our most important priority; it will remain so from now until our launch date! This does not, of course, mean that we do something stupid to achieve schedule. Recovering from an imprudent action could take up a lot more schedule than a little delay to lower the risk. Every development decision will have to consider a number of factors, including risk, cost, etc. However, among those factors, schedule must be the most prominent. I realize that this runs counter to the "do not fail" mentality that is part of our acquisition culture. But not failing does not equal succeeding.

There are a number of reasons why schedule is so important. The most obvious is that the users have been waiting a long time to get this capability when you consider the program history; their patience is not infinite. Second, the recent events in Yugoslavia have increased schedule pressure. The Air Force only has the CALCM as a standoff weapon and it has a somewhat limited capability compared to what we could offer. The user sees future "Yugoslavias" as being the most likely scenarios for future application of airpower. He wants JASSM yesterday! Third, we have made an absolute commitment to a 40-month development -- six more months than Lockheed proposed. It was not easy to sell the system on that extension, but we did. Should it become apparent that we are not going to meet that new expectation, we will begin to hear a hue and cry that JASSM is "just another typical government program." It will affect our user support and, ultimately, our ability to get money. No one should forget that the user does have some alternatives to JASSM if it appears that we are in major schedule trouble (e.g., SLAM, air-launched TOMAHAWK, hypersonic missiles, etc). These may not be better performance or cost alternatives than JASSM, but painting them as better schedule alternatives could easily do us in. Anyone who thinks that the manufacturers of potential JASSM alternatives won't try to exploit any major schedule problems we have simply doesn't understand the current environment.

Remember the users' requirement is for a capability not a JASSM! Fourth, the Air Force's acquisition leadership has high confidence in our ability to execute. We cannot erode that confidence and expect to continue to enjoy the level of support that we have had. Finally, Lockheed's extremely attractive bids for production hinge critically on our meeting schedule. Should we slip our schedule to the point that either Lockheed will significantly raise those bids or that "the system" believes that Lockheed will significantly raise those bids (a much more likely outcome), we will have much bigger problems than we can handle.

Something to Be Proud Of
This Friday I learned that Mrs. D, over numerous objections, has issued an Air Force policy that past performance will be weighed at least equally to the highest-ranking factor in every source selection the Air Force does. While there are many who can see how to do this if we were just buying fuel, spare parts, housekeeping services, etc., the major objections came from those arguing that this policy was impossible to implement on complex acquisitions. To those who raised these objections, Mrs. D had a one-word reply: JASSM. We can expect that many will begin calling us to help them figure out how to do this. We will, de facto, become the model for others to emulate. I am asking Jackie to put together a briefing on evaluating past performance that we will offer to every Product/Logistics Center acquisition support office. Unlike what we have previously done in telling our story, this briefing will tell others how to do it rather than merely telling them what we did. We will talk about what we did only as an example. For reasons that I don't fully understand, many of the people in our system have to have everything laid out for them -- they can't extrapolate from what we did to what they should do. Hopefully Jackie can help with this. In the meantime everyone in the Program Office should be rightly proud of our pivotal role in this new and long-overdue policy. I consider it a great tribute. Incidentally, one of the recommendations from the Group I have been working on for the past few months is that this elevating of past performance should become policy DoD wide.

Requirements Creep
I have previously addressed my concerns about creeping requirements and the effect that they could have on our program. We have set up a Requirements Control Working Group (RCWG) to deal with this issue. Many see this as a user issue. However, the users we deal with have not been and are unlikely to be culprits in any creep. I am beginning to set my sights on others in our process as "creep culprits" -- in particular the test community, aircraft program offices, and outside Government offices. I want to emphasize two points. First, I demand that everything that looks like or smells like requirements creep go to the RCWG. This is true regardless of whether that "something" reflects a creep in development requirements or requirements for the production system. We may choose to accept the requirements change, but it will be a collaborative, deliberate decision that considers all the ramifications of the change. Second, I hold each team lead accountable for identifying potential creeps in requirements in his or her area.

JASSM NEWSLETTER, 19 April 1999

On Being a Team
A few weeks ago I went home to Dallas to visit my Mother and Dad. Although I have not lived in Texas in more than 30 years it is for me, as it is for many native Texans, still home. As I made my way from the airport to my parents' house in heavy traffic my mind was as far away from work as it ever gets. While I was momentarily stalled on a freeway I noticed that the car in front of me had a Dallas Cowboys sticker on the back window. As I began to move again, I idly began to count Dallas Cowboys stickers on other cars as they passed me or I passed them. By the time I got home I had counted a grand total of four. This was somewhat amazing to me, because I could remember a time when virtually every car in Dallas had such a sticker. I began to reflect on the reasons for this change and concluded that I was noticing all the stickers in the Cowboys' "glory days" -- America's Team, Super Bowl champs, etc. I was struck by how everyone on the sidelines seems to want to identify with a winner, but wants to disengage or criticize when the winning stops. Human nature, I guess.

What about the people on the team? It's the same human nature at work, but the results must be different. When there's a loss or a series of losses, it's natural for team members to want to assign blame, disclaim ownership, and criticize or redefine the intra-team relationships. Won't work. The team becomes dysfunctional. Being a part of a team demands that everyone on the team own every outcome in equal measure. Irrespective of whether the outcome is good or bad, everyone must share responsibility for it, or else leave the team. When the outcome is not what we would have liked, it's tough. But that's precisely the time when functioning as a team is most important. It does no good to belabor adversity or look in the rear-view mirror. All we can affect is what's in front of us, not behind. What we accomplish in this program, I am convinced, hinges not on individual team members, but on how well we function as a team. We can't let our togetherness depend upon whether someone else has a window sticker.

Terry Little is in the civil service with the Dept. of the Air Force, where he's been a program manager for five major defense acquisition efforts. He entered the Air Force in 1967 and served on active duty until 1975.