Trust The Process
I often feel that this aspect of complex systems engineering needs to be hammered into management and leadership more than the engineers doing the actual work. In my experience it is the far more likely that it will be someone in management that is running around pitching watermelon charts, and thus causing problems by not facilitating the application of resources when and where needed. Never-the-less, I include it here because one can often lead from the rear.
Real leadership is often found in people other than those suggested by org charts.
There is a quip that was included in a popular textbook on mountaineering that is appropriate when talking about this topic.
"I must hurry, for there they go, and I am their leader."
This condition often seems to be the case. Let's look at things from the perspective of the team that is functioning fairly well despite issues with official leadership. A team that is functioning well like this will be ignoring any poor behavioral examples, and instead will have been working to nurture the proper culture and ethos for itself. If we personally commit to lead by example as members of our teams, we can often help our teams to make our delivery commitments and do our part to keep the program on schedule, regardless of what the riff-raff on high may be doing. We may succeed in doing a little leadership training in the process. Good behavioral examples can rub off just as much as bad ones.
Trust in each other and trust in the process is the key.
As you can see from what I have written so far on this site, these materials on the air vehicle design process are not about the details of the engineering itself. I am taking for granted that anyone spending any time on these pages will be totally familiar with the application of the standard engineering process diagram illustrated above. I say standard, although it is true that most versions of this chart neglect to include the tall white reporting box of the left. But other than that, the rest is just a basic textbook engineering process flow. I have added some color that maps to what one might expect to see on the stoplight charts at various stages of progress for the more challenging systems integration tasks. Other than that, I don't think there is much I can add to what folks already know very well. Most technical people can draw the core of this chart in their sleep.
The only other thing I might add here is a personal opinion which should be treated as just that. In my book, pitching a watermelon chart to report status should be a firing offense, or at the very least, a cause for being given an opportunity to go away for a few weeks and ponder the consequences of what is essentially and act of sabotage. I would apply this approach at all levels, starting in the board room. At this point, my friends would typically say something like "why don't you tell us what you really think Craig."