Author: Stephanie Rodgers

Though evaluation most naturally occurs at the conclusion of a project, it is important to consider opportunities for evaluation during the project’s execution as well (a process called “monitoring and control” in project management lingo). Strategies range from informal but frequent check-ins to less frequent but more intensive written statements.

Evaluation Opportunities:

• Weekly (tracked via completion of to-do items on tracking software)
• Monthly (informal discussions/interviews with individuals)
• Quarterly (formal meeting with all team members, principal investigator, and project sponsors)
• Annually (written evaluation by each team member)
• At Project Milestones (written reports at the conclusion of a project phase)
• At Project Completion (written report by project manager and/or principal investigator for institution and stakeholders, and note that this might be a good time to suggest more resources for follow-up projects or further development)

Note: Do not forget to include self-evaluations. What have you been doing, and what should you be doing? How do your team members evaluate themselves? Make changes where appropriate.

Common Evaluation Issues

Team Member Not Completing Tasks Efficiently or On Time:

What is impeding the team member?

• knowledge or skills
• time management or priorities
• personal issues (especially important with students)

What can you change to correct these issues? Give them training, more flexible scheduling, or a few days off?

When should you replace a team member? Set criteria for what constitutes an egregious disruption or impediment to project.

Delays in Resources:

• Provide regular reminders to resource providers.
• Draft formal letters of request (perhaps routed through a higher-up).
• Schedule phone calls from principal investigators or major stakeholders.
• Create hard delivery deadlines.

At identification of issue, begin creating alternative scenarios for personnel or resource support.

Handling Problems

• Direct communication can smooth a lot of issues. Ask if something is wrong, and how it can be resolved.
• Make sure every team member has an opportunity to offer constructive criticism (anonymous or otherwise) and feels heard.

On all teams, personal issues often interfere with professional ones. Some of these can be managed with a casual chat over coffee, but others may require more active involvement or additional one-on-one meetings.

Written Evaluations

Written evaluations can provide a record of an individual or team’s progress or contributions to the project, from both their perspective and yours. Be sure to provide them the opportunity to assess your work, as well.

Individual Evaluations of Projects

For individual team members to evaluate the project, ask them:

• What are you doing?
• What do you wish you were doing?
• What are you unwilling to do?
• How much time is it taking?
• What is the most frustrating thing about this project?
• What are you learning along the way?

These responses can be anonymous or not. You just want to establish a feedback loop and catch impending problems as early as possible.

Evaluation of Individual Team Members

To evaluate team members, ask:

• Have they been meeting project deadlines and managing their time well?
• Has their work been up to standard?
• Have they been working well with other team members?
• Have they been communicating effectively and attending team meetings?

Evaluation of Multi-Institutional Collaborative Projects

• By each team project manager (“my team did this well, but not this”)
• By each team member (“my role was this, and I did this well but not this”)
• By each team principal investigator (“this worked for the project, this didn’t work for the project”)
• By you from an overarching perspective (recommendations for change/stasis)

 

External Evaluations

Select a successful, comparable project or team (in terms of scale, deliverables, etc.) and ask them to spend the day with your team and then provide feedback. What are they seeing? What do they suggest?

External parties, including project sponsors, can often see things without distraction.

 

From: Evaluating Your Project and Team

Digital humanities is generally a public-oriented field of inquiry, with results that can be shared beyond a specialized academic discipline. Crafting an effective publicity campaign can help you connect with others in your field, find partners, secure more funding, and generate excitement about your research.

Branding Your Project

• Choose an appealing title that communicates your topic.
• Design a visually appealing, intuitive logo and website so that those who want to publicize your work may do so easily.
• Provide citations on each page so users may easily give appropriate attribution.
• Get your project out on social media.
• Be consistent about branding! This is how you retain control of your image.

General Tips

• Figure out which social media sites your scholarly community uses.
• For every account, write down username and password.
• Make use of social media plug-ins on websites and across social media accounts.
• Do be judicious about linking project accounts with more personal accounts.
• Don’t open accounts unless you’re willing to update and maintain them.
• Build updates into your work plan and schedule!
• It’s probably not a good idea to create accounts for short-term projects.
• Remember, no matter your privacy settings, no social media account is perfectly safe.

Press Release Material:

• Award of funding, including internal grants (if it’s competitive, get credit).
• Documenting your progress (milestones: software, books, articles).
• When new partners join (welcome them, network with their connections).
• When you publish/present findings.
• Release of products or deliverables.

Components of a Press Release:

• Project title and Abstract
• Message/Update
• Tags/Handles of partners and funders
• Website link
• Quote from pertinent person

It might be useful to write a single blog post on the update and then push it out on relevant platforms and to interested parties.

It might also be useful to get quotes from people with a lot of pull or large virtual following, so that you reach their network, as well.

Outlets (Who to Send Press Release To):

• Project Staff
• Campus Stakeholders (college, library, research office, press office)
• External Partners
• Funders/Sponsors (let them know their money is well spent!)
• News outlets (general publications as well as digital humanities- or discipline-specific)
• Your professional network

Timing

You are ready to discuss your work publicly when you:

• Start your project (project generation, plans, how to get involved).
• Are in progress (issues you are dealing with, partner-seeking, beta-testing).
• Reach the midterm (initial results).
• Deliver final products (successes and failures).

Coincide your major project press releases/deliverables with:

• Deadlines for conferences
• Funding deadlines
• Start of the academic year

 

From: Designing Your Publicity Campaign

Projects don’t always proceed as planned, and sometimes changes need to be made or problems arise. Reflect on the situation and consult your project documentation (charter, budget, and work plan) to figure out where the issue is. Should the project change course? Is there a problem in resources, personnel, or something else?

Making Changes to Your Work Plan

You can’t control everything, so you do have to be prepared for changes and anticipate problems where possible.

What might change?

Change in scope of the project (may require approval from sponsor):

• Overall project change (e.g., change in deliverables)
• Design element change
• Technology change (e.g., need to change coding language)
• Change in mission/business (e.g., shift of topic)
• Change in skills (e.g., team members leave)

Change in baseline (which might require budget adjustments):

• Project specifications
• Financial changes (e.g., budgetary issues due to altered labor needs)

Changes in resources (e.g., planned resources no longer available and must be reallocated):

• Partner changes (e.g., someone leaves and funding must be moved)
• Changes in discipline/field

When is change needed?

• you’re not meeting deliverables (e.g., too many of them or too little time)
• your team isn’t working well together
• you have addition of, or change in, partners
• resources disappear
• funders or stakeholders request changes
• principle investigator (PI) isn’t doing their job (e.g., due to time constraints)

When is change allowed?

When it doesn’t cost you:

•                         additional money,
•                         additional time,
•                         additional deliverables,

UNLESS by making the change you:

•                         deliver a better product.
•                         you can increase the impact.
•                         you are better positioned for the next phase of the project.

HOWEVER, be especially cautious about scope creep:

•                         when new partners come to the project.
•                         when PIs get excited.
•                         when projects get press.
•                         when your staff changes.

To prevent scope creep, conduct regular scope assessments.

Ask:

• Does the current scope accomplish the primary goals?
• Are the core stakeholders pleased? Get their feedback.
• Is the project team enjoying its work?

When a project becomes painful:

• Identify the quickest route to completion (while still meeting all requirements of original proposal).
• Remove all extraneous meetings/work. Streamline as much as possible.
• Be up front about what isn’t working.

Changing Project Scope:

1. Schedule an all-team meeting to discuss changes and potential effects.
2. Draft a memorandum of change (or other formal documentation) to update project work plan and team members’ responsibilities.
3. Notify stakeholder, and ask permissions where necessary. Here it is generally much better to ask permission rather than ask forgiveness.

Confronting Problems

When Projects Go Awry

Delays (avoidable or otherwise):

• Determine what (or who) is causing it.
• Figure out what you MUST have to move forward.
• Set and enforce hard deadlines.
• Use your power(s) to get things moving.

Not enough money:

• Revisit budget and identify where you can save money.
• Determine if money can be reallocated.
• Figure out which deliverables have the most impact, and prioritize them.

Not enough time:

• Prioritize deliverables.
• Be realistic about what can get done.
• Consult work plan and make adjustments.
• Let team members/funders know immediately.

When Team Members are Unsuccessful:

• Is it a personality problem?
• Is it a knowledge issue?
• Is something going on with that person?
• Play to people’s strengths.
• Offer training.
• Offer opportunity to discuss.
• Draw a firm line in the sand.

When PIs (Principal Investigators) are the Problem:

“I am so….(busy, overworked, overcommitted).”

• Be clear that time is money.
• Be clear that everyone (and their time/effort) is valuable.
• Be clear that without their support, the project can’t move forward.
• Be clear that you can’t reconfigure everything because they have an issue.

Your Options:

• Document deliverables (or lack thereof).
• Document your attempts to meet/discuss.
• Write a formal letter of request.
• Cut off access to staff and resources.
• A combination of these.

Keeping a log of issues that arise may help you identify patterns of problems.

When YOU (the project manager/coordinator) are the problem:

• Allow team members or PI to suggest changes.
• Be honest when you no longer are useful to the project.
• Discuss clearly your problems/issues and offer solutions.
• Decide whether you still believe in the project and then act accordingly.
• Don’t let it fester.

Your job is to see the project through, but you should also be aware that at times, the best course of action will be to end the project, rather than continue to pour time and resources into a doomed venture.

 

From: Building Your First Work Plan, All About the Problems

Before beginning a project, it’s a good idea to construct a work plan that details the progress of the project from start to finish. Creating and distributing this plan will ensure that all team members and stakeholders are on the same page regarding the project’s schedule and deliverables.

A work plan includes:

• a list of itemized tasks, as detailed and specific as possible.
• a list of individual responsibilities. Assign each task to someone.
• a time element, including length of time per task and a reasonable deadline.
• an account of how tasks depend upon one another for completion.
• a deliverables/outcome element.

Step One:

• List every major objective, and include all the individual steps to get to it.
• The first time you do a digital humanities project, treat everything as a task that must be assigned to someone. Include every task in the formal work plan.

Step Two:

• For every task, list who is responsible, by team and/or by person.

Step Three:

• For every task, list the deliverable.
• Determine the task’s success criteria.  How do you know when the task is completed, and who is responsible for determining this? Upon completion, where does the deliverable go, physically or digitally? (Think through storage issues.)

Step Four:

• For every task, list the amount of time required from start to finish.
• Consider how the tasks depend on each other’s completion (i.e., their dependencies). This will also help you think about staff allocation, which in turn helps you think about time allocation and therefore resource/financial allocation. (Don’t forget to account for wait times, such as opening expense accounts, processing paperwork, or awaiting equipment delivery. In addition, take into account “closing” activities, like submitting finalized forms and wrapping up loose ends.)

Common Time Measurements

How do you measure time? It depends on the project’s overall duration and complexity. A single year project will most likely be written by the month. (Also, be aware that it’s unlikely anyone will get anything done Dec 15-Jan 15, as well as the first and last 2 weeks of the academic semester. Take into account national and religious holidays, as well as other time zones.)

Budgeting Your Time

• Assume you’re working on a 40-hour week.
• It may be easier to estimate the percentage of someone’s time, rather than the exact amount of time, that the task will take.
• Budget not only your own time, but also that of your team.
• Remember, it is unlikely that all team members will be contributing 100% of their work week to the project.

How do you figure out how long something should take?

• Figure out what other tasks this task is dependent on.
• Determine how complex it is.
• Ask how many people are engaged in the project/task.
• Is it something that someone has done before? Can you ask for input?

Ways to Build a Work Plan

• The plan that works best depends on the nature of the project and how you like to organize your work.
• Some possibilities:

-Word document
-Excel Spreadsheet
-Microsoft Project
-Tree chart: good for showing task dependencies and relationships
-Gantt Chart (typically recommended by books on project management): shows time, with objectives and deliverables, broken out by task. Good for assigning tasks, labor, and person-power.
-Network diagram: maps the longest path through the tasks and dependencies to determine timeline.

• Figure out what organizing principles works best for you, your project, and your team.
• Try to make sure you don’t have any bottlenecks, where everyone is waiting on one person to finish something. Find something else to move on with while you wait.

Ways to Improve Your Work Plan

• Color code types of work: by person completing task, by objective, by type of task (e.g., all coding tasks are purple, project management is red), or by who is in charge of making supervisory decisions
• Create modules: identify teams and types of work that are interdependent, to designate portions of the project that you can hand off to those teams and allow them to sort out their day to day goals to achieve the overall objective you’ve assigned to them.
• Identify dependencies.

Work Plan in Practice, by Project Role:

• Overall project responsibility: project coordinator/manager (PM) and principal investigator (PI).
• Administrative tasks: generally PM, who keeps paperwork done, and keeps in contact with all other project heads to make sure things are operating appropriately.
• Technical tasks: lead programmer, who delegates technical work.
• Website tasks: web developer.
• Content tasks: typically PI, with holistic and intellectual vision. May delegate specialized tasks if necessary.
• Financial Tasks: business manager, who assists you in handling financial documents and record keeping, as well as hiring (as in graduate lab assistants).

Common Errors in Work Plans:

• making them too broad.
• making them too specific (so they are constantly changing).
• underestimating the value of a communications plan.

Goal of work plan: Don’t overwhelm yourself or team members, but also don’t leave project members wondering what’s going to be happening or whose responsibility a task is. Remember to be realistic: it doesn’t help to write fiction.

 

From: Building Your First Work Plan

Before creating the budget, consider to whom you will be submitting it: an external funder or an internal funder. Both are equally important, but they may have different requirements. In addition, don’t forget to consider long-term or recurring costs as well as immediate funding needs. You do not want is to get midway through a project only to discover you do not have the funding to complete your proposed objectives and deliverables.

Getting Started

• Make sure to plan ahead.
• Double-check the funder’s specific requirements and limitations.
• Use templates where possible: they reduce both error and workload.
• Don’t forget indirect costs!
• Consider asking for guidance from your university grants office, if possible.

Elements of a Budget

Salaries (typically the largest portion of a budget):

• Base calculations on your actual salary. Do not give yourself a pay raise!
• Ensure that you place people in the correct salary categories, and do not forget to include benefits.
• Attend to the difference among faculty, staff, and student pay scales and schedules. In deciding between research assistants or hourly student workers, consider that research assistants are better for projects that require a sustained engagement or intellectual role, while hourly students workers are generally better for specific, short-term tasks. Do not forget to include your project manager, programmer, and systems administrator in your staff!
• Do not include time spent developing the budget in the budget.
• If you need to make an adjustment, you may be able to do a re-budget, which is generally fine if you’re moving money around within categories, but generally frowned upon if you attempt to move money from one category to another.

Other Direct Costs

Equipment:

• You should generally only include large equipment needs (over $5,000 for single item).
• Equipment can only be used for work specifically described in your proposal, so if the item will be useful beyond the life of the project, mention it as a part of building a “sustainable infrastructure.”
• Be aware that purchase of some types of equipment will be prohibited or intensely scrutinized (e.g., laptops, phones, tablets).
• Provide vendor quotes in your justification or as supporting materials.

Travel:

• Funds can be used to meet with collaborators at other universities, and it’s generally acceptable to travel to conferences so long as it is connected to your project. If you are presenting (or applying to present), include that in your proposed budget.
• Do differentiate between domestic and foreign travel, and again, justify costs with vendor quotes.

Materials and Supplies:

This category generally covers miscellaneous expenses, including printing agendas, name tags, etc.

Publication Costs:

This includes publishing fees for project-related articles (e.g., journals that require a fee for article publication).

Other:

Don’t forget about server hosting fees, small equipment purchases (can only be used for the project), publicity swag, and consultant fees or honoraria.

Indirects

Your institution wants their cut. Indirects are used to pay for all the things that aren’t directly related to your project, but are required by your project (lighting, heating, printer paper, wireless access/network connectivity, administrative overheads).

Indirects are charged at a federally negotiated rate, typically calculated as 50-60% of your direct costs (varying by institution), and at different rates for different activities (e.g, teaching vs. researching). Some foundations (Mellon) prohibit the charging of indirects, while some institutions offer different indirect cost rates depending on the grant activity, so MAKE SURE you investigate and get the lowest rate possible. Sometimes, indirect costs can be waived directly.

 

From: Principles of Budget Design

To ensure that the project’s objectives remain fixed, the project team may wish to fill out a scope statement that clearly details the objectives and deliverables that are within scope, as well as those that are out of scope.

Avoid scope creep.

As a project progresses, enthusiasm and momentum may tempt a project team to allow a project’s scope to expand beyond its original parameters, leading to scope creep. Though the changes may seem minor, additional goals cost time and/or resources, and may even hinder project completion.

Define what is in scope.

Create a detailed list of the project’s objectives and deliverables, breaking complex items into individual pieces. (In other words, if the project entails building a website to present digitized historical letters, treat the digitized letters and the website itself as two separate deliverables.)

Define what is out of scope.

Determining what you will not be doing can be just as important as determining what you will be doing, especially in terms of preventing confusion and managing your stakeholders’ expectations. Consider what is not within the project’s scope. (These items often follow the phrase, “Wouldn’t it be great if…?”) List any related tasks that may potentially sidetrack the project or its members.

Determine success criteria and constraints.

What constitutes success for the project’s objectives and deliverables? List the criteria, while taking into account success from multiple angles.

• Objectives: How will you determine if the goals of the project have been achieved?
• Deliverables: How will you decide if the deliverables function as intended?
• Budget: What are the budgetary constraints, and how will you work within them?
• Resources: What are the resource constraints, and how will you work within them?
• Timetable: What deadlines must be met?

Making Changes

Change sometimes becomes necessary during the course of a project; however, making adjustments to the project’s scope requires consultation with team members and stakeholders, as well as careful consideration of the proposed change’s impact. Ensure that project resources can accommodate the change, and document the implications for the project’s deliverables, resource requirements, and timeline. (Consider the scope, cost, and time as a triad wherein one element generally may not be altered without affecting the other two.)

Additionally, make sure that it is clear who has the authority to make changes, and what the decision process for making and documenting changes looks like.

Changes should be reflected in updates to both the project charter and scope statement, and new versions of these documents should be distributed to all team members and stakeholders. Alternatively, you made use a change request form and change log to be appended to original project documentation.

 

Projects are rarely undertaken alone, and the larger a project team becomes, the more carefully you should build the team and develop protocols for working together.

How do you know if you need to add team members?

If the team has reached its limits technically (lacks skills), infrastructurally (lacks resources), or intellectually (lacks expertise), or if the current team cannot meet the project’s objectives or provide deliverables on schedule, it might be time to add members.

Do note that the addition of team members may impact the timeline, scope, and/or cost of your project.

Building a Project Team

Below are some areas of expertise and roles that might need to be filled in a digital humanities project (though staffing needs will be project-specific). Be aware that a person may fill more than one role, but no one person should do everything. Building in some redundancy may also be helpful in coping with issues as they arise.

Areas of Expertise:

1. Project Manager: organizes activities, sets meetings, watches deadlines, hires staff, generates reports, monitors risks and issues.
2. Subject Researcher: asks the core academic question, provides subject expertise.
3. Public Humanities Specialist: is attuned to and responds to the needs of the public.
4. Computational Researcher: supports computer development, makes technical decisions, ensures digital best practices.
5. Information Specialist: attends to data curation, preservation, and stewardship.

Project Roles:

1. Project Director/Sponsor: Intellectual and Strategic Leadership
2. Project Manager: Logistics, Planning, and Details
3. Business Manager: Finance and Budgeting
4. Assistant Project Director: Development and Outreach
5. Graphic/Website Designer: Branding, Logos, Website
6. Lead Programmer: Technical Vision and Day-to-Day Supervision
7. Programmers: Hacking, Coding, Building
8. Systems Administrator: Hardware & Software Configuration; Security/Access
9. Educational Specialist: Curriculum Design & Training

Other Stakeholders and Interested Parties

Not everyone invested in a project will participate directly in its development. They may contribute funding (granting agencies), provide physical space (institutions or universities), contribute materials (libraries or archives) or generate publicity (professional contacts in the field). Consider keeping these interested parties involved in decision-making, commensurate with their resource contribution and level of investment in the project.

Managing Teams and Stakeholders

Prior to project initiation, identify clearly what each team member and stakeholder will be contributing to the project. Determine and document their pattern of continued engagement, including communication practices, to ensure efficient transfer of materials and timely project completion.

 

From: Building Your Project Team

Once a project proposal or business case has been accepted, it’s a good idea to gather team members and stakeholders to develop a project charter together. The charter represents an agreement among interested parties regarding the nature of the work to be done, the commitment of resources, the timeline, and expectations (and in general, all parties contributing resources to the project should be included in both approval of and changes to the charter). Some information to consider including in this document follows.

Objectives & Deliverables

What is the purpose of the project? In other words, what is the problem to be solved or need to be addressed, and how will you do it? What product, service, or process will result? Explain, in terms comprehensible to a lay audience, the significance of your project and what it contributes to your field, institution, or community.

Preliminary Scope Statement

Consider not only what objectives and deliverables are within the scope of your project, but also consider what is not. Beware scope creep!

Assumptions & Constraints

Some project work requires enabling conditions be in place (for example, that funding is granted or that a particular software application be institutionally available and supported). List them to ensure that these criteria can be met. In addition, it may be helpful to include any limitations that may prevent completion of the project.

Project Team & Stakeholders

Stakeholders, in addition to project team members, will frequently be invested in the success of the project. List all team members and stakeholders, taking care to detail their roles and responsibilities.

Funding & Budget Information

Document all funding and resources, as well as anticipated expenditures, including equipment, technologies, programs, web hosting, data storage, expertise, and personnel wages.

• Remember to consider not only immediate cost of completing your project, but also ongoing or recurring costs, such as the cost of maintaining or preserving the final product.
• Don’t forget to consider funding and resources external to the ECDS!

Timeline

Build out a detailed timeline, including milestones and deadlines. Note any potential bottlenecks or dependencies. In other words, attend the to relationships among individual parts of the project to avoid unnecessary delays.

• Remember that few, if any, team members will be committing 100% of their time to this project. Take into account team members’ other time commitments.

Other Considerations

A few other items might be worth writing into a project charter:

• publishing rights and credit
• citations/attributions of the final product
• communication practices
• grievance or conflict management procedures
• documentation protocols
• preservation and stewardship

Signatures

Because the charter is an agreement among all parties, each individual or group contributing resources should sign it and retain an up-to-date copy for the duration of the project.

 

From: Charters, Agreements, and Handshake Deals

Documenting the details of a project helps ensure its success. For some projects, you may be required to submit a detailed proposal (or business case) before being provided funding or institutional support. Regardless of formal requirements, these topics deserve thoughtful consideration before the initiation of the project and the commitment of time and resources.

Description & Justification

Describe what you want to do and why.

• Look for similar projects to avoid overlap or replicating others’ work. Determine what is unique about your own project and what you will be contributing to your scholarly community. What problem will be resolved, what question will be answered, or what opportunity will be created, through your project?
• Decide what tools and methods you wish to use. Consider whether these are the most appropriate means to your end, and avoid using technologies for their own sake. Refer continually to your project’s guiding question.

Deliverables

What products or services result?

• Deliverables may include a website, blog post, book, presentation, workshop, publication, virtual exhibit, code, digitized materials, or service.
• Consider deliverables at multiple levels. For example, a website hosting a collection of digitized historical letters comprises two deliverables: the digitized letters and the website itself.

Performance Measures

What constitutes success for the project?

• For each deliverable, document the conditions of its success. Consider not only the details of the product, but also your timeline and resource constraints.
• Be careful to avoid scope creep (i.e., inadvertently allowing the scope to expand beyond that of your proposed project).

Audience & Stakeholders

For whom is your project intended: academics, the general public, your institution, etc.? Who is invested, intellectually as well as financially, in the final products? Ask how to best design your processes and deliverables to reach that audience or meet the needs of interested parties and stakeholders. If considerations of audience and stakeholders become complex, consider completing a stakeholder analysis.

Resources & Funding

What do you need to reach your goals?

• Resources may include funding, equipment, technologies, programs, web hosting, data storage, expertise, and time. Identify entities and groups that may potentially provide these resources (especially through your institution).
• Investigate grants through foundations like the NEH, the Mellon Foundation, and other granting agencies to locate potential funding.

Timeline

How long will your project take?

• Remember to consider milestones, deadlines, and potential bottlenecks or resource constraints.

The first step in developing a digital humanities project is selecting a topic, and it may be helpful to organize your project around answering a central question.

Tips for formulating your question:

• Ask what you are passionate about and what you enjoy spending time on.
• Think about issues your field continually argues about. Remember, the question may not be new to your discipline, but the approach might be.
• Know that a good research idea is more about communication than creativity. The question, as well as your approach, needs to be clear.
• Understand that digital project ideas are built, not discovered.

A project:

• is a sequence of related activities with a definite beginning and end.
• is derived from a central question, issue, or problem.
• requires resources.
• requires an audience and/or other participants.
• results in a product or service.

Examples of products: events (meeting, workshop, conference, symposium); research (analysis, investigation, experiment, monograph); methodologies/tools (code, website, curriculum)

Projects are about: telling a story, writing an argument, answering a question, developing a theory.

5 Parts of a Research Project:

1. question, problem, provocation
2. sources (primary or secondary)
3. analytical/discovery activity
4. audience
5. concrete products (deliverables)

Types of Digital Humanities Projects:

• those that produce humanistic knowledge (e.g., building digital exhibits, text encoding)
• those that discover existing knowledge (e.g., by digitizing and making available materials to other people, or crowdsourcing the transcription of audio)
• those that analyze knowledge (e.g., text mining, mapping the flow of historical letters)
• those that preserve knowledge (e.g., bit curation)

 

From: Formulating Disciplinary Questions as Research Ideas