One of the most important parts of project management happens before a project exists. Before there is a project plan, a timeline, a budget, a backlog, or a steering committee that consumes everyone’s Tuesday afternoon, someone has to decide whether the work should happen in the first place.
That decision matters because every project that gets approved consumes capacity. It uses people, attention, money, and organizational energy. Even a small project has a way of creating meetings, follow-ups, status reports, support needs, and more than just a few spreadsheets.
This is why project selection needs more discipline than many organizations give it.
In a lot of companies, projects get approved because someone influential asked for them, because a department has a pain point, or because the idea sounds reasonable in isolation. The problem is that almost every idea sounds reasonable in isolation. But when reasonable ideas begin competing for the same limited resources, some of them need to be rejected, and others need to be chosen with confidence.
A good decision should survive the meeting where it was made. If people leave the meeting questioning the decision, or wishing that decision hadn’t been made, you may need to rethink your decision process. That means the decision needs to be clear enough that people understand why it was made, what it depends on, who owns it, and what would cause it to be revisited. They also need to be in full-alignment that everyone agrees on the goals. Otherwise, the decision will quietly dissolve the first time someone asks a hard question.
There are established frameworks that help with this. Bain’s RAPID framework is one of the better-known approaches. It clarifies who recommends a decision, who provides input, who must agree, who decides, and who performs the work once the decision is made. That kind of role clarity is valuable because many decisions fail simply because nobody knows who actually has the authority to make them.
There are some challenges to this framework. The idea of “agree” winds up with too many people that need to agree, and a need for a veto, which undoes the purpose of agreeing. Sometimes the decision doesn’t actually stick, particulaly if “agree” never happened unanimously. Inputs can often clutter decisions, and people who need to agree don’t understand what they’re agreeing to.
Personally, I prefer a more streamlined approach using a system I’ve titled, aptly, “STREAM.” This process has six steps—a little longer than RAPID, but more precise because only the first three are the decision-stage:
- Screen. Start by screening the idea. Ask three questions: Ask: Does the idea solve a critical problem, or fulfill a need? Will the project deliver clear, measurable benefits within a defined time frame? Can the project’s success be replicated or scaled to enhance value or impact over time? If any one of these passes, this is probably worth assessing further.
- Verify the screening with a final question: is the sponsor willing to do the work to gather objective data?
- Test. Then, assess it using SMART criteria. Is this idea specific, measurable, actionable, realistic, and time-bound? This criteria should ultimately lead to a one-page project summary or strategic business case that can be reviewed by an approval team.
- Verify the test by asking, “is this project worth it?”
- Review. Confirm that your project aligns with your company’s Strategy and Operations, and that it is both Feasible and Financially worthwhile. Combined with a one-page summary, your change advisory board or a similar decision-making team (like RAPID’s Agree and Decide roles) can make a quick assessment of where something sits in operations.
- Using these four categories, and validation criteria within each, you can determine the priority of this project relative to other projects.
- Note: This is the part where the decision is made. Screen, Test, and Review are the decision.
- Equip. Identify the project’s sponsor or primary stakeholder(s), assign a project manager, and identify the subject matter experts (SMEs).
- Verify that these are the people necessary to make the project happen.
- Arrange. This is where you define the actual deliverables, timeline, risk management expectations, and mitigation strategies.
- You’re ready to go if you can plan the work, and then work the plan.
- Mobilize. Now get the team ready to implement.
The questions in the first two steps are intentionally simplified because the purpose is not to create a complicated intake process. The purpose is to prevent vague ideas from becoming official work before anyone has tested whether they deserve to be there.
Of special note here: if your company is relatively small, it’s common for the “go / no-go” decision to be made by a single person, usually the CEO or company owner. The purpose of Screening is to provide an objective assessment that “sniffs out” the bad ideas before engaging too many people. The Testing process provides multiple layers of objective assessment including documentation to back a claim before a final decision is made.
The Review phase is an amazing phase, because it determines when the project will be done, using objective criteria that weighs it neutrally against other projects. It’s wonderful to have a hundred ideas, but you can’t implement a hundred projects at the same time. Having a priority framework ensures that you don’t get locked into do everything all at once. Most of the time, approving new work means something else will move slower, receive less attention, or be postponed entirely. That is not a bad thing. It is simply the cost of making a real decision.
A decision starts to stick when people understand the trade-offs. If a project is approved but nobody knows what it displaces, the organization has not really prioritized. It has added work to the pile and hoped the pile would somehow become more organized through enthusiasm and pizza lunches. Pro tip: it won’t. I have yet to see enthusiasm produce a reliable resource plan, although it does make for a lively kickoff meeting.
Once the decision is made, it should be recorded in simple language. The record does not need to be elaborate. It should identify the outcome, the reason, the owner, the expected benefit, and the trade-off that was accepted. That gives the organization something to return to when the project is questioned later. This can all be recorded on a one-page summary.
This is important because every meaningful project will eventually be questioned. Priorities shift, costs increase, people become unavailable, new opportunities appear, and so on. When that happens, a well-documented decision gives leaders a way to evaluate whether the project still belongs on the list. Further, by maintaining a list of prioritized projects and ideas, you can quickly refer to where, in sequence, a project exists, which can help to defer questions for projects that are still a long way off.
Without that record, the organization ends up relitigating the same decision repeatedly. Making decisions that stick does not mean refusing to change your mind. Sometimes a decision should be revisited because the facts have changed. Having the same categories (strategic alignment, operational alignment, feasibility, financial viability) and the same criteria per category means that a reassessment when conditions change only requires a few numbers to be updated, and the priority reassesses itself. At least this way, everyone sees the same thing at the same time, and agrees to the change impacts.
This ensures the project can move forward with something far more useful than enthusiasm.
It can move forward with permission, purpose, and a reason to exist.