| I suggest all project and
program managers consider publishing a newsletter about
their programs or projects for their team members. It
doesn't need to be fancy. I do mine as an MS Word document.
And it doesn't need to come out too often. You're not
trying to compete with the local newspaper. I recommend
once a month, but even quarterly would be better than
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."
Below are samples of a newsletter I publish for members
of my team in the Joint Air-to-Surface Standoff Missile
- 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
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).
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.
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,
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
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.
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.
Search by lesson to find more on:
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