Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Initial Request

  • Select a feature to work on in the product request spreadsheet (which will be updated with pain points when we start investigating them)

  • Compile all information regarding this feature that is currently available before reaching out

  • Check in with @Leroy Shaigorodsky / PM for the area (if there is one) for any other initial context

  • Play around on Finish Line to try and recreate the issue. If you need permissions or to actually create/edit something, you should run it locally.

  • Set up a slack thread to investigate in #software_product_requests, making sure to ping the following people:

    • @Leroy Shaigorodsky

    • @Reid Chandler / @Arnav Joshi (depending on which team this feature will apply too)

    • @Anthony Bernardi

    • @Principle Stakeholder (whoever is noted in the document for you to reach out too)

      • If this is a pain point, you can reach out to @Leroy if you aren’t sure who to contact

    • During this inquiry, make sure to check in with the necessary questions with @Leroy before you reach out.

    • The above slack thread may become a meeting if the scope is large enough

Design process

  • Write up a solution (or a few, if needed) based on feedback

  • Check in with @Leroy Shaigorodsky about your findings from the meetings and your proposed solution in the #software_product channel

  • Once a direction is approved, flesh out the sketches and work on detailing the specs in a GitHub ticket

    • Epics will need more focus

    • Tickets will need to include all business logic and necessary mockups

  • The expectation will be daily / every other day check ins in #software_product -> make sure to ping Product Leadership for questions

  • When you reach a good stage and are ready for pen-final review, move to next section

Review

...

Introduction

The purpose of this document is to thoroughly record the purpose, metrics, and roadmap for the Northeastern Electric Racing Project Management Dashboard website (“NER FinishLine”).

This document will help articulate the why and the what behind the product, the motivation for building it, and the impact that it should have on the team.

Users

The NER FinishLine's primary users are NER’s Project Leads, PMO members, and other NER leadership. These three user segments will likely give rise to specific application user profiles. Below is a list of the focus and priorities for each user group:

Project Leads

  • The one or two projects they are assigned to lead

  • The expectations for what should be done for those projects

  • Submitting the necessary updates to those projects

PMO members

  • The few projects that they are responsible for

  • Understanding upcoming deadlines

  • Both submitting and processing change requests

Other NER leadership

  • Seeing a general view of active projects

  • Drilling down into project details as is necessary

Metrics

Metrics that are important and relevant to the NER FinishLine are as follows:

  • Change request turnaround time

  • Measured as the average duration between a change request being submitted and fully implemented

  • One of the primary metrics that the NER FinishLine should help improve

  • Lower turnaround time helps keep the PM System accurate and up-to-date

  • Weekly active users

  • Measured as the total number of users who have logged in within the last 7 days

  • A secondary metric that the NER FinishLine should help improve

  • Higher weekly active users represents more club members interacting with the PM System, thereby increasing awareness and understanding of project activities and expectations

  • Change requests citing estimation issues

  • Measured as the total number of change requests which include "Estimation Issues" as a reason / cause in the last 90 days

  • A minor extended metric that the NER FinishLine will hopefully help improve

  • Fewer change requests being submitted due to estimation errors represents more accurate planning of projects and work packages, making it easier to manage and monitor the portfolio of projects

  • Estimation errors are highly dependent on the human element of project planning; the NER FinishLine is intended to provide increased information specificity, clarity, and transparency

  • Work package delays

  • Measured as the average percent increase in work package duration as a result of a change request containing a timeline impact element over the last 12 months

  • Fewer work package delays represents both more accurate duration estimations and fewer timeline-impacting issues cropping up

  • A metric that the NER FinishLine will primarily serve to help measure

Business Value

The value of the NER FinishLine is in increasing the accuracy, efficiency, and effectiveness of NER's Project Management System. The NER FinishLine also serves as an engaging learning environment for club members interested in learning about the design and development of professional-scale web applications.

Risks

The key risks associated with the NER FinishLine v2 project are related to team members and expertise.

Attracting and retaining committed team members to contribute to the project has proven to be difficult from experience with the NER FinishLine v1 and the first 6 months of the NEW FinishLine v2.

Additionally, having team members that are experts in both the club's project management system and software development is close to impossible.

Mitigation efforts primarily surround engaging the club's Outreach team to pursue student outreach to Khoury College students and holding learning sessions to teach project team members about the club's project management system.