How do you know the solution your project built actually works before you hand it over and walk away? That is the problem that solution evaluation and business analysis close solve for CAPM candidates — they give you a structured way to check the result is fit for purpose, document what was delivered, and smoothly transition everything into day-to-day operations.
Jump to a section
A simple way to picture Solution Evaluation and Business Analysis Close
A new kitchen renovation is finished. The cabinets are installed, the granite counters are sealed, and the tap works. But before you sign the final cheque and hand over the keys to your family, you walk through every inch with the contractor and a clipboard.
You open every drawer. You run the dishwasher through a cycle. You check that the oven reaches exactly 200 degrees C. This is solution evaluation — you are confirming the finished kitchen meets the requirements you wrote down months ago. You test the acceptance criteria: does the island have enough electrical outlets? Does the bin drawer open fully without hitting the pipes?
Then you schedule the handover. You teach your partner which switch controls the under-cabinet lights. You leave the instruction manuals in a drawer. You take the contractor's final invoice and file it away. That is the business analysis close — transitioning the solution to the people who will live with it every day, closing out the paperwork, and locking the project file.
If you skipped this walkthrough, you might discover six months later that the waste disposal unit was installed backwards and your warranty has expired. The evaluation and close steps prevent that regret.
Any project, whether you are building a mobile app or updating a payroll process, ends with two critical activities that beginners often confuse: solution evaluation and business analysis close. They happen at the tail end of the project life cycle, but they serve different purposes.
Solution evaluation is the process of checking whether the delivered solution meets the business requirements and acceptance criteria that were defined at the start. Acceptance criteria are the specific, measurable conditions that must be true for the stakeholders to accept the product. For example, if a bank asked for a new loan approval system, a criterion might be: the system must return a decision within 60 seconds for standard applications. During evaluation, the business analyst or project manager runs tests, performs walkthroughs, and measures performance against these criteria. If something falls short, they document the gap and decide whether to fix it, adjust the criteria, or accept a minor deviation.
The evaluation also checks against the business case — the original justification for the project. Did the solution actually deliver the expected return on investment? Did it solve the problem it was supposed to? This prevents the embarrassing situation where a team delivers something technically perfect that nobody actually wants to use.
Business analysis close, meanwhile, is the administrative and transitional wrap-up. Once the solution is accepted, the business analyst ensures that all project documentation is completed, organised, and stored in a central repository — requirements documents, test results, user manuals, and decision logs. They also hand over the solution to the operations team or the end users who will run it day to day. This transition includes training, creating handover documents, and clarifying who is responsible for ongoing support.
Another key piece of close is the lessons learned session. The team reflects on what went well, what went wrong, and what they would do differently next time. These insights are captured formally so that future projects in the organisation can benefit.
A common IT example: a company builds a new customer relationship management (CRM) system. During solution evaluation, the business analyst checks whether the CRM actually tracks leads from the moment they enter the website funnel. Acceptance criteria might include: the lead status must update automatically when a sales rep sends a quote. If it works, the solution is accepted. During close, the analyst hands over the CRM admin manual, trains the sales team on how to run weekly reports, and stores the requirements document in the company's shared drive. They also lead a lessons learned meeting where the development team admits they underestimated how long data migration would take.
Why does this matter for the CAPM exam? The exam tests your ability to distinguish between evaluation activities (testing, validating, measuring) and close activities (handover, documentation, archiving). It also tests your understanding of acceptance criteria as the yardstick against which success is measured. You will see questions that describe a scenario and ask: is the Business Analyst performing evaluation or close? Or: which document defines the conditions for acceptance?
Remember that evaluation happens before the solution is formally accepted, and close happens after acceptance. Evaluation is about verifying quality; close is about finishing the paperwork and handing off responsibility. If you keep that distinction clear, you will handle the exam questions confidently.
Define Acceptance Criteria
Before development starts, the business analyst works with stakeholders to define specific, measurable conditions that the solution must meet to be accepted. This step sets the yardstick for later evaluation and prevents subjective 'I don't like it' rejections.
Conduct Solution Evaluation
After the solution is built, the business analyst tests or walks through the deliverables against the acceptance criteria. They document any gaps or defects and work with the team to fix them until all criteria are met.
Obtain Formal Acceptance
Once all acceptance criteria are satisfied, the business analyst gets stakeholders to sign a formal acceptance document. This sign-off confirms the solution is ready for handover and triggers the close process.
Transition the Solution
The business analyst creates handover materials such as user manuals, admin guides, and training plans. They train end users and operations staff, and transfer responsibility for ongoing support to the appropriate team.
Archive Business Analysis Artifacts
All project documentation — requirements, test results, acceptance forms, and handover records — is organised and stored in a central repository for future reference and audits.
Capture Lessons Learned
The business analyst facilitates a session where the team reflects on what worked well and what could be improved. These insights are documented and added to the organisation's knowledge base to benefit future projects.
Sofia is a business analyst at a mid-sized insurance company. Her latest project is a new online claims portal where customers can upload photos of damage and track their claim status. The project team just finished coding and testing. Now it is Sofia's job to evaluate the solution and close out the business analysis work.
Step one: Sofia reviews the acceptance criteria that were documented during the requirements phase. She pulls up the original list and sees criteria like: the portal must load in under three seconds on a standard mobile connection; customers must be able to upload up to ten photos at once; and the claim status must update within one hour of a decision.
Step two: She schedules a walkthrough with three stakeholders — a claims adjuster, a customer service manager, and an IT support lead. Together, they run through each scenario. The adjuster tries submitting a mock claim with ten photos. The portal freezes on photo number eight. That is a failed acceptance criterion. Sofia logs the issue and the development team agrees to fix it by optimising the image compression.
Step three: After the fix is deployed, Sofia re-runs the test. This time, ten photos upload in under three seconds. All acceptance criteria are now met. The stakeholders sign off on the solution acceptance form.
Step four: Sofia begins the close process. She writes a handover document that lists the system's login URLs, admin credentials (which she changes before sharing), and the schedule for nightly data backups. She also creates a one-page quick reference guide for the customer service team showing how to manually adjust a claim if the portal glitches.
Step five: She organises all project files — the requirements document, the test results, the signed acceptance form, and the lessons learned notes — into a folder on the company's shared drive. She emails the operations team the final handover package and schedules a 30-minute training session for next Tuesday.
Step six: Sofia leads the lessons learned meeting. One insight the team captures: next time, they should involve the customer service manager earlier in testing, because she spotted a confusing user interface element that nobody else noticed. That insight goes into the organisation's continuous improvement database.
At this point, Sofia's work on the project is done. She can move on to the next initiative knowing that the claims portal is running smoothly and the operations team is equipped to support it. That is the real-world value of evaluation and close — it prevents chaos at handover and ensures the project's benefits are actually realised.
The CAPM exam tests solution evaluation and business analysis close in the context of the business analysis domain under the 'Planning' and 'Monitoring and Controlling' process groups. You can expect roughly three to five questions on this topic. Here is exactly what the examiners want you to know.
First, know the definition of acceptance criteria cold. Acceptance criteria are the pre-defined, measurable conditions that must be met for a solution to be considered acceptable by the stakeholders. The exam loves to present a question where a stakeholder says 'the system is too slow' and asks what was missing. The answer is clear acceptance criteria defined before development started.
Second, distinguish between solution evaluation and business analysis close. Evaluation involves verifying the solution against requirements and measuring performance. Close involves handing over deliverables, archiving documents, and capturing lessons learned. A typical trap question describes someone training end users and asks what activity this is. Training is part of transition, which is a close activity, not evaluation.
Third, know the outputs of these activities. The key outputs of evaluation are validated requirements, an accepted solution, and a list of defects or issues. The key outputs of close are the handover plan, the project files, and the lessons learned documentation.
Fourth, understand that evaluation can happen in increments. In agile projects, evaluation happens at the end of every iteration, not just at the very end of the project. The CAPM may test that the concept of evaluation is the same regardless of the life cycle — you always check against criteria.
Fifth, be aware of the relationship between the business case and evaluation. Evaluation should confirm that the solution delivers the benefits stated in the business case. If a question describes a project that met all technical requirements but the company lost money, the correct answer might be that the evaluation should have revisited the business case assumptions.
Trap patterns to watch:
The question gives a list of activities (testing, training, writing manuals, archiving files) and asks which belongs to evaluation vs. close. The trick is that training and archiving are close; testing is evaluation.
The question describes a scenario where acceptance criteria were never defined. The correct answer is always that the business analyst should have defined acceptance criteria during the requirements phase.
The question asks who is responsible for solution evaluation. The answer is the business analyst, but the project manager also participates. The CAPM expects you to know the business analyst leads this work.
Key definitions to memorise for the exam:
Acceptance criteria: measurable conditions that must be met for solution acceptance.
Business analysis close: the process of finalising and archiving business analysis work and transitioning the solution.
Solution evaluation: the process of assessing the performance of a solution against defined requirements.
Transition: the handover of the solution to the operations or support team.
Lessons learned: documented knowledge gained from the project for future improvement.
Solution evaluation verifies the delivered solution against pre-defined acceptance criteria to confirm it meets business needs.
Business analysis close involves transitioning the solution to operations, archiving project documents, and capturing lessons learned.
Acceptance criteria must be measurable and agreed upon by stakeholders before development begins, not after the solution is built.
Evaluation happens before formal acceptance; close happens after acceptance and involves handover and documentation.
Lessons learned are a mandatory output of business analysis close that capture insights for future project improvement.
The business analyst leads solution evaluation and close activities, though the project manager oversees the overall project closure.
These come up on the exam all the time. Here's how to tell them apart.
Solution Evaluation
Focuses on verifying the solution against requirements and acceptance criteria
Involves testing, walkthroughs, and measuring performance
Happens before formal acceptance of the solution
Business Analysis Close
Focuses on handover to operations and archiving project documents
Involves training users, creating manuals, and lessons learned
Happens after formal acceptance of the solution
Acceptance Criteria
Specific, measurable conditions for accepting the solution
Defined before development starts to guide testing
Example: the system must process 100 transactions per minute
Business Requirements
High-level statements of what the business needs from the project
Broader in scope, may include goals and constraints
Example: the system must improve customer satisfaction
Verification
Did we build the product right?
Checks the solution against specifications and design
Often done through testing and inspections
Validation
Did we build the right product?
Checks the solution against the business need and stakeholder expectations
Often done through demonstrations and stakeholder reviews
Lessons Learned
Captures what went well and what could be improved for future projects
Created at the end of the project during close
Stored in the organisational knowledge base
Project Status Report
Reports current progress against plan
Created regularly throughout the project
Shared with stakeholders to track performance
Mistake
Solution evaluation and business analysis close are the same thing — they both happen at the end of the project.
Correct
They are different processes. Evaluation checks if the solution works against requirements. Close is the administrative wrap-up and handover to operations.
Beginners see both happening at the end and assume they are synonyms, but the CAPM exam specifically tests the differences.
Mistake
Acceptance criteria are just nice-to-have wish lists that stakeholders can change after the solution is built.
Correct
Acceptance criteria are formally documented, measurable conditions agreed upon before development starts. Changing them after the solution is built causes scope creep and requires formal change control.
In real life, stakeholders often try to add last-minute demands, so beginners think that is normal process. The CAPM teaches a disciplined approach to prevent that.
Mistake
The project manager is solely responsible for solution evaluation and close.
Correct
The business analyst leads the evaluation and close activities for the business analysis work. The project manager oversees the overall project close, but the BA own the requirements validation and handover.
Project management and business analysis roles blur in small organisations, so beginners assume the PM does everything. The CAPM clearly separates these responsibilities.
Mistake
Lessons learned are optional and only done if there is time at the end.
Correct
Lessons learned are a mandatory part of business analysis close. They capture valuable knowledge to improve future projects and are formally documented and stored.
Many real projects skip this step due to time pressure, so beginners think it is optional. The CAPM treats it as a required output.
Mistake
If the solution passes all tests, evaluation is complete and no further documentation is needed.
Correct
Even after passing tests, the business analyst must still perform close activities: signing off acceptance, creating handover materials, training users, and archiving documents.
People equate 'it works' with 'done'. But in IT projects, failing to close out properly leads to operational chaos — no one knows how to support the system or where to find the manuals.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Without pre-defined acceptance criteria, stakeholders can reject the solution based on subjective opinions, leading to endless rework. The business analyst should define measurable criteria during requirements gathering to give the team a clear target.
Yes, especially in agile projects. Evaluation can occur at the end of each iteration or sprint, where features are tested against criteria incrementally. In waterfall projects, it typically happens once near the end.
The key stakeholders or the product owner — the person or group who represents the business and authorised the project. The business analyst and project manager usually facilitate the sign-off.
Verification checks that the solution was built correctly according to specifications (e.g., does the button work?). Validation checks that the right solution was built for the business need (e.g., does the button solve the customer's problem?). Both are part of evaluation.
It varies depending on the project complexity. For a small project, close might take a few days. For a large system with many users, transition and training could take weeks. The key is it is planned, not rushed.
The business analyst documents the gaps and works with the project team to fix them. If the criteria cannot be met, the stakeholders may agree to accept a deviation through formal change control, or the project may need to extend its schedule.
You've finished Solution Evaluation and Business Analysis Close. Continue through the CAPM study guide to build a complete picture of the exam.
Done with this chapter?