PMTips: Today we are doing an interview with Jon Quigley, who is a Project Management Professional with over thirty years of product development and manufacturing experience, ranging from embedded hardware and software, through verification and project management.
Jon has an Engineering Degree from the University of North Carolina at Charlotte, and two master’s Degrees from City University of Seattle. He is on the Western Carolina University Master of Project Management Advisory Board, as well as Forsyth Technical Community College Advisory Board. He has been a guest lecturer on Project Management at Wake Forest University in Charlotte, NC and the Eindhoven Technical University where he acted as an expert resource to a Configuration Management conference sponsored by the university to the local high-tech businesses.
Jon has won the Volvo-3P Technical Award in 2005 and the Volvo Technology Award in 2006 and secured seven US patents and several international patents, ranging from human machine interfaces to telemetry systems and driver’s aides.
In 2009 he established Value Transformation, a product development training and cost improvement organization. He is an experienced teacher, having taught at universities, as well as at technical schools and businesses. He teaches, coaches and consults on topics like product development, product and process management, and project management. He holds the PMI’s PMP and ISTQB’s CTFL certifications, for which he also teaches preparation classes.
Jon has authored or contributed to more than 15 books that explore topics related to product development and project management, some of which are: Scrum Project Management, Testing of Complex and Embedded Systems, Total Quality Management for Project Managers, Configuration Management: Theory, Practice and Application, Opening the Door: 10 Predictions on the Future of Project Management in the Professional Services Industry and many more. He has also contributed to numerous other works including the Encyclopedia of Software Engineering.
As a member of the PMI he has spoken at numerous PMI events throughout North Carolina and Virginia. He has also given numerous presentations at product development conferences on topics related to product development including testing, agile and project management. Jon is an expert at ITMPI (IT Metrics and Productivity Institute) and is one of the Pm2Go experts, as well as a recurring contributor to the Software Process and Measurement cast.
Jon, welcome and thank you for accepting our invitation. We are honored to have you with us today.
Jon Quigley: Thank you, Ana. I'm glad to be here. It’s a good thing we made connections to make this happen.
PMTips: You have over 30 years of product development and manufacturing experience in the automotive and vehicle industries, ranging from embedded hardware and software through verification and project management. Can you tell us how one develops a career in the rapidly changing and fast-paced digital world? Moreover, what kind of challenges have you faced in your professional life?
Jon Quigley: I can say that one of the things that have got me where I am – because I didn't have a road map, I didn't create a road map – it was mostly curiosity and a constant wanting to understand how things work or how things could work or how things could be better. It's a constant questioning of where you are and what you see, why you see it, why you perceive it to be the way that it is. That's a pretty fundamental part, because that curiosity is what enables the next part which is ‘I should go explore that.’ You know, the first thing is ‘does that matter, should it matter, what do I know about it if anything, why would I need to know about it, for whatever reason.’ And then that curiosity precipitates, or makes you go off and do the things that come next, which are ‘I think maybe I will dissect this part’ or ‘I will read on this’ or ‘I will go study this’ or something like that, to try and learn more. And then that is like the thread of a vest or a jacket, pull that thread and there's another thread right behind it, it just keeps on going, it leads to something else. So you find yourself starting at one point and just kind of working through a progression that your mind takes you [on] based on that curiosity. There are a lot of challenges with this because, mostly in large companies, they tend to put you in a bucket that you're hired as a particular position profile: you are a project manager, you are a senior project manager, you are the guy who writes code or the gal who writes code; those constraints can really hinder your exploration a little bit.
I was very fortunate. My first job was at a small industrial application company, and they were organized so that the engineer that designed the product was also going to be the engineer to help set up the manufacturing. He was also going to be the person to help test it. [I] did everything, everything from research, the individual components, designed the system, except for maybe the packaging, [but] you still had to contribute to the packaging, which is how the part fits inside an enclosure, how the enclosures are shaped. So that sort of stuff, that wide range of experiences kind of set the tone for the things that would follow, the need to have a constant variety and the constant curiosity.
PMTips: Can you tell us if there was a project that left a strong impression on your understanding of project management? Is there one project that you cannot help but recall each time you start working on a new one?
Jon Quigley: This is a good one. This is a good question. It was called the ICO 5 Project, which was an instrument cluster project that went out in 2005, for Volvo actually. It started about a year and a half, two years earlier, and this was a big change from the way the company had developed products for their vehicles. Volvo was a multinational company, it's a large company. I guess most folks know that it's out in Europe, Sweden to be specific, but this is the truck company, and Sweden owns Mack Renault, they bought Mack and Renault, and they have a Volvo platform here in North America. They're not the same truck, they share some parts, but they're not the same or the same vehicle. So Volvo goes and buys another company – they bought Mack, and Renault trucks, which also had Mack trucks. The merger of these two large truck companies required some large system changes, to take advantage of materials, use common material as much as you can where it makes sense, and you get volume discounts on those materials which make it possible to offer a better value to your customers. So the ICO 5 Project did a couple of things: it was to develop a unique instrument cluster for the North American brand that worked off of the European brand, also at the same time to develop the one for a Mack truck that moved their system to the system similar to the vehicle architecture, electrical architecture to the Volvo trucks, so there's a lot of technical challenges in this. It consisted of assimilation of another truck brand, or merging of these two system architectures that work the same. It consisted of the political aspects that go around that – there were trade-offs for each platform, the North American version in the Volvo truck, and then North American Mack truck, because they were not the same.
And what I learned in that was how good a close relationship with the team members – essentially it proved to me the synergy rule, the one plus one equals five or even three or four, five, because there have been a few times in my life when I've worked on what I would call a serious team, and that was one of them and I have no idea how it came about. It just came about. People just did what they needed to do, they knew what their areas were and how they worked together. It was rather exceptional in my view. And so prior to that had been largely a technical project, but at this point I started to see this is seriously not just technical. It's really about managing the technical with the social parts of this, to create an environment where really interesting things can be born out of.
PMTips: You currently work as a project manager at TE Connectivity, the global leader in sensor and connector technology and also a company that strives to engineer a safer, sustainable, productive and connected world for all of humanity. Can you tell us about the kind of projects you manage at TE Connectivity and how you make sure that they contribute to a better future for the whole planet?
Jon Quigley: Well, the product line I work on is sensing technologies for emissions, as in diesel trucks, heavy construction equipment. Most folks know that these vehicles had in the past produced emissions that were not really good for people or the planet. Then over the years those things have gotten better and better. And so the product I work on, or around those, reducing the particulate matter or getting rid of the bad stuff out of the exhaust that's a byproduct of the combustion event of the diesel engine, so for me that's a really big deal, that means less [of] these pollutants into the world and a safer better place.
PMTips: You have won the Volvo-3P Technical Award in 2005 and the Volvo Technology Award in 2006. What was your initial response to receiving this kind of recognition? Did it influence your professional image in any way?
Jon Quigley: I would have to say I'm not sure it influenced my professional image – externally, I can't – but internally, that was a pretty big deal for somebody that grew up in a trailer park in North Carolina. It starts to make me think that maybe I'm able to do more than I think I can, or thought I was able to do, without even planning. It's not like this was on my target of things to accomplish, win these awards from Volvo. I was just focused on where my curiosity took me, which was this particular project, which was the one we talked about earlier, the ICO 5 Project. In addition, the challenges because of the merger, there was a whole new way of doing an instrument cluster in terms of the software. Most companies outsource the software, and in this case the operating system was outsourced. The component, the software that actually made the vehicle do what it needed to do, was done in a lab at Volvo at Greensboro. So at the same time I'm winning this award because I was part of the global core team, I was kind of struck back because the reason I'm winning this award is because of the success of the project, and the reason the project is successful is because of the group of folks that we were working with at BPMA in Greensboro that weren't part of this global team. So I was a little bit conflicted there. My name was the one that came up and there were about six other folks, at least four that need to have their name on it, and I did the best I could by them to make that better. So I thought it was prestigious and really cool that I got to go, to make a trip to Gothenburg. I came away knowing just how important those other interfaces were, the actual social part of the work and getting the job done kind of reinforce that.
PMTips: What does it mean to have worked for Volvo 3P, considering that this entity is responsible for the creation of the 3 point safety belt, which has been the most effective lifesaver in traffic for fifty years. How challenging is it to work on a project with that much significance? What are the major responsibilities of project managers working on projects that involve the safety of passengers?
Jon Quigley: This is a really good question. Do you walk into a company – everybody knows Volvo, you know. Even if you don't know the 3 point safety belt, you know that their vehicles are designed to be a safe vehicle, if you're aware of them at all and high quality too. So when you walk in that kind of thing, you're thinking ‘Maybe I hold myself to a high standard in terms of performance,’ that sort of things I will not let go by as in the quality of that deliverable, or of the attribute. I have to consider maybe even a higher level of standard, or of refinement, because we're talking about somebody whose name's been around for a lot longer than mine, and is directly associated with these quality activities or quality products. So when you walk in the door you're thinking, everything I do I need to make sure is as pristine as I can get it before it's seen by the customer, or encouraged by the teams I'm working on to make it as pristine as we can get it before the customer sees it, which adds a certain layer of attention to detail that may not exist if you weren't concerned that your name was now being attached to Volvo, when your actions were attached to such a high-end vehicle. So that makes that a little more challenging because of the significance.
In some industrial applications maybe you can get by with some minor imperfections visibility wise, or strange performance, but we're talking about a company that has a high reputation. The major responsibilities for a project manager working on projects like that, that involve safety, is to make sure that what we think we know we actually know. And by that I mean project managers are constantly making decisions, or they are influencing the direction of the work – are we ready to go to the next part of the work, for example, is this a sufficiently good quality to allow us to move to some next piece, depending action that happens on this piece of work. And what I find is that a lot of times yes, for haste maybe, there's so much work going on or too many projects being ran that we sometimes shortcut this understanding, or we find some brief evidence that suggests we're on the right path, rather than look for something that tells us we're not on the right path, say confirmation bias kind of thing, or rose-colored glasses as we call it here in the States. That means a measure of optimism bias. And when you're working at a company [where] you're delivering a high quality, high-end product, that optimistic bias, in my view, must be tempered with a real critical eye, because that's how you find the defects, how you find the things that should and can be improved. So balancing that level of optimism with a good deal of critical thinking, and a critique of the actual situation and determining ways to really understand that metrics or measurements is very important when it comes to any project. Then when it comes to safety related projects, that's even all of a more so, because there are a lot of legal consequences as well associated with these things.
PMTips: What was in your focus and also the major challenge for you while working on the projects for Volvo? What defined the success of the projects you managed?
Jon Quigley: Well, large companies have political intrigue, and so that's a real tough nut to crack, as in who in the organization's hierarchy and in your team need to know where their interest resides and what political motivations do they have. They have to sort of discern those sort of things, you have to address those in a way that allows the change that you're looking to have happen occur. The other thing that decides the political intrigue is large companies have knowledge, they're all over the organization – who knows what and which one of these many different perspectives actually or adequately represent the situation of the circumstance, or the product that we’re looking at. So discerning those sort of things, it can be a little difficult as well. And for me what mattered is not necessarily who was saying what, but one is how we can create an environment where anybody can say what they need to say, because that's really important, and then the two is find a way to find out which one of these is correct – not assuming somebody is not telling the truth, surely they think what they're saying is true but that doesn't necessarily make it true.
So you have to find to way create an environment where people can say what they need to say about what they see and what they think, and then find a way to see if what they say and think is really the situation your encounter. And those are through some kind of measurements, or some kind of additional queries to other parts of the organization, perhaps. Because the only way to make a change, or an only way to address whatever challenge you have, is to understand the nature of that challenge and then create some kind of action to address that challenge. And usually that involves the team too, and that's where that project team environment [is], where they can say what they need to say. When I worked at a project – sometimes project gets the bad news – you know you're working through Thanksgiving, and many project managers might say things like ‘this is an opportunity,’ or trying to spin it really quickly as ‘everything's good, this is going to be fine.’ My personal approach is that's not an adequate way to address. I in these difficult challenges would let the team pop off. In fact I might pop off just a little bit on my own, pop off when I get a little irritated, and demonstrate that in front of the team, demonstrate what a reasonable approach might sound like and then quickly get everybody through that negative, because you know they’re experiencing it, quickly get them through that, and on to the positive part of fixing or correcting or making the necessary adjustment, you can't just suppress the stuff.
PMTips: One of your responsibilities while working for Volvo Group Trucks Technologies was to manage a group of more than 15 Verification Engineers and Technicians across two locations, Pennsylvania and North Carolina. How challenging is it to lead a team of people that are working in different parts of the country? How did you manage to address and resolve the various issues they all faced?
Jon Quigley: It really is a challenge. We treat distributed teams like that's a really good idea, and it certainly has merits, but it doesn't come without challenges. And one of those is those off-site folks, if they don't have contact with the other side, or are seen as a standalone, separate group of folks rather than part of this team. So that's one of the challenges, how to ensure that everybody on your team, the ones located in your immediate building and the ones located wherever they have to be located, believe that they're actually part of the team in contributing.And there's some things you can do there besides just having the occasional meeting or even the formalized meeting. Video conferencing helps setting some ground rules for how we perform when we're having these virtual discussions, as in levels of distraction, what you can't have in the room, with your cell phones, laptops and things like that. And then occasional visits.
And because the teams were – in this group of 15, who were broken into chunks of separate little groups, like there was a section of folks in this 15 people that were systems integration people. That means they did vehicle work, they climbed on the vehicle, they tested the parts that were all the vehicle via driving and stressing, things like that, stressing while actually driving. There was a group of people that ran software tests, automated level software tests on the individual components. And there was an environmental guy that did – one on each site – that did EMC electromagnetic compatibility, environmental things like thermal extremes, vibration, all these things that a vehicle can be subjected to as it rolls down the road. So when the team was divided up like that, I made sure that they had a counterpart at the other location. There'd be two people, one person in the Greensboro location, one person in the Allentown location that did environmental work. So those two folks were, in addition to being part of a verification team that was this 15 people, they were also their own little subunit inside that to work out things like the environmental stimuli to which a vehicle can be subjected to or individual components can be subjected to. Same was true for the software testing.
PMTips: You are the principal and founding member of Value Transformation, which is a product development training and cost improvement organization. The purpose is to offer the best consulting and training solutions by connecting the practical experience and domain expertise of the experts that teach these classes. Why do you believe that merging the practical experience with theory is the best approach when it comes to teaching professionals?
Jon Quigley: Well, it's impossible to espouse a theory without having any true understanding of the work in itself. It is that practical experience, or the tactical experience that informs what matters, which informs the sort of things that a person would need to learn. Also, in my experience, it's not like every one of these things are separate. For example, just look a project management. We have project management as a set of disciplines, if you look at PMI, so a set of knowledge areas that are used to deliver some kind of temporary something – in our case we're going to call it a product – we deliver a product of a certain scope and at certain time, with a certain cost, both for the product and for the project. So we treat that like that's a standalone thing, but if you even decompose the project itself, let's look at the knowledge management areas, let's take a risk for example, and so if we have some risks that could cause our schedule to be late, right, so risk is connected to our top-level project delivery. Now let's take a look at something like software testing or testing of the product. If I test, if I have in my time plan a chunk of time for testing and I run my tests and the product fails the test and it's a pretty significant fail, can that have an impact on my project schedule? Certainly it can, so it can have an impact on my project schedule. The point I'm trying to get at is that all these things are interconnected when it comes to – I'm thinking most things – the software testing and the project are intimately connected, configuration management software testing and the project [are] also connected.
So the thing is, when you’ve set about trying to learn something, you learn one domain of it, that you don't really see the consequences of that one domain on others and you may not understand that until you've actually done the work, which helps you understand what kind of learning, what kind of training or what should be the end result of this training event. Okay, so now you understand what risk is, but you can't see how to apply those set of actions, activities in the real world and in a real project that's trying to achieve some objective. And it works both ways – you bring in the real world into the training; that helps establish the details of what the training should encounter, but you also take that real world in the script of the training in a way, so that those that are taking this or undergoing this training will be able to immediately start applying it or be given some ideas for how this stuff, you know, works with the other pieces.
PMTips: One of the most noteworthy things about your career is that you have secured seven US and several international patents, ranging from human machine interfaces to telemetry systems and driver’s aides. Is there one that you consider to be more important than the others?
Jon Quigley: I don't think so, but what I find most interesting about those is the collaborations. They were all different, but they were all similar in that it was a collection of people thinking through a problem or an opportunity that was in front of them, ‘Wouldn't it be great if…?’ some kind of statement like that. And then people just kicking those ideas around and find out how could that happen or is that even possible. For me that's the true take away of any of the intellectual property generation. It's seldom the one person sitting at a desk, [that] designs all this stuff, maybe has a dream of what the intellectual property would look like or the product would look like, and then starts scribbling away at documentation and making prototype parts to test their theories.
It's more of those brief moments where we're not actually buried under the workload of accomplishing the project when we can look at things with a more longer-term view: what would we do, how could this be done better, or wouldn't it be great if, around other people voicing those things rather than keeping them to yourself. In fact, a few of these were started out by being outside around a picnic table, we were frustrated about a roadblock and trying to figure out how to make something and how to achieve some objective within the constraints, or within the conflict. All conflict is not bad, some things, some conflict is good. It generates these questions ‘How can we do this differently or better?’
PMTips: You have authored or contributed to more than 15 books on a range of product development and project management topics, most of them used in master’s courses at universities across the globe. How do you approach writing these books? Do you treat them like projects and what do they mean to you?
Jon Quigley: I do treat them like projects. They mostly come out of this whole ‘takes us back to the beginning, where it's curiosity,’ right? Okay, the first one was – I saw or I worked with the project management at a Tier 1 supplier, and they were using words wrong, as in key project management words, like critical path. When you say critical path that means a very specific thing, that's not just an immediate something that's in my way. And I thought I need – they're not getting it, I need to help them with this, so I started the first book to kind of meet that. And that's where I met Kim Pries. I'd started writing chapter 1, chapter 2, and I found out that he had been writing and he had written a number of books. I had known him for probably seven years at this point, I didn't realize that, and I asked him some questions about ‘How do you go about doing this?’ after I'd already written two chapters in Word, and Word kept crashing, so I've called him up and talked to him about it. He suggested a new tool, InDesign, and I started using that and we talked about ‘You know what? This would be better if it was the two of us cause we have…’ He actually worked at the supplier. He was on the inside of the company with the project manager I was having some difficulty with. So I thought that's a pretty good perspective, one [working] at an OEM (Original Equipment Manufacturer) and one at a supplier. So that curiosity is what starts them, or seeing that interconnection between the disciplines, because they're not all project management books, but they're all product development centric books. The interaction of these things, and seeing that the whole of the product development as a system or as collection of subsystems helps.
And then I do treat them like projects, because when you get a contract, you sign the contract or deliver a book, you have now a delivery date. This thing has to be delivered, a certain number of pages, a certain number of graphics and a very specific delivery date. Now there's plus/minus in all of those things, plus/minus to the page count, graphic count and the delivery date. You know, if you're 30 days early or 60 days late, they’re probably not going to hurt you, but you still have to deliver this thing at some time, and sooner is better than later. So you have to handle them all like projects. And for me that means that I get to practice project management in a different domain rather than product development, although you can argue developing a book is in fact some kind of development work, but you’re also collaborating in a much different way. In many cases the project manager, at least in most of the cases in my career, the project manager is on site with a bunch of engineers and they may have some other folks off-site. The book writing, everybody's off-site, we don't share a server somewhere, so we have to find a way to manage the updates to the books and changes to the books. Everything's connected here, there's risk of [not] getting the book done on time. So it's just like a mini project.
PMTips: You co-authored Project Management for Automotive Engineers: A Field Guide with Roopa Shenoy, a book that offers an enterprise-wide look at project management in the automotive and heavy truck industries. With this book you have paved an objective road for professionals working in the automotive industry. What kind of advice do you offer for dealing with the challenges that project managers face when managing automotive projects?
Jon Quigley: Well, one of the big things to take away is focusing on what really matters in the project. I find that these larger projects end up with a lot of dispersion of the effort, everything matters equally and that's not true, that's not even remotely true. Some things matter a lot more than others. So the advice I offer is to look at this incrementally, take it in small bites, figure out what really matters most at this particular point in time, and then focus on understanding that. And that will tell you some other things that will tell you what other depending actions you may need to take.
This book came because I had a friend I worked with, he was a project manager when I was the test and verification manager, Jacob Haglund. He was doing some PM work at this company and he said – I’ll paraphrase – his problem was that his team members really didn't know what a project was or how to work in a project. They did their work and they did their work in isolation. When things changed they just adapted, but they didn't understand the consequences of that change on them and other folks, or the consequence of their change and in response to that change on other folks. So for me that book was to try and show the connection to engineers – these are the things you do, but this is how what you do is connected to everything else, or at least a number of other things else in the company so that when you make a decision that you think you can make unilaterally, you should be thinking about unilaterally, but what does this mean downstream, who really needs to know this and why, and if I don't know that answer I should go ask to find that answer, not just assume that that's the case that nobody needs to know.
PMTips: In your book Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality that you co-authored with Kim Pries, you address the project management of embedded products from concept to production. Considering that you present a few war stories and offer concrete solutions to problems that might occur in production, would you say that there is a proven way for delivering a reliable complex system to market?
Jon Quigley: I would say there are some consistent steps you should take, or at least you should consider, and that the system that you're looking to deliver dictates what really matters. And that being – what I'm trying to say here is context matters. Some things matter more, in some cases, than others and it depends on what you're working upon, what you're working that sets some of those definitions or what matters most, the context of what you're doing and where you're doing. So for example let's take a product that has no legal consequences and all the legal issues are removed from the system, so anything that you would have in your repertoire that was there to make sure that the product met the legal requirements [is] not necessary. But there are some key things that are required for developing a reliable and complex system to market vehicles. For example, we know that if we save our testing to the end of the project, or into the product development cycle, that that's going to not work, that's going to cause us to find late problems, postpone delivery, and that's really where the learning starts at the end. That's absolutely what you do not want to do. So it makes better sense to deliver small iterations of the system throughout the development process, the sooner the better, with some small defined set of capabilities that ever grow, rather than try and deliver it all at one whack and then try to figure out how to really make it work.
Those approaches, the iterative and incremental approach, even when you're using some kind of stage gate approach is important. And configuration management and managing these changes to each of the subsystems in a way that allows the parts to go together. For example, let's say that I have an electronic control unit, let's use an instrument cluster, and I have an instrument cluster that has a number of gauges – instrument cluster being the driver interface to the vehicle - has a number of gauges on it, speedometer, tachometer, fuel gauge, air pressure gauge, oil level, oil temperature, things like that. Okay, so if I want to test some of these things on the instrument cluster, I'm going to need those similar systems or the systems that support that on the vehicle working in a particular order. For example, for speedometer I will need to get engine road or speed of the vehicle, road speed from probably the engine, and if I don't have engine road speed from the engine and I want to run a test on my speedometer in the vehicle, I can't do that because I don't have the engine road speed broadcast from the engine, or the vehicle speed. So this is where configuration management comes in and that's part of the scripting: what things get delivered in this system along the way. Say, for the first pass I want to be able to drive the vehicles, I'm going to need brakes, I need a transmission that allows me to shift, I need an engine that makes to the transmission, and I'm going to need certain instruments, certain things the driver has to see to make the truck legally drivable. So I'm going to need a speedometer, probably need a tachometer for the shifting. There are legal requirements around break pressures for air brakes, for class A trucks, or for heavy hauling trucks, and those things would have to be in place. So the configuration management scripts out what each one of those iterations of that software system are going to be. And that will fall under the project management to define those. The first package needs to look like this, contains these set of features, the next one does this. And that will be in the project management plan, but the mechanism that actually does the work is the configuration management, or that's a product management sort of set of activities.
PMTips: If you could give yourself advice, look back and talk to a younger version of yourself, let’s say right when you started working on your very first project, what advice would you give? Also, is there any advice you would give to young professionals who wish to become project managers?
Jon Quigley: The advice I would give myself would be – when I was in my youth I was reactive. I will call it reactive, as in I did not receive bad news very well, and maybe handle the frustration very well, so I would say be patient, you don't get there overnight, just keep working at it and you will understand these things eventually, maybe, but if you don't quit you always have a chance of understanding more the next day. So I think there's something to be said for the patience in yourself and understanding these things, and progress in general. Persistence and patience, these two go together I think.
And I think that that advice also I would give to a young professional trying to become a project manager, or professional working to become a project manager. I would ask them to also think about their desire to go into project management, because it's a tough job. It's everything from technical work, to working with people, and I don’t mean managing people, because that's not necessarily what happens, but it is getting a collection of individuals, or creating an environment as best you can or a collection of individuals to achieve an objective that is often a stretch goal by the company, as in it's sometimes underfunded, it's sometimes understaffed. I've not worked at a company that threw everything they had at every project they had. It's more like they want to minimize opportunity costs, they want to get as much done with as little as possible, and that makes sense from resource utilization and capital utilization for the company. But it creates a situation that is often very challenging for the project manager and the team members. So this is a job that requires not solving problems, but you can't necessarily use solving problems with project management, but creating an environment where they can be solved, where the team has confidence that they can in fact be solved, rather than just throw their hands up and give up. And on top of that you have the executives often pushing the PM in ways that run contrary or are antithetical to team development. For example, mandating a particular delivery date when the executives don't understand how all the parts go together. So it's a very challenging job, a project manager, and you're everything from friend of the team members or colleague, to guidance counselor, shoulder to cry on at times, I'm sure, and someone to rage against when people are really frustrated.
PMTips: Jon, thank you once again for being our guest today. We really appreciate you sharing your experiences and knowledge with our readers and listeners.
Jon Quigley: Thank you, Ana. I really enjoyed this. I look forward to future ones as well.
PMTips: Yes, of course. We will invite you for a second interview next year.
Jon Quigley: Nice.
PMTips: Thank you very much.
Interview conducted by Ana Mitevska