Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management.
Download PDF Transcript of Podcast
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Related Podcast: Evolution of the Product through Configuration Management
Transcription of Interview
Joe: Welcome everyone. This is Joe Dager, the host of the Business901 Podcast. With me today is Jon Quigley. He is the author of several books on project management and product development topics including software development. Jon has multiple master’s level degrees as well as certifications and more than 25 years of product development experience, ranging from embedded hardware and software design through verification and project management. His company Value Transformation consults and trains organizations in those area and has a broad range of expertise in both small and large companies. Jon is also a past Business901 podcast, and that may be his greatest qualification here. Jon, I’d like to welcome you back and could you update me on what you’re doing now?
Jon Q: Thank you, Joe. Yes, I would. I recently left my long-term employer Volvo to do Value Transformation work instead of trying to burn my candle at both ends by having a day job and a night job. So there should be a noticeable increase in output and throughput from Value Transformation.
Joe: Did that just happen because of let’s say you got a big job with Value Transformation or was it just kind of a gradual process, and you needed to do it?
Jon Q: It was a gradual process. I was not only wearing down trying to do two jobs, come home at the night to the wife and the son and do this work also, write books and magazine articles and things like that, but it was also the level of fulfillment.
Joe: When I think about you, you’ve been a very prolific writer. I mean you’ve gotten four or six books – I’m not sure of the exact number but they’re not exactly airplane reads either.
Jon Q: No, they’re not. Yes, they’re not airplane reads but they’re fun to write. I learned a lot in the exercise and the collaboration with the other authors. I think it’s now seven or nine books plus contributor to two or three other ones if I remember correctly.
Joe: What’s your latest book, Jon?
Jon Q: The latest book is Configuration Management: Theory, Practice, and Application. It covers configuration management at an enterprise level. Instead of going very deep into every one of the CM areas, it talks about the historic aspects of configuration management, product growth in general and how in the ancient days, somebody would build something, something would learn something from that and add something to it and make the analogy — it looks a lot like an Agile environment, only nowadays it’s much faster. Somebody build something and then somebody decided, you know what I could do one better; let’s build that with this adaptation. And then it talks about how change management throughout or documentation control or product control does not just occur at your manufacturing site, even though a lot of people would like to believe that. Your design, your development work has to fall into some kind of configuration and change management control. In fact, concurrent engineering essentially requires that you have some control over the iterations as you grab the various sub-assemblies or develop the various sub-assemblies that are put together to produce the system.
Joe: Well could you define from the point of view of the book Configuration Management to kind of put an umbrella on it for us?
Jon Q: It manages the growth of your product, and that includes some of the requirements or even earlier than that from your marketing surveys and studies and clinics. It manages what you learn along the way so that the next set of people who use that have some traceability to why they’re doing what they’re supposed to do.
Let’s start at the very beginning. Let’s say you’re a marketing guy and you produce some marketing studies and you’ve released a document and I’m using a document that you have released, there’s no way of me knowing whether I’m using the latest iteration that you released or whether I’m using something from six months to a year ago of what may have been released regarding this product. Your configuration management helps keep those things under control is where you would know those kinds of things. In other words, if I’m a design guy and I have your marketing clinics, surveys, and stuff like that from a year ago and I’m building a product and you have something later that maybe three months ago, I’m building something that you wanted maybe a year ago, and it may not look exactly like what you need now.
Joe: We’re really talking about something a little bit different than program management. This is really configuring the resources and keeping track of all the resources so that what is the newest is kind of what is on top, available to someone.
Jon Q: Right. That is one aspect of configuration management, and that goes all the way down to the manufacturing. It starts very early on in the controlling of requirements, and the requirements themselves are going to fall into some kind of configuration management auspice all the way through to manufacturing. In fact, if you build a product that’s customizable, as in you have parameters that configure it for this — and parameters, if it’s a software product memory location that are alterable to tweak the full function or fit or performance to a particular system, those things are also configuration management related.
Joe: You start out the book and the first chapter is on product life cycle, is that how we should view CM over the life cycle of a product?
Jon Q: For me, that’s true. For me, like we talked about earlier, the marketing studies, that’s where you’re trying to understand what exactly this new product might be. Those things would fall under some kind of change management control or revision controls so that the people who will use those documents to make the product are going to need to understand something. Even in the growth stage of the product, you’re going to need those to know that as well because you’re still adding things to the product. You need to differentiate this present iteration of the product from a previous iteration of the product.
The only time I’d say it’s in decline and probably there’s some correlation between decline of the product, or closing of the product, or death if you want to call it and the next iteration of the new and improved variant of that product. Unless the product is just thoroughly a dud, you’re building something like the iPhone 6 or the iPhone 24, you’re building something that’s going to grow off of something you’ve already built and even then, your CM work would be helpful to know what you had when you finished that product.
Joe: You’re managing the evolution of the product through CM.
Jon Q: That’s a good way of putting it all the way through the lifecycle. The project management has a vested interest in this because a lot of that is change. If you have a project identified to build a product or if you have a project identified to add some feature content, those are changes and those are going to fall into some kind of auspices of configuration management office.
Joe: Where does CM reside in then? Initially you think of software, and you think of it as an IT function, but if we’re using configuration management for products and I assume services too, where does that reside? I mean who gets to sit there and say this is mine?
Jon Q: That’s a good question. I’ve seen it a lot of times as a sustainable entity on its own. It’s a CM office. I’ve seen it also part of a system’s engineering group where the designs are controlled through the systems engineering aspects of the project. But at some point, the product becomes an operational thing and not a project. In those cases, there are rules usually applied in the organization’s operations for how to handle changes. DCN releases — excuse me, Design Change Notifications that have definitions and content and release documents associated and things like that.
Joe: In this day of being adaptable and agile, should we really spend time to document all this stuff? Sure we need some documentation done but heck — it seems like I’m creating work for myself sometimes. Is there a fine line on what goes into configuration management and how strict of a practice we keep?
Jon Q: I think there should be, and I think there probably is. If you are in a company who is building Website applications, and you’re all self-contained and you know where the source code at and it’s only in one place or two places, then maybe the risks associated with that make you inclined to take one approach that might be a little streamlined. The same is true with Agile; if you’re building something that has no potential for harm and there’re not many downstream consequences in terms of build, then you might strip away some of it. But the thing is this, it adds time but if you don’t do it, it’s probably going to add a lot more.
I will share a little story that’s a little embarrassing but, fortunately, it was 25 years ago, so I learned from it and moved on. When I was first out of school, a job at an industrial applications, I was building or designing 8051 embedded type control systems. I’m writing the software, I build a little bit, and it works, and I build a little bit more, and it works. They get a little complacent because I think I’m the deal because everything I build works fine. So then I sit down and I write, write, write, write, write, write, write and build, build, build, build, build, and compile it and I compile it with no errors. Now all along, I had not changed the source file name. I build a lot, I compile it, I burn it into the target integrated circuit, and I put it into the system, and the things that were working no longer work. In fact, nothing works; not what I added, nor what was there that used to function. I think to myself, oh man, I’m in trouble. Because my source code, I kept no traceability on what rev was attached to what. I didn’t bump the revision; I just kept on writing, and the compile was the same way. The only thing I had that worked was in an integrated circuit in another one of the prototype systems. I had to take the IC out of that system, put it into a reader and the hex code out of it and turn that into the assembly language.
That was a lot of work; a lot of unnecessary work. Why? Because I chose not to keep an iteration that I knew worked separated from an iteration that I was building in terms of source code and in terms of a compiled version. In fact, I got very lucky in that I didn’t just choose to overwrite the existing memory location of that IC with this new compiled version that gave me a good compile but didn’t do anything. That’s an example of a CM failure, and I will attribute it to my youth.
Joe: Should every part of an organization have somewhat of a configuration management system then?
Jon Q: It should have some kind of change. It should identify the things that matter down the stream or that have to be coordinated and the things that impact your end customer. I could tell a story; I had recently given a presentation, and this gentleman came up to me and says, we have configuration management issues. We have a system we’re building and here’s the part number for the system. One customer has three or four of these models and a card goes bad in model A, in one version of it, so they reach into one of the machines not being used, pulled that same card out, and put it on this same piece of equipment and it doesn’t work. If those were in fact the same machines like they were supposed to be, like their order information says or part number suggests, then theoretically, any card that was in one machine should be able to be put in another machine if it’s configured similarly and work, but it didn’t.
Joe: When something like that happens, I guess in software, it’s not that what I would say uncommon for something like that, is it?
Jon Q: No, it’s not. In fact, I think that’s one of the big failures you see. I’ve seen where the definition of the modules that go into the compile are not quite there, so you’re not sure which ones were in the last build. So this present build, you may be used a different module and something that used to work no longer does. Or if you’re coordinating, let’s leave software for a little bit because many mechanical people might think, oh this only applies to software. It only applies to software; that’s a fact and largely because you can’t see it, but this does apply in the mechanical world as well when you’re coordinating your designs for mechanical parts. This part fits with that part or that part number and if you change something, a part number or one of those parts, you have to consider whether it impacts the other part. You see often where a change — somebody thinks a subtle change in an angle of a bracket mounting for this system has no impact anywhere else in the system until you put the parts together and go to verify the product or the system, and then you find out that that bracket means I can’t build this system at all in a way that would work.
Joe: Well, I’d have to agree with you because I’ve always felt like that 95% of the time, everything works, and I always end up with that other 5%.
Jon Q: Me too, if that’s the way it is.
Joe: I’m a firm believer in that. I live in that 5% world.
Jon Q: We’re the lucky ones. We’re the lucky few.
Joe: When I think of configuration management, I think of it kind of like a separate entity that’s taking place and really to keep it updated means it has to be part of my everyday work, doesn’t it?
Jon Q: That’s right. It doesn’t need to be excessive, and it doesn’t need to be a lot of manual manipulation, but there should be some controls here. Imagine an Agile team that produces a build of some set of features and they hand it off to some test guy. What’s the test guy supposed to test? If you haven’t identified, have some release notes associated with it or a version description document to use or some CM vernacular, then that test guy is kind of left there scratching his head figuring just what cases are run, and that’s going to cost you time. What if he tests something that he thinks should be there because you haven’t told him what’s in it, and he finds out it’s not in there, and he issues a fault report. Well, now you have a bug in your bug tracking system. It’s not really a bug; it’s just we haven’t built that yet. So it can be as simple as an Excel sheet if you’ve got an Agile team to understand what pieces matter, what pieces you build and articulate that to the rest of the team in the downstream folks. If your Agile team is interfacing with some other Agile team or conventional project management, you’re going to need to manage those exchanges and those interfaces between those other parts similarly.
Joe: Can I have one umbrella of configuration management that kind of works for all these different disciplines within my organization?
Jon Q: I think you can but again it depends on the organization’s aversion to risk or what they’re building. If you’re building an aircraft, you’re probably going to want something a lot more rigorous and formalized. If you’re building something that’s highly tooled and costs a lot of money to do that highly tooled, you’re probably going to want to spend the money to make sure the configuration is mapped, that the changes are always synchronized well, and the iterations are planned. If you’re building a product that has a lot of adaptations out in the field or configurations out in the field, you probably need to spend some time on this as well. But if you’re building software for a phone and your team is collocated, you can probably strip it down to some essential parts.
Kim Pries and Kim Robertson, when we write together, we have revision control over our books. It’s not like it’s got a lot of overhead to it but we know how to keep track of the changes, we know how to keep track of who made what change at what time so we can see the growth of the book or a chapter in the book over time and we know, “Hey, when something went wrong here, and you’re the last person who had it, what does this mean…” kind of thing. It doesn’t need to be heavy-handed. It probably becomes more heavy-handed the riskier your product line is.
Joe: One of the things I like about the book is that you have an entire section of when things go wrong, so I think you had enough experience to know that a plan doesn’t always work, right? What’s in that chapter a little bit and can you tell me one of the worst stories in it?
Jon Q: Well, I already told you one of them, unfortunately. One of them is where you burn your hand but just keep building on top of it and then you realize, oh yeah, I probably should have kept a revision back or at least a couple of revisions back. But there’s a story in there from Kim, I’ll see if I can recall this one correctly, where there’re two different units of measurements used in the AB aerospace application that caused a space probe to rather than land gently on the surface it was supposed to land, it auger in so to say, he just splashed into it and when they traced it back, they found out that in one part of the system, they were using one set of measurement units, meters, and in another part of the system they were using another set of measurements units — I don’t really remember what, but essentially it meant that the slow down cycle for the vehicle weren’t equal. The assumption was that the data would be okay or that those two things were equal and then it lands as a crater. That’s a configuration management fail by the way.
Joe: How do I get started? I mean because this seems to me a little bit overwhelming. I know I need to tighten things up, and I’m going to call it configuration management now; how would I get started?
Jon Q: A good way would be to probably take some kind of Pareto of what your problems are and figure the symptoms anyway and try and trace those back to see if there are configuration management implications. For example if you’re spending a lot of time in rework because a design from line organization A and line organization B consistently don’t put together well when they’re supposed to and you’re losing millions of dollars in rework, that might be a really good place to understand what set of problems are causing that. In that case, it’s probably some kind of change management function or design synchronization function. So a Pareto of where you’re losing the battle or where you’re losing the most money is sometimes helpful.
And then because it’s an organizational thing and not an entity, in other words if I’m a verification group, I can’t really institute a configuration management policy. It’s really an executive function to introduce or to make sure my folks are behaving according to some measure of configuration management, but any one entity – the design guys, the verification guys, the mechanical guys can’t enforce this because really it’s about managing the changes and the synchronization of the product or the system over the life of those changes. So you can’t really do it for one line discipline. It really requires the measure of some input from all those line disciplines, and that’s why it’s standalone entity often, but the Pareto was a good place to start.
Joe: So does it become a project in itself?
Jon Q: If you’re going from nothing to something, it would be until you have it established and then it becomes operations. It could be that way.
Joe: To me everybody has to take ownership of it to a certain extent.
Jon Q: Right. They have to be at least aware of it and knowing there’re certain actions that need to happen rather than jump into the fire.
Joe: I’ve had a discussion lately and with your experience in project management and things, I wanted to ask you about it and kind of get your opinion on it. Someone claimed that really, we lose so much when we disband projects and close them out and all the internal knowledge of the people that was built into the project. They’re saying that for a life cycle type thinking, that that typical traditional beginning and endpoint is starting to get a lot fuzzier on projects anymore. Is that type of thought appealing to you or do you think it’s full of pitfalls?
Jon Q: Some of that I definitely agree with. I’m not sure it’s full of pitfalls, but the reality is, in conventional — and Agile does this much better I think than conventional. It really is your team learns considerable in the course of executing to deliver the project, right? They’re doing the work, and they’re going, okay, that did not work. Let’s not try that again. Especially if it’s an innovative company, at least innovative in how they go about it to work. At the end of the project, even if you manage to catch that, in a lessons learned book, it become something that’s not searchable and the only people that really remember that are the people who were in that particular project. If you could keep that team together, then that knowledge rolls into the next project because they had that experience recently and they’re able to apply, “Okay, we know that didn’t work last time, let’s not try that again…” kind of mentality. Or if we’re going to try that again, we need to alter some premise or some part of it. Agile is much better in that we’re looking at that at the end of every sprint. So at the end of every sprint, what did we do good? What can be made better? What was some of the big challenges that are going to hurt us if we don’t get them under control? And keeping the team together throughout that means that that knowledge stays intact and when you start a new project in conventional project management, you have a whole new set of team players, some that have learned and some that have not and they have to learn it the hard way, then you’re in a difficult spot. So I can see that. I don’t know how to institutionalize that learning. I think that’s a big deal if you can do that.
Joe: I think that’s interesting. What’s upcoming for you and Value Transformation?
Jon Q: Well, I’m finishing a book – project management with the society of automotive engineers on project management for automotive folks. I got a risk management class that I’m working on; that’s risk management from a product development perspective. It’s a risk management project class, but it’s associated with the things around product development. For example, the selection of your scope and what does that mean for you, how selecting scope influences everything else downstream, and the next thing is the strategy. If there’s my scope, I have a number of strategies to select, which one is the most probable to be successful?
Joe: We forget about scope and vision, or we got the vision, but we sometimes forget about scope sometimes.
Jon Q: Yes, exactly.
Joe: We iterate towards scope, and I’m not sure you can always do that.
Jon Q: Yes. And then the strategy is often interesting too. I’ve seen your clearly defined scope that’s maybe iterated enough, so you have a pretty good confidence that the scope is well or well-defined or perhaps it’s well-defined because it’s a legal obligation set upon you by the government, well then you really don’t have a choice on what that looks like. You better follow what the government tells you it’s supposed to look like. But you still have an option when it comes to strategy and the strategy has an impact on whether you’ll be successful. Example consider Picket’s strategy or Robert Lee’s strategy marches Picket’s group of men across the Gettysburg, that open field for about a mile. That was not a good strategy. I’ve seen strategies that really amount to that; when you’re looking at two alternatives or two ways of achieving an objective, and you’re up against a legally mandated introduction date, one of those strategies perhaps may be low cost over the long haul and the other is low risk immediately. Perhaps when you have a hard date instituted by the government, it might be better to go with the low risk strategy and then introduce the low cost strategy after you’ve gotten your development under control for the government mandate for example.
Joe: You said you were working on another book for project management, what is that book about? Is it Agile? Is it Waterfall? What is it?
Jon Q: It’s a little bit of all of that because for me — well, first of all, the automotive industry tends to be with some certain exceptions a little more towards stage gate and waterfall-ish sort of thing. Now that doesn’t mean that they gather all the requirements then do all the build, it’s still iterative and they’ll go through gates, but it tends to be a little heavy-handed because a lot of those parts are highly tooled and costs a lot of money. And if you make a mistake in the automotive world for a key switch, or a brake, or an airbag or any one of those other things you happen to hear the news, you see the consequences can be pretty dire for your company’s reputation and for many people’s lives. So they tend to be a little more conservative, but that doesn’t mean that you can’t mash some parts of Agile into the work. I’m a big proponent of that. I don’t think conventional project management is the be all and end all; neither do I think Agile is. It really depends on which one of those fits the company, fits the objective, fits the risks associated with the project, and things like that. Even if you are a conventional project organization, there’s ways of mashing parts of Agile that make good sense.
For example and this is what I like, the daily sprint meetings. You can have a conventional project management and still have those sprint-ish kind of meetings where you’re discussing with the team where they are with regard to the project. In fact, I when I was with my previous employer, I was a verification manager, and I had set the verification up work for a particular emissions project, very Agile-like. I had a list of specifications that needed to be tested too and they were prioritized; things that make the truck go and things that make the truck go safely – things like that, and then convenience features which were at the bottom. So that was prioritized. We used a burned down chart of the requirements because they need how many requirements from each one of those documents and then we divided it. We, the team divided up what made good sense to be tested where; if that makes good sense to be tested on the hill rig, if that makes good sense to be tested on the vehicle. In fact, they can’t be tested on a hill rig because you’re looking for the real world influences, so you have to do that in a real world environment and things like that. We kept what analogous to a burned down chart. We knew what incentive was up. We need to accomplish X number of test cases per day to hit the target date delivery and made some assumptions about the number of hours worked and drew a straight line and just monitored the actual execution against that straight line. So it was very much like stealing little snippets of Agile and employing it on this subset of a very big conventional project, and it worked very well.
Joe: All these different definitions of project management disciplines seem to be kind of nerfing themselves together for what’s needed at the time and for the team that you have.
Jon Q: And I think that’s appropriate. I think that’s the best way to solve this rather than say Agile is better than conventional, or conventional is better than Agile. The thing is, it depends on.
Joe: Yes. What’s the best way for someone to contact Jon Quigley and find out about Value Transformation?
Jon Q: Value Transformation is on LinkedIn. You can search there, Jon Quigley if you do a search for me. Or email me at [email protected]. You can reach me on at LinkedIn @jonmquigley. So there are a lot of ways you can get a hold of me. I’m on Google too, so please, connect with me.
Joe: What’s your URL?
Jon Q: www.valuetransform.com.
Joe: I’d like to thank you very much, Jon. I appreciate your insight as always and look forward to talking to you again as maybe you get further down on that next book.
Lean Sales and Marketing: Learn about using CAP-Do