2. We Got the Grant!
Brad Brandewie (Aug 14, 2011). Good times on the White Rim...
https://www.mountainproject.com/photo/107247382
3. The Grant is Not the Goal
And...Grants Present Challenges
4. Grants Are “Big Design Up Front” (BDUF)
1. In order to secure funding, you need a plan
2. Software plans are often wrong
“Accurately understanding other people requires
getting perspective, not simply taking it. To
understand the mind of another person, we need to
rely on our ears more than our intuition.”
Tal Eyal, Mary Steffel, Nicholas Epley (October 09, 2018). Research:
Perspective-Taking Doesn’t Help You Understand What Others Want
https://bit.ly/2QLhX4m
6. Guarding Against Grant BUFD
● Validate your core ideas before applying
○ Lo-Fi (paper) prototypes
○ Test a [Bare] Minimum Viable Product
(MVP)
● Strive to commit to goals, not features
● Identify a strong product owner (doesn’t have to
be the PI)
● Workshops - e.g. brain-dump features into a
spreadsheet, everybody ranks them 1-5 pre-
meeting, discuss conclusions
● Lose the grant
○ A bad grant is worse than no grant
7. Everything Changes
● Hard deadlines: it’s “done” on May 1st...because
it’s May 1st
○ Reality: you try many things that don’t make
the final cut and alter many original ideas
● Software evolves, grants do not
○ User needs change, the technology
environment changes, everything changes
○ Large systems tend to be hard to change
● Maintenance eats you over time
○ “Software maintenance costs will typically
form 75% of TCO.”
https://galorath.com/software_maintenance_cost
9. Planning for Change
● Be as broad as getting funded will allow
● Seek grants that closely align with institutional
strengths and goals to gain institutional support
● Limit project scope and dependencies
○ Do a couple of things well, avoid “featuritis”
○ Quickly kill-off features that don’t work
○ Small systems evolve more easily
● Low maintenance implementations
● Alternative supplemental / sustainable funding
models?
● Seek out “Exploratory” grants
● Under-promise & over-deliver
10. Planning for Change
● Be as broad as getting funded will allow
● Seek grants that closely align with institutional
strengths and goals to gain institutional support
● Limit project scope and dependencies
○ Do a couple of things well, avoid “featuritis”
○ Quickly kill-off features that don’t work
○ Small systems evolve more easily
● Low maintenance implementations
● Alternative supplemental / sustainable funding
models?
● Seek out “Exploratory” grants
● Under-promise & over-deliver
Editor's Notes
Chicken and egg problem: users need to see something in order to evaluate it.
Lo-fi tests, MVPs, other forms of work products are powerful grant materials
Careful with SURVEYS - we are terrible at predicting what products we will actually use and how we will use them