Keeping the Fusion in Fusion Lifecycle: How to Deliver a Successful Project

KATELYN WILSON: Good afternoon. Welcome to Keeping the Fusion and Fusion Lifecycle: How to Deliver a Successful Fusion lifecycle implementation. I'm Katelyn Wilson. I'm an industrial engineer PLM specialist with Advanced Solutions, an Autodesk partner. And I am certified by Autodesk to implement and support Fusion Lifecycle. So I work with companies of all sizes, whether they're really small to something really large to help them implement Fusion Lifecycle as well as support them once they finish. Today I have Andree Cordts with me from Oxygen Development.

ANDREE CORDTS: Hi my name is Andree Cordts. I am a project manager. I have been working in project management and process improvement for roughly about 10 years. I'm from Quebec, Canada, and I'm the director of new product introduction for a company called Oxygen Development. So for you that are not familiar with Oxygen Development, no we don't make anything that has anything to do with oxygen. Some of you may have one project, some of our product, not a lot. But we are a cosmetic manufacturer. So we develop cosmetics, manufacture them, and then work with our customers in developing packaging, and then support them throughout the entire launch and ongoing lifecycle of the product.

So we have factories in Florida, Germany, Milan, where we have an . Innovation facility we have a site in Dominican Republic and recently we acquired a new site in South Korea. We decided a year and a half ago the company brought me in to actually look at their new product introduction processes. And after redesigning the processes, we decided to go through a reimplementation. So today we're going to talk to you about how that reimplementation of the PLM Fusion Lifecycle system went.

KATELYN WILSON: So in case you are not aware of what Fusion Lifecycle is, Fusion Lifecycle is a cloud based product lifecycle management tool, or PLM, by Autodesk. It's designed to help businesses manage their product's lifecycle, their processes, whether that's change management, quality management, as well as bringing people together more effectively than any other tool and this can even include 3rd party people such as vendors and suppliers and customers. Fusion Lifecycle also improves the way that companies creates, build, and manage their products as well as their service. Fusion Lifecycle enables process improvement, or else why would you even go about getting Fusion Lifecycle? So it does so by eliminating bottlenecks. It provides you with a single source of truth for your data, and with that it provides you with a standardized searchable structure of your data.

I mentioned that it can help connect you with your vendors or suppliers so you can bring them directly into your Fusion Lifecycle processes, as well as helping you better manage things like change processes, quality management supply chain, or any other process you can think of for Fusion Lifecycle. Some reasons why you might choose Fusion Lifecycle, it's a cloud based system, which is really great. So you can connect anywhere at any time. So last night when I was flying here, I could have been approving a change order. If I was home sick with my kids or my dogs, I could help move a product along in the NPI process. You also get to partner with Autodesk.

So a really big benefit of that is you get the resources and the know how that Autodesk has, and that helps your business improve as well partnering you with other partners such as us with Advanced Solutions to facilitate any other process. Additionally, Fusion Lifecycle is designed to grow with your business, which is really nice because you can start off really small with something like a quickstart implementation where you just put items and build materials in change management. If you're a small company and then as you grow you can add other things like your quality management or the supply chain. If you decide you want to include task management, you could start adding that along the way. So it kind of just take a little bite at a time.

This is just a visual to show you how Fusion Lifecycle can help improve your processes by taking what you have, your employers, your vendors, your overhead, put that in with your processes, and then you get improved results. Some of these can be things like Time-to-Market improvements. We can evaluate your cost to risk for cash flow as well as increasing your overall productivity. Andree will touch on these when she discusses how Fusion Lifecycle helps benefit auction Oxygen Development. So a big question, and I hit on it a little bit, is what processes can you manage with Fusion Lifecycle. So out-of-the-box we have a list of things like quality management, which can be things like corrective action, preventative action, returns. We have change management, so whether that's a change request, a change order, problem report, deviations.

Supplier vendor management. So if you wanted to have your suppliers in Fusion Lifecycle handle audits against them, supplier corrective action requests are also available. Document management, items and material managements, new product introductions/development. And you can even make your own processes. So if you wanted to include a product testing or a training management we could. If you wanted to do a custom task management or project workspace, all that's usable with Fusion Lifecycle. So Andree, obviously you're here today because you guys needed a PLM system. So why did Oxygen Development need a PLM system?

ANDREE CORDTS: So as a cosmetic manufacturer, there is a level of complexity that goes into what we develop. So being a cosmetic manufacturer, we develop a lot of colors cosmetics, which means that for every project that we do, we may develop from one formula to 50 formula per project. And then there's the aspect of the packaging. So when we develop formulas, we develop the formula with the packaging. So there is it may look like nothing, but it actually has we have to consider everything from the primary packaging to the labels and all of these things all the way through our bill of materials to be able to provide what our production floor documentation that can help them manufacture the project the product in a way that's good to ship to our customers.

So with that complexity, it also involved a lot of different departments. So our R&D department will develop the formula. Our engineering will look at feasibility study and all of these things. So that complexity, when you're a small company who manages five, ten project, it works when you're doing it manually. But as you were growing and your business is increasing, it becomes unsustainable to try to manage that manually. And for us now managing about 400 to 500 project per location, it was unmanageable to do it without a system to support us. So that's the reason why we chose Fusion.

KATELYN WILSON: OK so you need a PLM system, which we established, and with all of the PLM systems that are out on the market currently, why did you end up saying let's do Fusion Lifecycle?

ANDREE CORDTS: Well, the interesting thing about us is when I joined the company, I mentioned earlier I joined a year and a half ago to do a process improvement, I wasn't familiar with Fusion Lifecycle. So when I came in and we redesigned the processes, all I had seen is the system we had in place. And when we redid the processes, the system was no longer aligned. It was originally designed in a very siloed departmental way and we were looking for a process that was more collaborative within the or the different phase of the project. So when I came in I wasn't sold on Fusion because I only knew what we had. So we looked at the Oracle Project, we looked at Microsoft Project, and then we ended up going to Accelerate in Boston.

There, there was a lot of different companies that showed us what they were doing with Fusion and that's where we actually really realized that Fusion is very customizable. And that's the reason why we decided to go with it because it was so flexible. We could get it to make it what we wanted. And it was matching the process that we had recently redesigned, and it was also giving us the flexibility of having a hybrid system. We wanted something that was doing project management and PLM, so product lifecycle. So that's the reason why we ended up sticking with it.

KATELYN WILSON: So they stuck with it, we did an implementation that wrapped up back in the early part of the year. So now that you guys have been using Fusion Lifecycle for several months, how has it benefited Oxygen Developments.

ANDREE CORDTS: So it really helped us by having a centralized system. It's giving us a lot of transparency within the organization. They actually look at exactly where our projects are within the entire phase of the launch. So we're able to actually really measure the workload of each department at any given time. So the transparency was really a big, big, big benefit for us. And by being able to use the system to measure, we were able to actually do a lot of process improvement as well.

So what the system gave us is that it helped us save time and it helped us save money by doing a lot more work that has value added as opposed to wasting time searching for information with scattered places, we had a centralized system. It helped us with having less mistakes because a lot of people were making this assumption when we were doing it with a lot of information within the system and outside the system. We spent a lot less time in meetings. So if you're a meeting marathoner, this is not going to help you because the system is actually really there to improve processes so we had a lot less meeting.

From a data entry and data management, it's very easy to actually navigate through the system and enter data and data throughout the system and the reporting is great. Having the ability to report from one system was really key for us. So being a process improvement person, I am big on numbers. So my office has a saying on it that says without data you're just another person with an opinion. So here I wanted to share with you some of the improvement that we saw at Oxygen.

So some of the thing that we saw was an 81% increase in the turnaround time of our finance department. We saw an 11% reduction in the data entry lead time. We eliminated our weekly status meeting, which was four hours. And then by being able to measure our KPI centrally we were able to do our process improvement very geared towards the area where we were struggling.

So if certain things were taking too long then we were really able to target why. What are they are the RCAs of why we're late on our project? And you can see in the graph over here, when we did the initial implementation seven months ago our average KPIs was roughly about 51% for new product introduction and we are now at 85%. So it really shows where we were able to target our improvement.

So by show of hands, how many people here are actually planning a new implementation or are looking to maybe introduce Fusion? Great, that's very exciting because Katelyn and I are going to actually show you how we work together to achieving success with the project.

KATELYN WILSON: So the key learning objectives we're going to have for today's course are going to be once you leave the room you'll understand the best practices involved for a successful Fusion Lifecycle implementation, understanding what data to gather and how it relates to PLM. Knowing who should be involved in the process and when, should I have someone involved in the discovery phase versus the implementation? Should it be both? And then lastly, if you take nothing else from the class m at least take the very last goal of learning how to visualize the end goal and the importance of defining success before you start your implementation.

So I'm going to walk you through the phases of a Fusion Lifecycle implementation. We're going to start with the discovery phase, move onto mobilization, and then following that, we'll have implementation, user acceptance testing, training, and then we'll end up with post completion support. So what is the discovery? A discovery is typically, depending on the scale of your project, can be a one day on site visit where we dive into your processes, determine what it is you want to manage in Fusion Lifecycle. If you have a smaller scale project, perhaps we're just doing items and building materials and change management. This might be something that we just do via a web meeting like go to meeting.

In the discovery, we're just determining the processes you want to manage in Fusion Lifecycle, trying to get out any feasibility issues that we may run into. We'll determine the data requirements within the system. So do you want to have items and building materials, and if so, what does the data look like for an item? We'll map out your workflows. So we'll actually typically go to a white board and start drawing out your work perhaps for your change order process, noting who's involved and when, what happens if you reject, what happens if something isn't going out at this point process. And then we'll understand the functional groups involved in your processes, which is something really important that I'm going to get to at the end by trying to expand that group to include multiple instead of just one or two.

And the end result of our discovery is to provide an accurate budgetary estimate to the clients and that we feel confident about. So this is going to say for your implementation we expect it to take X amount of resource hours, so that's what we bill you for. And then at the end of that, here's how long we expect it to take. So we expect it to be 40 hours and it will take 12 weeks, for instance. Prior to the discovery, there is some prep work that goes into place just to make sure we're really not wasting anyone's time.

So we'll have some pre-sales meetings to determine if Fusion Lifecycle is the best solution for you. If we determine early on it's not the best solution then we're not going to go forward because we don't want to waste your time and we'd rather you find a solution that's going to benefit you the most. If we do determine that Fusion Lifecycle is going to be a good fit for your company, we'll then move on to gathering the subject matter experts that we need. So if you have a heavy bulk implementation that needs to take place, or perhaps there's a manufacturing or AEC subject matter expert who should get involved for our team so that we understand everything we need to know as the PLM consultant, then we're going to do that.

So under what prep did you guys do with your gap analysis and with your process reviews to have the preparation that you guys did have for your discovery phase?

ANDREE CORDTS: So there's five things that is important when you actually prepare for your discovery and one of them I want to touch on even though for us it wasn't a big part of our project, and that was sponsor support. Because the company had already made the decision to improve their process, they were already really, really sold on the fact that we wanted to get something new to actually improve. But it's important if you do not have sponsor support to actually get somebody that's actually is really invested in the success of what you're trying to achieve. That's also important when you actually select the project team that are going to work with you in preparing that project.

So when we selected our project team, we wanted to make sure that we were selecting people that knew what the goal was, what are we trying to achieve? But also people that actually understood the processes. They understood the process, they understood the business, and they understood the goal. And we also wanted people that were decision maker in their department because we wanted to make sure that we were able to make decision on the fly if we were going to put something in or change something within the support system where the Fusion Lifecycle. So that was very important for us.

The other thing, the main thing that we did prior to discovery was really mapping what we wanted the system to look like. So that's going to be important for you guys to actually map what you want the system to look like and take into consideration gap analysis. So we look at what we had before, we looked at what we wanted, and then we looked at what that meant as far as things that we needed to add. But keep in mind when you're mapping your process, and that comes from a process improvement person, not to map exception. That was part of the failures that we've had in the past where people are trying to map every possible avenue that could happen with a project. You don't want to do that you want to map the most common avenue and the exception should be handled as exception.

But basically what you're trying to do by doing all of this is define your end goal. What do you want the system to look like? What do you want it to achieve? If you don't have an end goal, it's difficult to understand when you're done did you reach anything? So it's really important to know what you're looking for and be clear about what you're looking for especially when you talk to your partner.

KATELYN WILSON: So the one big benefit as an implementer of knowing what your end goal is and knowing what your success is is when I actually determine what I want to implement for you, how should I help you design your processes. I'm going to keep that in mind. So if I'm working on something and we decide that we want to go down some routes and I start looking at it and I think, how does this even relate to the end goal? Andree can look at it the client perspective and say you know this doesn't relate to it. I have no idea how it got in here, we need to remove it. It's not going to help us get to success.

I mean it really helps us that when we get to the end of our implementation, we can look back and say did we hit every goal that we needed to hit, and if not what do we need to do to get there? Otherwise like Andree said you get to the end you're just kind of like, well now what do I do? We spent all this time, you don't even know if you did something that's worthwhile.

So some final notes just to recap on discovery, again it's typically the actual discovery part is around a one day event. It can be less, it can be on site for online. The entire discovery process does span over a couple of weeks. Like I said there are some pre-sales meetings to determine if it's worthwhile and then there's some follow up questions to answer anything that may not have been finalized for the budget estimates. We'll look at your individual processes, map out the workflows, determine the data requirements.

And a really big thing that I learned last year when I was speaking with one of my clients was not worrying about what you don't know. So what I mean by that is myself I know nothing about make up. I know that Andree about lipstick but today that's pretty much about all that I know. But it doesn't matter because I know what processes are and I know how to manage them in Fusion Lifecycle. And same thing for Andree. She didn't have to know about Fusion Lifecycle because I have that part down. So as long as she can answer my questions about their processes, I can answer her questions about Fusion Lifecycle and it all come together and you don't stress about the little things.

And then lastly keep it as a definition of success in the foreground. Always make sure that you're focusing on that. When you're deciding if you want to do something or not, go back to does that help me reach success or not? So once you finish discovery, assuming you sign and say I want to move forward and actually implement Fusion Lifecycle, we hit a mobilization phase. The mobilization is an on site meeting where typically it's about two days, a day and a half to two days, where we really hone into your processes.

And this is where we do some deep dive. And deep dive I mean we're figuring out what kind of data fields you want to include. Do you need a notes field, and if you do is it a paragraph, how many characters do you want allow a user to fill in, when is it required to be filled in? We are going that deep into your data. We're also determining what existing applications you have. So for Andree it was we already have Fusion Lifecycle and determining where its strong points are, where are the weak points, what can we do to help make Fusion Lifecycle better. We'll also map your workflow out workflows out in further detail. So again getting up to the whiteboard, writing things down, getting rid of redundant steps.

We'll determine your data that you're going to put into the system. And as a result of all of this and developing a weekly communication plan, we're going to get a project plan. And our project plan is going to be our detailed roadmap for the entire implementation. If it's not in the project plan, odds are it's not getting done and it wasn't a priority. If something isn't in there and you need it, then that's something that we have to refocus on. Just edit the project plan and then move forward.

Our project plan is a very detailed plan for your work spaces. So what scripting is going to take place, which processes we're including, what the work flows looked like, again, every single data field we'll look at your training. So if you're going to have admin training, is it custom or is it standard? If we have end user training, are we breaking that up into different groups like factory workers versus office? And then we'll also map out the data migration. So are you going to import items and building materials? Are we importing attachments? If so, what are the quantities behind all of these things and at what point are we going to implement them, will there be a validation of the data, et cetera?

Again I guess everybody uses project plan throughout the entire implementation. There'll be a schedule that goes along with it. And this really ensures that we're going to stay on track, on budget, and on time with your project. So Oxygen Development was very prepared for their mobilization, one of the most prepared clients I've ever had. So I'm going to let her give you some tips and tricks of what they did so that they could have a successful mobilization.

ANDREE CORDTS: So again, the first thing that we did is prepare. So one thing that was good is that a year ago I sat where you sat before mobilization. So I knew she had given me some tips of what to prepare for the entire process. So we went back to our office and then we went ahead and started mapping in very, very detail in a detailed way of how we're going to do this system. So workflow, works states, and who's going to do certain steps, what information, what's mandatory by certain phase that needs the information needs to be gathered. So we spent a lot of time mapping exactly what we want so we worked with the project team and trying to better understand what their pain point was, what they wanted.

But one thing that I need to address here is also make sure that your project manager is a strong and strong enough to say no, because we did a lot of vetting of the requirements when we actually prepared for mobilization. Because want it or not, you're going to get people in within the company that want to add everything in the system. And the system is here to support you. It's not here to replace everything. So you have to find a way to be able to say no to certain requirements. And the way we did that is we were asking everyone two questions.

First, is it going to be reported on? It's not going to be reported on, then maybe it's not needed. And then the next question we're asking is it information that's useful? So if the information is reported on or it's information that's actually useful, then go ahead and put it. But we had to cut a lot of different information to actually try to keep the system a little bit simpler because we knew that from previous implementation where we were trying to do too much.

So the other thing that we walked away from AU last year with is reporting and how well the system is designed to report, and we had not considered that previously. So things to prepare for when you're actually preparing for your mobilization is look at the information that you want to report on. For us in cosmetics, we actually cared about a few things we wanted market information. So is all the project that we're getting right now lipstick? Or is it lip gloss? Like what's the information about the project that we're getting so that we can target maybe on trying to get the business that we're not getting as many projects on.

We also wanted to know information about what business we're getting versus what business we're not getting. So our leads are going into the system. So when the lead is cancelled, why is it cancelled? Are we too expensive? What is the reason why we're losing business? So the system helped us with reporting on that. And then again the KPI as I mentioned trying to understand what we're trying to measure and making sure that the fields are there within the right workspace are within the right location to be able to measure what you're trying to measure.

And then the last thing we did is making sure that our subject matter expert were going to be present and available during the visit of Katelyn and our team.

KATELYN WILSON: So once we finish mobilization with Oxygen Developments down in Florida, we moved on our implementation phase of our project. So our implementation phase comes with a schedule as part of a project plan. And in this project schedule we really just outlined week for week what we're working on. So at the beginning we did our mobilization followed by us at ASI writing the project plan.

We then moved to what we'd be working on. So I have group one developments, and that would be an ASI pass. And then below that I have Oxygen Development review group two. So this was a really beneficial way for me to know that I'm staying on track to know what I should be finishing each week, as well as Andree knows who she needs to have available on her team. So we were working on group one work spaces on the first week of January, then she would need to have those team members readily available to answer questions.

And then the following week if they were going to be reviewing those work spaces and making sure they like them, they still need to be available. So the responsibility matrix in the schedule really makes sure that we're all being held accountable and we're all paired for what we need to be doing. During the implementation, it's pretty obvious that your implementer is going to be doing things. If they're not, don't use them. Your implementers are going to be developing your Fusion Lifecycle based on your project plan. So they're going to be going down and knocking things off that list exactly as they're documented.

They're also going to develop a ticketing system. The ticketing system is something like a user acceptance testing or a bug and issue log. And this is just used to keep track of changes that you want from Fusion Lifecycle. A little added bonus to it is you get to get people involved in using the system early on because they are getting used to functions. And it's also a work space that you can continue using throughout the entire time that you're using Fusion Lifecycle.

We'll also be managing our weekly meetings but we'll provide you with status updates. These are things like perhaps we have questions on a specific workspace, maybe we are expecting that we might hit a roadblock so we're going to bring it up now so we can be proactive and avoid it. And then we'll also handle other project management tasks like making sure we're not using too many hours, updating you on our progress, and then any other project management tasks that we have on our end.

And then you as a client do you have other things that you have to be doing during this time. Some things are obvious, some things might be hidden. So Andree will tell you about what they did during the implementation phase.

ANDREE CORDTS: Well as Katelyn mentioned, there was weekly calls. So we attended the weekly call, we made sure that we managed the project from our site as well. And then most of our involvement was definitely in user acceptance testing. So in order to do that, we spent a lot of time doing our test case study. So we did the test case study than we did user acceptance testing and utilize the system that was developed by Katelyn to issue our ticket.

So if something was not working properly, we'd issue a ticket, it would get fixed, and then we'd continue going on the implementation.

KATELYN WILSON: So we've been talking about user acceptance testing a couple of times now. So a recap of what it is, it's just a way to log issues that you're running into with the implementation. So I developed a workspace and perhaps I forgot to include a field to be validated. And you realize it and you let me know hey we need to validate that. Or perhaps we built the field out to be 100 characters and after you go through some of your test data or projects or old building materials, you notice that 100 characters isn't enough. So that would be something that you would log and then I would change it in the implementer.

Andree went through a little bit of what they prepared for and how they prepared by coming up with their test use cases, really making sure they had several develops that they could go through and test all sorts of possibilities for a project. As the implementer, what I gain from this is I know things that aren't working properly. So obviously if a field isn't long enough characters I need to fix it. I know the acceptance of your users. So it's kind of in the name user acceptance testing, but this really determines are your users liking the system? Are they going to use it? Is it developed OK?

So there's a really big risk of not doing it and that is that we developed a system that's not user friendly and we don't know it because we didn't test it with your users, and they decide they don't want to use it, you don't adopt it, and you wasted all the time, money, and effort developing a system that people don't want to use. So it's a really big risk in not doing it. The cartoon kind of goes along with that. So I highly recommend really coming up with a really great test protocol and ensuring that you're testing as many options that you can think of. Do you have anything to add to that Andree?

ANDREE CORDTS: Well as Katelyn mentioned, make sure that you actually develop multiple different testing protocol and involve your team because the team has to actually have a vested interest in the success, and they have to understand that they're the groundworker that are going to do that testing. So it was very important for us to actually share all the different protocol that we had developed with them together in advance so that everybody's knowing which protocol they're going to be testing. And another thing that we actually went and included in there is testing the reporting. So make sure that you test your reporting as well to make sure that the data that you're getting out of each of the report that you want to develop is the right thing.

And then lastly, the other thing that we did is we actually tested the system efficiency. So for us, a big thing was to make sure that the system is fast. We wanted a system that was creating workspace fast that were saving fast. So we included that in our test protocol. Our team member would actually enter data, save, and actually measure the amount of seconds it takes to save because we wanted something that was fast. So that was very important. So consider that this was part of our initial goal so we actually made sure that it was included in our UAT.

KATELYN WILSON: Yeah and that was a unique one that I want to point out is that the save time. So I kind of laughed when Andree first told me this, like it needs to save in seven to ten seconds. And I've never had a client tell me that. They're just like, oh, I just want it to be user friendly. Never so specific. So we were kind of working on it and I said, let's just build everything out and if it's not fast enough, then let's evaluate what's in there, which is what we have to do with some of the work spaces. I remember getting an email from her that said like this is taking 30 seconds, it can't take 30 seconds, and I'm just like oh my gosh.

I'm getting out my phone, I'm timing it, and I'm giving her back feedback. So I'm telling her let's eliminate some of these pick lists, let's get rid of some data fields that are just duplicates and so forth. So for me as an implementer it also brought to mind things that I can suggest to them that our best practice is moving forward. So from here we moved on to some training. So the administrator training can be customized where we just train your company only and we tailor it to what we implemented for you guys. Or it could be part of a pilot class or something that's standardized and we never strayed from it.

And so in the admin class you're going to learn some of the basic functionality of Fusion Lifecycle, how do things work, how do I adjust workflows, as well as what you do as an admin. So how do I create new fields, how do I modify existing ones, how can I add a state or workflow transition? And even going all the way down to the scripting that takes place. So how do I write a little bit of JavaScripting? What can I do with JavaScript and Fusion Lifecycle and so forth.

So the JavaScripting part can be a scary term for a lot of people. But so some things I try to look for when I'm looking for an admin from a company is do you have fast learning skills? Are you a- do you have strong computer skills? And then also do you have a developer driven though process that you could work on some of this JavaScript?

We also have our end user training. So this is for anyone that's going to be using Fusion Lifecycle. This is a recorded training so that you have it moving forward. If you get new hires, you can just say here's the recording, go ahead and review it. What we do with this is we just provide you with an understanding of the functionality of your tenant. So we built these work spaces, here's how they're supposed to function, here's how you access them, here's how you transition a workflow, add data. If you wanted to learn how to print attachments, that's one thing I just did with a client. Reviewing reports and how you're supposed to use them. All of these are things that we cover within your end user training.

And then once we do end user training, we hit a point where we say we're ready to go live with our implementation. And when we go live, we're just starting to use it, whether this is a gradual introduction to Fusion Lifecycle or we're just halting off all use of a different system and jumping right into our system and saying, OK, start creating our change orders in here, start creating items. We pushed all of our data over, we completed data migration, and we're ready to actually start using Fusion Lifecycle as it was developed.

So Oxygen Development again had a very unique scenario in that they already had Fusion Lifecycle and so we had to determine how do we start using new work spaces in Fusion Lifecycle. So I'll let Andree discuss what they decided to do for that.

ANDREE CORDTS: So again when we went through the go-live, we actually planned for it. So we decided we elected to go to a soft transition between the old system and the new system because we had, again Fusion Lifecycle. So we determined by looking at our projects a hard point by which any project that was further along than this would actually stay and be completed in the old system, and any project that was before that specific point would be migrated in the new system. So we shared that information with all of our team so that everybody is very clear about the go-live process so that they know that as of this date they no longer enter a new project in the old system, you're going to go in and enter them, and these are the list of projects that you have that are going to be migrated.

So we ask at that point these are all of your project, please go ahead and clean them. Very important to clean for any kind of data migration to clean the system and make sure that the data that you're transferring is accurate and not outdated. We also ask the team if any project had been stagnant for too long then we actually would go ahead and cancel them. So a lot of planning to our go-live to make sure that everybody was on board about how we were going to do that

KATELYN WILSON: And then once we hit the go-live state we hit a post completion support phase. And this is something that could be we're here for 30 days to support you and then you're pretty sufficient, we just check in every once in a while. It could be an ongoing thing where we're supporting you for years as you continue to develop and we continue adjusting our processes. And what we do in post-completion support typically is we're resolving issues we didn't find during user acceptance testing. So if we perhaps didn't catch one of those fields that should have been populated without being able or had it populated before you could move your workflow, we'd adjust that here. If you had any adjustments you wanted to make to your system we could do it.

So we're really just bullet-proofing it so that we are testing all of the use cases because we can't come up with all of them so we're not going to hit them all in the user acceptance testing phase. We do this by continuing the use of the ticketing system. And depending on how you want to handle your post completion support phase, it can also be for things like we want to re-evaluate our workflow, we've improved our processes, we've eliminated some of our steps, we want your help going in and fixing this because there's a lot of scripting and we don't want to have an issue with it. Or whatever the case may be, you don't have the bandwidth to do it on your own. And that's an implementer is there to help you deal with this post completion support.

So there were a lot of lessons learned in this project, as well as with any project. Some of them we learned as a result of this being not their first implementation. Some of them were as a result of them coming to this class, as well as just the fact that we sometimes don't learn things until we finish the implementation and say wow, I wish I had known when we started. So I'm going to let Andree go through her list of things that she knew or didn't know what she would want you to moving forward with your own implementation.

ANDREE CORDTS: So again if we go through, if you're going to walk away from this class with a certain amount of things that you're going to remember, these are the things that you should leave remembering. So have a sponsor that's really invested and has a good idea and a support of what your goal is. Have a strong team, a strong team that knows processes, knows your business, and that is ready to make the decision when decision needs to be made. So make sure that your project team is very strong.

Preparation, preparation, preparation. Prepare your workflow, your work state, all of the information that you want in the system. Your goal obviously make sure that that is prepared. But at the same time when you do that preparation, keep in mind that you want to vet the requirement and make sure that you keep things simple because you don't want to end up with a system that's unusable in the end. It has to be user friendly. It has to help your processes and support your business.

So one thing to keep in mind is to keep it simple. When we actually did our initial implementation, we went a little bit overboard and then now with the system that we have in place we just decided to scale it back and say, let's start something small. Because as you use the system, you're going to realize there are certain things that you thought you would want or things that you thought you would use that are not as useful as you thought. So your ideas of success is going to change as you use the system. There's things that you're going to say I love this and I want to do more of this.

So keep in mind that the system can be a phase one. You can start with your simple processes and then add on as you go as you learn from the system. I mean we're still adding on and then seven months later. So we're still learning from the system. And so that's really important to phase in your functionality.

KATELYN WILSON: Which takes us to a point of we could actually start with doing Quick Wins in Fusion Lifecycle. So some Quick Wins are going to be things that you can implement quickly, like we can throw together a task workspace in a couple hours you can start getting all of your users using it. And that starts getting people in the system, you're getting your money back quickly. It's also things that are going to touch a lot of user groups. So if you can bring in one group by putting together a change request workspace versus five groups inputting an MPI, you might want to start with that MPI and get people using it, again get your ROI sooner.