DEV Community: Buddha Lama

Approach to Assessing and Evaluating Project Outcomes and Findings

Buddha Lama — Mon, 28 Sep 2026 14:51:22 +0000

Planning, defining success, and working with secondary data felt like separate problems at first. But they turned out to be the groundwork for two things I have to do throughout the project: assess it while it's running, and evaluate it once testing is done.

Planning against a moving target

Data imputation for clinical fields isn't a settled area. New methods and evaluation approaches keep appearing. That makes committing to a fixed plan feel slightly uncomfortable.

The Phelps, Fisher and Ellis (2007) planning chapter helped here. Experimentation is iterative, not linear. So milestone dates carry a buffer, not a promise. That's also the reasoning behind running the project in one-week Scrumban sprints (Ladas, 2009). Each sprint has a Review step, which weighs progress against my success criteria. Then an Adapt step decides whether to keep, adjust, or drop a method before the next sprint starts.

I track all of this in ClickUp: a Gantt chart for the overall milestones, a Scrumban board for the weekly sprint cycle, and custom fields as a running decision log — what was tried, what the result was, and whether it was kept or dropped. This is what ongoing assessment actually looks like. Not a single check at the end. Deviations get flagged as they happen.

Defining success when the field itself hasn't settled

If the plan has to stay flexible, the definition of "done" needs to be just as deliberate. Otherwise there's no way to tell whether an adjustment is progress or just drift.

Wingate's (2014) distinction between verification and validation gave me that anchor. Success means the imputation is built right — passing the RMSE, distribution, and significance thresholds. It also has to be the right thing — meeting the F1/AUC floor that shows it actually improves readmission prediction. Conflating the two would let me claim success on a technicality. A statistically plausible imputed value that does nothing useful downstream isn't a win.

That's why evaluation happens in two layers, not one: a distribution/significance test, and a classification-performance check. Both are judged together, never either alone.

Secondary data as the anchor

None of this planning happens in a vacuum. It's all built on a dataset I didn't collect myself. The Diabetes 130-US Hospitals dataset (Strack et al., 2014) is secondary data — 101,766 patient admissions across 130 US hospitals, gathered for hospital administration purposes, not for my research question.

That gap matters. Fields like medical specialty and payer code sit in a genuine judgement zone — roughly half missing, with no bright-line rule for impute versus exclude. Their missingness pattern was shaped by whatever administrative process generated it, not by anything I control or fully understand. Using secondary data responsibly means logging the reasoning behind each field's decision individually, rather than applying one blanket rule across the dataset.

Takeaway

Planning in a field that's still moving isn't a weakness to plan around. It's why assessment has to be continuous, not a single end-of-project check. And it's why evaluation has to test both that the work was built right, and that it's the right thing.

References

Ladas, C. (2009) 'Scrumban: Essays on Kanban Systems for Lean Software Development'. Available at: https://www.semanticscholar.org/paper/Scrumban%3A-Essays-on-Kanban-Systems-for-Lean-Ladas/09b6383d58f385c25580b095c32ca5246b1d1a84 (Accessed: 28 September 2026).

Phelps, R., Fisher, K. and Ellis, A.H. (2007) Organizing and Managing Your Research: A Practical Guide for Postgraduates. London, United Kingdom: SAGE Publications, Limited. Available at: http://ebookcentral.proquest.com/lib/sunderland/detail.action?docID=354865 (Accessed: 17 September 2026).

Strack, B. et al. (2014) 'Impact of HbA1c Measurement on Hospital Readmission Rates: Analysis of 70,000 Clinical Database Patient Records', BioMed Research International, 2014, p. 781670. Available at: https://doi.org/10.1155/2014/781670.

Wingate, L.M. (2014) Project Management for Research and Development: Guiding Innovation for Positive R&D Outcomes. 1st edn. Boca Raton: Auerbach Publications (Best Practices and Advances in Program Management Series). Available at: https://doi.org/10.1201/b17241.

Deciding How to Analyse Missing Data: My Method Selection Process

Buddha Lama — Mon, 28 Sep 2026 14:06:36 +0000

I almost skipped this decision entirely — turns out that would have been a mistake.

Why this decision matters

Moving on from my previous post on tool selection, working through the material on research paradigms and method selection pushed me to a more fundamental question: what kind of research is this actually, and what does that mean for how I analyse my findings? It would have been easy to treat method selection as a formality, pick "quantitative" because I'm working with a numerical dataset and move on. Working through the readings on qualitative, quantitative, and mixed-methods approaches convinced me that's too shallow a justification, and that the method decision has real downstream consequences for how defensible my final results will be.

Working through the decision

My project uses the Diabetes 130-US Hospitals dataset — a secondary, pre-existing quantitative dataset of 101,766 clinical admission records (Strack et al., 2014), including demographic fields like race and weight, clinical measures, and a 30-day readmission outcome.

Using the checklist-based reasoning from Urban and Van Eeden-Moorefield (2017), the decision toward a quantitative-dominant approach was fairly clear: my research question concerns measurable outcomes (imputation accuracy, downstream classification performance), not lived experience or narrative meaning that would call for qualitative data.

What surprised me was how Creswell and Plano Clark's (2018) concept of method dominance still applied even to a project I'd already decided was quantitative. There's a small interpretive element embedded in an otherwise numerical pipeline: judging why a field like race might be missing — administrative inconsistency versus a genuine data collection gap — draws on clinical and contextual reasoning that isn't purely statistical, even though the output of that judgment feeds directly into a quantitative decision (which imputation method is valid to apply). I hadn't expected a "quantitative" project to have any qualitative-adjacent reasoning in it at all, so this was a genuinely useful correction to an assumption I'd made too quickly.

What this means for my analysis plan

Greenfield and Greener's (2016) treatment of elementary statistics gave me the practical layer underneath this decision. Rather than assuming a single test will do the job, I'm planning a layered analysis:

Descriptive statistics and distribution checks — establishing skewness and whether fields are close to normal.
Comparative significance testing to evaluate imputation quality — chi-square for nominal categorical fields like race, and t-tests or their non-parametric equivalents for continuous fields, depending on whether normality holds.
Classification-model performance metrics — testing whether the imputation method chosen actually matters for predicting 30-day readmission.

Given that several of my demographic fields are unlikely to be normally distributed, I'm expecting to lean more on non-parametric tests than a default t-test-first approach would assume.

Takeaway

Method selection isn't a one-off decision made at the start and then forgotten — it's something I'll need to keep justifying at each stage, from data gathering through to final significance testing.

Being upfront about the parts of it that aren't purely mechanical — like the missingness-mechanism judgment — will make the eventual write-up more honest and more defensible than pretending the whole pipeline is objectively statistical throughout.

References

Creswell, J.W. and Plano Clark, V.L. (2018) Designing and Conducting Mixed Methods Research. Third Edition. Los Angeles: SAGE.

Greenfield, T. and Greener, S. (2016) Research Methods for Postgraduates. Newark: John Wiley & Sons, Incorporated. Available at: http://ebookcentral.proquest.com/lib/sunderland/detail.action?docID=4644084 (Accessed: 19 September 2026).

Urban, J.B. and Van Eeden-Moorefield, B.M. (2017) 'Chapter 4: Choosing Whether to Use a Qualitative, Quantitative, or Mixed-Methods Approach', Designing and Proposing Your Research Project. Washington, DC: American Psychological Association.

Choosing a Visual Project Management Tool for a Solo Research Project

Buddha Lama — Mon, 28 Sep 2026 13:50:26 +0000

Why this matters for evaluating my project

One of the recurring themes in the Research Project Management module of my MSc in Computer Science with Data Science has been that effective project management starts with reliable, up-to-date data — and visual tools are what make that data usable at a glance rather than buried in a to-do list. For my dissertation (data imputation on the Diabetes 130-US Hospitals dataset, targeting 30-day readmission), the challenge isn't team coordination — it's keeping track of an iterative process: testing imputation strategies, evaluating outcomes, and being able to justify those decisions later in my methodology write-up. This post documents how I arrived at a tool to support that.

Evaluating the options

I started from four standard project-planning tools — Gantt charts, timelines, Kanban boards, and RACI charts (Project Management Institute, 2021) — and quickly ruled out RACI entirely: it exists to clarify shared responsibility across multiple people, and as a solo researcher I have no team to allocate work across. The other three, however, map onto genuinely different needs: a Gantt chart or timeline for the fixed, non-negotiable milestones (data approval, evaluation, submission), and a visual board for the messier, iterative side of the work that doesn't move in a straight line — for which I settled on Scrumban, a hybrid of Kanban's board layout and Scrum's fixed-length sprints (Ladas, 2009), rather than a pure, continuous-flow Kanban setup.

Rather than stopping at the course materials, I researched what's actually being used in the market right now. A few tools kept surfacing specifically for research use: Notion (increasingly popular among researchers because it combines project management, note-taking, documentation, and knowledge management in a single platform), Trello (still widely recommended for individual researchers and small academic groups for its simplicity and Kanban-style tracking (Nowogrodzki, 2020)), and ClickUp, which came up repeatedly for its extensive customisation and suitability for complex, non-linear workflows. Miro was a useful counterpoint too — good for early-stage mapping of how ideas relate, but explicitly not designed for execution or long-term tracking, which ruled it out as a primary tool for me, though it could still be useful for the earlier design decisions.

My decision: ClickUp

I settled on ClickUp. The deciding factor was that its Gantt, board, and timeline views all draw from the same underlying task data — so I can hold one dataset (milestones plus experiment tracking) and simply change the view depending on what I need to see, rather than maintaining separate tools for scheduling and iteration tracking. I run the board as a Scrumban setup — Kanban's visual layout, but worked through in fixed weekly sprints rather than continuous flow — since a solo project benefits from regular checkpoints without needing Scrum's full ceremony (a Scrum Master, a Product Owner) that a one-person team has no use for. Its custom fields also let me attach structured metadata directly to each task — which imputation method was tested, the rationale, the outcome — functioning as a lightweight decision log built into the workflow itself, rather than a document I'd have to remember to update separately.

What I'm watching out for

ClickUp's flexibility is also its biggest risk for a solo user: it's easy to over-engineer the workspace before actually using it, especially given my own tendency to want to fully understand and structure a system before committing to it. My plan is to start with just two lists — milestones (Gantt view) and experiments (board view, run as Scrumban: To Try / Testing / Evaluated) — and only add complexity once I feel a genuine gap, rather than designing for problems I don't have yet.

References

Nowogrodzki, A. (2020) 'What project-management software can do for scientists', Nature, 583. Available at: https://www.nature.com/articles/d41586-020-01918-0 (Accessed: 28 September 2026).

Project Management Institute (ed.) (2021) The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK Guide). Seventh edition. Newtown Square, Pennsylvania: Project Management Institute, Inc.