Hindsight 20/20: Procurement – How To Get What You Need

Hindsight 20/20: Procurement – How To Get What You Need

Presented By Josh Quintero

Josh:

Good morning, everyone, and thanks for spending some time with us today. Like was mentioned, my name is Josh Quintero, and I’m a senior consultant with Access Sciences. I’ve been with Access Sciences for about six years. For the last three and a half, I’ve been primarily focused on content management requirements gathering. So, a few months ago we decided to create this webinar series. We decided to title it Hindsight 20/20. We did this to help emphasize that many companies are often unsatisfied with their project result, and you have to look back on lessons learned. So, at Access Sciences, we wanted to share some of our lessons learned and best practices from all the projects that we’ve completed, helping companies improve their information management landscapes.

So, just a couple quick disclaimers here before we get going. Like everyone, I’m sure, on the call today, I’m talking to you guys from my office today. That being said, I live just a few miles down from an Air Force base south of Houston, and periodically we get a Top Gun style F-16 flyby, so if you hear a little bit of jet noise, I apologize for that, but they don’t listen to me when I ask for a no-fly zone. Also, one more thing is we might have some unregistered participants if the doorbell rings. Marley and Harvey and Yukon here generally don’t care about the noise they make whenever I’m on a conference call, so you might hear a bark or two, but that’s just them, I guess, cheering me on as we go. So, now that we’ve gotten all these silly kind of disclaimers out of the way, let’s go ahead and talk about what we’re here for.

The first thing we’re going to do is we’re going to discuss how we got here; what got us to this point. Then, we’re going to discuss how software is procured now, and the trouble areas that we’ve seen in projects. Then, we’re going to talk about the value of engaging the stakeholders, how to create some structure around the requirements gathering. We’re going to discuss how to define the approach to the procurement process itself. We’re going to discuss the creation of demo scripts that are specific to you and how you work, and then, of course, we’re going to talk about the objective evaluation of these systems.

So, like it was mentioned, this is a series of webinars, four-part series, this being the second one, and during the first one we assessed the organization, okay, but now what? What do we do with that information that we’ve garnered from that assessment? Well, if the assessment recommended that we needed a system to help with one issue or another, then we’re probably going to want to go out and purchase a piece of software, and that, of course, is what we’re talking about today. We’re going to be peeling off another layer of an onion, if you will, and dig a little bit deeper into the details of what the organization actually needs.

But before we get too far, I’d like to just pull up a quick poll and see what kind of issues you guys have encountered procuring software. So, hopefully you guys see that poll. Of the procurement that you have encountered, have the software demos been useless? Once it’s rolled out, have the systems not worked for all of your departments? Have you encountered that terrible low user adoption? Or have you not had any issues whatsoever? So, the way that software is procured isn’t anything that’s new or groundbreaking. The need is identified in one way or another, whether it be a department comes to you and says, “Hey, we need something,” or you get it from a consultant’s report. Then, you go out and you gather the requirements, you see some demo of software, and then you select the system, of course. But the majority of the blind spots that we’ve seen in support of these larger buckets…

There are, however, some best practices that we can help fill in to these gaps and make the procurement process a whole lot easier and far more likely to succeed. So, I’ve added these four tasks to the model here, and I’ve also renamed it as a stakeholder-centered procurement model. As we move through the presentation here, we’ll sort of see why I named it stakeholder-centered. When we’re looking back for lessons learned after you’ve completed a project, these four steps are going to be the most likely culprits of any sort of stumbling, or possibly failure. The basic steps are still there, but you’ll see the sort of impact that having these four things added are going to create in the project. But the first thing we need to figure out is pretty much how did we get here.

Like I mentioned before, at some point there was a need for new software identified, and since this is part of a series that we’ve put together, we’re going to go ahead and assume that it was from an assessment from the first webinar. We’ve assessed the organization, and out of that came some results. What are those results, and how do they influence why we’re going to buy software? Well, the gap analysis could notice some gaps in departmental processes or in existing systems that a large, overarching organization-wide content management system could help close. The common themes could have seen some, excuse me, some issues within departments that span multiple departments, and we need to close those as well. Excuse me a little bit for my clearing of my throat. I’ve got a little bit of a cough going on.

So, now that we’ve seen what sent us down this road, let’s go ahead and look at the procurement model again. We see the stakeholder engagement is, in fact, the first box here. That’s pretty much because it’s one of the most important things here. This is going to set the stage for how the stakeholders view the procurement and how actively they participate. You’re going to hear me say this multiple times, but this whole thing is about them. It’s not about forcing them to use a system, it’s about asking them what the system needs to do in order to make their life better. If it doesn’t do that, then you’re never going to get their support. Also, as we move through this, you’re going to notice that for each of the tasks on this model, we’re going to talk about the value, and also the risk you’ll encounter, and you’ll also hear a story or two from previous projects.

So, what sort of value are we going to get from engaging the stakeholders? What can we expect? Well, we’re going to be able to demonstrate the value of this effort. You have to tell people why they should come and meet with you for about an hour. What’s in it for them? They have to be shown its value in their daily job. Otherwise, they’re just not going to buy into it. After all, this is what this effort’s all about, it’s about them. It’s going to help prioritize the initiative. These people, like all of us, have many things to do, and this is just one more that they have to add in. So, hopefully, once you show them the value of this project, you’re going to be able to get a little bit of their day. So, you have to show them, again, what’s in it for them.

It’s going to help you ensure that you get the right people in the room. Simply put, without these right people, you’re just not going to get the information that you need, and you’re going to have a whole bunch of issues after that. It’s going to help drive active participation. This is probably the second most important value right behind ensuring that the right people come. Without this active participation, it’s going to be just a bunch of people sitting in a room staring at each other and not saying anything, and I don’t know how many out there have encountered this, but I can tell you it’s pretty much the worst thing and is very, very not productive. So, with the active participation, the meetings are pretty dynamic, and they can be really entertaining and fun. One person will hear something that another says, and that’ll spark their mind and lead them to mention something else that they might have forgotten otherwise. So, the conversation sort of bounces around the room back and forth on to different topics.

So, while this can wreak havoc on the person taking notes, it’s very productive and very worthwhile when it happens. By informing the stakeholders of the process early and engaging them throughout it, you can show them the value and really just gain their support. So, we’re going to look at this cat for just another second, because it makes me laugh. Okay. Moving on. One of the best ways we found to do this is to hold town hall style meetings. They’re short town hall style meetings where we present what the project is, what their role is, and then what they also should expect. There’s often a misconception about exactly what types of projects these are. The one thing that needs to be made perfectly clear is that it’s not an audit. I mean, out there to question their value to the organization. Their value is exactly why they’re being asked to come.

So, like at the end of any presentation, you’re going to ask for questions, and hopefully you get quite a few, because this will help not only educate the entire audience, but also help ease any anxiety they might have. So, as you can see, the value is pretty apparent, right? You can see why you need to do these things, but what really happens if you don’t? Well, you get the wrong people in the seats. If you don’t demonstrate why it’s important to have the subject matter experts, the people that know what’s going on there, you can often get people that are considered, air quotes, “less critical,” somebody that just has time, perhaps. This is a big issue because you won’t get what you need from the meeting, and that less critical person would have just wasted their time.

You’re going to have to deal with competing initiatives. As all of you are aware from looking at your own calendars every day, you have a lot of things to do, and every day it gets worse. So, these competing priorities can drive this requirements gathering to the very back burner. So, they have to know why it’s important for them to be there. What’s in it for them, yet again? You might have to do a lot of rework. This rework I’m talking about is from having the wrong people in the seats and having to deal with competing initiatives. Once you have that issue, you have to go back, you have to find out who the right people are, you have to contact them, wait for them to get back with you, check their calendars and yours to make sure that you can find a good time, and then hope they come and something else more important doesn’t pop up. All this can be avoided if you engage with them early and show them the value.

So, here’s the third part of the conversation here. I was on a project where, for several meetings, we didn’t have the right person in the room. We would speak to them, they would always say, “Well, you need to talk to Jane for that. You need to talk to Bill for this.” So, all the questions that we were asking them just didn’t get answers to. This caused the exact same kind of rework that I was just describing, and while it isn’t really a project killer, it does cost time, money, and can create the occasional headache for the person having to schedule all the meetings. So, how you avoid this is pretty dependent on your organization, its size, and its culture.

During one of our requirements projects, the records manager walked door to door, spoke to every manager she could, just to make sure that we had the right people in the room. Now, this wasn’t a large organization, so it could be done this way, but the point of that story is that she put forth an effort, and this effort should be put forth regardless of the size of your organization. I mean, you should do whatever it is that your organization responds best to. Maybe that’s email, maybe that’s something on the internet; whatever it is that they respond best to. So, once we’ve engaged these stakeholders, we need to go ahead and move to pretty much the meat of the conversation, or one of my favorite parts, which is the requirements gathering.

So, during some research I was doing for another project, I found a statistic that said over half of the software projects fail as a result of improperly gathered requirements. So, the importance of gathering requirements is often overlooked, but as we’ll see here, it’s essential to any software project’s success, and the approach that you take is more vital than you can possibly imagine. So, not seeing the value of a comprehensive requirements gathering can leave a project kind of dead in the water. So, what are these values here? Well, for one, we get a measuring stick. These requirements are going to serve as the bar at which you measure all the software that you’re going to look at. If a software doesn’t meet your requirements, then it’s something that you can just go ahead and push to the side and not have to spend any more time referred on, vetting.

You get a grocery list of functionality. One of my favorite stories here is the old saying about not going to the grocery store while you’re hungry, and it pretty much applies to software procurement as well. I mean, I don’t know how many of you have gone to the grocery store and ended up coming back with a couple boxes of cookies or a couple pints or gallons of ice cream, but when you do, was it even on the list? When you don’t have a grocery list you end up buying too much because everything looks really good, or really neat in the software world, and sometimes you don’t even get what you went to the store to buy to begin with. You’re going to get user buy-in. Whenever you get this user buy-in, it goes from an air quotes “just a system I use” to this is my system because I had a hand in what was selected.

Again, let me keep harping on this, but the value of having project champions in the departments is absolutely priceless. It’s something that you can’t pay people to do. Without requirements, you’re going to risk over-promising, which can be a huge issue if the user is told they’re going to get a piece of functionality, and then, at some point, they realize that they don’t, and that at some point, it’s usually during implementation, which is probably the worst time in the process that it could happen. This is going to make people very weary and lose sort of confidence over the software itself. You can risk over-buying. So, one of the reasons you want to be so careful with how these requirements are gathered is that nothing will lead you to over-buy as having too many requirements. Most of the systems have a whole lot of bells and a whole lot of whistles, especially the larger ones, and like any car, the bells and whistles are usually extra, and often go unused.

Another thing this does is it adds a lot of complexity to the implementation, which also increases the price of that. You risk under-buying. Without a comprehensive requirements list, some departments may be overlooked, and their requirements may not be gathered. So, what can happen is during the implementation, when you roll out to these groups, it’s noticed that now we need an extra module, or we need to get some custom coded solution after the initial purchase, and I’m sure that everybody’s aware that you always get a better deal whenever you bundle things together upfront instead of having to go back and buy things à la carte. You get the lack of user buy-in that a lot of you had. When the systems are selected for you rather than with your input, you’re going to get slow or possibly just no adoption whatsoever because it’s not theirs, right?

Not too long ago we were asked to perform a review of a pilot project for an AP automation tool. This was an accounts payable invoice processing tool. During that, it became pretty clear that the implementer hadn’t gathered the requirements thoroughly enough, and that the system had to be reconfigured multiple times in order for it to fit the user’s needs. So, this did two things. This pushed the timeline really far. I think it was around a year, and then it also increased the spend by half. Had these things been recognized in the requirements gathering phase, they would have gotten what they needed and not gotten a really bad taste in their mouth because of all the reconfiguration. While it may seem like a big step backwards to go back and get those requirements, it’s actually probably the quickest way forward, and probably cheaper as well, since you don’t have to worry about doing all this reconfiguration at the developer’s cost.

So, to ensure that we get the requirements correct, we look at some Requirements 101. When you’re gathering requirements, you’re more than just asking people what their requirements are for software. You’re not going into a meeting with a list of requirements and saying, “Okay, yes or no? Next one, yes or no?” This is just not a good way to do this. To keep this from happening, you’re going to have to engage with a lot of people from a lot of the organization. Take this org chart, for example. Optimally, we would talk to corporate, as well as the Scranton branch. It seems like a lot of people to talk to, perhaps, but you need to speak to enough people that you get a full representation of the enterprise or organization. If you only speak to a quarter or a half, that’s just not going to be enough. You’re just going to get a quarter or half of the requirements.

It’s not uncommon for us to speak to 200 or more people in larger organizations. While we were working at a government organization up in the northwest a couple years ago, we spoke to about 300 people during the requirements gathering phase. We first began speaking to their project team… They initially had 36 meetings because they had 36 departments. After we started doing a little bit of digging, a little bit of analysis, we realized that there was a whole lot of subgroups within these major departments, and so we ended up having 72 meetings to make sure that we had full coverage of their organization. This sort of helps to illustrate the types of things that you’re going to have to think about when setting these projects up. Another thing is that in order for you to make these meetings as efficient as possible so that you’re making the best use of everyone’s time, you need to have the right people there.

The right people are those that are going to be familiar with their group’s business processes. These are the ones that perform these processes daily. You need people that are intimately familiar with all the ins and outs and the whole process within their department. You need people that can explain who they collaborate with. We all work with people inside and outside our areas, and this person needs to be able to speak to how that occurs. They need to be able to describe what is working and what isn’t. This is an important aspect of this requirements gathering, that you don’t just focus on what isn’t working. It’s not just negative. You’re actually looking for things that don’t work. You want people to be excited to tell you, “Well, this works great.” So, you need to be able to do that as well.

By the end of these meetings, you need to understand what the users need. I mean, that’s the point of these meetings, right? The most efficient way we found to do this is just talk to people about what they do and how they do it. Through these conversations you’re able to glean the requirements from what they say. You’re not asking for their requirements, like I mentioned earlier, you’re getting them from how they do their job. Most people are going to give you a deer-in-the-headlights look if you ask them what their requirements were for software. I know a while back I would have. You talk to them about the documents they create, who they collaborate with inside and outside their organizations or departments, how they do that. What are the tools or systems they use? Like I mentioned before, you don’t concentrate just on what doesn’t work. You need to know what works well so that you can see what’s working and maybe replicate that in another area of your organization.

So, what you’re likely to find is that an issue that has been the bane of someone’s existence has often been solved by someone in another department. To illustrate this, during a project last year we spoke to a department that had a process for collaborating on documentation with an offsite facility using share drives. The next day we were talking to an HR representative from another group, and she had a similar process where she was collaborating with that offsite facility, but on HR documents, and she hadn’t had anything built around it. So, she was having to deal with emailing stuff back and forth, a lot of versions and that sort of thing, and having to find which one was the newest one. So, we told her what the other group had done, and she was just over the moon about it. It was going to make her life so much easier.

Even though that’s not what we were there to do, we were there to collect the requirements for a system, that sort of knowledge-sharing is what you get from not just focusing on what was wrong. She went back to the department and just sang our praises about how great it was that the project was doing, how helpful we were, and all that sort of thing. Again, that’s not something you can put a price on. So, you’ve gathered all the requirements, you’ve engaged the stakeholders, but what does the requirements document look like? The requirements document looks similar to this. It is obviously much longer than this one, but it’s similar to this. We try to mold the requirements to what makes the most sense for the organization that we’re working with, but usually they’re ordered by basic functionality like content management in this example.

So, this document includes both directly mentioned requirements, and then requirements that aren’t specifically mentioned, but they’re needed to support another one. If there’s a requirement that they have little sub-requirements in order to make things work, that’s sort of the things that we’re talking about here. Depending on the type and size of the organization, we usually gather about 150 to roughly 200 requirements. When we get much higher than that, we start having to determine what is really a requirement, and that’s just something that’s nice to have. Unfortunately, this involves a lot of internal discussion and requirements waiting, so what you’re going to find there is that people often have very different views of what actually is a requirement. It’s very, very personal and how they work.

So, there are going to be some pretty large decisions here that need to be made once that final requirements list is created. One of the big questions that you’re going to hear is any one system, can it fulfill all the requirements? This is another issue of having too many. If you have 600 requirements, is there any one system that’s going to fulfill them all? Probably not, and that’s what this waiting document comes in handy. It enables you to tabulate the decisions, and it causes the true requirements to sort of bubble up to the top. In order to keep the requirements list from getting out of hand, we don’t add requirements that are standard for all the systems. You wouldn’t want to add a requirement that the system be able to store PDF, Excel, and Word file types, because that’s basically what they were designed to do. That’s the core function of these systems. So, we don’t add these to the requirements listing, so it doesn’t muddy the water.

The requirements document helps you make an informed decision about what you’re going to purchase, regardless of the procurement route that you’re going to take. So, the reason that we spoke so much about the requirements is that they’re going to lay the groundwork for the entire project’s success, and when people are looking to buy something, we all have different styles about how we do it. We generally want to know what we need before we go out and get it, and a couple of these organizations are very much the same. While very often software is acquired through a formal RFP process, it’s not the only way that we see software be acquired. Before we talk about the rest of the process, just want to quickly highlight a few ways that we see organizations being introduced to this purchasing process.

We see organizations that, for one reason or another, have software suggested to them. We’ve had clients come to us and say, “We just got acquired,” or, “We have a sister organization that is suggesting that we use this piece of software, but we really don’t know if it fits our needs, so we need to what is going on here.” We’ve had organizations come to us and say that they have old software. They look at their software and say, “This software is 10 years old and it really doesn’t fit with what we do, but we are about three or four updates behind and we’d like to see if that one really will fit our needs if we get the update. Do we really want to spend that time and effort updating it if it’s not going to do us any good?”

Finally, you may have more of an informal RFP process. Someone may ask you to go get three vendors and have them give you bids. You may not want to go through an entire formal RFP process, even though that is a very valid and oftentimes used way, but you just may not have the time or want to put forth the effort that it takes to sort through 15, 20 responses, and then having to develop a short list of all those. So, the major key here that I wanted to share is that it’s not as important which one of those paths you take, since they all can lead you to success. The key at this point is that you know what you need. You’ve defined the requirements and you’re ready to move to these next steps. These next steps are what are going to lead you to succeed, regardless of this process, regardless of the process you’ve chosen.

So, the number one thing that this whole process is trying to do, level the playing field. Every step along the way here is performed in a manner to do exactly that. All the vendors build on the same scope of work. They are all asked to provide pricing in the same manner. They respond to the same set of requirements and the standard format. They use the same demo script that we’ll talk about in a second, and all the evaluations are scored in the same way. All this is so at the end, you have this apples-to-apples comparison, so this will make the lives of the people selecting the system a whole lot easier. As mentioned a second ago, we’re going to see how we can level the playing field even further with these creations of demo scripts that are specific to your organization.

So, as part of creating them, we need to cover as much of the organization as possible without unnecessarily burdening the software vendors. So, it’s a good idea to go ahead and select processes that are both common across the organization, and those that are specific to certain areas, but whose requirements will sort of test that software. It’s kind of hard to make specific examples here, since a lot of organizations have small systems that handle a lot of things like, say, processing invoices, that sort of thing. But you want to pick processes that everyone can relate to. Maybe it’s an approval process that… Everybody can relate to needing something approved. The scripts have to be written in a system agnostic manner. Basically all that means is that they aren’t system-specific. Any vendor can come, look at the script, and then use their system to create their demo.

So, before we talk about the script itself, let’s see what kind of answers we get to this question: how valuable have you found demos to be? Did you see what you needed to see? Were they very valuable, maybe somewhat valuable, they didn’t quite show you everything? Were they not valuable at all? They didn’t show you at all what you needed? Or have you not seen any? So, software vendors spend a lot of time and a lot of effort creating their standard demos. These are extremely practiced, and they highlight the strengths and kind of minimize the weaknesses of the software; not in a malicious manner, but just in a way that makes everything look great. And there’s a time and a place for that, a place like conferences, events, or even webinars like this one.

But the time and place is not whenever you’re trying to see if that software demo or if that software is going to work specifically for you, and that’s sort of probably why they weren’t valuable at all. They didn’t show you how you worked. So, having this well-written demo script sort of takes them out of that little demo and makes them show you how the system really operates. So, the values that you’re going to get from creating these demo scripts that are specific to you, we got to get demo scripts that are written with user input. You’re going to get demos that show you how you work, and we’re going to level the playing field between the vendors. So, for the next couple slides here we’re going to talk about each one of those in a little bit more detail.

Demo scripts aren’t created in a vacuum. They’re a large, collaborative effort between the person creating them and the users. So, during the requirements gathering you’re going to uncover some processes during that, and you’re going to document them at a high level, and using these as a base, you can kind of create the demonstration that I mentioned a little bit ago that targeted both enterprise-wide and specific department requirements. These scripts are then sent to the users. They’re adjusted with their user input, and then sent back to them for approval. So, you can see again how we’re sort of weaving the users’ input through this entire thing, and because of this collaboration, we’re going to see demos that show you exactly how you work. Not all organizations perform the same type of work in the same manner, so it’s important to see exactly how you work in the demo.

Is it going to make your life easier? Is it going to create unknown problems that you’re going to have to deal with? If it creates new problems, then you really want to find that out in the beginning and not after you spent a whole lot of money purchasing a piece of software. So, like I discussed earlier with leveling the playing field, the standard demos that the vendors are going to give are going to be very likely to be quite different. Each software usually has some sort of niche that it lives in and that it performs best in, so of course, the software vendors are going to show you that. Software A, a vendor may demonstrate how it handles AP invoices. The software vendor B may show you how it processes engineering documents. Clearly, you can’t compare these, because they’re not apples-to-apples, and it’s one of the exact reasons that the playing field needs to be leveled.

All the vendors need to be playing the same game and not wildly different ones. You can’t tell if a person is good at baseball by watching them play football. I mean, it’s just not an easy thing to do, and this is basically what would be happening if you were trying to figure out if a demo for AP would work on how you process your engineering documents. So, by creating these demo scripts, you’re going to help mitigate the misrepresentation of software capabilities. There might be some behind-the-scenes magic from a straighter demo, but really doesn’t represent what the software can do. While we were working at a client in the Midwest not too long ago on, I believe, a separate project, the client that we were working with saw a demo of an ACM system. The vendor didn’t own an integration that was supposed to be seamless between what the users were currently using and this new system that they were demoing.

So, this got the users really excited, as it should, because it wouldn’t have to change any of the processes whatsoever. They would just keep working as they were. But after the software was purchased and after it started to roll out, this turned out to not be the case, and so the integration didn’t work after all, and it became this huge roadblock to user adoption. You might hear, “This can’t help me,” from users. If you don’t see how you work, then you might as well be watching someone do taxes. I mean, it’s not going to help you in your daily work, unless, of course, you do taxes for a living. So, last year we were brought in to gather requirements for a client and found out during this that their legal department had seen a demo of some software.

Unfortunately, the demo wasn’t tailored to them, and so as soon as they were done watching it, they checked it off the list of vendors that they were going to go any further with. I mean, they decided that they weren’t interested in it at all. I mean, this was from specifically not having a tailored demo. From our experience working with that software, we know that it’s capable in doing what they need, they just didn’t see it, because the straighter demo was given. You might buy software that’s incredibly difficult to configure. You’re going to have to support this software, and if it’s hard to configure and you need the vendor’s help to do it, I mean, that just doesn’t make sense. One of the things that having a custom demo does is it allows your IT folks to request that they see a demo of how the demo was created. They can see how things were done and if it was incredibly difficult for them to do things. You want to be able to support this and not be tied to this vendor every time you need to make some sort of change to the configuration.

As part of the procurement model here, I have system demonstration, but obviously you’re not going to be given that demo to yourself, so we’re going to see how we’re going to objectively evaluate that. In order to have a transparent self-evaluation, you need to make sure that the system selection is done as objectively as possible. We all know that people have a hard time being objective, but we would try to limit this to just the usability and the configuration options, how things look, how things feel whenever you’re using it sort of thing. So, how do we do this? By creating some structure around it. If you don’t create structure around it, you get a beach day like Pam here, and having to try to calculate what these people feel score, and that’s pretty much impossible. So, by creating a form that gives you a way to score the software, you’re able to be as objective as possible.

Each line item on that script is demonstrable, and so you can put a score to it as a result. While you’re watching the demo, as you’re going down the list you can ask yourself, does this software fully meet the requirement, is it only partially, or is it not met at all? And then you put those scores to them using a predetermined list of scores. Then, following that, the scores are tallied, and then those are added to the overall scoring process. So, doing the scoring in this manner, like I mentioned, allows the process to be transparent and defensible. The demo is not how you choose software, but it’s an important aspect of the selection. It’s like purchasing a car. You can do all the research you want, you can see how much it is, all the bells and whistles and what have you, but you got to get in and see how it works, and that’s pretty much what the demo helps you do.

All right. So, now we’ve reached the part that everybody wants to see. You’ve selected the system. You’re as excited as these kids are, and all the due diligence has been completed, the demo evaluations have been tabulated. You can now make an informed decision about this software and know for a fact that it’s going to meet your requirements. So, what’s all this been based on? The users have told you what their requirements were. The users confirmed that you modeled their work processes correctly. So, if you’ve done everything right, all it’ll appear is that you’ve kept score. Even though there’s been a whole lot of work done, you’re keeping score along the way and involving the users in everything. So, old Al sums it up pretty nicely here. It may not be rocket science, but that doesn’t mean that it’s something that takes zero effort or expertise. It’s a pretty common sense, but common sense isn’t all that common is a saying that’s used quite often.

In an EMC market we see this process not occurring more often than we see it actually occurring, and it’s one of the reasons that software projects fail. If we go back through this list that we’ve kind of made and Albert’s going through, I mean, what’s the common thread? That common thread is the users. If you go back to where we were at the beginning, you can see why I changed the title of the procurement model to stakeholder-centered procurement model. This is what it’s all about, involving the users. Everything in that list is about the users and how you use what they know to get the right information while bringing them along through the entire process. You engage with the stakeholders early and often, having these conversations about what people do and how they work, making the vendors show you their system in your work, and evaluating the software. All extremely vital parts, and also deeply involve the users.

This webinar was about procurement and not about change management, but you can sort of see how important it is that you put change management in all these projects, and luckily for everyone here, the fourth webinar is going to go into more detail on how to manage those changes during these kind of projects. So, in this webinar I’ve shared a few things that we understand lead to success, and why projects struggle, and the foresight needed for success often comes from hindsight being 20/20. So, let’s make sure that we all join Ashley Schilling for the next webinar, as it’s very closely tied to this one, since requirements feed directly into implementation. If you’re interested in learning more about these types of projects or other things that we do, please check out our website. We have a lot of good case studies out there to read. I’m not saying that because I wrote some of them, but they are pretty good to give a read to.