Leading Special Projects

Teams utilize many different talents
(courtesy 2013.igem.org)

Leading a operations team is an experience everyone should do as often as the opportunity arises. Some people always look for leadership possibilities and thrive on nearly every task they manage. Others think they are leaders and quickly prove to everyone around them that they have no clue as to what is going on and how to get the most from team members.  Still a third group seeks to avoid leadership opportunities and is content to be a role player.  To be an effective leader on a special project that requires fast answers and execution, here are a few tips:

• Utilize the group's strength.  Early in my career on Boeing's portion of the F-22, I was tasked to lead a team of engineers and operations folks to help build a test box for a live fire test to ensure survivability for the wing.  Since the first test failed miserably there was a high level of concern to get the right answer quickly. During our meetings to plan our next test, I utilized the members of our team by engaging them in conversation about all engineering, manufacturing and operations parameters.  They were far more experienced than I was at the time, so it would have been foolish of me to try to "fake" my knowledge.  Instead I let the experts help guide us to the optimum solution and I served the group as a facilitator.  The next tests were ultimately a success and the program passed an essential milestone for survivability.
• Do what is necessary for success.  This seems obvious but many people feel that they only need to do their assigned tasks and let others do theirs.  Sometimes others get pulled away onto something else, have trouble executing, or simply just don't have a sense of urgency for a special project.  Then you have to forge ahead and do what they haven't done.  I did this one time in my Boeing career when I had to do layouts of an area another engineer was supposed to perform.  He kept procrastinating the job until it was getting close to jeopardizing the program.  I stepped in and started the job.  It caused some conflict with him but the job had to be done.
• Give credit to those who help.  Often during a busy project, you have to ask people to go above and beyond what is expected of them.  This includes after hours and weekend work to get the task done.  At the least, you can send them a thank you note or let their manager know how much they helped you.  It is the right thing to do and helps ensure they will be willing to help you again in the future.

(courtesy agilebacon.com)

Self-Directed Work Teams

(Courtesy of www.blog.commlabinda.com)

In an earlier post I discussed integrated product teams which are cross-functional teams composed of members of different  skill sets all focused on developing a product or improving a process.  Another kind of effective team is the self-directed work team.  A self-directed work team may be cross-functional in membership.  Or it may contain mostly members from a single functional group or organization.

A self-directed work team is a team which can operate autonomously to identify problems or areas needing improvement, outline plans to solve the issue, and proceed to implement the plans to a successful conclusion.  These teams do not require constant monitoring by management.  If fact they perform much better if management "stays out of the way".  It's not to say management should not be briefed on what the group is doing and a timeline for completion  - they should be aware.  It's really a fact that a self-directed team knows how to work without being told what to do.

One of the teams I worked on at Boeing was a self-directed tooling team that solved various tooling issues related to F-22 fighter airplane manufacturing.  It was a team made of experienced design engineers as well as new engineers out of college.  They common thread was that everyone on that team wanted to make the program better and worked hard to reduce costs, improve flow, and steam line operations.

One incentive to encouraging aspirations to developing a self directed work team is to set up standards for different levels to work teams.  Start at criteria for a  Level 1 self-directed work team and list completion criteria for this level.  Keep going up to say a Level 4 which would be the most complete and autonomous work team.  Provide incentives to teams to reach a Level 4 and you will find that more employees will work to improve their effort without a lot of management oversight.

A good article on self-directed work teams is here:

http://www.qualitydigest.com/magazine/1995/nov/article/self-directed-work-teams-competitive-advantage.html#

 A self-directed work team working an issue
(Courtesy www.ctspring.com)

Integrated Product Teams

Historically functional groups such as design, tooling, quality assurance, manufacturing, and others have tended to operate with their own circle.  For instance as a  design entered the functional group for evaluation, it was reviewed and then comments were passed back to the originating group (usually design).  The process iterates until everyone is pleased and then the design is moved to the next functional group and the process continues.  An extremely time-consuming process.

My best experience in avoiding this was working in an Integrated Product Team (IPT) as an engineer on the F-22 fighter program for Boeing.  In an IPT the structure is focused on a product rather than a function.  The IPT I worked in (Internal Spars) had members from design, stress, tooling, quality assurance, and manufacturing sit together to develop a superior design concurrently.  

As a design was developing, each functional member could provide immediate input to ensure the design was optimized while it was being designed rather than after the first iteration was completed.  It was a refreshing way to design a product and highlighted several benefits:

• Decreased design time as all functional members were able to contribute while the design was being developed.  Feedback was incorporated immediately and  design was able to progress more rapidly to completion. It was immediately evident that operations would be improved by working together from the beginning.
• Working together with other functional group members allowed me to understand what was important to them.  I had previously thought of other functional members as "them" but working in an IPT made me think of "us".
• In an IPT I was able to understand the entire design build process as I was involved in all phases of it, not just the design process.  I have used this experience in subsequent design activities to make me a better engineer.

(Typical IPT example)