Transparency
One of the primary jobs of management in an engineering development process is moving resources to where they are needed. In order to do this, a leader or manager needs to have a clear understanding of current status, and be able to recognize when help is required. In the PDCA cycle, staying aware is the "Check" part of the cycle. Providing needed resources is the "Act" part. Visibility is critical.
For the line supervisor or technical lead there is no substitute for the concept of management or leading by walking around. Staying close to the work and talking to the team about their progress and challenges is critical. At least weekly the status stoplight charts should be updated. Failure to maintain accurate status charts is equivalent to hiding status. Some might even call it sabotage.
Alan Mulally was quite good at managing program visibility. His personal take on the process was documented in the 2001 book by James P. Lewis titled "Working Together." I have a copy of it with a personal note tucked inside from Alan, complete with his smiling airplane icon signature that he used while at Boeing. The story of how he took this system with him to Ford is told in the 2012 book by Bryce Hoffman titled "American Icon." One of Alan's favorite quips to remind people of just how critical good visibility are to successful program management is: "You can't manage a secret." I can't recommend these books highly enough.
The style of status or stoplight charts in the old Boeing company varied quite a lot from one part of the company to another. But certain key items were always there, regardless of the style. There would be the task description, its duration, and any critical dependencies. The color boxes or stoplights would have two parts. The left box or light would be the condition as reported during the last status meeting. The right would indicate the current status.
The exact meaning of color assignments would vary depending on the nature of the task. If it was something that was routine that had been done many times in the past, then even though work had not yet really begun, green might be ok.
An example of something that can be safely green before it is even started might be the acquisition of a new work stand from a supplier that has been used before for similar work, and there is nothing new or novel about the stand, and the supplier has been contacted and made aware that an order is coming with an expected due date, and they responded that this would be no problem. Of course, checking in with them periodically before the clock runs out would be required.
However, a complex or novel task that requires lab work and integration with other systems or components might best be shown as red until a working prototype has passed some initial tests, and there is a high degree of confidence that the selected concept is going to work. Even then, it would be safe to keep the task as showing yellow until its done and ready for delivery.
Accurate status reporting and rapidly responding to issues that threaten the schedule is the only way that costs can be controlled. Without that, there simply is no chance of doing so. The ability to apply resources is typically a function of budget authority. Thus, the speed of the flow of status reporting up through the chain of command to the level where the authority required to apply needed is critical. There are two parts to this.
First, status must be accurately reported. That's the transparency or visibility part. The second part is one of leadership competency and proper status meeting attendance. The person to whom status is being reported must be able to understand what they are being told. And, everyone who needs to know needs to be in the meeting. This is true even for things that appear to be making good progress and for which the person doing the reporting is not asking for help. Someone who has a dependency on that task may recognize an issue that the person doing the reporting may not be able to see. Let's look at a critical example which has happened more times than we might like.
Let's say that an engineer upon visiting a supplier who is supposed to be producing a critical item discovers that the supplier actually doesn't understand the nature of the task and is unlikely to be able to support the program at all, let alone meet their schedule commitments. Through how many layers of reporting will this information have to pass before the needed action of cancelling a contract and lining up a new supplier actually happens? What if the supplier in question is working on some hugely expensive item, and there was a lot of public fanfare when the contract was first awarded, so that making the change has to go all the way to corporate?
You can see the problem if the entire structure of the company is not steeped in a culture of integrity and transparency. It only works if the culture is functional from top to bottom. The result is absolutely predictable if there is a breakdown in the understanding of how to think about budgets, MEACs, schedules, and commitments at any level. The program will be years late. Making money on it will be impossible. Trust on the part of the customers will become seriously damaged - perhaps irreparably.
It is any leader's paramount responsibility to encourage and reward high quality visibility. Problem identification and reporting should be celebrated. In order to be able to do one of their most important tasks, which is to allocate resources where needed, leaders have to know where help is needed. And, the faster they respond to a need for help and provide it, the lower costs will be and the more money will be made. The alternative to a culture of transparency is a leadership team that is flying blind. In that condition a crash is inevitable. In the aerospace business, that crash will be both literal and figurative.
Transparency is critical!