- Tactical Briefs
- Collaborative Manufacturing
- Control Panel Optimization
- Embedded systems & Trends
- Embedded Vision in Manufacturing
- Energy Efficiency
- Ethernet I/O Networking
- Factory Floor Network Deployment
- Factory Floor Network Reliability
- Fieldbus I/O
- Hands-on Guide to OEE
- HMI, From the Web to the Cloud
- Industrial PCs and the IoT
- Internet of Things
- Machine Safety
- Machine Safety Standards & Strategies
- Make a lasting connection
- Mechatronics @ Work: Insight & Technology Solutions
- Opening Up Your Gateway to Asia
- Real-time Operational Intelligence (RtOI)
- Robotics in U.S. Manufacturing
- Robots & Machines in Motion
- The Future of Industrial PCs
- The power of PackML
| May 3, 2011
4 Questions on Successful Engineering Project Management
Whether engineering a process, building an interface or designing a product, you need a plan. You also need a way to collaborate, because nothing happens in vacuum.
Projects multiply, clients get more demanding, tools and techniques change, and engineers by their very nature look for a better way. John Person, vice president of engineering for Tangent Engineering (www.tangentservices.com), has been looking at how successful engineering teams work since graduate school, and has had the chance to apply what he’s learned at Tangent—a company he co-founded that has grown from 3 people to 10 in the past 5 years. He’s managed a lot of people and projects in the past 10 years, and he talked with Automation World's Managing Editor Renee Robbins Bassett about how people and projects have changed, and where he’s finding project management success.
Automation World: How have engineering projects and project management changed over the years?
John Person: The projects themselves haven’t changed much. The nature of product design is that you’re constantly waiting for input from clients, fabricators and suppliers. Obviously knowing what stage you’re at is important, but if the project schedules are not dynamic or fluid, you can’t really track projects properly. For Tangent, the challenge has always been blending transparency and information exchange into our project teams—eight core engineers split into virtual teams of two to four, depending on need—as well as trying to balance those projects simultaneously for different clients.
I started my career at a real transition point in terms of project management. Engineers always had access to computers, but they were using them more for analysis than project transactions. Use of e-mails was coming up, so there was a lot of printing out of e-mails and keeping them in binders to track projects. It seemed really inefficient, but it’s kind of ingrained in the engineering process now, which is all about documentation and control and understanding why you made the decision or changes you did.
When I talk to colleagues at other companies, they say they spend most of their day sorting through e-mail traffic because they’ve been copied on everything. They filter through about 200 e-mails a day: Half don’t need to be read at all, 25 percent they are glad they read but they don’t need to respond to them, and only the top 25 percent need a response. Trying to filter out that kind of inefficiency, while still maintaining the paper trail, is something I’ve been really interested in.
AW: How have you and your engineers changed?
Person: About three years ago I was looking for a more collaborative way to manage the projects and the teams—a way without me doing the scheduling all the time. A lot of engineering companies have the momentum and incentive to maintain the paper-based e-mail transaction systems. But people are also looking more into social networking to collaborate on these projects, to make project management more integrated into the way people are using computers now. I really wanted to make a change there. Then there is tracking our time on jobs. A colleague of mine was in charge of this whole rollout of a new system and we were talking about using Gantt charts. He said, “I hate Gantt charts because they’re only as good as the day you print them out. They blow up immediately after that. There’s no way to adapt them to anything that’s happening in the project.” I agree with that.
It always seems like a successful larger company would take a small group of people into a room, like in a skunk works, or bring together a group that hadn’t been together before so that they weren’t encumbered by the set quality metrics that the company had put in placed based on old systems. They could just freely get their work done in a collaborative way. I wanted to emulate that. I’ve got kind of a younger, Generation Y team and they’re always texting, Skyping, chatting as part of the project collaboration.
There are all these ways that people are interacting now that is a nature flow of information, and I wanted to be able to capture that as part of our design process, so that people could work a little more fluidly and stay on top of things without feeling like I was always cracking the whip for them to give me answers.
Also, when you’re working through the product development stage, there is a lot of interaction upfront, which then moves to design and analysis work, followed by points of milestones and decisions. As an individual engineer, you may have one project where you waiting for client feedback, so how do you know what you’re working on next? Individuals planning their time, and me as a manager coordinating their time, is of course a big part of project management. Being able to work more collaboratively seems to be a better environment for everyone.
AW: How have the tools changed?
Person: We had been using a job spreadsheet for time tracking, but there was no feedback or metrics for how close we were to the end of the project, or if it ran under or over budget. A couple of years ago I found this cloud-based project management tool (LiquidPlanner, www.liquidplanner.com) and we decided to jump in and embrace the style of it. We let people manage their own time, and LiquidPlanner keeps projects under control and delivered on time.
The LiquidPlanner approach was a different way to looking at projects and business. I like that it’s Web-based. It gives people the ability to access it from different computers, which allows people to work remotely if they want to. That’s a big plus for younger-generation staff. People want the freedom to look at something at 11 o’clock at night or not be in the office in the morning so they can do a specific task and get it done. It also keeps all our notes and documentation in one area.
We needed a tool that put everything in one centralized place and would allow us to literally drag and drop resources to fit changing priorities and needs. Tasks, assignments, priorities—it all becomes intuitive. If it’s on the top of my task list, then I should do it first. And everyone can see what’s at the top of each person’s task list. LiquidPlanner’s realistic scheduling engine is the opposite of a Gantt chart, which requires users to set up a static plan in the beginning, with all direction and input from above.
Our engineers know best how long a project will take, so all hours and estimates are driven by the active participants in the project. Instead of having project robots, we put the onus of ownership on them from a task and project perspective, and the results are better follow through. My job now is to confirm that their estimates are reasonable and nudge them to stay on track.
AW: How has the change in project management style helped your company?
Person: I’ve seen a 30-40 percent increase in the amount of projects we can handle since deploying LiquidPlanner. For example, we had a project recently that normally would take three to four months to complete, but with the software tool, we laid out the plan and delivered in six weeks. Best of all, this was for a prototype design, where the client gave us a napkin sketch and we had to deliver a functional prototype. This is a project we would not have touched before given the timeline. I attribute the success to being able to stay focused with my team. I was the lead engineer with two design engineers working with me. And then we had a client outside and an outside fabricator.
Prior to that, project management was more like me keeping a big list on my wall and scratching off tasks as we thought of them and had to do them. And there was no transparency. If I was out of the office, people wouldn’t know what to do next and they’d be calling me to find out where others were. Instead of me laying out a project and constantly trying to true it up to find out where people are, I put in a general structure and project milestones of how I’d like to see the project go together, then allow the actual people working on the tasks to take ownership of them on a weekly or monthly basis.
They can control their own destinies, which is good for a lot of reasons. For me, because I’m not trying to work the schedule from the top down and dictate it in that cascade manner. For them, because people can actually manage their own day to day, and understand how it fits in the big picture. You get better productivity when people understand what the whole goal is, instead of just working on micro targets one day at a time. Before, we were running blind. I knew what I needed from the top down, but I just didn’t have a good feedback loop for that.
It makes it more transparent for the client as well. We have some clients that are just not computer savvy and I can’t force them to use [LiquidPlanner’s Portal function]. But there are others who really get into it. They like being able to chat; they like being able to see the progress bar that shows time and estimated time. They don’t have to sit there wondering if anyone is working on their project today. They can go check at any time. It keeps everyone a bit sharper too, because you know that the timeline can be scrutinized.
That’s a benefit of transparency—there’s nothing to hide, so why hide it? Also, with the software we can adapt. With micro-corrections, of course we’re going to stay on target, but if something really big comes up that no one had anticipated, then we can flag it and say we have to deal with a complete change. In a traditional system, you can’t do that because you’re just asking a person, how come you haven’t done this task I planned from the top down 10 months ago? That’s an advantage of this kind of bottom-up management style: managing change and giving people the opportunity to participate in managing change.
The best of the essentials!
Secrets to Automation Project Success
Sign up to receive timely updates from our editors and download this FREE Automation Project Survival Guide. It’s packed with field-tested best practices from industry experts that can help make your next automation project a success.