I can think of countless projects that I've been on that started with we need a new piece of software or a SAAS or probably my favorite is we need a button on our website and that's going to solve every problem imaginable and ultimately the button the technology solution actually made the problem [Music] worse the world our organizations and customer needs are changing too fast for monolithic projects to take months to years to be implemented we need that value now yet few teams can operate in pure agile and those challenges magnify with scale and Rising complexity the answer is Shifting to a solution delivery life cycle that includes improving intake product management and operations it's no longer simply about development and deployment joining me here today to talk a little bit more about how we're going to implement that in practice is principal research director Vince Mirabelli advisor on solution DLC Vince what have you been hearing out there in terms of pain in the marketplace that led us down this road and why you know people should actually care about this solution delivery life cycle yeah I mean first of all great great to be here Jee thanks thanks for having me I would say the the thing that we hear the most is about building alignment with your business partners so as a as a technology team you know how do we ensure that we're aligned well with what our business partners and the entire organization are trying to achieve and part of that led to this expansion this reimagining of what the software development life cycle the traditional sdlc is and it's it's it's no longer just about software it's about that holistic uh endtoend process of delivery of value and so it's not about software software may be one of the pieces that we deliver but this is about delivering a solution that adds value and builds alignment across the organization Vince tell me a little bit about the current state this world of software development life cycle and not solution development life cycle um you know where's the pain what what are some of the risks of doing it that way when we're looking through that software lens we're really hyperfocused on that development and delivery of software but what it misses is is the book ends so at the at the at the front end we've got product management are we building the right products are we delivering the right value to our stakeholders are we doing the right things and and and building the right things for our stakeholders that become part of that solution at the other end we have this concept of continuous uh Improvement continuous delivery so are we delivering software sort of monolithically and at the end it's like here's your thing away you go or are we taking more of a a lower a agile approach iterative approach at the end end and emphasizing implementing and and enabling a continuous delivery model so that we're we're cycling through and and and enhancing the value that that the solution brings so it's it's no longer just about software software is the piece in the middle that may enable the the delivery of value but it's really about those book ends that's really different and that's why we had to expand this definition to include the that end to-end solution Vince one of the key insights Maybe the key Insight you know underpinning this entire research set is that delivery is about more than just software you know can can you share with me you know what that means to you and you know what technology leaders should be thinking about in that capacity we tend to default to this this software solves everything and and at the end of the day our stakeholders don't care about software or process enhancements or uh changes they just they're trying to solve a problem and so what we're doing here is we're we're trying to enable that and help them get to that place where where they're able to solve their problem we're helping them solve their problems you know I I can think of countless projects that I've been on that started with we need a new piece of software or a SAS or uh um probably my favorite is we need a button on our website and that's going to solve every problem imaginable and and ultimately the button I won't get into the the the specific details but the button the technology solution actually made the problem worse and so that was an example where technology uh and the the the software did not solve the problem what we had was actual you know Pro a need for a process change and a need for some some additional oversight and governance and so that's the piece that really includes that treating the the product as as a whole so that we deliver Optimal Solutions so you know we we start with product management what is what are the right things what are the right features what are the right functions and how are we going to manage our our products our processes our projects whatever whatever we want to call them and then down into that that idea of continuous delivery so getting deploying a solution it rating fixing what what might might broke might be broke or what we don't like or what features are going to continue to en enhance value so it really does take that end to end it's not about that software the software is important right I don't want to minimize the impact and the value of of software but it's a it's a way we get to the solution and to that delivery of value it's not the end in a solution DLC world how does product management or how does that initial piece prevent us from going off the rails prevent us from the we just need software we just need a button on the website problem if you've got effective product managers they can do a really good job of of cutting through the noise to ensure that the features and those functions the pieces that they're that are going down through the funnel actually are going to add value and so they become I I I don't want to say that they're The Gatekeepers because that gives them this this air of authority but what they really do is they understand what it is that the business and the organization and and their stakeholders need and then they're they're getting they're guiding it through the various definitions of done so that it's to a point of okay now now it's ready we've articulated the problem we understand the impact uh we understand why this needs to exist now we're ready to develop a soft a piece of software or you know some lines of code that help us solve the problem so product managers become effectively become The Gatekeepers to effective solution delivery what does an effective product manager look like and is it buildable or it does do you have to hire for that so I I think both I think both are possible I think good good product managers we like to say good product managers or product owners are are like CEOs of their product right they they own it they own every aspect of it uh they own the budget they own the plan they own the strategy they own everything all too often I see product owners who are proxies they're representatives of the business and so they may be product owners in title but they're still just following the direction of their line of business partners and we all know that they all want technology and that's that's fine good good product owners are like that that true owner they they're they own it from end to end so I would say it's a skill that you can acquire because there are people that probably have that skill although I would I would maybe argue that having someone in house that develops the skill maybe of more value and the reason I say that is they already come in with that tacit organizational know know they understand the culture they understand the players they understand how to navigate the waters as it were and so they may need upskilling in the in the technical aspects of product management um and then they probably need some practice and some experience but I I think that you you know you you could go either way I know which way I would suggest yeah Vince in this research one of the first statements that we make is that waterfall is dead what do we mean by that and what are the implications I think at this point waterfall has uh outlived its its its life um we you know I think there's still a place for it somewhere in the world but not in the world that we live in now uh we're moving at too fast a pace to spend months and months and potentially years planning those big monolithic massive projects because the world is changing and so waterfall is dead is is is really our way of saying you know you can't waterfall does not have a place anymore now I will say I have seen in some instances where organizations try to make that transition to Agile and just end up recreating waterfall in in small it's like mini waterfall they need it now right so so one one of the things I caught you saying there was you know basically monolithic projects bad right which is kind of a you know a component of this whole no waterfall approach I have to believe there are organizations out there that you know could be hearing that and saying well I'll tell that to my boss because I'm in the middle of this like monolithic project how do we get out of that and how do we make sure that you know when we do have to deliver new kind of you know foundational Business Systems what what what should that look like in the modern era it can be challenging particularly for for larger Legacy organizations it's it's much like steering a battleship right you need you need to start start turning hours before you actually need to to turn and so it it's not going to change overnight um what we need to do is really espouse the the value of delivering iteratively and the impact that that has on our organizations and on our Solutions but also on our stakeholders just like anything else we need to present the what's in it for them so what's in it for our organization to deliver iteratively and I won't even say agile but to deliver iteratively versus in that large uh upfront planning which which may or may not ever come to fruition uh I'm sure you know the everyone that that that's that's watching this or that that has uh has been in in the project space for any any time has worked on a project that never got out of planning and so you know you could spend years planning something that never actually delivers value I think if we if we avoid the waterfall uh delivery method and go to a more iterative method we're going to deliver value or we're going to figure out what doesn't work fairly quickly the next key Insight that you know came out of this I was reading is that business unit integration is not optional so you know tell me a little bit about you know how we got there and you know what that means and what that looks like in practice Yeah we we need we need each other one of the things that I've I've tried to to Really push is is this distinction between I'm in it and I'm in the business and unless you've outsourced your it function you're all the business and so recognizing that we the the involvement of our business stakeholders is not an option we need them and they need us right so it's sort of a symbiotic relationship between between the different lines of business let's call them it's not about us versus them it's about how do we align so that we're we're delivering value to each other from the business perspective we're getting the right solutions that are going to help us solve the problems and the challenges that we're facing that day from an IT perspective we're working on things that add value and we're not working on pet projects or working on on initiatives that maybe don't help the organization achieve their strategic goals and and objectives so we we need each other and the only way that that's possible is by building that alignment building that bridge between the the those two lines of business how do you do that what does that look like that integration how do you how do you get started it starts with understanding what it is that your business partners need and then you start the process of building that bridge it it's it really is about building trust and and enabling that alignment between between us and them and I I don't use that carefully because I don't want to make that argument that it's US versus them it's not but it's about building that bridge and building Trust ensuring that we're all um aligned to how we're going to deliver value how are we going to deliver value for our stakeholders and how are they going to receive value from us they need it and Technology to unleash to unlock the value until we get to that delivery we only have potential value right we're building potential value we're building potential value all along our our our our funnel it's not until we actually launch that into the world deploy it that our business partners start to to to realize that value and that at the end of the day that's what they care about so we need to build trust we need to demonstrate that we are uh capable and and have the ability to deliver that iterative value to our stakeholders so it becomes a uh it becomes a process of of just building and growing together in our research Vince I noticed you know we we took a stand when it comes to solution delivery and we said quality has to come before throughput can can you expand on that for us and and you know how we got there and what the risks are of maybe doing it the other way around yeah I mean so if do we want to do we want to deploy subop suboptimal Solutions into our stakeholder group into our customer group no of course not and so by building in quality up front we ensure that we are reducing the amount of rework we're REM we're reducing the amount of of required effort and we're reducing our uh or we're increasing our stakeholder satisfaction with the solutions that they receive so to your previous question that's that's one of the things that we can do to start building that trust and building that relationship with our with our stakeholders but we need to we need to get to that that point where we're we are delivering value how do you get to these quality standards and who needs to be you know sitting at the table to do so one of the biggest challenges I think is actually aligning on a shared definition of quality like what does quality mean it can be subjective and one organization's definition of quality is going to be very different than another so what's important is that all stakeholders align on what that definition means so that you can drive towards that achieving that level of quality the last thing you want to do is have a a difference or Delta in that definition within your stakeholder groups where one group is expecting has defined quality as this and another has defined it as this and that's how you get that that conflict between stakeholder groups because they're just not aligned so first and foremost Define what quality means so that you can align and drive towards that I'm joined today by three esteemed analysts from infotech Ari glazel Rob fail and Vince Mirabelli gentlemen I want to jump right into the discussion on solution DLC really interesting and Innovative model here and I wanted to ask you right off the bat is this something that is kind of tailor made for small mediumsized you know projects and and and software challenges or does it scale all the way up to um you know kind of enterprise software uh Vince do you want to take that first the principles that are included in in in the blueprint apply across the board um I think they just they help establish good practices in your software delivery your product management and your continuous Improvement continuous delivery model so that and that builds out your your solution DLC so I I would say that this this was this scales across the board I got a question for either of you if you don't mind me asking a question now based on that would you say that would you start there like like if I'm picking up the infotech research on this would you start with say for example your Erp implementation or would you start with something smaller it would depend it's always depends right right it is one of those if you have no process or framework to work with then this will give you a starting place if you already have certain pieces in place then maybe you need to optimize some of those first right if for example intake requirements analysis if you don't have that piece then the rest of it not going to work because there's no solution to deliver because you don't actually or can't figure out what you're delivering so that in the end would the start you have to have the start in the right place to get you through you also ultimately will need the framework because you need from start to finish right so does it apply yes it should probably apply to everything do you have to apply it to everything immediately no but you will at some point I would say I just to to build on that I would say uh could you apply it to an Erp size project from jump yes you could yeah should you I I I'm I'm a big big believer in getting some at bats and getting some practice and locking in the process before being able to apply it at a broader scale so I I it would scare me to do something that massive but that's not to say that you couldn't well so let me take that uh oh because I for an Erp the reason actually people have infotech is because we have the experience to take you through that solution framework so you don't have to apply it you use our methodology you apply our expertise to give you the framework without actually having you to understand the framework but so it does get applied you I don't think you'll be successful without the framework in an Erp implementation but you don't necessarily have to have it you can borrow it from an expert such as us just staying on that point for a minute Rob one of the uh you know one of the maybe more controversial things you know we wrote on this is just waterfall is dead right as one of our insights given the work you do in the Enterprise app space you know is waterfall dead should it be dead is it dead in some areas and H how does that apply when we get to the the biggest implementations my back software developer for more than 20 years there's always been that question now I've always been on the more flexible I'm not very good at following rules kind as side so it's always been when is waterfall successful waterfall is successful if you understand all your requirements up front and everything you have to deliver Hardware engineering chip and level engineering you need that because it's incredibly expensive to make a mistake that if you design a software chip it cost you about $25 million in today to do a prototype you don't want to get very many mistakes when you do that because you're throwing away $25 million so that case waterfall makes sense because you have an incredible amount of front-end effort before you get to the solution because of the value and I think that's really where you have to look at it what's the value delivered by doing that waterfall full solutioning throw it over the fence to the next stage I want to talk about what first of all focus on waterfall is waterfall is dead sure so Eric Reese of the The Lean Startup uh The Lean Startup uh um books and articles if you've read it you know he said a few pretty profound things one of them was you know waterfall is only appropriate if you completely understand the problem and solution agile is only appropriate agile is only appropriate if you understand the problem but not the solution and lean you would use if you don't understand the problem or the solution and you to figure out both so focusing on waterfall for a second right I I challenge any member to tell me that they have something that they're implementing where they completely understand the problem solution perfectly if you do if you do then you just need a checklist going from 1 through 10 do that and you're done right that's not what we're you know with solution DLC what we're saying is that like that's just not the case that's not realistic let's not pretend that we live in that world still there are certain heart you're right in specific very specific more narrow than I think uh anyone really implies where waterfall is still aoia but really in terms in the context of of it organizations and what their providing and the value they're providing to to their customers internal customers and external customers uh you know waterfall is truly dead yeah and I I would say that in the vast majority of cases yes it does not apply and now people will continue to try to apply it but it doesn't it as I said it isn't dead because there is that small percentage it's so small it's not even worth discussing so sticking with that for for a minute I mean you talked Rob about the you know the I guess the cost of failure or the cost of a redo and and so you know in in some specific instances you need to be able to answer those questions you know before you you know before the shovel goes in the ground so to speak yes is is is that true of you know an Erp implementation of a CRM implementation like when you've got that level of complexity how how do you best leverage something like the solution DLC to to make sure that you're finding the right balance between you know you know we're going to iterate and fail fast versus we're going to answer all the questions before the shovels in the ground so an Erp is already decomposed into systems you've got accounts payable you've got procurement you've got your full supplying chain these are all pieces that in some cases you can Implement in parallel and stand or stand alone uh so often as you're implementing your core Finance you can go ahead and do your procurement pipeline because they're not really connected except for the final piece to get the invoice over there but all procurement setup isn't dependent on the finance setup so you can do these in and you can decide how fast I can fail on these different pieces um and you can fail independently without affecting the rest of the program so there is lots of flexibility this definitely applies that you can do a full solution delivery you could do the the fail fast and temporary piece look at data migration nobody gets data migration right the first time it is often a multi-art stage piece and in the end you may just decide it's good enough um so there is built-in failure in an Erp you just have to manage it it's never one shot you never take you never shoot your shot and you don't get another shot at it right but the whole concept around solution DLC and the integration of agile and good product practice on the front end cicd integrated CC Pipeline on the on the on the far end there is you're going to be taking a lot of smaller shots and it's about organizing those shots appropriately so even in the case of an Erp here and I believe you're saying this is is really it is is about I'm not going to implement everything all at once I'm not going to implement my whole financials module and my whole you know AP module and all those pieces all in one one shot I'm going to I'm going to figure out maybe using some good business analysis practices some good requirements practices understanding what's most important versus less important and and order in and stage in what you're going to do that's just how that's just how you build software these days yeah like there's no you're not going to implement and configure your entire Erp then test it then hand it over you want to in your individual functions put the testing as close to the configuration piece and get it done and then moved on you know as we think about solution DLC relative to software DLC you know we're thinking about now kind of the broader ecosystem and the pieces on each end of that you know I think about that in relation to you like agile to waterfall and I'm sure you know for each of you you've seen an awful lot of agile implementations that are kind of waterfall and agile clothing is that a risk with solution DLC that they just put you know people put lipstick on software DLC and they call it solution DLC and if it is a risk how do you get around that so I'd like to respond because I I I agree that's a real that's a genuine criticism and I understand where that comes from one of the main motivations there were a couple key motivations behind the research uh and why we did it the way we did it one of them was around that you don't have a team of a of a 100 or or 5,000 people writing code in a company anymore building their own homegrown HR System their homegrown Erp their homegrown data transfer function right this is why we're not talking about software you know software and and development that's why we not talking about software development life cycle we're talking about solution delivery and so how how do we support solution delivery delivery of offthe shelf Erp offthe shelf products maybe there's a little bit of configuration in there but it is about it is a recognition that the world has changed it's not about putting a lipstick on the on a pig the world has changed right we're just not doing it anymore and we need to catch up with how people are actually delivering Solutions in organizations today yeah and to add to that even when you're building a custom system we don't say go out and write it from scratch we are saying pick a platform something that gives you a base and a bunch of functionality and then extend it so that there are solutions out there to do case management why would you build your full case man man agement system from the database go ahead and build it on top of something gives you a large ecosystem you can leverage and it already has the full solution delivery built into it because here is a a functioning platform and all you're doing is building on top of it and so you start off actually with a solution to deliver um you're just building it on top of it the so what what act sorry har no please what what what you actually end up with is that building on that base you don't have to configure everything you just have to you have to figure out and then configure what's changing and which makes the job in in theory way easier because it's just what's changing from A to B as opposed to what does B need to be yeah you're not inventing you're not exactly so development has turned into configuration maybe a little bit of scripting here and there as you need it right as as we think about the you know the the roles and responsibilities here um does this does this model require us being in a product ownership world does it require product owners to be successful or does it work with a variety of kind of you know operating models may I take that first please go ahead please take first so a product ownership model implies that there's somebody that's accountable for the delivery of value So my answer is yes can you sure but but you're you're going to miss a lot of the the key benefits of the solution delivery life cycle by not having that P that role I'm not going to say person G be careful I almost caught myself there um who's accountable for the delivery of value so who's accountable for that thing end to end and that person needs to be and person or group needs to be there to make sure again using what what Vince had said a little little earlier on right uh you know deliver the right thing the right time the right people and if I'll let you go next I know you want I'll let you go next but I'm going to really go next really was going to say was it really is a question of you know could versus should yes and that that's really all I wanted to say could you yes should you no we recommend you don't and and what I want to add is I think people if they think that nobody's accountable they're fooling themselves there's no ownership ultimately whether you take ownership or not someone is in the end accountable which really means you have ownership you're just not necessarily acknowledging um because in the end if your your Erp fails or your your software development project fails somebody's going to have to pay for that yeah and whether they're willing to accept that or not is up to them it's better to go in with your eyes open saying I do own this I'm accountable and make sure that you're delivering so is there is there a step zero to all of this which is like you know understand um and clarify who is accountable for the delivery of this value like I don't even want to say call it this role um or or change the roles but at least clarify who that person is is that a fair statements that needs to be step one and you could call the name whatever you want doesn't really that's that's really as long as you're internally consistent call the role whatever you want to call it but somebody needs to be account someone needs to be defined as that accountable individual for the delivery of value and if I could quote from a a movie a famous movie I you know you can guess the title there can only be one one and that's very important right yeah I I use that line whenever I talk about Ry and I you know that's sort of what we're talking about here is that roles and responsibilities is there is only one right yes I don't know what movie you're talking about I'm um but but no I I mean when when it comes to you can have multiple responsible you can have multiple consulted you can have multiple informed for accountable there is only one CU you need to know where with whom Does the Buck stop yeah right that you just you you end up with pointing fingers of well I thought you were doing it and I thought you were doing it and who's actually accountable you have one person and that's where projects fail is that nobody's willing to make a decision and often in public sector this is one of the challenges that people aren't held accountable and this is why projects take so long uh that we see it less in private sector is that there tends to be someone accountable because usually it's it literally is the buck stops here yeah uh in public there is less accountability this is obviously what we're working to change and I know a lot of the public sector is working to change but it's the one area that we see it is projects run long because no one's trying to no one is accountable right um and it's hard when you're looking at election cycles and things people are on a cycle well after four years I'm no longer accountable so who cares so these are the things that's why accountability is a culture another it's trust in in the organization is important if you're advising you know an organization where there isn't sufficient accountability you know would you just tell them okay well sounds like you know solution DLC isn't for you or or how how do you get there go ahead so I mean we would probably start them start them elsewhere as opposed to solution DLC to get started I mean solution see the way it's laid out it will link you there but generally a good a good info you know in fact all of our good infot analysts will be able to listen to that and diagnose that and say okay without without a sense of ownership and accountability here I mean you could have the most spectacular uh process you know known to person kind and it will fall apart and so uh we would start them with some of our other research that does talk about uh you know product ownership as a function product practices and in general and and acclimating them to that first giving them that context to then be able to uh I think really appreciate what this what this research does yeah I think it's it's a cultural change um that's what you need to instill yes and you can only do you can't jump in and say I'm changing your culture that doesn't work so that's why you have to sort build trust and show them that this thing actually works and through the examples of different things that that makes a difference what pieces of research would you guide them to if that's their if accountability is a challenge we have a few pieces of research on the product side that would that would help if we're talking about accountability there is uh make the case for product delivery to talk about product management as a very broad concept as an introductory piece we have uh uh you know we have deliver new digital product Vision which talks about the activities that that uh you know product management needs to should be undertaking and in terms of the role of product management itself we have a piece of research that's been recently updated and it's really you know really well done mature scale product ownership which talks about
2024-08-13