You have a difficult task. There are lots of resources on product development and project management but you don't want to fall into the trap of using 'the perfect process' in an 'imperfect environment'. Your company or industry may not tolerate multiple prototype builds, field trials, onerous process validations, etc. and if you attempt to introduce these things you fall flat. i'd take an afternoon to document what you do now (even if applied inconsistently) and then see how that maps against a typical project schedule. Where you see gaps you can decide if and when to try to introduce into your process. Some things you may try and then decide they have no value added - tailor to suit

Sounds like you may want a large project process and a small project process. Daimler has something like a 30 gate process for passenger car development but they reduce it to something like 15 gates for commercial vehicle development

Sounds like you're being set up for failure. As mentioned above, documenting how projects are done now and comparing that to standard lean/agile design philosophy is the logical starting point. I'd start off with the basics, establish a few simple rules for max intervals between design reviews & gateways, a rough template of what each needs to cover, and who needs to attend them. Prepare to be the "bad guy," prepare everybody involved for the reality that process standardization ALWAYS has growing pains, and keep your nerve steady. Best of luck.

maybe have a category of less than $$ dollar amount, you do this process.
If you have a category of greater than $$ less than dollar amount, you do this process.
Maybe a 3rd category of greater than $$ dollar amount, you do this process

The highest dollar amount you would have all the gate checks and signatures and procedures.
The higher dollar amount you would have most of the gate checks and signatures and procedures.
The lower dollar amount gets the bare bone gate checks, signatures and procedures.

Seems to me that the first thing you need to be concerned about is the work breakdown structure (WBS) that identifies all the deliverables/schedule for each project. That can be part of the "plan the work" adage, followed by 2nd part of the adage, "work the plan" to stay on schedule and cost, recognizing that it can be an iterative process. The WBS can be cast into an MS Project format, where each deliverable is a milestone/inchstone. You can populate MS Project with the allocated budget in dollars/hours as well, but you also need the discipline to maintain the IMS for the duration of the project and not treat it as a "one and done" hurdle to get through some internal wicket.

Presumably, you can use your IMS to populate your Outlook calendar with the deliverables and suitable reminders so that everything can stay on track. Given that premise, your project folders ought to follow your WBS, to some extent.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! https://www.youtube.com/watch?v=BKorP55Aqvg
FAQ731-376: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm

Wow, fun stuff! A great challenge for sure if things are really undefined. Just curious, how big is the firm? Is there really no process that exists yet?

Instead of looking at this as a potential set up for failure, flip the script! This is an opportunity to grow and create change in the organization. If the process is undefined, you have the opportunity to organize this chaos.

As mentioned above, there are a lot of approaches and methodologies you could use based on project size/complexity. I don't think it makes sense to get into it here. If you feel really unsure of yourself, it makes sense to do some research and personal development in this area. Your company should support this as it will save a lot of money in the long run if you do.

The key here - make sure that whatever process you implement is in line with company culture. You'll be making changes for sure, but if your new process is diametrically opposed to the culture, culture will win every time. Start with what's working and find a way to layer on improvements step by step so you and everyone else doesn't get overwhelmed.

Cheers!
morethan-engineering.com

Quote (engineering.coach)

Just curious, how big is the firm? Is there really no process that exists yet?

The firm is about 40 employees. The engineering department is 5 people, with 4 actual engineers who design and make drawings, with myself being one of them.

There is no real process in place. With the current set of projects, there hasn't been much new design work. We're currently using designs that are 10-20 years old and adapting them to newer projects. It is simply taking old drawings, maybe making a few new modifications here and there, and converting them over to the new project. I have not been on long enough yet to go through a large project, but we have several in the works that will require everything to be done from scratch. Looking back at past projects, there is no documentation or information other than engineering drawings. I have no idea how these projects went from idea to finished product, how designs were tested, how everything was sourced. No paper trail.

From my experience here, current projects are 50% engineering sending out designs and 50% manufacturing building these designs WHILE ALSO coming up with their own changes and sending it back to the engineering department to get drafted up. Complete chaos.

That's exactly how I'm trying to approach the situation we're in. I see it as an opportunity to seriously turn this place around and get stuff running smoothly. My only issue is, I don't have much experience and I'm going in completely blind. I can't even really lean on the senior engineers because they never really had a system in place either. Management sees this and is pushing me toward taking the initiative and fixing this situation. Everyone wants change and a process, but no one ever took the initiative and I guess it worked because the company has continued operating for several decades.

A few people mentioned documentation. I'm a little confused about the whole documentation thing. I don't know what exactly to document, specifically when it comes to processes, and when because I've never really done it myself. I don't want to waste my time documenting too much or documenting the wrong things that don't help us move forward on a project.

Quote (IRstuff)

Seems to me that the first thing you need to be concerned about is the work breakdown structure (WBS) that identifies all the deliverables/schedule for each project.

I've been doing a bunch of reading lately on project management and have been looking at incorporating some of the principles into my work. The problem I've found is sometimes I'll try and apply project management methodology toward smaller projects and it makes small projects unnecessarily complex and slows them down. I'm probably over-complicating it on my end.

I appreciate the advice so far. Going to continue digging. I really don't see this as me being setup to fail. I see it as an awesome opportunity to grow the company, grow my role within the company, and develop a huge amount of skills and experience.

Try to sell it as making sure that deliverables and timing are clear so that people are not wasting each others time not finding away to get things done faster or figure out who is the hold up. As has been said start with the basics. For example does everything think they will able to get the projects done with 4 people? If not you will be supporting them to avoid being overloaded.

PMP training was helpful for me but it depends where you get it. Are they giving you skills or telling you how to pass a test?

Check around your area and see if you have a chapter of the National Management association within reach. This organization will help you with their meetings. https://nma1.org/
They do help if you can find a chapter nearby.
B.E.

You are judged not by what you know, but by what you can do.

OP,

I was in your exact position a few years ago. One of the best things I learned is that there will probably never be a perfect, written process for these projects and it is foolish to try to shoehorn one in. Setting up routines, however, is not.

First, get a regular audience with the project sponsor, whether it is your supervisor, the president, or someone else. Then make sure their needs are met. Remember, Quality, Cost, and Delivery: you can only have two and you can only focus on one.

Second, while your senior engineers don't have a process, they sure know what has worked in the past and what hasn't, whether it be design, scheduling or some other thing. Get together with them every once in a while to go over your plan. I'm sure they will be delighted to tell you where you screwed up. Take it in stride.

Third, simple milestone schedules work best to start(Ideation done by Christmas, Design done by Feb 1st, etc.) Trying to micromanage a thousand tasks crammed into an MS Project file works great for putting small teams to sleep. If your group is used to that, go ahead, but don't introduce more than one new process at a time, or people will start to shut down.

Fourth, meet regularly with the team. Send out meeting agendas a day or two in advance so people know what is going on when they walk into a conference room. Take detailed notes during the meeting, review what's done, make decisions, assign tasks, and send out the meeting minutes/summary in writing by the next day. THIS is your documentation. Of all the ways I have tried to record projects in the past, I always find myself looking at weekly meeting minutes for the best reference.

Fifth, always give yourself more time than you think. Two things will always go wrong. The first will be something you should have caught, but you have a deadline approaching and you missed it. The second will be something you didn't even think was possible and will set the project back by two weeks through no fault of anyone involved.

Lastly, your plan will be useless the day after you implement it. That is OK. Keep records of what happens in writing: emailing agendas and minutes. Don't let anyone be able to say "I didn't know..."

Good Luck!

Chris

Quote:

A few people mentioned documentation. I'm a little confused about the whole documentation thing. I don't know what exactly to document, specifically when it comes to processes, and when because I've never really done it myself.

I would start off with a simple process flowchart and use that to create templates for each gateway review. Google "DMEDI chart" or "product development gateway deliverables." For each major step (gateway) in your product development process there are various deliverables that each dept within the company will have. Gate 0, pre-launch: 1. marketing & ROI study, 2. initial requirements doc created. Gate 1, project launch: 1. technical feasibility study, 2. schedule & budget established, 3. initial rough concept. Gate 2, experimentation: 1. Initial design complete, 2. Prototype build complete, 3. new technology testing complete, Gate 3: 1. iterations, 2. validation testing, 3. manufacturing review, 4. DFMEA doc created, etc... Once you have a high-level flow chart then create a presentation template for each, even if its just one-slide with a list of what must happen at that gateway review and who must attend, it gives your staff a process to start working toward.

You also should establish a minimum cadence/max time between reviews and gateways. Personally I don't like to go more than a month without a scheduled formal design review for each project or two months between gateways. Having a formal design review ensures that any/all questions and doubts are expressed within your lil dept, they also allow management, manufacturing, sales, etc to familiarize themselves and offer their own experience and opinions on technical issues. The gateways OTOH are project oriented and ensure that the project overall is progressing on-time, on-budget. Quite often you'll find that you need to have a gateway 4, 4a, 4b, 4c, etc due to long stretches of testing or otherwise - that's perfectly fine, the whole point is to make sure the entire project team is communicating and on the same proverbial page.

Needless to say, once you have a draft of the process laid-out, reviewing this is a good way to get buy-in and prevent opposition to your process.