How to Write Chapter 5 (Summary, Conclusions, Recommendations) for Capstone Project — With Examples

How to write Chapter 5 capstone is often seen as the easiest chapter to write—and the easiest one to write badly. It consists of three short sections: Summary of Findings, Conclusions, and Recommendations, which together usually run 1,500 to 2,000 words.

Many students notice the small word count, copy a generic conclusion template from Scribd, swap in their system name, and submit. The adviser writes “this could be any capstone” in red ink and sends it back.

Generic Chapter 5s are the most common reason a defense gets stretched into a second meeting. The panel reads Chapter 5 first when they grade — it’s the shortcut to “did this student actually understand their own project?”

If your conclusions don’t map cleanly to the objectives in Chapter 1 and the results in Chapter 4, the panel knows in 90 seconds and the rest of the defense gets harder.

This guide walks through the three required subsections, the optional fourth (Implications, when your school requires it), and the panel-defense logic behind each. By the time you finish reading, you should be able to draft Chapter 5 in one focused 3-4 hour sitting.

Part of our complete capstone documentation series:

• Chapter 1: Introduction
• Chapter 2: Review of Related Literature (RRL)
• Chapter 3: Methodology
• Chapter 4: Results and Implementation
• Chapter 5: Summary, Conclusions, and Recommendations (you are here)
• Full Chapter 1-5 Template (Free Download)

About the running example. Throughout this guide, we use the same Barangay Information System example used in Chapters 1 through 4. Your system might be a Library Management System, Hospital Management System, Inventory Tracker, AI Chatbot, or anything else — the Chapter 5 structure transfers, only the specifics change.

What Chapter 5 actually does

Three things every Chapter 5 must accomplish:

Closes the loop on Chapter 1. Every objective stated in Chapter 1 must have a corresponding conclusion in Chapter 5. If Chapter 1 had six specific objectives, Chapter 5 must have six conclusions. Not five. Not seven. Six.

Summarizes the Chapter 4 results without repeating them. The Summary of Findings section condenses what the numbers showed. The full numbers stay in Chapter 4. Chapter 5 says “the system reduced certificate processing time by 99.6%,” not “the system reduced certificate processing time from 2,880 minutes to 12 minutes, with a standard deviation of 4.2 minutes across 12 measured certificates.”

Tells specific people what to do next. Recommendations aren’t “this study suggests the system should be improved.” Recommendations name the audience — the Barangay Captain, future BSIT researchers, the Department of the Interior and Local Government — and tell them specifically what action to take.

If Chapter 5 only summarizes (skipping the recommendations), it gets sent back. If the conclusions don’t map to Chapter 1 objectives, it gets sent back. Panels grade Chapter 5 against all three checks.

The 3 (sometimes 4) standard subsections of Chapter 5

Most Philippine BSIT and BSCS templates use a 3-section structure. Some programs add a fourth Implications section. Check your school template first — the names below match the most common templates:

1. 5.1 Summary of Findings — what the results showed (~350 words)
2. 5.2 Conclusions — what those findings mean, mapped to Chapter 1 objectives (~350 words)
3. 5.3 Recommendations — what specific people should do next (~400 words)
4. 5.4 Implications (optional, school-dependent) — broader significance beyond your project (~200 words)

Target total: ~1,500 to 2,000 words for the actual chapter body. Less than 1,200 signals you wrote generic placeholder content. More than 2,500 signals you re-explained Chapter 4 results instead of summarizing them.

5.1 Summary of Findings

What this section does

Condenses the Chapter 4 results into one paragraph per major finding. The panel reads this section to refresh memory before reading conclusions. Don’t paste tables here — those live in Chapter 4. Use prose, with numbers.

The 1-paragraph-per-finding structure

Each paragraph follows the same pattern: name the finding, give the supporting number, name the source within Chapter 4. Three to five paragraphs is the right count. Cover at minimum: implementation outcome, testing outcome, evaluation outcome, comparison against baseline.

Worked example

The Barangay Information System was successfully implemented at Barangay [name] in April 2026. The deployment used standard XAMPP, PHP 8.1, and MySQL 8.0 components installed on a single desktop PC at the barangay hall, with no internet dependency required for daily operations. The implementation also included a 2-hour staff training session and a 12-page user manual.

Testing across 32 test cases (14 unit, 12 integration, 6 user acceptance) produced an initial pass rate of 93.75%. The two initial failures — a printer paper-size mismatch and a Windows Task Scheduler permission issue — were corrected, and the full test suite passed on second execution. Full test case documentation is included in Appendix C of this study.

System evaluation was conducted with 12 respondents (1 Barangay Captain, 1 Secretary, 7 Kagawad, 3 frequent walk-in residents) using both ISO/IEC 25010 and the System Usability Scale. The system received a weighted ISO 25010 mean of 4.29 (Excellent) and a SUS score of 78.4 (Above Average). The Functional Suitability and Performance Efficiency dimensions received the highest scores; Security received the lowest, primarily due to the absence of two-factor authentication.

Comparison against the manual baseline showed substantial efficiency gains. Average certificate issuance time decreased from 2 to 3 working days under the paper-based process to 12 minutes under the new system — a 99.6% reduction. Resident record retrieval, previously requiring manual binder search averaging 6 to 8 minutes, now completes in under 5 seconds. The barangay also saves an estimated PHP 12,000 per year in printer ink, paper, and physical storage costs.

5.2 Conclusions

What this section does

Each conclusion in Chapter 5 must map directly to a specific objective from Chapter 1. If Chapter 1 had six specific objectives, this section needs six conclusions in the same order. The panel will check this alignment within the first minute of reading Chapter 5.

The 1-conclusion-per-objective structure

Each conclusion is a 3-4 sentence paragraph that does three things: restates what the objective set out to do, states whether the objective was achieved (yes, partially, or not), and cites the Chapter 4 evidence that supports the claim. No new information appears here — only conclusions drawn from what’s already in Chapter 4.

Worked example (matching 6 objectives from Chapter 1)

Based on the findings, the following conclusions are drawn:

1. The first objective, to design and implement a normalized MySQL database for resident records, certificate requests, and blotter reports, was fully achieved. The implemented database follows Third Normal Form (3NF) design and supports all functional requirements as evidenced by the 100% pass rate on the 14 unit tests covering database operations.

2. The second objective, to develop role-based authentication for Barangay Captain, Secretary, and Kagawad, was fully achieved. Each role accesses only the modules and records assigned to it, as verified through the user acceptance testing scenarios documented in Appendix C.

3. The third objective, to implement automated certificate issuance generating printable indigency, residency, and clearance certificates in under 60 seconds, was exceeded. Measured certificate generation in production averaged 12 seconds, an order of magnitude faster than the stated target.

4. The fourth objective, to develop an integrated blotter management module linking each record to involved residents’ profiles, was fully achieved. All 47 blotter test entries created during UAT correctly linked to existing resident records.

5. The fifth objective, to implement a daily automated database backup routine, was partially achieved. The backup routine functions as designed after the Task Scheduler permission fix; however, the backup currently writes to a secondary local folder rather than an external location, limiting protection against hardware failure. This limitation is addressed in the Recommendations section.

6. The sixth objective, to evaluate usability with at least 10 respondents targeting a SUS score of 70 or higher, was achieved. The system received a SUS score of 78.4 from 12 respondents, exceeding the target by 8.4 points and placing the system in the “Above Average / Acceptable” range.

5.3 Recommendations

What this section does

Recommendations tell specific people what to do with this study or system. Generic recommendations (“future researchers should improve the system”) get rejected. Specific recommendations name the audience and the action.

The 3-audience format

Most Philippine BSIT programs accept a 3-audience structure for recommendations:

1. To the end users (the Barangay, the school, the hospital — whoever uses the system). What should they do with the system as it exists today?
2. To future developers or maintainers. What technical improvements would meaningfully extend the system?
3. To future researchers (the next BSIT students taking on similar projects). What did this study leave for them to investigate?

Some schools add a fourth audience — the academic institution itself or a relevant government agency. Use it if your school template requires it.

Worked example

To Barangay [name]: Continue using the system for daily operations and assign one staff member as the primary system administrator with backup responsibilities. Schedule a quarterly database backup audit to verify backup integrity. Consider allocating PHP 3,000 to PHP 5,000 annually for an external storage drive to enable off-site backup, addressing the limitation noted in Conclusion 5.

To future developers and maintainers of this system: Three specific extensions are recommended. First, implement two-factor authentication for the Barangay Captain account, addressing the security concern raised by two respondents during evaluation. Second, extend the backup routine to write to either an external USB drive or a cloud storage location, removing the single-point-of-failure on the local PC. Third, add a Filipino language interface as a toggleable option, since 2 of the 12 respondents specifically requested it during UAT but the limitation was outside the original 4-month timeline.

To future BSIT researchers: Three areas warrant further investigation. First, this study evaluated one barangay in Negros Occidental; a multi-barangay pilot would strengthen generalizability of the findings, particularly for barangays with significantly larger populations. Second, an inter-barangay coordination module (allowing residents who move barangays to transfer records) was outside this study’s scope but represents a clear extension. Third, no formal cost-benefit analysis was conducted comparing the PHP 0 free system to the commercial barangay information systems retailing at PHP 80,000 to PHP 250,000; a follow-up study quantifying full TCO would inform broader adoption decisions across Philippine local government units.

To the Department of the Interior and Local Government (DILG): Consider evaluating open-source barangay information systems as a baseline reference for the LGU Digital Transformation initiative, particularly for rural barangays where commercial system licensing costs are prohibitive.

5.4 Implications (optional, school-dependent)

What this section does

Implications describe the broader significance of the study beyond the specific system built. Not every school requires this section — check your template. When required, the implications section typically runs 150 to 250 words and covers practical, theoretical, or policy implications.

Worked example

This study has several implications. Practically, the system demonstrates that a functional barangay information system can be built and deployed using free, open-source components by a 3-person undergraduate team within a 4-month timeline, suggesting that similar systems could be replicated across the more than 18,000 barangays in the Philippines at minimal licensing cost. Theoretically, the findings reinforce existing literature on the Technology Acceptance Model (Davis, 1989), particularly the finding that perceived usefulness — measured here through certificate processing time reduction — strongly correlates with usability ratings. From a policy perspective, the study supports continued investment in BSIT and BSCS capstone programs as a low-cost mechanism for producing locally-relevant government digital services, complementing larger-scale national digital transformation programs.

The defense moment Chapter 5 sets up

Panels open Chapter 5 first when they grade. Within the first minute, they check three things: does the conclusion list match the Chapter 1 objective list, do the recommendations name specific audiences, and does anything in Chapter 5 contradict Chapter 4. If those three checks pass, the rest of the defense becomes a conversation rather than an interrogation. If those three checks fail, the panel begins the defense already skeptical, and you spend the first 15 minutes defending Chapter 1 instead of presenting the system.

Write Chapter 5 last, but write it carefully. The reading time on Chapter 5 by the panel is short; the impact on the defense outcome is large.

Common mistakes that get Chapter 5 sent back

• ❌ Conclusion count does not match objective count from Chapter 1. The panel reads the lists side-by-side.
• ❌ Generic recommendations (“future researchers should expand the system”) with no specific audience or action.
• ❌ New information appearing in Conclusions or Recommendations that wasn’t in Chapter 4. Chapter 5 cannot introduce findings.
• ❌ Repeating Chapter 4 numbers in full instead of summarizing them. Chapter 5 says “99.6% reduction”; Chapter 4 contains the raw measurements.
• ❌ Recommendations that recommend things already done in the study. “Recommend implementing role-based authentication” is wrong if Chapter 4 already proved it works.
• ❌ Conclusions written in marketing voice (“our system revolutionized barangay operations”). Cut every adjective that isn’t backed by a Chapter 4 number.
• ❌ Skipping the “To future researchers” recommendation. Panels look for this specifically because it demonstrates academic awareness.
• ❌ Word count under 1,200 in the chapter body. Signals that placeholder content was not replaced with project-specific text.

Quick reference — Chapter 5 readiness checklist

Before sending Chapter 5 to your adviser, confirm each item:

• [ ] Conclusion count exactly matches the Chapter 1 specific objective count
• [ ] Each conclusion references at least one Chapter 4 result by number
• [ ] Recommendations name at least three audiences with specific actions
• [ ] No new information (not previously in Chapter 4) appears in Chapter 5
• [ ] Summary of Findings is prose, not tables (tables stay in Chapter 4)
• [ ] Word count is between 1,500 and 2,500 in the chapter body
• [ ] Implications section is present if required by your school template
• [ ] No first-person (“I”, “we”) unless explicitly allowed by your template

How long should Chapter 5 be

Most Philippine BSIT and BSCS templates expect Chapter 5 to run 1,500 to 2,500 words in the main body. The chapter is intentionally short — it summarizes and concludes; it does not document or evaluate. Less than 1,200 words usually means you wrote placeholder text instead of project-specific conclusions. More than 3,000 words usually means you re-explained Chapter 4 results instead of summarizing them.

Free Chapter 5 template — download and adapt

Skip the blank page by downloading our Chapter 1-5 Template (Free Download) — pre-formatted Word document with placeholders for the Summary of Findings, per-objective Conclusions, and 3-audience Recommendations. Replace placeholders with your study’s specifics and you have a defendable Chapter 5 in one focused sitting.

You’ve completed the series

Chapter 5 is the final chapter of your capstone. With all five chapters drafted, the remaining work is revision, formatting, appendix preparation, and defense scheduling. Browse the complete series:

• 📚 Chapter 1: Introduction
• 📖 Chapter 2: Review of Related Literature (RRL)
• 🔧 Chapter 3: Methodology
• 📊 Chapter 4: Results and Implementation
• ✅ Chapter 5: Summary, Conclusions, and Recommendations (you are here)

Related capstone resources

• 150+ Best Capstone Project Ideas for IT Students (2026)
• UML Diagrams Library
• All Project Hubs

About this guide

This guide was written by the editorial team at PIES Information Technology Solutions — working developers who have helped 200+ BSIT students pass capstone defense. Every conclusion-to-objective mapping and recommendation format in this guide comes from real defended capstones at Philippine BSIT programs. Have a question or want a custom capstone built? See our Hire Us page.

Now open Word. List your Chapter 1 objectives. Write one conclusion per objective.