Top Ten Criteria for a Successful Engineering Project

by Randy Speed, © 2009

This article is for the lead engineer, project engineer, department manager, or project manager. You are a team. The success or failure of a project depends not on any one individual, but on the dynamics of the team. Your program is hopefully already employing these strategies. If not, I hope that you can gain some insight that will in some way improve your success (on-time, on-cost, meets requirements).

The lifecycle of a project has many stages. This article is geared towards the engineering development stage.

Can a project be successful with an incompetent project manager? Absolutely. Does it happen often? Probably not. A successful engineering project is a result of good team members, competent leads, and a get-the-job-done philosophy. Project managers make decisions that affect the program, but you decide how to carry them out.

Everyone wants to be part of a successful program, but it is never successful because of one person’s actions. A good project manager empowers his people to do their best. His/her job is to make decisions. The philosophy lies on the responsibility of the individuals and as a whole, the team. Hint: Positive attitudes and optimism are contagious.

Let’s examine the steps of the typical project cycle and how certain philosophies affect their outcome. Assume that top management has evaluated the company’s assets and abilities, that sales has identified a contract and financing has approved a proposal, and your company is ready to embark on a new project. The deal is done and now the fun begins. You’re up next.

1. Meet the Players

You’ve heard it before, you have one chance to make a first impression. We’re not talking about a popularity contest, but a great amount of respect is lost if you forget someone’s name once the game is in play. Everyone (with very few exceptions) prefers to be called by their first name. Write team members' names and titles down, and their area of responsibility. This is one of the reasons you brought a pad and pencil to the kick-off meeting (engineers always use pencils, not pens). Be advised, this first meeting is where future allies are identified. Treat and respect everyone as if they have dire information you need. They may. Don’t assume that everyone wants to be there. Some may have wished they were not on the project. Regardless, you must work with them. Above all, treat everyone with professionalism and respect.

2. Requirements

Requirements of the program are like the eight ball of game of pool. You always keep your eye on the ball and they drive your every move. The people who wrote the requirements are intimately familiar with them. You should be too. Remember that becoming intimately familiar with the requirements raises your apparent status within the group. You will be like the A student who did their homework whom everyone wants to hang out with. Let there be no misunderstanding here, you must treat your knowledge and familiarity of the requirements as you would a compass on an instrument approach. Study them, memorize them. They are the voice of your customer and are the reason and justification of your every move.

There are different grades of requirements. Some are hard and fast and cannot be changed, government rules and laws for example. Others are up to interpretation. It is inevitable that unforeseen circumstances will cause the requirements to be revised, reconsidered, and traded off with other mission goals. Do not be surprised to find that some requirements actually contradict other requirements. They must be refined over time. As they do, be keenly aware of the ripple effect on your company’s bottom line and your available resources.

The Requirements Document (RD) is a wish list that more or less sets the goals the customer wants you to achieve. If you have ever written one, you know. It is not an easy task. You write it with the expectation that your supplier will question portions of it and help you refine it.

It amazes me when I see managers indignantly talk down to a customer (See: Respect the Customer) because they have been asked to do something contrary to the RD. Do not hesitate to politely remind your customer about RD456123 which is the statement of work that they prepared which your team used to predict cost. But do not use it like a club.

3. Planning

Your management is going to want to know ahead of time what you need to get the job done in terms of resources: manpower and money. These commodities are the hot buttons of your company’s controller. The key here is conservatism. Overestimating leads to further breakdowns in order to justify or explain the cost (good thing). Underestimated the work may look good to the controller. But if you are wrong, your estimates will be the evidence to later hurt your reputation and destroy your credibility.

Many books have been written on the subject of project planning but in an attempt to simplify the complex process, think breakdown. You can only understand the big picture by understanding the individual pieces and components. When you are given one week to estimate the cost of a 2 year engineering and development program, you can only understand so much.

Conservatism in your numbers can be the cure for unforeseen events, which will happen. Experience comes in handy here. Review previous projects and note the differences. Ever wonder why you are charging your time to so many different numbers? The data is useful for estimating future costs. Spreadsheets are the tool, company veterans and historical data are the fuel.

The third, and perhaps most important component to planning, is the four-letter word we all get rewarded or burned by – time. Without the proper planning (and dare I say – by the right people with the right experience) the project is heading blindly into the dark. Three predictions (people, money, time) must be constantly reviewed, questioned, and compared to the ever-changing requirements. The wild card in all this is knowing that there will be unknowns. Things will happen that will tend to throw your plan off track. You will, of course, not get frustrated when one of these events occurs, because you knew it would happen. What counts is how you deal with the unknown event.

Take inventory of your team’s skills versus those necessary to carry out the project. Also know your weaknesses. Do you need outside temporary talent? There are plenty of design shops with special skills that you can go to rather than trying to wing it on your own. Your customer will be impressed and your product will have a greater possibility of success. Use professionals when you need them. When someone asks you for something, be sure to ask when they need it. If you are unable to provide it by that date, then agree on an alternate date. Don’t wait for the date to come before letting them know that you need more time.

After the proposal is delivered and the project is in play, planning does not cease. It is a continuous tool for literally everything we do. Planning is like a tree that starts broad then branches out to the individual limbs within the organization. Each level must follow through the three steps of 1) determine the requirements, 2) plan, and 3) execute.

One example of planning is the how a particular assembly will be modeled in solid CAD. The group lead should sit down and plan out the order in which the parts will be created and placed, noting the interdependencies and relationships within the assembly. Another example is a stress lead sitting down with his engineer and developing an analysis plan, deciding what loads should be checked and what sections should be taken, drilling down finally to how the analysis should be carried out. Once the engineer begins work, there should be no question as to the direction they take.

4. Consistency

Keep the same person on a particular piece of design rather than moving from person to person. And make it clear who you give ownership to. This practice relates to learned familiarity and accountability. If a piece of design is thrown from one engineer to another, then to another, the result is that no one becomes the expert on the design. When the same person stays with a certain piece, they become intimately familiar with it, begin to understand it in ways that were not immediately obvious, and finally exploit the design and morph it into something beautiful and innovative. They recognize flaws that were not initially obvious in the planning stage.

This level of human/machine evolvement cannot and will not occur if a manager or lead is constantly moving the design from one engineer to another. In the end the materials and shape will have evolved into a near perfect balance of existence and purpose. I just love when an engineer explains to me how something works which I can see is obvious, then begins to show me the not so obvious secondary and tertiary purpose of this and that tab, or slot, or small and seemingly insignificant bump in the material. This tells me that the engineer’s manager gave this person ownership and left him alone to pour his energy and thoughts into an object that ultimately contributes to the overall good reputation and profits of the company.

5. Respect the Customer

If the customer is wrong, and you know they are wrong, then stop, relax, allow the alarms to go off in your brain that tell you that what you do and say in the next few moments and how you handle the situation will have long-lasting affects on the company and you. Withdraw for a moment before you act. I believe that one should never pass up a perfect opportunity to shut up. You cannot stick your foot in your mouth if it is not open.

The human response to this situation is to quickly point out that your customer is wrong, showing that you are smart and to make a point. This does not work to your advantage. A better way of handling it is to ask questions – curious questions, that do not insult your customer. Remember, the customer is not your adversary. I am constantly amazed to hear grown adults raise their voices at each other in self-righteous tones while in unknowingly building a brick wall between their customer and their company while making themselves look like a child in front of their reports.

Engineers are by nature, argumentative creatures. However, there is a big difference between intellectual arguments and insulting the customer. Capitalize on the moment. Relax, and ask questions that help your customer come to a realization that they are wrong. Don’t expect them to admit it. If the issue goes away, then you have succeeded. If not, then you can always elevate it to your manager.

6. Meetings

Regular status meetings are important. However; I have attended meetings where the only person sitting is the program manager. I have been in other meetings where the only person standing is the program manager. I had wondered if there was a subliminal message being sent. The PM sits comfortable while the engineers, young and old, thin and heavy alike, are forced to stand for 45 minutes and listen to things they need not be involved in. They were called “stand-up” meetings. All along I thought they were called “status meetings”.

There has to be some thought given to accommodations (e.g. enough chairs), amount of time, and the need to be there. Have a set time and day and stick with it. Make the meeting start promptly, no need to humiliate the late comers, walking in late is enough. Stop the meeting at a predetermined time (no more than 30 minutes). Be ready to take isolated subjects “off-line” where only those necessary can re-convene.

Involve your outside staff. They should have access to a party line to phone in and be on speaker phone. Do not dominate the meeting, but keep it moving. Use a whiteboard. Have a large calendar in the meeting room. Assign someone to move things from the white board to electronic notes when necessary. I like white boards. My meeting office has two of them – one for short term or hot objectives and one for the long term. This maintains visibility for everyone involved. Do not make everyone contribute. Department heads can speak for their staff, but the staff should be welcome to come and welcome to talk if they have something to contribute.

Group meetings. Empower your group – no matter how small - to share information with others in the group. You would be shocked to learn how much time one person can waste on something so simple as, for example, how to work with canvases in Microsoft Word or sorting in Excel. A 15 minute get-together on Friday mornings for your 4-person group pays enormous dividends. It also gets the juices flowing for what I call “nuggets” – information that would otherwise remain with one person, but could benefit the group (i.e. project) if shared with others. This could be techniques, or information, or demonstrations by anyone in the group.

You would be surprised to know how much you can learn from synergy (if I may) just by having these 15 minute gatherings. Have your people jot down their ideas along the week as they come up. Then, at the group meeting, we learn and share. This is also a good time to bring your staff up to speed on the project. People need to know that they are being informed of the program status, etc. There should be no secrets. Brief your group on what you learned from your weekly management meeting.

7. Sense of Humor

You gain respect by not just knowing your stuff, but also knowing when to inject humor. Don’t take it too far. We all know someone who makes jokes about everything, which gives the impression that they may not be able to get down to serious business when the time comes. However, humor and lightness are good medicine especially when injected at the right time, and especially if you are good at it.

8. People

Within a group, try to match people with others they seem to be compatible with. I believe that everyone should have a mentor. It would be great if everyone had a mentee as well so that they could see both sides of the coin, and experience what their mentors go through. If your work requires peer reviews, then match the people up who work well together. Stay with the pair (See Consistency). If they are on the same level, then ideally they would swap the task of reviewing each other’s work. Over time the team will gain a respect and knowledge of each other’s talents and weaknesses. The result is a synergistic bump in productivity. Be willing to change up the people and pair differently, but once you see that a particular team appears to be gelling, leave it alone.

Always have a backup person. This applies to everyone in the company. It does not matter what role a person plays within an organization, there should always be another person to go to in their absence. Obviously this cannot be construed as having duplicates, like hardware redundancy to reduce system failure, but it can be compared to the idea. The backup person should know who they are backing up and at any time realize that they could be called upon to make decisions outside of their role. Implementing this concept will ensure that the project keeps running with minimum downtime or delay. Teach this idea to your organization and empower people to carry through with it.

Allow time for training. Even though we remain focused on the project completion, we are all in the process of learning. The nice thing about a new program is that you are guaranteed to learn something you didn’t know – this goes for everyone involved. Don’t resist it. Indulge. Of course you should be stingy with your people’s time. Nobody wants to waste time training for something that is not relevant, but if it is, then get the most out of it. Mine the student afterwards for what they learned.

Show concern for your fellow worker’s personal life. Remember the names of their spouses and children. We are not robots. Everyone likes to know that you care about them. Show them that life is important outside of work. A healthy and happy worker leads to a productive workforce and is better for the company.

9. Organization

I learned long ago that my day is more productive when I write down the four most important things I have to do tomorrow, before leaving for the day. When I come in the next morning, I don’t have to think so hard. Share this idea with your fellow workers.

10. Wrap-up

When the project is over, ALWAYS document a “lessons learned” with contributions from every department. You can have a "working" document to hold ideas as they pop up during the program, but set time aside at the end to formalize and discuss the lessons. The department head should compile each group’s contribution into a final document. Make the time. It will be a valuable tool for the next project. This is not a time to be concerned about your image. In fact, you will be admired for your humility and your boss will respect your honesty.

Summary

The fact that you have experienced some of what has been discussed here is a tribute to your keen sense of observation. I hope that you have come away if not a little wiser, then at least with a new perspective that will help others. Bottom line is that if we didn’t deliver a successful project for our company, then the next project will be harder to find. Best of luck on your next project.