Process Development and Documentation as a Deliverable

Introduction

This blog post is about some of the work that I’m doing to help launch Hesburgh Libraries 📖’s Strategic Innovation Lab (SI Lab 📖).

The SI Lab’s purpose statement is as follows:

As a part of the Office of University Librarian, the Strategic Innovation Lab’s charge is to focus on the 2 to 5 year range for how the Hesburgh Libraries can position itself to meet changing campus stakeholder needs. In partnership with library stakeholders, the Strategic Innovation Lab investigates and defines opportunities (e.g., business cases) that inform strategic decision making in alignment with stated organizational priorities.

From that purpose, we’ve established eight key principles:

• Advance the Hesburgh Libraries’ mission and vision.
• Think long term.
• Focus on user needs.
• Support the whole organization.
• Communicate effectively.
• Conserve organizational resources.
• Integrate & Include diverse perspectives.
• Model innovation culture of learning and experimentation.

We’re positioning the SI Lab to develop processes that can receive organizational problem statements and work to clarify those problems and perhaps engage in ideation and developing approaches to solving the problem. In Bringing the Whole Toolkit to Problem-Solving I wrote about the four problem solving phases and preferences: Clarification, Ideation, Development, and Implementation.

Given that we’re creating new processes, and don’t have a mandate to implement services or products, we can assume that our work will inform later work. What follows is my outlines of the high level considerations for the SI Lab’s projects.

What follows is a draft document, highlighting some of the preliminary process design with a focus on documentation.

Before thinking through implementation details, I want to capture how we reference and connect documentation, as that will be a key deliverable of our work.

In this case, I’m thinking of documentation as a means of delivering on transparency. Some of the documentation will itself be a deliverable (e.g., a completed Purpose and Principles Statement) whereas other documentation is around decision-making (e.g., discussion about status change of a project).

Glossary and Conceptual Ideas

I’m including this to help separate three conceptual ideas:

• Project
• Task
• Problem Statement

The above terms require some definition. By a Project, I mean a time-bound group of activities with clear start and finish criteria. For example, writing this document could be considered a project. I do not necessarily mean for this project to be something managed by the Project Management Office. A Problem Statement is a submitted and observed problem. A Task is an activity within a project. By definition, a task could itself be a project.

Someone submits a problem statement. When SI Lab begins working through a problem statement, we create a project of type “Problem Statement Evaluation”. For this problem statement evaluation project, our primary focus is to clarify the submitted problem statement. Note, work is not done “on the problem statement” but instead on the project (via tasks). Output of the project may be updating/adding documentation for the referenced problem statement. The act of clarification may reference other problem statements or projects.

That last sentence is critical to the data model; with only one project type, we have the possibility that we’ll reference more than one problem statement (even though the goal of the project is to evaluate the initial problem statement). As we imagine other project types (e.g. prototype a service), it is conceivable that that “prototype a service” project would reference multiple problem statements that all allude to a solution explored by the prototype.

Another consideration is the status change log. With transparency as a goal, not only is the current status of a project, task, or problem statement useful, but so is the decisions that went into “moving something along.” The status change log can be a useful point of reference when we start a project and there might be past explanations to help guide future work.

What are the Activities Referencing the Documentation

• See the current state of a project
• See the state of all projects
• To help onboard a new project participant
• Place to develop ideas
• Hand-off current work to next group
• Place to reference decisions made regarding a project
• A reference point for future projects
• Look at who worked on a project
• A place to capture meeting agenda, minutes, and tasks

Conceptual Relationship Diagram

Below is a relationship diagram of the concepts and possible activities.

@startuml
entity ProjectType {
  name
  workflow
  documentation location
}
entity Template {
  location of template
}
entity ProjectTypeTemplates
entity Project {
  status
  date started
  documentation location
  project type
}
entity ProblemStatement {
  description
  status
  date submitted
  documentation location
}
entity Task {
  status
  description
  documentation location
  project
}
entity Reference {
  explanation
}
interface Referenceable {
  as Interface
}
entity StatusChangeLog {
  from status
  to status
  date of status change
  explanation
}
abstract Artifact {
  literature review
  research
  decision document
  meeting
  README
}
ProjectType |o..o{ ProjectTypeTemplates
Template |o..o{ ProjectTypeTemplates
Reference }o--o| Project
Reference }o--o| ProblemStatement
StatusChangeLog }o--o| Project
Artifact }o..|| Project : written to\ndocumentation\nlocation
StatusChangeLog }o--o| ProblemStatement
Reference }o--o| Referenceable
Project ..* Referenceable : is a\nreferenceable
ProblemStatement ..* Referenceable : is a\nreferenceable
Task }o--|| Project
Project }o..|| ProjectType
@enduml

From the conceptual diagram there are some data organization considerations.

Problem Statements Dashboard

• Date Submitted
• Status Updated on Date
• Status
• Description

Possible Attributes

• Associated Projects

Projects Dashboard

The Projects Dashboard provides high-level insight to all of the projects, their current state, and provides wayfinding to each project’s documentation.

Useful attributes for a project on the Projects Dashboard are:

• Date Created
• Status Updated on Date
• Status
• Name
• Short Description
• Project Type
• Location of Documentation

Possible attributes:

• Status change history (date of change and to what state)
• List of people on the project
• Associated Problem Statements

Project’s Documentation

Each project should have self-contained documentation. With a single self-contained location, the “Location of Documentation” attribute from the Projects Dashboard will need only one entry.

For simplicity, let’s assume that each project has it’s own directory. The project’s directory should have a meaningful name. This would be the “Name” attribute from the Projects Dashboard.

README

Within the top-level project’s directory, there should be a README file. The README file should orient people to the project. The contents of the README file should include the date someone submitted the project and the project’s name. The state of the project and location of documentation may be useful; Imagine if someone printed out the README, what would be useful. Note: One challenge of status is the duplication of information from the Projects Dashboard and the Project’s README.

Status Changes

Given that projects have a status, we should provide documentation on when and why we changed status. That documentation could point to an evaluation rubric used for determining status. These status change overviews might make sense in the project README.

Tasks Dashboard

There’s an assumption of work to be done. A list of tasks with the following attributes:

• Date Created
• Status Updated On Date
• Status
• Name
• Responsibility matrix assignment (RACI 📖) matrix
• Location of Documentation (if applicable)

Task

Some tasks may require space for collaborative development. For example, the task “Draft a Purpose and Principles statement” will require a space to capture that work and to solicit feedback.

Meetings

Invariably, there will be meetings associated with the project. Each meeting should have a clear agenda, a list of attendees (and those that send regrets), a place for minutes, and tasks to create. Those tasks should be visible on the Tasks Dashboard.

Decisions

There will be decisions made regarding the project. In some cases, those decisions may warrant documentation. That documentation could point to meetings or action items.

Research

As part of delivering a project, there will be research activities. The research material may not map one to one to tasks (e.g. many tasks may build from the synthesis of research). The project’s documentation should provide wayfinding to the materials used in research.

Literature Review

Given that there will be research activities and decisions, we should provide a place for literature review.

Develop Solutions

For a project, it looks as though a file system would be useful. I’m disinclined to think in terms of attachments, as an attachment represents the document at a fixed point in time. Attaching a research article to a project might make sense, but attaching the project’s literature review may not (as one task in the project might be writing and developing the literature review).

Another observation that comes from years of software development is that the closer the documentation is to the code, the more likely the documentation reflects the implementation of the code. I map this observation to project tasks and inter-related documentation. For example, meetings generate tasks. Meeting agenda and minutes are documentation as are task assignment, creation, and status updates. However, the execution of the tasks may or may not create artifacts.