Tag Archives: projects

Announcements, First Wednesday, Technology

New Project Request Process

Last week, I presented our New Project Request Process at First Wednesday.  This request process is to help the Digital Strategies & Technology (DST) Leadership Team more effectively evaluate and prioritize projects that require ITS resources.  Over the summer, we developed and tested a two-stage workflow aimed to lower the barrier for library staff to submit project ideas and streamline the prioritization of projects into our three new project management streams: Library Systems, led by Karen Newbery; Web Experience, led by Tom Crichlow, and Application Development, led by Cory Lown, or into the existing Operations stream, led by John Pormann.

You can view the presentation here.  (My presentation begins at 35:45, but you should definitely watch Karen present on the Updated Request App and her trip to DKU.)

The quick summary notes of our process is this:

  • Project Summary is a short, one page summary of your project idea that includes 4 major elements:
    • Summary
    • Project Rationale
    • Goals
    • Stakeholders
  • The DST Leadership will evaluate Project Summaries within one month of submission and accept it, decline it, or request more information.
  • Accepted Project Summaries will be assigned a Project Lead, who will guide the Project Sponsor in writing the Project Charter.
  • Project Charter is an in-depth project plan that includes these elements:
    • Project Details:
      • Requirements – list of the high-level project requirements
      • Scope Statement – narrative description of the project scope
      • Deliverables – A deliverable is a unique and verifiable product, result or capability to perform a service that must be produced to complete a process, phase or project.
      • Estimated Schedule – focus on schedule and timeline, not specific dates
      • Completion Criteria – what must occur before project is considered complete
      • Goals – specific measurable objectives the project must achieve for completion
      • Dependencies – any outside factors, including people, data, and systems
      • Collaboration and communication strategy – frequency of meetings, project management tools used, plan to provide communication to those outside the project
    • Risks to Scope, Budget, Resources, Schedule, Technologies
    • Stakeholders – people outside of ITS (List of names and contact information)
    • Project Team – roles needed for team (Specific team members will be assigned, if project is approved and scheduled)
    • Budget – especially important for grant-based projects
  • The DST Leadership will review Project Charters within one month of submission.  Accepted project charters will be prioritized based on one or more of the following:
    • Portfolio Management review of resources by the Director, ITS
    • EG input for projects involving two or more divisions, or that impact campus users, or that impact a majority of DUL staff
    • Input of corresponding AUL, if competing projects require same team members of an previously approved project in queue
    • Input from DUL department or existing committee with governance oversight of a particular area, such as WebX or Digital Preservation and Production Program

We believe this process will enable us to plan projects more effectively with project sponsors and utilize the Libraries’ resources more efficiently.  We also believe this will improve communication with stakeholders and provide EG with better information to make priority decisions for projects that have benefit or impact to our staff and users.

You can download the Project Summary and Charter template here.  You can submit your Project Summary to dst-lt@win.duke.edu.

 

Announcements, Behind the Scenes, Duke Digital Repository, Projects

Change is afoot in Software Development and Integration Services

We’re experimenting with changing our approach to projects in Software Development and Integration Services (SDIS). There’s been much talk of Agile (see the Agile Manifesto) over the past few years within our department, but we’ve faced challenges implementing this as an approach to our work given our broad portfolio, relatively small team, and large number of internal stakeholders.

After some productive conversations among staff and managers in SDIS where we reflected on our work over the past few years we decided to commit to applying the Scrum framework to one or more projects.

Scrum Framework
Source: https://commons.wikimedia.org/wiki/File:Scrum_Framework.png

There are many resources available for learning about Agile and Scrum. The resources I’ve found most useful so far in learning about the framework include:

Scrum seems best suited to developing new products or software and defines the roles, workflow, and artifacts that help a team make the most of its capacity to build the highest value features first and deliver usable software on a regular and frequent schedule.

To start, we’ll be applying this process to a new project to build a prototype of a research data repository based on Hyrax. We’ve formed a small team, including a product owner, scrum master, and development team to build the repository. So far, we’ve developed an initial backlog of requirements in the form of user stories in Jira, the software we use to manage projects. We’ve done some backlog refinement to prioritize the most important and highest value features, and defined acceptance criteria for the ones that we’ll consider first. The development team has estimated the story points (relative estimate of effort and complexity) for some of the user stories to help us with sprint planning and release projection. Our first two-week sprint will begin the week after Thanksgiving. By the end of January we expect to have completed four, two-week sprints and have a pilot ready with a basic set of features implemented for evaluation by internal stakeholders.

One of the important aspects of Scrum is that group reflection on the process itself is built into the workflow through retrospective meetings after each sprint. Done right, routine retrospectives serve to reinforce what is working well and allows for adjustments to address things that aren’t. In the future we hope to adapt what we learn from applying the Scrum framework to the research data repository pilot to improve our approach to other aspects of our work in SDIS.