So as far as the input is concerned to this process or
this technique, it's the deliverables of the previous phase.
And then, maybe some plan for the next phase.
So the deliverables and all those things getting to the gate.
And then you have something called a criteria,
which is basically the questions or the metrics on which the project is judged.
So based on, the organization will set this criteria, so
that when a project goes to a gate check, they know what to expect.
And then, so that the criteria is applied, and
at the end of the gate, processed, or the gate checked or the stage gates.
You get the results of the gate review process, which could be a decision.
So whether to continue to go ahead or to kill the project.
Or to hold the project, which might be due to the funds or, maybe,
something else came up, which is higher priority.
So the committee or the organization may say that well, this is a good idea.
But we want to hold onto it right now.
Or it might be recycled, the idea that it might be moved or
merged with another project.
Or it might start a new project with a totally different view or
perspective, and so you might be recycling the idea.
Another thing that you get out of the gate process is approved action plan for
the next gate.
So during the gate process, they also review what is your next plan, and so
they approve it.
And then the last thing is, the list of deliverables and date for the next gate.
So what will be done in the next phase, and then, what will be the date for it?
So those are the gate structure and elements.
And so let's take an example, like how you could apply this phase gate or
stage gate concept in some of the models that we have learned.
Let's take a look at waterfalls.
So in waterfall model, you might be, and again like I said,
every organization will do it differently.
But, in this example, we might replace this.
So going from requirement to design, you might put a gate in between those two
to say whether after requirements we're going to check.
Come together as a team, review and see if we want to continue.
Similarly, after design, you might learn a lot of things.
So it might make sense to put another gate right there and
say do we really continue although we have invested so much?
But do we continue with the development and the testing and so on?
Or you might do, after testing, is it ready for deployment?
Then you could do another test after that based on the results,
does it really make sense to continue?
But like I said, any organization will customize it to their needs.
If you look at the incremental model,
one of the variations of the incremental model.
Again, you can just replace this with the gates.
You can replace between design and implementation with a gate.
And then, after every increment,
you could probably potentially put a stage gate there.
That should we continue with the next increment or did we achieve our goal?
Should we stop, and so on.
So you can apply these gates at different places.
If you look at the unified process that has, almost, I would say,
an inbuilt gate check after every iteration.
So after inception, you can do it then after every iteration of the elaboration,
you can do a stage check or get check.
And then similarly you can do, after each of these iterations.
And so, it's pretty straightforward in terms of applying this technique to
unified process.
And then if you look at the spiral, the step four has the inbuilt feature,
or you can say, expectation, to check whether to continue the next cycle or not.
So it has this inbuilt check of the project that's due.
Is it still in the business case, should we continue or not?