Speaker 1: Have you ever been in a situation when you've delivered multiple projects and your project management process is well oiled, but at some point it just stops working? It worked before, but now you have new challenges or new situation and you feel like you're pressured to adapt. Hi, I'm Natasha Kasimtseva, your project doctor, and today we're going to talk about three key areas to look at and ask questions about to tailor, mix, and match different project tools and methodologies to fit you, your specific project, and your specific team and organization. Well, all projects are different and a certain delivery approach that might have worked for a certain client or certain project or even a certain team might not work for others. Well, wait, do not panic, that's okay. You know, technology and overall situations change, right, and we are always prompted to adapt and find new solutions. So, why should project delivery be different? The Project Management Institute even coined the term that describes our ability to mix and match and decide on the combination of project management tools and techniques, inputs and outputs, and processes to fit our project delivery best. And this term is called tailoring, tailoring your project delivery. While there is a myriad of project management tools, techniques, and different schools of thoughts and philosophies about how projects should be managed, there is a consensus around three different areas one should look at while deciding how to best tailor your project delivery. Those three different areas are culture, team, and project. So, let's dive right into it and start with the culture. The culture is really how things get done in a particular organization. It is a set of spoken and more often unspoken rules that would impact the decision making, the actions that are taken, and also team behavior. Here are some key questions to ask. If you're trying to pioneer a certain implementation approach, say Agile or Predictive or Hybrid or Waterfall, whatever it might be, look around and see what organizational culture tells you. If this culture is mature in the Waterfall delivery, then probably going full speed with Agile will be challenging. I'm not saying that would be impossible. I just want you to be realistic and really aware of their environment and situation around you. So, the first question was about executive buy-in, team buy-in, and understanding of the approach that you're trying to pursue. The next question to ask is the level of autonomy and trust in team. So, if the level of trust in the team to deliver working quality solution is high, you might try iterations and it might be easier to go with Agile approach. However, if the trust is low and the team is new, for an example, or inexperienced in certain technology or in tools and techniques for that specific project, probably having a more predictive, rigorous process might be more helpful to get everybody on board and kind of walk everybody through those stage gates to get to the final result. Decision autonomy that exists around an organization also matters a lot. Usually, Agile processes require higher degree of decision autonomy, assuming that developers who work with stakeholders, product owners, would have a high level of say of how the solution is going to be presented and developed. They can determine their own process of how they get things done, right? So, it's usually all around self-organizing teams, which does require a higher degree of autonomy. If decision-making autonomy is really concentrated and limited to the management, and so the team usually just follows the orders, probably that type of environment is more equipped and ready for a more predictive, rigorous waterfall approach that will fit the culture a little bit better. That's not to say that you can't introduce elements of Agile to increase collaboration and maybe transparency, but I just want you to be cautious and just ease into it. So, since we are already talking about team decision autonomy, let's switch gears and talk about the second component and the area where we need to focus when gauging our project management approach. So, the second component is the team. It really helps to look at the team and the team dynamic. Projects are delivered by teams, right? So, it just makes sense to see how teams function in this particular culture. So, we already talked about decision autonomy, which is very important, but another question around culture is availability of the team. So, usually, especially in the world of software development, you will have developers who are actually building the solution, but they cannot build the solution unless they have access and clear understanding to requirements, access to the stakeholders, and business partners who actually have the business knowledge and the why the solution is needed. So, it really helps to know the degree of availability of those other stakeholders on the project, and I'm talking about business partners, I'm talking about the key users that might provide some business insight on the solution and the business purpose. So, usually, Agile teams, or if you provide your solution or develop your solution in iterations, assumes that high availability of everybody who is engaged in the process, your developers who are building, your stakeholders on the business side, business partners who can provide, who can answer questions to clarify requirements, or provide any additional feedback when you iterate over some testing, or if there's certain decision that needs to be made on the executive level, access to those decision makers can really speed up or slow down your delivery process. And the last area, but not least, is the project. We really need to look at the nature of the project and the nature of the requirements. So, these are the key questions to ask. Well, first of all, is the project mission critical? Right, for example, let's imagine we're developing a COVID vaccine, right? That's a mission-critical project, it has to be done, really high stakes, right? It's kind of a hyperbole of an example, but it's a good example nonetheless. So, in this environment, you might decide to pursue a certain approach that would provide you the level of rigor that allows you to have, to lower your risk, and to really have control over how your project is going from the beginning to the end. When I talk about rigor, I usually think about waterfall or predictive delivery, and that's type of delivery where you pre-plan everything, and then you execute just according to your plan. And the main, so there's a lot of pressure on change management in a sense that you need to avoid changes to scope, you need to make sure that your requirements do not change, you need to make sure that your team stays stable. So, and usually for mission-critical products and projects, a waterfall or predictive approach that provides a little bit more rigor might be the better way to go. So, another question to ask is, would it be practical to break up the project or the product of this project into sections? Right, so sometimes, especially in the in the world of software development, and again it all depends on actual product that's being developed, sometimes it's practical to say, well, we have all this functionality that needs to be developed, but we can start by iterating and delivering the features incrementally. So, in other words, we do not have to wait for every single feature to be done to be able to release it back to the customer for them to start using the feature, right? So, if it is possible to break up the features into sections that could be completed end-to-end and delivered to the client for them to use, that's wonderful. That's actually a very good indication that agile approach would be wonderful, because agile allows you to have shorter cycles and quicker feedback loops and faster delivery to the market. So, that's kind of a good example to gauge your delivery method. However, there might be situations when your project requirements and your product overall, or a service for this matter, is structured in the way that you really have to have every single component in place, developed and tested out to have the overall value for the client, right? I'm trying to think of an example. Let's say you're building a residential one-family house, right? It doesn't make sense to just build a bathroom and say, hey, family move in, you can use this bathroom, right? It's kind of a silly example, but it's a really good representation of what that means. So, there are some projects, let's say in this case, building a one, you know, single family house, where you really have to build it holistically, right? You have to have a foundation, you have to have the walls, you have to have your roof, your electrical, your plumbing, everything in place before you actually have the final house that could be sold for people to move in and live in. And then the opposite one, the opposite example where you can actually break up the features is if you actually could deliver sections in chunks, say, hey, this is one bedroom that's ready, go live in it, right? And then kind of assemble the end product this way. But yes, in an example with a house that's not practical. So, when it is possible to break up your delivery into increments and individual features that can be delivered end-to-end, Agile would be the best approach. When you really have to plan everything out and wait for every single component of the project to be delivered to actually have the final result, probably a more rigorous process such as, you know, predictive or waterfall with maybe iterations would be a better place to start. In the project management world, there are standards, there are best practices, different schools of thought of how you should deliver the project. But in the field, when you're actually doing it, remember, your project delivery doesn't have to be cast in concrete. You don't have to just be stuck in a box of a single methodology or a single process. Actually, it would be impossible to be this way because all projects are different and environments in which you will deliver your project will change, especially if you work as a consultant and you transition from company to company, from project to project. So, I want you to feel totally fine and relaxed. When you feel like your project delivery method that worked before is not working anymore, that's fine. That's fine. It's normal. It happens all the time. And so, in this moment, when you start feeling overwhelmed because, you know, feel like you're pressured to change, I want you to take a deep breath and look around other project tools that are available to you. If you are accustomed to Agile delivery, but you are operating in an environment that's more predictive and waterfall, lean on to some predictive tools, some waterfall delivery methodologies and processes. And you can kind of pull components of certain delivery methodologies to create a hybrid approach. If you've delivered projects in a predictive manner, right, with plan being done at the beginning and then really, really honing into the change and keeping the requirements stable and your team stable, but you feel like maybe your team is different or the market requirements changed, right, and you feel this pressure to deliver functionality faster, maybe it's time to sit down and maybe scale back on the planning and really see if iterative or more Agile approach would be a better fit for your new team and your new situation. I hope you enjoyed this video and leave a comment down below on whether you agree that culture, teams and the nature of the projects are key areas to look into when you're gauging your project delivery. And how do you figure out how to go about your new implementation and how do you decide on which tools to use? That would be very wonderful to hear from you. Thank you so much for being with me today. If you haven't subscribed yet, please do and I'll see you on my next video.