What are your requirements (granular) and constraints (abstract and/or
granular)?

For example:

   - Define the core need(s) informing the advocacy of the project.
   - Document the desired outcomes in the abstract, and then with as much
   granularity as possible.
   - What class(es) and/or types of documents are you storing?
   - How many files are you looking to store?
   - What is the predicted growth of usage (predicting need for
   scalability)?
   - What level of meta-data faceting are you looking for?
   - What are the use cases for data inclusion?
   - What are the use cases for service consumption?
   - Identify current statutes and local policies which may guide and/or
   restrict certain models of implementation and/or use.
   - What is the breadth of skills directly available to support this
   project?
   - What is the depth of skills (how many people with each skill)?
   - What is the implementation budget?
   - What is the long term maintenance budget?
   - Are there opportunities for collaboration and/or partnerships (eg
   neighboring libraries with a similar need or better, a similar project
   already in the works?

These, and other req-cons can help you to better understand what type of
investment should be considered for your project.  It can certainly be less
feasible for smaller institutions, with less staff, and less wiggle room in
budgets to fit a product to the needs.  However, going through the process
may help you to determine if it feels more like you're trying to cram your
needs into a specific product.  Forcing a product onto a project in which
it just doesn't fit will often lead to predictable failures and resource
waste.  There may be a realistic possibility that your institution simply
doesn't have the means to achieve its core need in this.

Detailing your needs, requirements, desires, and constraints though can
definitely help you refine the search for solutions, and navigate them with
more clarity.  It may help you and your colleagues to reinforce the Drupal
path, or it may help you craft buy-in for a product/service initially
considered "off the table" if it can be demonstrated that that product or
service has been successfully implemented by other institutions with very
similar needs.

Success is oft found in the meta ... Good luck!



Joshua Klingbeil - IT Director
Wisconsin Valley Library Service

*I have learned that when I am able to empty my mind of *
*                                preconception, predisposition, and
prejudice... *
                 *... what remains is possibility!*


*It's easy to answer "No! And here's why not..."
  It's empowering to answer "Yes! Now let's figure out how..."*

On Thu, May 5, 2016 at 4:15 PM, Kelsey Williamson <
[log in to unmask]> wrote:

> Hi code4lib,
> I was hoping to get some input on this. My small, scrappy institution is
> considering using drupal as a repository, primarily via the Biblio module.
>
> Obviously this is not ideal, but for reasons I won't get into, our tech
> environment won't support ePrints or dspace, and hosted services are not an
> option either. We do not really have the level of technical expertise
> required to support any fedora-based applications, and cannot hire any
> additional support. There's a chance existing staff could stretch to get
> there, but it would not be a pretty process.
>
> With all that said, do any red flags come to mind? I looked through both
> code4lib and drupal4lib listserv archives and poked around google, but
> didn't find much evidence of anyone else using drupal in this way. Seems
> suspicious. While my gut tells me it's a bad idea (metadata! standards!
> preservation!), I'm having trouble articulating this to my group in a way
> that sticks, because using Biblio would be easy. I would appreciate hearing
> any other thoughts or opinions on this.
>
> Thanks!
> Kelsey
>

-- 


<http://facebook.wvls.org>  <http://twitter.wvls.org>