Go/No-Go Decisions in Business Analysis and Project Management

Like This Blog 0

Added by Steve Fullmer March 4, 2019

This post if from our PMI-PBA Business Analysis Certification course. Start training today!

Go/No-Go decisions is an important consideration for a Business Analysts. It can happen in any project life cycle, but more likely, it’s going to happen in a project life cycle that’s predictive, or one where there are incremental phases or stages.

We’re talking a more formal approach to this concept to verify the work and then validate or confirm that we’ve got value to it.

What we’re trying to do is make the decision of whether we’re going to simply go ahead and verify.

If we go past verify to validate, that’s a no‑go.

If there’s any reason to pause, recheck, or to re‑verify, that would be a no‑go decision. No‑go is not an absolute, it’s a transition point.

For those of you who are familiar with the space program, it’s like that countdown before launch, “Do we push the final lift or go button?” You’re checking with everybody, “Is all the work correct? Is it ready? Do we verify that we should be able to go?”

If you’ve got a project that’s in cascade, (predictive), or one that’s incremental, (stages or phases), very often a phase gate would be a Go/No-Go decision. It might be at the end of a phase that is complete and ready to be passed on to another team, or it might be paused for some reason until we resume and take off with the next part.

That’s the concept of Go/No-Go. It’s not just about yes/no. It’s about verify/validate. We don’t validate until after the go, so it’s not validate first. It’s, “we’re going to go show it to the customer.”

It’s that last check by the maître d’ or the head chef for all the food that’s being picked up and brought out right to the customers. Make sure the presentation is right, not just the flavor, that the hot food is hot, the cold food is cold. Everything is served at the right temperature, that champagne is just right before we pop the cork and have someone taste it, serve it, etc.

The determining factors that control whether we’re going to do the Go/No-Go are:

Go/No-Go Drivers

• Type of Project
• Type of Product
• Project Lifecycle
• Corporate Constraints
• Regulations

Go/No-Go Decisions are a formal check. Many projects have informal checks all throughout them, but go no-go decisions are a formal check.

Type of Project

Clearly, within the type of project, you can have a Go/No-Go decision for release or a cut to production for a full project in Agile, so you could have formal. More likely for predictive, more likely for my essentially incremental, but it doesn’t have to be.

The role of the Business Analyst in an Agile project (Adaptive/Agile) tends to be informal, which means the team is making decisions for what work they’re doing. The team is saying, “Hey, we believe that this is packaged… This feature is complete… We’re ready to release to the customer.”

If you put a formal review, or a formal retrospective of what’s learned before you show it to the customer, you’ve added a formal Go/No-Go step into an otherwise informal project life cycle like Agile.

Type of Product:

The type of product that you’re looking at is a very clear indicator. If the product needs to be of high quality. There are the possibilities of including nonfunctional features, and there’s a possibility that the customer, will not pay at all and will just say, “Done. Forget it,” then you certainly want to check before you go for customer validation.

Any time you’ve got high risk, high complexity, it leads us back to the predictive or incremental kind of project, but if the product itself has those characteristics even (even in an Agile approach) these are reasons for Go/No-Go formal approach.

Project Lifecycle:

The project lifecycle is another element that we add to the project and the product together. Project Lifecycle feeds back into both predictive and incremental types of projects. (For those seeking PMI-PBA Certifications, this could be on the PMI‑PBA exam. Not that they just talk about the project, just about the product, but also the life cycle.) It can include all three, Project, Product and Lifecycle.

Corporate Constraints:

You may have corporate constraints. What we mean by that is, policies, or business regulations, or rules suggest that formal review, formal sign‑off, formal acceptance by different teams is ready before we go to final presentation.

Regulations:

Finally, often, external regulations will guide that you do not sign off until you dot all the (i’s) and cross all the (t’s) and make sure that you’re prepared for a formal review.

Go/No-Go Tools:

RACI Diagram

A couple more elements to consider with Go/No-Go decisions, beyond the drivers, and not just this concept of verify/validate but the tools we might consider as a Business Analyst. This can be a great time to go back and look at your RACI (Responsible, Accountable, Consulted and Informed) Diagram when we talk about Go/No-Go to find out who is involved in the decision.

Accountable:

Somebody is accountable for this particular component, whether it’s a component or the entire deliverable that’s supposed to be checked, typically the Project Managers is accountable for integration of a full project and therefore the product being delivered to it, but you could have a RACI diagram that’s different.

Consulted:

You could have Go/No-Go decisions for a Business Analysis RACI Diagram that you oversee as a Business Analyst, or it could be the Project Manager, but remember, C’s with whom we consult to get input before you make a Go/No-Go.

Particularly in the space program, there’s all those people you’re checking with, “What’s the fuel levels? What’s the power levels? What’s the quality of the astronauts’ breathing and heart rates?” All those different things you check on, you’re consulting.

Inform:

Maybe before you make the decision, it’s important that you inform somebody.

It’s really common because we say formality is important here (formal). We might go back to the same group or individual that we did an interview when we started the whole effort. That stakeholder, customer, sponsor, or the person that makes the decision will ultimately sign on. Maybe we do a similar interview process where we’re asking for their readiness to confirm that whatever their acceptance criteria were met. We’re visiting with them.

Often, in projects, there’s a formal meeting between the customer and that project manager, where they’re going to get formal sign‑off. You might want to be helping that project manager with the Go/No-Go in terms of formal preparation.

Meetings (Focus Group):

Another concept that might be there is the focus group which are subject matter experts by invitation. You might want to get together a numerous subject matter experts in a focus group. The focus group is not about elicitation any more. It’s about confirming that these experts have reviewed all of the elements, and they’re the ones signing off on the Go/No-Go decision before you look for formal sign‑off and acceptance.

Go/No-Go decisions are a formal, crossover from verify to validate to utilize all of your skills, tools and resources as a Business Analyst before making this recommendation.

I look forward to seeing you in the classroom or online!

Steven Fullmer
Interface Technical Training Staff Instructor

Steve teaches PMI-PBA: Business Analysis Certification,  PMP: Project Management Fundamentals and Professional Certification, Windows 10, and CompTIA classes in Phoenix, Arizona.

Steve’s Video Certification Training Classes at Interface Technical Training:

Project Management Professional (PMP®) Certification Video Training PMBOK® 6th Edition

PMI-PBA Business Analysis for IT Analysts and Project Managers (PMI-PBA)® Certification