This one is for Carla, the CIO. Once you have a working view of these key activities that you can link back to your view of product/market fit and your view of the customer journey, there are some great things you can do with it to really do a better job of chartering your IT projects especially "strategic projects" like digital transformation. There are four problems that appear a lot, I think, in IT based on my experience with my own projects and working with clients on the advisory side. One of them is order taking versus consulting, so just doing what the user says rather than really thinking about what makes sense. And that's not to say users don't know their job. They absolutely do but they're not really there to design software for you. That's not their specialty. In a similar vein, because it's generally so relatively easy to get started with enterprise software and they're usually done in these big batches and really just wants to get started deploying stuff so they can check things off and claim a win, but we're really looking not for a bunch of output from IT. We're looking for outcomes for the company, so spending a little bit more time designing, we'll talk about what that means, is often the right choice for an IT team that's doing even an internal project. Why? Because oftentimes, we're just papering over problems with processes that aren't well thought out or explicitly thought through or are done five different ways where that's a bad thing versus really thinking about what those processes should be. And there's a fallacy that good software will just magically solve those problems. That's just not true. Software can automate and standardize things that you already know how to do but you've got to know how you want to do them first. And then finally, working in small batches is really important because that allows you to see whether what you're doing is really working or not and intuitively improve on that. Let's talk about the inputs to this process. Guess what? The answers to these three questions are the most important thing and you've already got them. The first one is who are buyers and why do they buy from us? The second one is what's the journey they take? And the third one is what activities and what resources do we think are strategically important to deliver those? So those are the things that you've worked out in your business model canvas. And now, one thing that you can consider is creating what we call process inventory from your key activities. And I know what your thinking, process design. I'd rather just go home and watch TV. I've made a process design. It was this big silly thing that sat in the COO's office on a gigantic poster and had no bearing on reality or future reality or anything. It was just an exercise. And I've been there too, and I know that's a waste of time. This is a somewhat different approach. And the key thing is, two things really. One is we're starting from these key activities that we've hopefully chartered with the whole company or at least the whole division or area that you're working in so we know what we're doing has an anchor of significance to the company. Then we're decomposing processes and we're building them into individual atomic processes that we can use as really kind of like prototypes to guide what we're doing with the enterprise software. And what I mean by atomic process is really three main things. Every atomic process has a specific input. We'll go through some examples in a second. It has a series of steps, and these aren't like push a button, but these are about hand-offs where they're necessary between parties and pivots on based on what happens like cancels appointment, doesn't cancel appointment, stuff like that. And then it has a discreet output. And this may just sound like another bunch of gobbledygook about processes that's super boring and arbitrary, but I promise you it really does work and I've seen it work in enterprise software projects. And our goal here is to take NVA time, non-value added time. This is time people spend fixing mistakes and dealing with broken processes and waiting on things, and we're going to try and eliminate that. BVA time is basically paperwork, so time people spend, reporting out things, or explaining things to other people so those other people can do their job, and we're going to try and minimize that. RVA time basically is time that pays off to things that we've chartered in the canvas as being important. I'm going to share you an example what one of these processes looks like. And I'm getting just this little bit of a different example for various reasons. This is United Children's Theater. This is a nonprofit organization that basically provides an outsourced arts program to public schools. So their audience is children K-12 that want an experience in the arts, mostly theater arts, and they are a performing arts institute that offers affordable programming to low income schools and children. And unlike private institutions, their product offers great programming with a long track record of success at a rate that these students can afford and also, not mentioned here, but with financial aid to help them. And I want to go through the whole canvas but these are their key segments. They deal with their sort of audience. They deal with administrators and teachers at the public schools where their students are coming from and then they have donors that help fund them, and those people ascribe importance to these various propositions that's here. Pause the video if you want to take this in a little bit more. But I don't think the details are that important. This is an example of what a process inventory looks like. But we have this key activity of donor development, which I'm going to punch back here. Sorry. And that was here. So donor development basically means getting donations. So we're sort of taking this off and now we're going to put it into our process inventory. We're going to start here. And for those of you that are fans of bloopers and stuff, yes, there's a typo there. It's just the qualified donors is a sort of next level down process or functional process we call it. In this case, they're going to use Salesforce. So what tool they're going to use, you can put here or you can put a placeholder. If you're not sure yet that, is A-OK. The input is a fundraising campaign. The output is a qualified donor. And these are a few metrics that you can read about in the appendix. I won't cover them here. So basically, the input to the specific process we're going to look at here is a valid lead that came from a lead qualification process. And the output is going to be a qualified opportunity over here. It's a little tricky, the nomenclature. It doesn't mean necessarily that it is qualified even though that might mean that in common parlance. It means that it has been qualified in this case, so qualified or disqualified. So it's sort of like tested versus validated. So the questions we're going to want to know are did we qualify them on whether they donate to the arts? Did we qualify on whether they donate to K-12 schools? And do they have money this year? And then we have this pivot point, which is what this shape denotes. And if they are permanently unqualified meaning don't bug them anymore and the lead is marked as lost, if they don't have either these charters, and that's noted in the detailed notes about this process, and any task to call them or email them are canceled so we don't annoy people. If they're temporarily unqualified which would be that they don't have money this year, then, there's a callback task created. That's step six here. And if they are qualified, then that's recorded and the lead is converted and then a qualified opportunity is created. And this is something that means this is something we should focus on as somebody we should actively discuss the possibility of donation with at the current time frame. And the idea here is not to get all the detail in this one thing. That's what these numbers are for. They reference a set of notes that you can see an example of if you look at the reference. This is a really good way to take what you've done with the canvas and really charter IT in a way that you know what outcomes you're trying to get, you can link it back to the rest of the stuff that's going on with the business, and and have a real specific discussion about why a given thing is or is not important, and then downstream, you can charter and prototype to make sure you don't build a bunch of stuff that nobody wants by starting from good thought-out process designs that have been validated and sort of tested with stakeholders.
