Keith:
I want to thank you for taking the time to join today’s webinar, Keeping Your Project Healthy Using Project Health Checks to Monitor Performance. This is the second in our new series of project management webinars that we’ve been holding this week. And with that, I give you Jackie and Teresa.
Jackie Dudas:
Thank you, Keith.
Theresa Nelson:
Hi, good afternoon? So, we are here today to talk to you about ways that you can assess your project to keep it healthy. One tool that we’ve found here at RPI that works really well is something that we’re calling the project health check. And the goal of that health check is to identify project risks and get a plan in place to address them before they even start to develop. So typically, when we talk about managing a project and you’re looking at monitoring and controlling project progress, you tend to focus on this triple constraint, which is time, cost and scope, balancing those three to get optimum project quality. But we all know working on projects that there’s more to a successful project than just on time, under budget and within the scope. There are other variables like how well your project team works together, do you have good executive sponsorship and support? Is there good communication? Are your various groups committed to the project and doing rigorous testing? Those are some areas that can honestly make or break a project and they’re not necessarily captured by just looking at these three pieces until it’s too late.
So, what we’ve developed is this health assessment that periodically throughout the project looks at those different areas and helps you catch these problems before you’re running over budget or behind schedule. So, with a health assessment, we like to focus on factors that we’ve identified as part of successful implementations, we call these success indicators. And we take those success indicators and compare them to your current project. It looks beyond scope and budget to things that maybe aren’t as easy to track. As I mentioned before, those are things like organizational involvement and communication security considerations. Also like to take a break before each critical milestone in the project and look at these factors because that gives us an opportunity to course correct before they’re impacting your major areas. So, Jackie, do you have anything you want to add?
Jackie Dudas:
Yeah. So, who would be the audience normally for this kind of a presentation?
Theresa Nelson:
Yeah, that’s a great question. So usually the audience for this type of presentation is your steering committee, your executive sponsorship and project team leads. We don’t always share health assessments with the entire project team because like I’ve mentioned, some of the categories can be specific to team relations and those are the places where you need your steering committee and your executive group to know what’s going on and be able to step in and help resolve any issues.
Jackie Dudas:
Yeah, that makes sense. And so does every project need a health assessment or what do you typically do for health assessment?
Theresa Nelson:
Yeah. So, I’m finding that you don’t necessarily need a health assessment with every single small implementation. If you’re doing just some training or a little bit of custom development work, a health assessment might be more effort than is really beneficial. But where they come in very, very helpful is on large scale implementations. Anything where you’re looking at a large-scale organizational change or you have multiple team members involved, multiple parts of the organization affected, that’s where the health assessment can really help the project stay on track.
Jackie Dudas:
Yeah. And last question-
Theresa Nelson:
Sure.
Jackie Dudas:
Some of these critical milestones, what would be a critical milestone, like testing?
Theresa Nelson:
Yeah, so generally a project has at least three testing phases, those are great opportunities to take a pause and look at how the project is performing. Also, we like to go ahead and do them before a go live, especially if you have a multi-phase project, and after a go live in a multi-phase project. That’s a great opportunity to assess how the team handles the stress that comes along with a cutover and prepare for your next phase.
Jackie Dudas:
Makes sense.
Theresa Nelson:
So, what makes a successful project? These are some examples of areas that we feel carry across really any software implementation. When you’re looking at doing a health assessment, the first thing you want to do is say, “What does a successful project look like? What factors am I looking for?” So, these are some examples of categories that you could use but depending on your project, there may be other categories that are also very important.
Jackie Dudas:
Yeah.
Theresa Nelson:
Jackie, you’ve done these with me on several GHR or HCM projects, are there any categories that you’ve found come up again and again?
Jackie Dudas:
Yeah. So, I come from the HCM side so I can identify those kinds of categories. So, some things we’ve talked about in the past are empowering the HR generalist role. So, the HR generalist is a role or a person that Infor Lawson has kind of created within the system that does a lot of the basic administrative tasks. Another one that we have talked about is the job in position competency set up. This was very specific to the project that we were working on at the time, but it was a huge part of the project. So, not only did we want to make sure that the jobs and positions were set up correctly with the right relationship to each other, but competencies, KSAs were all really critical to the project, so we wanted to make sure that that was moving along well and also that it was getting the necessary attention from all areas of the project.
So, just like Theresa said, it really is going to depend on the project. These, however many these are, 10, are going to be really probably translatable across all projects, but you might want to add in a couple more depending on what you actually have going on. So, each one of these laws, the success indicator, or actually two to four success indicators beneath each law, what they do is provide an actual specific explanation that gives a little bit more information about what you’re really looking for. So, when we look at a law, it might be a little bit vague. Like client engagement, whose responsibility is that? Is it the client’s responsibility or is it our responsibility as your partner to engage you? So, the point of the success indicators is really to kind of spell that out. It’s a specific explanation that really gives details that allow you to better target the goal and be able to hit that target.
And then each one of those laws, we put a grade against that, and we keep it really simple so that we don’t spend too much time finding the gray areas between each grade. We have a meets or exceeds expectations, that’s your green check mark that means you’re doing a great job. Area of concern is a yellow circle, this is what we use to just say, “Hey, this kind of needs some attention.” It might be somewhere in between green and yellow, but I think we usually go and round it down to a yellow just to make sure we’re not missing anything that might sneak up. And then the red one, this is where there’s risk or it just needs attention. So, these might crop up and it’s not always a bad thing. Sometimes it’s kind of scary to see this when we’re going over the health assessment but sometimes it’s just saying, “Hey, we really need to pay attention to this, this is coming up, this is a really important part of the project and we haven’t paid a ton of attention to it yet.”
Theresa Nelson:
And it’s important to keep in mind that the purpose of the health assessment is to catch the red before it’s impacting your project. So, seeing the red, it always gives us pause but the good news is that we’re probably catching it before you’re seeing an impact on your budget or your timeline, which is great.
Jackie Dudas:
Yeah.
Theresa Nelson:
So, we thought it would be helpful to go through some of the categories in a project assessment and let you see what we’re finding makes a successful project. So, our first category is client engagement. And with client engagement, we’re looking for participation throughout the organization. And I always tell clients that means horizontal and vertical. You want vertical participation, meaning all levels from your end user all the way up to executive are in support and participating appropriately within the project. But you also on big implementations need to keep in mind that you’re involving multiple departments. When you’re implementing a piece of software, it doesn’t just affect one group usually, it often carries across other parts of the organization. And making sure that everyone is represented, and everyone has an appropriate voice is very important.
Another really crucial piece is project communication. And that kind of goes along the same lines with organizational participation. A documented specific communication plan is crucial to a successful project. And along those lines, it’s really important that we take the time early on and periodically throughout the project to make sure that all stakeholders understand it and that if it’s not working, we throw it out and make one that does work. So, that’s another key success factor.
Jackie Dudas:
Yeah. And really quick, just off script here, it just kind of popped into my head, but a communication plan, when I first heard of it, I thought, “Well, this might be a little bit overkill.” But then I actually-
Theresa Nelson:
It’s not.
Jackie Dudas:
I looked at what Theresa had put together, and I think it makes a lot of sense. And what it actually means, a communication plan, is it actually says we’re going to meet this many times per month or per week and this is what we’re going to talk about in each one of those meetings. So, in case you weren’t familiar with what that was or aren’t a believer, you should be one.
Informed design decisions are the next key critical factor or law. And what this means is we’re looking for a few different things here, we’re looking for both the client to be making an actual good decision about how to use their data or how to take their old data and put it into the new system and we’re also looking for well thought out or good documentation to come out of the design phase.
So, it’s both the client’s responsibility and the partner’s responsibility to help the client come up with these good design decisions. So we want to be able to empower the user or the client to actually make these decisions by giving them some training, which we’ll hit on a little bit later, and we also want to take the decisions that we come up with very seriously and provide documentation around what they are, why we made them. We’ve both been through projects where we have gone back and forth, we have baffled over a decision for weeks, finally made a decision and then a couple of months later, we say, “Gosh, why did we make that decision?” And we go back to the design documentation to realize, “Oh, there was truly a reason why we needed it to go this way and we picked that over the other way.” So informed design decisions are key and you’ll probably be revisiting any of this documentation throughout the whole project.
Theresa Nelson:
Equally important is a documented training plan. And this, I think sometimes falls into that same category as communication plan where it’s sometimes feels like, Oh, do we really need to take the time to list all that out and talk about it? Can’t we just say, “We’re going to train end users here and we’re going to train super users here.” But something that comes out of a really well documented training plan is it gives us a way to track progress and align expectations within the organization. So, we’d like to see that done pretty early on in the project. In the design phase we usually start laying out the training plan and documenting who’s being trained when and how that training is going to translate to actually using the system, and that is a factor that really sets you up for success throughout the whole project.
Jackie Dudas:
Yeah. And one of the things we actually didn’t hit when we started hitting these examples slides is the current rating versus the previous rating. It’s pretty obvious, I guess, but when you’re actually walking through this and going through the health assessment together, the first time you wouldn’t have a current rating or you would have a current rating but not a previous rating but it’s basically tracking it. So, we have that previous rating to let us know, were we doing worse before? Were we doing better before? Are we about the same the whole way through? So, just something to keep in mind as you’re going through the project. You’re normally doing this a couple of times, like Theresa said, at those critical milestones.
Automating tasks, so this is important not only for the project itself, so maybe you do the same things cyclically, you have to do a conversion every couple of weeks, but also for the result of the project itself too. So, I guess my conversion example is the best one I’ve got for when you’re doing a long-term project and there’s something like conversions where you have to do it over and over again, we would need to figure out a way to actually automate that so that we’re not doing it manually each time because that can really eat into the time of the project. And by the same token, when you’re putting your system up and running, you want to remove a lot of that manual intervention that maybe you’ve been doing in the past, or maybe it seems like you would have to do with the new system by automating this, whether it’s IPA or system delivered pieces, that way you’re not over and over using those manual tasks.
Minimizing customization, this is another one to cut down on some of the time you’re spending in the system making it perfect for you. I know that you want to make it exactly what your organization needs but we often recommend that you don’t customize it too much so that you make it hard to actually support. And we often see that clients would remove things that they’re not using from the system, which makes sense and it’s all well and good, but you might miss future updates that come or when future updates are coming and you might miss functionality that’s delivered that actually either takes care of the original problem or it gives you a way around that original problem.
So, minimizing customizations keeps a lot of the work off of the tech team from having to customize the system exactly the way that the functional team wants it, but it also allows you to embrace the out of the box functionality and maybe standardize your processes throughout the organization. So instead of making the system do exactly the weird way that we’ve always been doing it, we can now get the organization to agree to these system limitations and maybe standardize it throughout the organization.
Theresa Nelson:
One of the very first tasks that we do when we go into any implementation is develop a product line strategy. And this is really a crucial key to the whole… It affects your testing plan, your training plan, your entire implementation. This is the piece that outlines which environment you’re going to do each piece of the project, where you’re building, where you’re testing, where data conversion starts. Any good implementation will have a very clearly defined product line strategy, and another really important piece is the communication plan. This isn’t something that you write up once and you say, “Well, we’ve got it, here it is, everybody sees it, we’re done. This is something that you have to periodically revisit throughout the project and say, “Is this still working, or do we need to throw it out and figure out something else?” And this is where I think the health assessment has really helped us on a few projects because this is an easy thing to kind of forget about when you’re in the pit and you’re just building and testing and fixing, and it is something that has to be periodically reviewed.
So, by having a health assessment reminding you periodically, “Oh, hey, that’s right, we’re supposed to sit down and look at the product line strategy again.” This kind of gives you that prompt to remember to reevaluate and see if it’s still working for your project. So along the lines of the training plan, it’s also really crucial to have a good test plan. And your test plan is something that’s developed very early on as well, and used to track progress as you’re going through your testing phases. One very crucial element is this middle success indicator, making sure that the test plan includes very rigorous data validation because you can’t just expect to start testing and make sure that you’ve validated all of your data, especially with a data conversion involved. It takes time to develop that plan and those scripts and to make sure that everyone on the team who’s doing testing understands what success looks like.
Jackie Dudas:
This next one is pretty obvious from an HCM background, but occasionally a project has a finance or payroll risk awareness component to it. So, some of those success indicators that we usually follow, especially for an HCM project are parallel payroll, so this is where you’re actually running a payroll in your test system and comparing it to your production data and making sure it matches up. Really, we are also looking in this area for active participation from the finance and payroll teams as well. So, even if it’s a project that’s maybe just HR or just supply chain and you think, oh, it’s just us, we’re not affecting anybody, if there’s an account or an accounting unit tied to it, it’s definitely going to go downstream somewhere. So, you want to make sure that you’re talking to finance, talking to payroll, maybe you don’t quite need a whole parallel payroll, but you probably want to test it or at least figure out where that downstream effect is hitting.
Theresa Nelson:
Yeah. And I just want to add we generally recommend in any of these projects, at least talk to your finance and payroll staff, they should know what’s going on and we should from the very beginning be working with them to determine what’s the appropriate level of their involvement in the project because pretty much everything we do with Lawson implementations is going to eventually touch finance or payroll.
Jackie Dudas:
Yeah. You don’t want to find out too late.
Theresa Nelson:
Yeah, no.
Jackie Dudas:
And then the last one we have here is transfer of ownership. So, we generally see this where at the beginning of the project your consultant is kind of your subject matter expert and they’re building maybe building out the system for you, creating that design document, helping you learn what the system is going to do and what your new process is going to be like. But what we’re looking for as the project progresses is that transfer of ownership and knowledge to the client. So we need both active participation from the client and active transfer of ownership from us so that it’s kind of a smooth process, and maybe where we start out training the team at the end of the project we would do a training the trainer and then the client is now able to train other end users within their organization.
Theresa Nelson:
So, hopefully at this point you’re thinking about projects that you’re working on and starting to wonder, “Is my project healthy? How are we doing?” Hopefully, as we’ve been going through some of these success indicators, you’ve been measuring your own projects up against what a successful project looks like. So, we’ve developed to help you out a quick 10 question quiz that we’re going to send out that lets you go through some of our success indicators and answer how frequently your project is participating in these things. And we’ve developed some scoring, so you’re going to come out with a percentage. And if your percentage is 75 to 100%, we consider that a very healthy project. But it’s important that you don’t forget to get your checkups because even healthy projects can become sick over time. So, just because things are going great now, doesn’t mean you ignore the doctor and never go back and look at it again.
If you get a 55 to 74%, we would say it’s time to schedule a doctor’s appointment, it’s time to meet with your executive group, your steering committee and maybe go through some of these in more detail and talk about the areas where your project is starting to falter a little bit. If you get a 30 to a 54%, we would say visit Urgent Care. If that’s where your project is falling, then it definitely is time to pull a steering committee meeting and maybe circle back with your project team. If you get a result in there, we’d be happy to come in and help you with any project assessment work and getting everything back on track. And a zero to 29%, hopefully no one will get a zero to 29%, but in that case, it’s the ER. In that case, you probably are already seeing some impacts on your budget and your timeline, and maybe even your scope has creeped to something beyond what you thought was manageable.
Jackie Dudas:
Yeah. Maybe take a screenshot of this for when… We will post this so maybe take a screenshot.
Theresa Nelson:
All right. So that brings us to the end of our discussion, but are there any questions?
Jackie Dudas:
No questions?
Theresa Nelson:
Great.
Keith:
Great. If you guys have questions at another time you can always reach us at rpic.com or try to reach out to Jackie or Theresa directly. I want to thank them for a wonderful presentation.
