How to Review This Year’s Work and Decide Which Projects to Add Next Year

Start With Something You Finished

You’re putting together next year’s plan, and the requests are already arriving. A department wants a new reporting tool. Someone has an idea for a customer portal. A project that missed this year’s budget is back on the list.

Before you start comparing them, choose something your team completed this year. Look at what became easier after it launched.

You may have a clear answer. A task that used to require three people now needs one, or a customer can complete something online without calling for help. You may also hear that the project launched successfully but still needs a spreadsheet or an extra review to make it work.

Those answers can tell you where to look next. They can also keep you from approving a new project to solve a problem you have already paid to address.

You don’t need to reopen every decision or investigate every deliverable. A small number of thoughtful reviews can give you a much stronger basis for planning. Start with work that has been in use long enough for someone to describe what changed.

Choose a Few Projects That Can Teach You Something

If your review becomes a catalogue of everything your team delivered, you can spend weeks assembling information without learning much. Choose projects that connect to the decisions you need to make for next year.

Include something that appears to have worked well. You want to understand what made it useful and whether that success could support another improvement. Also consider a project that continues to generate questions or requests for help.

A third choice might be a project related to a significant proposal for 2027. If you are considering expanding a platform, review the part already in use. You will have a better starting point than a demonstration of what the next phase could do.

Be realistic about how much experience you have to evaluate. A process introduced last week has not had the same opportunity to prove itself as one used since March. An annual task may have run only once. Record those limits so an early impression does not become a firm conclusion.

For each selected project, identify someone responsible for the outcome and someone who uses the result. They may be different people, and both perspectives matter. The person who approved the investment can explain its purpose; the person doing the work can show you how it performs.

Recover the Problem You Were Trying to Solve

Open the original brief, proposal, or planning notes. Look for the reason the project mattered before the conversation turned into features and deadlines.

Suppose you introduced a shared intake form for internal requests. The goal was to reduce the back-and-forth needed before work could begin. Completing and publishing the form was a delivery milestone. The result you wanted was a request arriving with enough information for someone to act.

That distinction gives your review a useful direction. You can examine whether requests are easier to understand, whether they reach the right person, and whether clarification still delays the start of work.

Sometimes the original goal will be vague. You may find a phrase such as improving efficiency without a baseline or an agreed measure. Acknowledge the gap and ask the people involved what difficulty they expected the project to address. You can establish a clearer question now without pretending it was documented at the beginning.

Also check whether the circumstances changed. A process designed for a smaller team may now serve a different set of responsibilities. Understanding that change helps you evaluate the original work fairly and decide what the next version needs to accomplish.

Ask Someone to Show You a Recent Task

A general question about whether a project was successful can produce a general answer. Ask someone to walk you through the last time they used what you delivered.

With the intake form, follow one recent request from submission to the point where work began. Look at what the person received, what they needed to clarify, and how they decided where the request belonged. You are trying to see the experience closely enough to understand it.

You might discover that the form collects all the required fields but leaves the purpose unclear. A requester selects a department and enters a deadline, yet the receiving team still needs a conversation about the outcome. The form works as designed, while the original delay remains.

You might find the opposite. The new process could be saving time consistently, with the occasional exception receiving more attention simply because it is frustrating. Looking at several representative tasks helps you avoid letting one memorable incident define the entire review.

In The Workarounds Your Team Invents Can Show You What to Improve Next, I wrote about learning from the steps someone adds around an official process. Those steps can be particularly revealing during a project review. If someone still keeps a separate list, find out what it provides before deciding whether the project needs another feature.

If two people describe the same result differently, explore the difference before settling on a recommendation. One may be measuring speed while the other is dealing with accuracy. You may need both perspectives to understand whether the project improved the whole task or moved the difficulty somewhere else.

Make the conversation comfortable enough for an honest answer. Explain that you want to understand what would help next. Someone should be able to describe a difficulty without feeling they are criticizing the colleague who built the solution.

Compare Results With the Effort Behind Them

Once you understand the task, look for evidence of what improved. Use information that relates to the original problem rather than collecting every available statistic.

For the intake process, you could compare the amount of clarification needed before work begins. You might examine the time between a request arriving and being ready for assignment. Choose a measure that helps you judge whether the project made the process more useful.

If you have comparable information from before launch, use it carefully. A quieter period, different request types, or a staffing change could affect the result. You can still learn from the comparison while acknowledging what else may have contributed.

If no baseline exists, say so. Recent examples, support records, and accounts from the people doing the work can help you understand the current situation. They may support a sensible next step without supporting a precise claim about time saved.

Include the effort needed to keep the improvement working. Your new report may save a manager time while requiring an analyst to clean up data every Friday. That could still be worthwhile, but you need to see both sides before deciding to expand it.

This is also where you should recognize a project that is quietly doing its job. A dependable process may attract few comments because people can complete their work without thinking about the system behind it. Give that result credit, including the ongoing care that keeps it dependable.

Decide What Kind of Follow-Up the Evidence Supports

Your review may reveal unfinished work, but that does not automatically justify another project. First, identify what is preventing the outcome you wanted.

If people cannot find the new process or do not understand when to use it, you may need clearer guidance and support. If the process creates a recurring obstacle for an experienced user, you may need to change the design. If the original need has disappeared, additional development may offer little benefit.

Return to the intake example. You could add more required fields, but that may simply make the form harder to complete. A better next step might be a clearer question about the requested outcome, with an example of the information the receiving team needs.

Try the smallest useful change when the evidence supports it. You can learn whether a revised question reduces clarification before approving a broader redesign. That gives you a way to act on the review without making every finding a major commitment.

Some findings will justify substantial work. You may learn that the process cannot support an important type of request or depends on a connection that does not exist. Describe that limitation clearly so you can compare the proposed solution with other priorities.

Give Successful Work a Chance to Go Further

You should also ask what a successful project has made possible. The next opportunity may come from extending something your team already understands.

Perhaps one department now handles requests more effectively, and another department has a similar need. You could explore whether the same approach would help, using what you have learned about the first implementation.

Check the differences before assuming you can copy it. The second department may have different approval requirements or receive requests from outside the organization. What worked well in one setting provides evidence to investigate, along with questions you still need to answer.

You may also decide the successful project is complete enough. Give it appropriate maintenance and let it continue delivering value. You don’t have to attach another phase to every good result to show progress.