We've done a lot of talking about system moves and needs and all that. At some point, somebody has to put this stuff together, somebody has to address whether you build the thing or do you buy it? Do you build the bespoke system that's like this multifunction knife, or do you get off the shelf, a knife that does the job but doesn't do everything that you need to do? Can you afford to build a bespoke system? On the other hand, can you afford to use the simpler knife? Now, in our leading change course, we'll go through a lot of software development building and buying in more detail. In this section, I really just want to introduce you to basic concept of software development. So, you heard that language. So, I hinted that when you buy the off-the-shelf tool you may be stuck putting their square peg into the realm holes of your environment, can you afford that? I don't mean just money wise but can you the disruption to the work flow? That means the different data, that means different knowledge that that entails. So, if you're going to buy, here's a really short bullet list of things that you should be aware of, you're going to put together or request for proposal (RFP). In that RFP you will have to use cases that you want them to demonstrate that they can meet. Just remember though, the needs requirements and specification. The use case is kind of at the level of specification, right. The system shall be able to run this use case. So, you have to know a lot internally before you articulate the use case. They come back and tell you that the system could accomplish what you ask them to do. It's unacceptable you want to see that it has and you want to see people, your peer institutions where it has worked. Obviously you want to avoid sales people, you want to talk to either the clinicians or the IT people, sales people are not there to help the workflow by and large. You may be lucky and have a really good sales on account executive but sometimes pretty often they don't. The last thing is to remember that you're not buying a computer program, you are buying your relationship. So, working with the higher folks up. So, even a vendor relationship is a stack sort of a thing. The organizations have to communicate, there has to be a cultural sharing. They have to have some sort of a common workflow, speak the same language, share the same data. It's kind of an interesting way of thinking about it. Software development. Well, first you have to know where are you. I argued that the stack is not a bad way to articulate where you are. It also is not a bad way or articling where you want to be, even if you're not able to articulate what the picture is. But it's going to look like you certainly can say that," I'm currently printing too slowly I need to print faster. I'm printing in black and white, I need to print in color. I'm currently printing manually, I need to be printing electronically." You may not know what a Laser Jet printer looks like before you start the process, you may not know that those technologies exist, but you certainly can articulate what you need to develop. Whether you're building or buying there's always this issue with the vendor. This is a cartoon that goes back to probably to the 1950s to a very famous project management cartoon one way or the other. The left-hand side, the upper left-hand is what the user said they wanted. The lower right-hand side is what they needed. You had the difference between, remember the difficulty or is it in eliciting what they really need and if you really understood what they need you can build them the thing that they truly need, but then in between you see all the different failures of this relationship. So, the project leader didn't understand that swinging means you can't hit the tree and the programmer kind of got the notion that the rope has to be on the branches kind of backwards. The project wasn't documented but it was described in flowing colors. I can hear the angels singing just looking at that armchair. I like the way it's was caught, it's crusted and build and then supported. So, you want to avoid everything in the middle. You want to get to that swinging tire. Good luck. Now that's the overall process. There is this notion of development that there's a general flow from what we've been talking about, needs and requirements to the specification then to the design, the implementation and deployment. Implementations is what they build, but deployment is when it gets put into place and you can see that there's testing very frequently. The testing is whether the thing is working the way it was designed to work. Remember, evaluation is whether it accomplishes the goal that you bought it for in the first place. You can't evaluate, the vendor cannot evaluate in their shop but they can test in their shop. The traditional way of software development followed that sequence rigidly going from requirements to design to coding and implementation to integration plays to acceptance and to release and payments, right? The waterfall model is really nice for project managers and for people who are paying because you can say, "Okay, first phases is requirements, you done with it when you submit the requirements document and we accept it, we pay you. Then you go onto design, you give me the design document and we pay you" etcetera. The problem is that these days, if by the time you get to release, its two years later, the technology is changed the problem is changed and this waterfall has failed you. So, a lot of people talk about Agile and a lot of people sell that, "Ooh, we do Agile. They are for users". So, here's some of the components of Agile and the main thing here is that, this whole process is continuous. So, you actually go through the waterfall but you will go through the whole thing many many times. Remember we talked about using the prototype as a way of eliciting what the need really was. So, imagine if you built that bad swing early on then the user could say," No, I remember seeing a tire somewhere. Yes, that's what I want, I didn't want a tire. You build it everybody's much happier". But it's also harder to write the contract for this because the specs are changing when you stop, when the scope no longer creepy. Managing these processes, this COBIT, as a whole family of sulfur management best practices, they and others talking about maturity models. Their maturity models and all different sorts. Remember you may recall with the hymns we had the system one to system seven, there was a maturity model inside too. This is the maturity model of the software development process with sulfur management process. The main point they want to make is if you look carefully, you'll see the stack. At the top you have business goals: What you want to accomplish. There the IT goals that support that. Then the activities of the workflow of the people developing the software and finally the measurement and evaluation of what's going on. So, the governance model shows that this control of the whole process and now those Agile steps have been chopped up into three large domains. How they operate that's your systems issue, and notice on the right-hand side you have monitoring in each level. Monitoring is kind of checking in real-time whether things are going okay and evaluating is assessing is, "Okay have we accomplished our goals? I've been saying everything in the context of building a kind of system inside an organization, the WHO has put out these maps tool for dealing with mHealth for scale which is the important part. Once they've demonstrated that it works, how do I go beyond the lab or this clinic or this hospital? They map that software development process out for you as well. So, bottom line, neither building or buying is a hobbyist activity that governance that we've talked about, attains whether you're building or buying. So, you need governance at the enterprise level. It's not something that you give the hobbyists or the enthusiast to be in charge of or if they're going to be in charge with, they have to include a broad range of stakeholders within the organization or as we saw with maps beyond the organization but always you got to be skeptical. Plus you saw how everybody can get things wrong. People want to make money out of this process. You have to be afraid and if I had a picture here I guess it would be the picture of the fly from that movie where the human being is turning into slides human fly. His friend tells their other friends, " Be afraid, be very afraid"