Hi. My name is Gorkem Sevinc. I am an Adjunct Assistant Professor at Johns Hopkins Medicine at the Division of Health Sciences Informatics. I am currently the Chief Technology Officer and Co-Founder at Facet Wealth. Previously, I have started a number of other startups that are in the health informatics space. My background is at Johns Hopkins Medicine. At the tech there, I led and created the Technology Innovation Center at Johns Hopkins Medicine and I was a faculty member in the Department of Radiology. Today, I'm going to be talking about project planning. The Project Management Institute lays out five process groups for project planning. On the next few slides, I'll provide some examples of each and how it relates to a project that I have worked on. The five main things that we're going to hit here is initiating, planning, executing, monitoring and controlling this project, and the closing phase. The example that I'm going to give today is on a project that we did at Johns Hopkins Medicine called the Prostate Active Surveillance project that we initiated back in 2016. This project is about doing active surveillance, utilizing machine learning, predictive analytics algorithms to determine whether a patient that has prostate cancer requires treatment or whether they can go untreated with minimal risk and going through this active surveillance process. Initiating phase of a project. My first goal, generally, is to build a relationship with the stakeholders. It's really, really important to get to know each other, determine who brings what to the table, and make the process of how we'll go about this project clear to all the project team members. It's very, very key to build this relationship early on, so that it's very clear to everybody who's doing what. Secondly, we like to define these project goals. In this specific example, there was an Excel-based system that was in use, and it was fairly effective but it was out of context and it was hard to use for physicians, and it was a great proof-of-concept. For a project, it was great to have a proof-of-concept that we can work off of. But our goal was not to take an Excel-based system and just build what I like to call Excel plus plus. So, we took this as a proof-of-concept and then we started ideating about what is the art of the possible. So, on this initiating phase, this is when you work as a team to collectively define the project goals, including that art of the possible. It's very key to ensure that stakeholders and the team members are properly engaged. So, early on, it's best to include all the stakeholders as much as possible. For us, this included physicians, nurses, engineers from my team, designers from my team and project managers from my team. So, all the project team and all the stakeholders coming together and getting engaged. We iterate on the project understanding a few times, so that happens over meetings or working sessions. This can be white boarding. This can be specifically just getting together and discussing things and to collectively produce a statement of work. This is my style. Sometimes in certain projects, statement of work is generated by the people doing the work and sent over to the stakeholders. I like to do this as a collaborative effort. So, the statement of work, what does that do? It helps us properly determine the scope of the project. So, my biggest nightmare always is scope creep. It's bound to happen in pretty much every single project, which is the project scope going over the original plan. So, you go over budget and you're perceived to under deliver where you're working hard towards the original plan but then, people are asking for other things that are not in the original plan. So, your statement of work, it's your best friend. It will protect the project and it will make sure that the scope of the project is well-defined. I actually even prefer to get a signature on that statement of work. It shows that it's a more of an official agreement on the scope, the budget, the deliverables of the project that we're all collectively essentially working on. In the planning phase, we do a few key things. We determine and communicate the project members what are the names, the roles, including the stakeholders, who's taking what role. If one clinical champion is going to be the main person who brokers all the feedback from other clinical champions, it's really good to define that at this point. Then, we determine and agree on the project process. How often do we communicate? How do we unblock any blockers? How do we update stakeholders on project status on a recurring fashion? We then start planning the actual work with the engineers and designers, of course. So, we define the phases of the project. I like to define on an informatics project is design, development, testing and deployment, with generally one more level of detail that we go down to on the specifics of each phase. What are we doing during designs? It could be low fidelity mockups, high fidelity mockups. In the development phase, what are we building first? We make sure to visit the scope, the statement of work, again after defining these phases with that one level of detail, because what you will see is that, as you go through these phases and as you're defining your project plan, there may be some really obvious things that were not thought about in the original statement of work. So, it doesn't hurt you to revisit that statement of work just to make sure that the scope is still well-defined, that it still makes sense from the budgetary perspective, and it's still deliverable. The details, as I said, may have an impact on the scope here. So, it has to be clarified with the project team. Then, the defined phases of the project then become this project plan. You could think about a Gantt chart or a project roadmap. There are many different kinds of project plans that can be communicated but it's very, very important to have this, and it can be shared with the project team, including stakeholders. This becomes something that you can also update as you go along. The next phase is executing. So, during this phase, what do we do? We execute. So, we define the detailed project requirements. I like to do requirements and use cases. Sometimes we like functional requirement documents, or product requirement documents, or project requirement documents and it's really, really best practice to define requirements and use cases early on, as it with as much detail as possible. Then, in this project, for instance, we did a full UI UX of the project. What does that mean? With a low fidelity mockups, these are like wireframes that show here is where this button is going or where that button is going, here's the workflow going through, and the high fidelity mockups, which includes the user interface perspective. There's a key point that I like to iterate on with stakeholders to get the workflows and user experience and design elements right. Because as you start building on the engineering side, revisiting things is higher cost, takes more time, whereas if you're doing it at the UI UX phase of the project, then you can iterate faster. So, once this design phase is complete, then we can start the software development process. There are many ways to do this. There are Waterfall, Agile, Kanban. I'm personally a fan of Agile, that's how I like to run my teams but that's a personal opinion, and there are many ways of going about it. Throughout your project, you should be doing monitoring and controlling what is happening. It's a key to make sure that during planning and during executing, you're always monitoring and controlling the project. So, number one thing to do here is periodic updates to the stakeholders, keeping them up to speed with the progress. This can include screenshots. This can include your original project plan. Here's where we are. Maybe a link to a demo system, that can always be helpful. The project manager is responsible for overseeing the original versus actual timeline. Are we still on track? Are we still on budget? Are there key risks? If there are key risks, let's identify them. So, there are key assumptions that we always have to make throughout a project, and these may or may not work. In this specific example, it helped us identify that there were machine learning algorithms that were based off of the Excel system, and through the assumptions and through our monitoring and controlling process, we saw that we could actually reuse what was built and expose it through APIs, application programming interfaces, like a wrap around them, and that actually saved us effort that we could use to deliver the other parts of the project. There are many metrics you can use here. These are the KPIs, key performance indicators. I recommend generally that the team defines these together. There are some normal ones that people always use, productivity, progress towards the goal, the budget. Are we delivering on time, on budget showing with these KPIs? There are some project specific KPIs that can be considered as well, of course, and they are all great metrics to keep in mind. The last phase is closing. So, during closing and sort of post-deployment, your deployment phase and your post-deployment making sure that everything is working smoothly is during this phase. It's really helpful to look at what lessons are learned. It's a useful place to engage the stakeholders and the project team. Think about what went well, what could have gone better on both sides, on the stakeholder side and the project team side, and how do we go about it for next projects or the next phases of the same project? What can we do better? Key lesson for us here. In this example was learning about the EMR integrations. We had assumed that we would have some key integrations early on in the project and that turned out not to be the case. This was an external dependency that we made some assumptions on. So, in closing, we discussed that we could apply in the project to be a bit more efficient and not assume a timeline for this EMR integration and could have treated it as a more better external dependence of it. That's it. So, thank you for listening.
