MIT posted this interesting article about the issue of hidden rework
in the development cycle. Your project can crash with surprise delays that
destroy delivering on time, much less on budget.
Firms seeking competitive advantage to increase market share, profit,
and growth have turned to concurrent development to speed the introduction of
new products and beat their competitors to market. However like any other
improvement process there are weakness and difficulties. Human nature does not
want to be the bearer of bad news, and the managerial attention does not always
help resolve the issue.
The F-35 is an example of concurrent development. While it looks like
the development is now progressing well, the program looks like a money pit.
The idea was instead of doing all the development on test planes, they could
start production while still testing and writing the software necessary.
Several years into the program design changes are still being made which
require existing models to be changed, and the software is years behind
schedule. The software on this program is critical to be able to use all the
technology and weapons available.
The cost of the F-35 was getting close to breaking the Air Force budget
before recently turning the program around. Some critic wondered if the day would ever come. (Don’t ask my thoughts on building
one airplane to fill the needs of 3+ airplanes though)
Did work with a smaller company that successfully implemented
concurrent engineering in their development cycle. Why did it work? Reality was
included with the plan, and being flexible enough to realize meeting schedule
with an inferior product was worse than redesigning the product again.
On our first project we were working on the development schedule. The
initial proposal was the standard design, prototype, testing, order machines
& tooling, then start production. I asked, “Has any design worked the first
time after testing?” The answer was no one could remember that happening. We
need to plan for at least one redesign after testing and have a contingency
plan for a second redesign. Including normal contingencies with average lead
times in standard planning processes made the concurrent engineering process
work. We used it both for new product development and product line extensions.
Back to fudging and hiding rework during development. This is a
dangerous practice that can come back to hurt the team and the company. The
natural tendency this setback is a small problem, and management does not need
to know. What you don’t realize is your sponsor and other leaders may have more
resources available that can speed up the redesigning and keep your project on
schedule. Second the later a problem comes to the surface, the bigger the consequences
for everyone involved.
Worked for a company that taught about Malpractice and the dangers to
your career and the business. They made a video and repeated it yearly. Such
danger for fudging, and little reward for doing it. We had one
customer, the US Navy, and could have lost the business without their trust.
Leadership is doing the real work of getting things out of the way of
your teams so your people succeed. Leaders have to make sure teams know they
have your support to be comfortable to innovate. Besides only about 40% of
software development project complete all features, on time, and within budget.
Projects failing should not be a crisis but a normal situation to be handled
calmly.
The quote jumped out at me ‘‘... don’t tell someone you have a problem
unless you have the solution. You’re supposed to solve it—and then tell them.’’ This thought limits the chance to get more suggestions, ideas and develop more alternatives.
Found it helped if I showed up with the bad news, with some
suggestions of my own or my teams, and was prepared for getting feedback &
suggestions. More productive engagement came from being prepared and open. Make
sure you are ready to deliver bad news and have leaders engaged when necessary.
No comments:
Post a Comment