New product development: A new and evolved approach to managing NPD projects
Ensuring fast NPD or New Product Development is one of the most important activities for any organization to sustain and grow. However, despite implementing the latest project management software and techniques, interruptions, rework, and lead-times for project completion remains high in environments with very high scope variability. Many CCPM implementations fail as well. This episode on the Counterpoint Podcast is an introduction to a whole new approach for managing NPD projects better. Satya has used many examples and case studies to help bring clarity to this new methodology. View the presentation at: https://bit.ly/30WKkHo Read for knowing more about implementing this method in pharma drug development: https://www.vectorconsulting.in/research-publications/consumer-goods-and-retail/generic-drug-development-the-prescription-for-success/
New product development is one of the most complex operating environment. Many companies struggle with huge delays, poor predictability of due dates and an environment of extremely high stress. Companies have tried traditional approach project management without much success. This is because of very high level of scope uncertainty, high variability of task durations and inability to define capacity. Critical Chain project management was initially thought of as an solution for this environment but results are also not decisive.
We have today with us Satyashri Mohanty, partner in Vector Consulting Group who has been researching the topic for last decade. As per him, the original assumptions of CCPM does not hold good for new product and R&D environments.
Let us discuss with him the new approach
Satyashri Mohanty :Thank you, everyone.
| Shubham Agarwal : | Hello Satya , what do you think is the problem of CCPM in managing new product and R&D projects ? |
| Satyashri Mohanty : | So, today’s topic is about how do we redefine CCPM for R&D projects, I’m sure most of the practitioners out there would have seen a problem in their implementations. And the problem would be something like this, when they open-up the portfolio chart after, let’s say, you know, one year of implementation, if they go back to the site, they won’t be surprised to see a portfolio chart where almost every project is in red, it’s not just in red. But if you extend the Y axis to include 150 percent above a penetration, you’d see many projects out there. It is not a rare thing to see after one or two years of implementation. So many projects are in red. And and we all know, the SOPs says that if a project is in red, we need to take actions to bring the project back on track. So, what happens to be in such environments is, there are two ways to approach the problem of reds. One is the classical way, where whenever a project is in red, the first thing that we tell our clients is take a buffer recovery action. Right. So, every project review, meeting ends with a buffer recovery action. Now, just imagine when many projects are in red, actually triggers expediting action, across many projects, which in turn, leads to multitasking or worse, people try to somehow show task closure, even though it is not perfectly close to show some percentage completion. So, all this kind of stuff keeps on happening, which actually puts more delays into the project, and hence more reds. So, this is one one-way people, you know, get into the vicious loop. Basically, you end up dismantling everything that you have implemented in terms of a stable priority system in terms of no multitasking in terms of full-kit, many such things starts getting violated. Now there is another approach that people do when they look at the portfolio of projects, and it’s all red. They say, okay, now, let’s let’s try to clean it up. So, there is a dominant voice that will come up and say, you know, let’s clean it up. Let’s reschedule bring the every project back on back to green. But slowly and surely these same projects starts getting into red. Now, once you start doing this rescheduling, often, actually, the top management loses control on the project, the project review meeting, if you just reset the baseline, they get a weak sense of control, okay. And as a result, the review meeting itself becomes ineffective, if you keep on rescheduling the review meetings loses their significance. And slowly, you know, without a good review, projects can also get delayed, and that also can contribute to to the reds. So, either way, if you see this kind of thing happens. And basically, if you see what we have done here is the as is environment has not really transformed to the new environment. It’s just that the lingo has changed. The projects are delayed and in the older environment before CCPM also projects were delayed and people try to expedite it, or you know, people try to reschedule things. And that’s that’s the typical conflict that used to be there before the CCPM implementation. |
| Shubham Agarwal : | So Satya why does this happen? |
| Satyashri Mohanty : | I want to focus this discussion on R&D environment itself. And my claim is that there are basic assumptions of the R&D environment, which the CCPM is not able to meet the original CCPM. And the starting point is the is the objective itself. So, if you look at the original CCPM for multi project environments, and if you go through the sente, the objective stated was, it was meant to deliver a high on time performance. And when I say high on time performance, it is as per the originally planned date, it’s not as per the revised latest revised date, right? It’s as per the original plan date, it is it promises very high level of due date adherence or reliability around the due date right. Now, what does this imply when you promise a due date, it just implies that the solution is actually very sensitive to the initial planning and the scheduling that you’re doing. So that becomes very, very critical that the initial planning and scheduling has to be as close to the reality as possible, okay, it should not be way off the mark. Number two is just making a single project plan is not important. And the number two need is to ensure that all the queuing delays are accounted for, while setting the due dates. And that’s we all know is the process called pipelining, where the projects are pipelined based on a most, most constrained resource or, or or a virtual drum. Right, basically the you know, we will stagger it and and get a due date. So that’s that’s the, that’s the end of planning, where we we get a valid date for each of those projects. Now, once it is, once this planning exercise is done, we tend to believe that this is a good job done and hence, the execution, the entire focus shifts to subordinating to the date that has been planned and that is how we will meet the on time performance. Now, what are the subordinating actions. The first is that the priorities has to be derived from the buffer colours. So, which means that if the buffer is red, which is a very high chance of missing the date, right, and that takes precedence over yellow and green colours. And the second is if the project gets into red one needs to do a special action, expediting action is also technically allowed, and you do what is known as a buffer recovery plan. So, you know, people who have done this would have seen how buffer recovery is done. So, this becomes a very, very important part of the review meeting. Now, the assumption here is that we have done a very good staggering the pipelining right, and the scope of the project is very well defined. So, these kind of recovery actions should not impact the entire pipeline, right. And if you see these assumptions are borrowed heavily from the drum buffer rope solution, even if you look at drum buffer rope solution, what we try to do is in the planning, we try to solve the problem of due date quotation by trying to resolve the load on the bottleneck. And and that’s how we get a valid date. Yes, product mix can change and for a changing product mix, there are better algorithms to account for that as well. But basically, the aim is that during planning itself, we have a capability to give what is known as a reliable due date. And once that is set in execution, we focus on the colour priorities and try to take actions to ensure that these so called reds do not miss the due dates. Now that’s that’s what is borrowed from DVR now, what are the assumptions in the DVR environment? One is that all the potential bottlenecks, they are dominant, okay, even if the product makes changes, we know where the new constraint is going to be. And more important, it stays stable at that place. Right. And the other important assumption is that not only the touch time is insignificant portion of the lead time, but the test time also stays stable. It’s not that you know, you you you planned for x work and it becomes 2x during execution, it is unheard of, in any DVR environment. Now coming back, let’s let’s check, what is the implicit assumption since we have borrowed from the from the environment of DVR There is also an implicit assumption CCPM does recognise that the touch time is very high. And that’s why it differentiates tasks from a project buffer, which DVR does not DVR just puts entire thing as as just the buffer. So here, it does recognise that the touch time is high. And that’s a need of having a project buffer which is segregated from the task times. But it also assumes that the touch time itself will stay fairly, fairly stable throughout the execution. Okay. And that’s that’s a big question mark. So, because of this assumption, we believe that during the initiation of the project, we can do a very good work of planning because the scope is very well understood. And the dependencies are also very well understood. And that’s that’s the real question mark. If you look at every R&D project, and this is if you look at R&D project, it goes through various phases, each phase if you see, there is always a check on what work we have done and is it right or wrong, it goes to some kind of a I would say a testing for example, once the concept is finalised, you go through what is known as a concept validation, right where people run simulations and so on so forth, there is something called a product validation people after making the product they check that does the product meets the functional expectations and then you go for a process validation whether you can produce the product and and also goes for production validation, which is can you produce in the in the required quantities, while maintaining the efficiencies. If you see each one of this is actually a question mark. And end of these each of this time it it opens up a topic, it can lead to to rework cycles that means the scope itself undergoes a change now, many environments have these kind of gates at a project level but even in a large project while you are making drawings your your while you are even making concept around let’s say a small portion of the project you might be going ahead and trying to test what is it all about is it really right did I go in the right direction? So, this this kind of questioning actually creates an environment where there are there are two wastages right the one wastage is what is typically you know call the I would say a type one wastage which is which is basically the all the wastage is related to expediting you know missing out on the full kitting multitasking. This is what is called a type one wastages but there is something called a type two which is not really a waste it is actually a value added rework which comes from answering these questions, Is my concept okay?, Is my product okay?, Is my process okay?, Is my production efficiency okay? right all these kinds of questions, the answers to that is provided through these phases in the project and whenever I try to answer this I get new knowledge and this new knowledge actually leads to rework and it is not a wastage it is it is actually a value adding rework, every time I test a prototype, I learn five, six things that fail and that gives me a feedback loop and I try to redo things. So, this is where the the scope, when particularly when you’re trying to initiate the project up in the beginning, you can never be sure about the entire scope of the of the project, right. And this is where I would say that the the scope of variability is extremely high for the for the R&D projects, right. Now, very important part for us is now to recognise that, that the scope variability is part of R&D projects is to first accept it, because once we accept it, then we can, you know, create a great solution. So, basically, when we say scope uncertainty is very high, which means that the initial baseline that we have set for the project, it will undergo a change. Okay. And which also implies that because of this high scope variability that the bottleneck resolution that I tried to do during pipelining, it’s a big suspect, because if the scope changes the so called levelling of the load that I have done, it might be wrong, okay.
So, also the other thing that has to be we have to be careful that you know, when we are talking about cutting things by half we don’t know what we are really cutting, right when we say we cutting things by half we are actually trying to kill the students syndrome and it’s a wasteful state. Now, we try to do that right in the planning phase itself when we try to cut the duration by half but when you don’t know what the entire scope of what you’re you don’t know what you’re really cutting and that really creates what we call as a you know procrustes syndrome, procrustes is if you know is a mythical bandit, who had you know a quarter of a particular size. So, every time he used to get a passer by in the in the in the jungle, where he used to you know, hide behind every time he saw a traveller he would capture him and and and try to fit him in the bed, if the person the the you know, the height of the person was lesser than the bed, he would stretch him out, right and then kill him by just stretching him out to meet the ends of the bed. And if the person happens to be taller, right, he will chop off the person to accommodate the bed. So, you know, this is a good metaphor for trying to understand what happens when we try to allocate tasks to you know, durations to tasks. So, either you will be too less which you know, your durations is too less, then you can have people chopping things off to show progress, right, which is bad, or that either duration is too high, you have the the impact of work expansion behaviour, which is called student syndrome, or, or the Parkinson’s effect, right. So, so that’s why the, the entire thing of trying to take a task and cut it by half, it doesn’t play a play out right. Because you don’t know what you are really really cutting. And so, basically, as I said the all this that we are trying to do trying to achieve during planning is trying to achieve a very high on time performance and hence the solution is very planning heavy. It’s very, very scheduling sensitive right? Now, if if you want to accept the fact that the initial plan made is going to be highly variable, then actually we end up questioning the very objective itself. That should on time, performance, be the objective of multi project environment right? So here, what I am proposing is because if you accept that scope variability is going to be going to be high and it is going to happen throughout the project. And it’s it’s very difficult to define where all it will it will hit you, it is better to set another assumption, which is not around due date, but the other assumption that we can other objective that we can put forward is the objective of lower lead time of all the projects, right the objective of now, CCPM implementation in R&D environment should be lower lead times for all the projects or in other ways we can say we want higher output of projects from a given set of resources. Now, when you give this as an objective, there are implications right? What are the implications? The first thing is, we now certainly are not so sensitive about how well we have, we have made a plan we are not sensitive about how well we have done the pipelining. But yes, we got to do everything possible to cut out the wastages of time and capacity that happens all the wasteful behaviour has to be cut out from the system. So the important point is that right now, we subordinate to the export resources, which is typically the the constraint in most of the R&D environments, you will have those 10-15 guys who are really the expert who everybody looks around for whenever there is a trouble. So look at those expert resources and say that these are the guys who will, who kind of control the the output of the of the system. So important is to ensure that these expert resources are not multitasking. Okay. And also to understand that since planning and scheduling is not going to take us anywhere, we have to give it up as a method to avoid multitasking, we can’t pipeline projects and ensure that the load is maintained. We can’t run a critical chain schedule which staggers the resources during the single project planning and expert multitasking to be to be to be cut off, what is really required is a WIP control system, or rule of one out versus one in that has to be done at a project level. And at times, not just at the project level, but at a task level as well. So those kind of rules are are very important. And if you see those are very execution driven rules that what happens in execution, we implement this kind of a pull solution to to control the, the bad multitasking, also it’s very important to understand that the the original plan that you did can change. So the longest path can also change, right? So when you have that, we now need to understand that the priority cannot be based on the buffer status, right? Because we don’t know what plan we have made, it can undergo a change. So we cannot take the buffer signals as as the as a real real signal . So Otherwise, we’ll end up making a mistake, whatever we thought, as the longest path right now. And if we decide to subordinate, we might end up and in hindsight, we found out that subordination decision was not correct. Right. So it’s very, very important that on the so called additional priority system around longest path, we need to be very careful for that, right. So it’s very important right that we use token systems for priority which means tokens of what is the number one priority, what is the number two priority, what is the number three priority, use the token system rather than the buffer signal as a way to decide priority of projects, okay. And and the token system is also inherited by by their tasks. And also very important to understand is that, you know, a lot of CCPM softwares, they try to optimise around the longest path. Now the longest path algorithm, right, that’s added algorithm that people try to build into create task level priorities as as different from project level priorities. Now, that’s, that’s a complication, which is not required, and at times, it can be damaging. So I just want to show you an example of how the longest path first algo can be devastating for a multi project environment. So let’s look at an example here. So let’s, let’s look at a project which has got three tasks here task A, B and C, |
| Shubham Agarwal : | I would request evryone to refer to the presentation attached in the link to understand what Satya is talking about. Satya you can continue
right and |
| Satyashri Mohanty : | we look at this lead time and we feel that we are not happy with this lead time A plus B plus C we are not happy with the lead time. So somebody closely examines the task A and finds out that actually task A can be split into task, A dash and A double dash. Now here the colour of the task represents what kind of resources are being used. So A requires blue resource B requires green and C requires the orange resource. Now, here so i found out that after you know innovating with with people that actually it is not that the task A has to be fully complete for task B to start, in fact, I can do a part of the task A, which is called task A prime, okay, and after that task B can start and A double dash is required when task C is initiated. So, wow based on this thinking I can actually in the planning stage, I can reduce the cycle time. That’s, that’s great, but very interesting to see here, that the resource here which is doing the the blue resource, which is doing the task A suddenly now has a window of opportunity, what is the window of opportunity after he completes task A dash, A prime should he continue to do A double dash? I think the answer is no, because it will be a waste of capacity, right? In a multi project environment he can afford to do to delay the start of A double prime, right. The way to do it is that this window of opportunity can be used actually to do another project. So, let’s see. So, this window of opportunity, which is you know, we’re getting a feeder path created. So, we have this window of opportunity, I can take up another A dash task of another similar project, which is project project two. So, all along the longest part of project two, I can pick up task A prime for project two as well. Now, look at this, what has happened when I stopped working from project one and shifted to project two okay. And I completed in that window of opportunity the task of project two, but what has happened is that the window of opportunity for project one that means the time available to come back to project one has reduced now, what do I do when I get project three, if the longest path first algorithm runs then actually project three also I should you know, take up the the longest path task which is again the task A if I keep on doing like that right if I keep on doing like that, you will find out that the yeah you if you keep on doing that, you will find out that you have delayed the the the project one basically suddenly this way of switching across longest path of many projects and opening many projects out can create an environment where you get into a complete desync right you you start you know getting into multitasking where everybody is kind of shouting because their feeder chains are are getting delayed, because you picked up the longest path and you left the feeder path of the first project. So, you went to the longest path of the second one, longest part of the third one, longest path of the fourth one and by the time the first one has become critical. So you you’re not coming back at the at the at the project the right time. So, this is what I wanted to show you the limitation of a longest path first algorithm in a multi project environment okay. So, so, if you see here, what we need to do here is get out of this so called task level priorities, focus on a project level priorities and have WIP controls, which is predominant way of controlling the execution and that is how we will control the multitasking. Now, so then it opens up a fundamental question then what is the role of planning what is planning meant for actually, the role of planning is to provide a good and a predictability of project completion date during the course of the execution at any point of time planning should be able to answer the question, okay, based on today’s information, tell us where this project will end at. Right. And that’s it, that’s the only role it is an good enough estimate at any point of time, when this project is going to get complete, it is not casting concrete, okay, it can be in a range for example, you know, we are trying to we are we are doing a currently a project with with a biosimilar where you know, durations can be as high as a biosimilar product and in pharma industry, the duration of new product development can be as high as you know, six, seven years. So, what do you mean by a due date performance? are we really talking about the date? Right? We can say, you know, around this quarter, we can and that’s that’s good enough for many environments in many environments is good enough to say, you know, my project is going to end somewhere around, you know, this this month, okay. This quarter, this month. It’s it’s, it’s it’s good enough, right? And that’s the estimation is required and it is an estimation the latest prediction, right? But it is not a commitment, it is not something that one should subordinate to, one should not just expedite or recover. buffer to meet that. Because once you do that, you set up a trigger of bad multitasking all throughout. Okay, so basically what we are saying is no single project expediting based on project buffer status. So what should project review then focus on because the baselines are now gone? Because the baseline keeps on changing, what should you focus when you’re looking at a project review. So basically, you’ve to be very careful when you’re doing a single project review, because a single project review can be a local optima, where you’re trying to expedite a project, so very important to look at is first is in the pipeline, where are my multi project cueing? Right? That’s that’s a very important question and try to see where i can resolve Where are my traffic jams like, like, when you open up the Google Maps, you’ve got to see where are those red points where, where jamming is happening, and and you resolve those jamming you help all the projects. Right? So that’s, that’s the first view, which is a project agnostic view. And you take a pipeline view. And the second, the view that you take for the project is about issue resolution, right? What is the current issue that is holding the progress of the project, right, you’re the you focus on resolving that. So you have all the processes, you have the full kitting, you have your daily management, you have the gate, the gates, the gate meetings, you have very good issue resolution. So what you get as a date from from the planning process is the latest estimate of how well you have done all these processes, right. And that’s, that’s the only thing that you can do, you can cut out the wastages you cannot cut out the touch time you cannot cut out the value adding rework it is you should not cut it out, right. So, what you can only do is cut down the wastages, right. So also very, very important to stop using fever charts and and because the fever chart can can create it is a very beautiful graphical interface. It’s a very good visualisation of the data. But it’s it’s I feel it’s it’s it’s damaging, when you try to use it for review meetings in R&D environment, it can trigger a lot of wrong actions. Right and and more important stop using colours for buffer status understanding for task priorities, use the token system. So basically, what we have done here is try to move a lot of the problem solving into the execution phase, if you see all the TOC solution solves part of the problem in planning, right and part of the problem in execution. So here we are trying to solve almost all the problems in in execution, the problems of the bad the wasteful behaviour, multitasking, or your student syndrome, you know, working without fullkits, all those things we are trying to solve in execution, what we are trying to do in planning is just trying to give a good enough predictability. And it’s a predictability as of now. Okay, and, and we give a predictability around a range of dates that this is the best we can do. Now, what happens is what we have seen in implementation is that once you do the implementation and do lot of improvement projects around the areas where you know, the maximum wasteful rework is happening, or around areas where you know, queuings are happening, you try to improve the predictability over a period of time. And what are the predictability that you improve to you improve it around a range, for example, a one year project, you can improve the predictability around, let’s say, you know, two, three months or on a multi year project, maybe improve predictability around around a quarter. And that’s what is this solution all about. Okay, and I think it is much, much simpler to implement, and it does not become a planning heavy solution, it becomes a execution heavy solution after doing this new approach. And our experience is almost every R&D environment, we are able to meet the objective of getting the output up, getting the lead times down, getting the chaos out of the system, getting the wasteful rework out of the out of the system. And we are improving the predictability over the period of time. So if you ask me, did you deliver all the projects as per the date? The answer is no. And I would like to say that that is not the failure because that was never the objective in the first place |
| Shubham Agarwal : | Thanks Satya |
Related Information
Get in touch
Vector Management Consulting Pvt. Ltd.
10th floor, Thane One, DIL Complex,
Ghodbunder Road, Majiwada,
Thane (West), Maharashtra - 400610, India.