From 93a0f01ecf6f9c1e59338ac64308287a1b37f298 Mon Sep 17 00:00:00 2001 From: samglover Date: Fri, 23 May 2025 12:06:57 -0500 Subject: [PATCH 1/6] Move Working with teams page to archived pages --- docs/{get_started => archive}/working_with_teams.md | 0 docs/get_started/beginners_guide.md | 2 +- docusaurus.config.js | 4 ++++ sidebars.js | 2 +- 4 files changed, 6 insertions(+), 2 deletions(-) rename docs/{get_started => archive}/working_with_teams.md (100%) diff --git a/docs/get_started/working_with_teams.md b/docs/archive/working_with_teams.md similarity index 100% rename from docs/get_started/working_with_teams.md rename to docs/archive/working_with_teams.md diff --git a/docs/get_started/beginners_guide.md b/docs/get_started/beginners_guide.md index a36647d95..d96a026b1 100644 --- a/docs/get_started/beginners_guide.md +++ b/docs/get_started/beginners_guide.md @@ -45,7 +45,7 @@ Now you are probably itching to start building your first interview! But before ## Review the interview project management guide -Building a successful interview involves more than just coding in the Docassemble playground. You'll also need to consider things like project management, [working with a team](working_with_teams.md), [requirements](working_with_teams.md#understanding-the-projects-users-and-intended-purpose), [usability](../style_guide/question_style_overview.md), [testing](../components/ALKiln/intro.mdx), etc. +Building a successful interview involves more than just coding in the Docassemble playground. You'll also need to consider [project management](project_management.md), [usability](../style_guide/question_style_overview.md), [testing](../components/ALKiln/intro.mdx), etc. **➡️ [Review the interview project management guide.](project_management.md)** diff --git a/docusaurus.config.js b/docusaurus.config.js index c861c7ee3..45641c7a8 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -124,6 +124,10 @@ module.exports = { { from: '/docs/alkiln/security', to: '/docs/components/ALKiln/security' + }, + { + from: '/docs/get_started/working_with_teams', + to: '/docs/archive/working_with_teams' } ] } diff --git a/sidebars.js b/sidebars.js index 672516a51..8e2ffc9fb 100644 --- a/sidebars.js +++ b/sidebars.js @@ -13,7 +13,6 @@ module.exports = { items: [ 'get_started/project_management', 'get_started/search_engine_optimization', - 'get_started/working_with_teams', ], }, 'get_started/resources', @@ -30,6 +29,7 @@ module.exports = { type: 'category', items: [ 'archive/bootcamp', + 'archive/working_with_teams', ], } ], From e2bbe0955ddb4d016ee193fab375645f140e90f7 Mon Sep 17 00:00:00 2001 From: samglover Date: Thu, 29 May 2025 09:27:08 -0500 Subject: [PATCH 2/6] Saving WIP on the project management page --- docs/get_started/project_management.md | 463 +++++++++++++++++++------ 1 file changed, 352 insertions(+), 111 deletions(-) diff --git a/docs/get_started/project_management.md b/docs/get_started/project_management.md index 086ace258..3a97458ab 100644 --- a/docs/get_started/project_management.md +++ b/docs/get_started/project_management.md @@ -1,154 +1,194 @@ --- id: project_management -title: Interview project management guide +title: Interview project management and working with teams sidebar_label: Project management slug: project_management +toc_max_heading_level: 4 --- -Whether you are a LIT Clinic student, a recent [Forms Camp](https://www.ncsc.org/consulting-and-research/areas-of-expertise/access-to-justice/forms-camp) graduate, or anyone else getting started on an interview-building project, this page will guide you through the stages of a successful project. +Whether you are building interviews for a court or legal aid organization, a LIT Clinic student, a recent [Forms Camp](https://www.ncsc.org/consulting-and-research/areas-of-expertise/access-to-justice/forms-camp) graduate, or anyone else building online guided interviews, this page will guide you through the stages of a successful project. -This roadmap reflects the procedures, templates, and tools the LIT Lab uses on our own interview-building projects, which you can adapt to your projects. +This contains the procedures, templates, and tools the LIT Lab uses on our own interview-building projects, which you can adapt to yours. :::tip If this is your first interview-building project, it may help to read more about [planning and building your first expert system](https://projects.suffolklitlab.org/legal-tech-class/docs/interview-structure/building-an-app-outline). ::: -## Identify key roles & responsibilities +## Overview {#overview} -![Interview project roles & lines of communication](../assets/interview-project-roles-communication.png) +Interview-building project generally follows these phases: -Every interview project has: +| Phase | Primary goal | +| :------------------------------ | :-------------------- | +| [Kickoff](#kickoff) | See [sample agenda](#kickoff:~:text=Sample%20kickoff%20meeting%20agenda) | +| [Research](#research) | Gain insight into and understanding of the problem to be solved | +| [Design](#design) | Agree on an MVP | +| [Development](#development) | Build the interview | +| [Feedback](#feedback) | 1–3 rounds of feedback and further development |per feedback round | +| [Launch](#launch) | Publish the interview | +| [Promotion](#promotion) | Ensure that people who need the interview will | +| [Retrospective](#retrospective) | Identify areas of improvement for the next interview project | -1. **Interview builders.** The person or team responsible for building the actual interview. -2. **Decisionmaker.** One person who is responsible for managing stakeholders and converting their feedback into clear decisions for the interview builders. -3. **Stakeholders.** Anyone who needs to have a say in the interview project, such as managers, judges, clerks, subject matter experts, IT staff, and users (self-represented litigants and lawyers). +After the kickoff through launch, the interview building team should hold regular [standups](#development-standups) and [check-ins](#decisionmaker-check-ins) with the decisionmaker and key stakeholders, with additional [communication](#communication) as necessary. -:::note -You may have a team of interview builders and dozens of stakeholders, or you may be the only person working on this project. Even if this is a solo project, it helps to keep your different roles in mind. -::: +### Research {#research} -### The decisionmaker +Before you start building anything, gain a thorough understanding of the problem you are trying to solve. -**While a successful interview project needs all these roles, the decisionmaker is especially important.** Most interview projects involve multiple stakeholders. When the interview building team requests guidance or feedback, multiple stakeholders may give multiple responses that may be confusing or conflicting and dramatically slow progress. +Work with the decisionmaker and subject-matter experts to document the process and develop user personas. Make sure they agree with your understanding before you move on to [design](#design). -The decisionmaker's job is to gather and clarify stakeholders' feedback so that interview builders have clear decisions to work from. The decisionmaker's responsibilities also include: +#### Document the process {#document-process} -* Being a single point of contact and single source of decisions -* Regular meetings with the interview building team -* Timely responses to requests for decisions and feedback -* Gathering feedback or approvals from stakeholders and converting it to clear decisions -* Making the go/no-go decision to launch the interview +An online guided interview is a single step in a larger and more complex process. -The decisionmaker must either (1) have the authority necessary to carry out these responsiblities, or (2) be responsible for getting authority when necessary. +Start by researching that process from beginning to end—especially what happens before and after someone completes your interview. It always helps to interview someone with experience and observe while someone goes through the process, or both. -## Kickoff meeting +
+ Process documentation checklist -Schedule a kickoff meeting for the project as early as possible. The interview building team, the decisionmaker, and the key stakeholders should attend. + 1. Familiarize yourself with the relevant law and procedure + 2. Identify 2 or 3 subject-matter experts you can call on + 3. Create a flowchart of the process from beginning to end + 4. Identify the user's ultimate goal + 5. What must have happened in order for someone to use this interview? + 6. What pieces of information will the user need to provide during the interview? Make a list, and classify each according to the [Jarrett and Gaffney](https://www.sciencedirect.com/book/9781558607101/forms-that-work) framework: + * **Slot-in** information the user already knows, like their own name and address + * **Gathered** information the user will look up from a readily available source like a court notice or a government ID (that you can tell them they will need before they start!) + * **Third-party** information the user will get by calling someone or looking it up in a database (make a list of the sources of this information) + * **Created** answers the user will make on the spot + 7. What documents must the interview assemble? + 8. What will the user have to do after completing the interview? +
-The goal of a kickoff meeting is to get everyone on the same page when it comes to roles, expectations, and timeline. A good kickoff meeting sets the stage for a successful project. +#### User research and personas {#user-research} -Here is a sample kickoff meeting agenda: - -* Introductions -* Identify the decisionmaker -* Development process overview (use this page) -* Schedule regular check-ins with the decisionmaker and one or two key stakeholders -* Introduce the source form/document, its context, and its users. In other words: - * Who can use this interview? In which language(s) will they be able to read and write? (Consider creating a couple of [user personas](https://en.wikipedia.org/wiki/Persona_(user_experience)) together.) - * What are they called (i.e., plaintiff, respondent, or appellee)? - * What can/can't this interview be used to do? - * Explain the court process leading up to someone using this interview. - * Identify the substantive laws or procedural rules the interview builders should be familiar with. - * Where and how must the completed documents be filed, served, or delivered? -* Agree on a [minimum viable product (MVP)](#stick-to-an-mvp) -* Define the requirements for this interview -* Agree on a process for changing the scope of the project (i.e., adding features) -* Discuss the timeline. Key dates: - * Start date - * Draft interview completed - * Preliminary feedback - * Decisionmaker/stakeholder feedback - * Interview finalized and ready for go/no-go decision - * Launch - * Promotion -* Discuss what success looks like for this project, and how you will measure it -* Consider doing a [pre-mortem](https://en.wikipedia.org/wiki/Pre-mortem)—imagine this project has failed and discuss why +Describe the intended user of the interview. -:::tip -### Stick to an MVP -A minimum viable product (MVP) is the essence of of iterative, incremental development—first make something that works, then make it better. +* Legal knowledge +* Assistance +* Education level +* Languages they can speak +* Languages they can read and write +* Reading comprehension level +* Time available +* Access to technology (computer, smartphone, printer, etc.) +* Reliable internet access +* Stress or trauma involved in this process -Consider [Henrik Kniberg's skateboard analogy](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp): +Consider creating 2 or 3 [user personas](https://en.wikipedia.org/wiki/Persona_(user_experience)) that together describe likely interview users. Considering design and development problems from the perspective of your user personas can give you insight into what actual users will need from it. -![Minimum viable product](../assets/mvp.png) +:::warning +If your user personas are too general, they won't be help you focus. If they are too specific, they can result in blind spots and missed opportunities. -Different projects will have different MVPs/"skateboards". The [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) can help you identify the MVP for your project (interviews built for the general public should usually target level 2+). Once you decide what this project's MVP is, stick to it. Don't add to the MVP without a compelling justification. +Even if your personas are about the right specificity, watch out for blind spots—details that could lead to a poor experience for other likely users. In the sample persona below, for example, "Maria" is a single mother. That's a helpful detail for understanding what someone facing eviction might be experiencing, but you probably wouldn't want to build an eviction defense tool that assumes all users are single mothers. + +To strike the right balance, each user persona should reflect about 20–30% of likely users. Then, if you create 2 or 3 user personas, they should cover the majority of likely users. Even so, when you always check for blind spots when referring to a persona=! ::: -## Complete the draft interview +
+ Sample persona for an eviction defense tool -After the kickoff meeting it is time to get to work! As you work on the interview, follow the [GitHub workflow](../authoring/github.md#workflow). If you get stuck on a problem for more than twenty minutes, ask for help. (Use the [Resources](resources.md) page to find options.) + **Maria Tenant** -:::tip -The LIT Lab's [interview project template](https://github.com/orgs/SuffolkLITLab/projects/22) can help you keep your project organized and on track. Just click the **Use this template** button to use it. (You'll need a free [GitHub](../authoring/github.md) account.) -::: + | Details | | + | :---------------- | :------------ | + | Age | 35 | + | Location | Boston, MA | + | Occupation | Retail worker | + | Family status | Single mother with 2 children, ages 8 and 5 | + | Income | Low | + | Housing status | She is renting a 2-bedroom apartment in a building occupied primarily by other low-income families | + | Technology use | She owns an older Android smartphone with a limited data plan; uses social media and does all her communication on her phone | -## Meeting cadence + | Challenges | | + | :---------------------- | :- | + | Financial strain | She earns $20,000 per year, which isn't enough for her expenses. She often has to decide between paying different bills. | + | Limited legal knowledge | She has limited understanding of her rights as a tenant and feels intimidated by legal processes. | + | Limited resources | She has limited access to technology and legal assistance due to her financial situation and work hours. | -Two recurring meetings will help you keep the project moving forward. These are short, 5–15 minute "standup" meetings to share progress and identify and remove blockers—anything preventing someone from making progress. + | Goals | | + | :--------- | :- | + | Stability | Her primary goal is to provide a stable home for her children. She wants to avoid eviction to maintain access to her children’s school and her local support network. | + | Education | She is keen to learn more about her rights as a tenant and how she can legally contest an unfair eviction. | + | Assistance | Maria needs easy-to-understand, accessible legal advice and support that fits into her limited budget and time constraints. | +
-### Interview-building team meetings +### Design {#design} -The interview-building team should meet frequently. Daily check-ins are common on active projects, and anything less than weekly is unlikely to be effective. +Before you start building anything, make sure everyone agrees on what you will be building. -:::tip -Consider incorporating our Monday community meetings into your standup schedule. We run them standup-style, with time for solving blockers as a group. If this is a solo project, the Document Assembly Line community can be part of your interview-building team! -::: +#### Identify the project requirements/MVP {#requirements} -These meetings should follow a straightforward standing agenda. Each person on the team should share: +Start by listing the requirements for your project—what it must do to be acceptable. Remember that you are building the *first* version of this interview, and you can iterate and improve on it in the future. Start by building something that works, using the minimum viable product concept as a guide. -1. **Progress:** what they worked on or accomplished since the last meeting -2. **Plan:** what they are working on now -3. **Blockers:** issues that are preventing them from making progress +
+ Minimum viable product (MVP) -The reason for sharing your progress and plan for the day or week is so that everyone has an idea what everyone else is working on. This is necessary for the project manager, and can help interview builders avoid code conflicts or identify when it's time to merge branches. + First make something that works, then make it better. Consider [Henrik Kniberg's skateboard analogy](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp): -The reason for sharing blockers is to get help. Some teams reserve a larger block of time and use it to solve blockers together, like we do in our Monday community meetings. Other teams prefer to solve blockers separately. And sometimes a blocker is a question you need answered by the decisionmaker. + ![Minimum viable product](../assets/mvp.png) -### Decisionmaker meetings + Different projects will have different MVPs/skateboards. +
-Weekly or every-other week meetings with the decisionmaker and one or two key stakeholders are a chance to keep them informed of your progress and get decisions when you need them to move forward. The standing agenda is similar to the one above: +The LIT Lab's [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) is a framework for thinking about your MVP. For interviews built for legal professionals, level 1.5 is usually enough. Interviews built for the general public should usually target level 2+. Levels 3 and 4 are meant for future iterations. -1. **Progress:** what the interview-building team worked on or accomplished since the last meeting -2. **Plan:** what the interview-building team plans to work on between now and the next meeting -3. **Questions:** oustanding questions that are preventing the interview-building team from making progress +An MVP can be as simple as a list of requirements. -When sharing progress and the current plan, it can help to give a percentage estimate. Something like: "We think we are about 30% of the way to a complete draft interview, and by our next meeting we hope to be at 50%." +
+ Sample MVP description for a court form -:::tip -Use [GitHub issues](../authoring/github.md#use-issues) to keep track of your questions for the decisionmaker. If you add a **question** label to issues, it is easy to pull up the list of your questions during a meeting. -::: + Maturity model target level: 2 -To get better answers, ask questions better. Here are some tips for asking questions: + * The interview flows like a natural-language intake with a new legal aid employee + * Compound questions are broken up into separate screens + * The interview uses branching logic to skip unnecessary questions and provide a logical flow + * The user is not asked for the same information twice + * The interview correctly populates every field on the form + * The user can sign on their computer or phone screen + * Questions are written in plain language (for a 6th-grade reading level) + * The user will be offered a next-steps document to download + * The form identifies users who cannot use the firm as early as possible, and gives them an "off-ramp" + * The interview has been approved by key subject-matter experts + * The interview has been tested rigorously with a combination of scenario-baesd user testing, random input testing, or automated testing +
-* Only ask for a decisions when you can't make it yourself. Before you pose a question to the decisionmaker, ask your interview-building team (or the community). -* Avoid open-ended questions. When you decide to pose a question to the decisionmaker, give them two or three options and explain the pros, cons, and implications of each. -* If you do ask an open-ended question, explain that you are trying to generate ideas, not decide on a solution. -* Don't ask the decisionmaker to design the interview. It is usually better to ask for goals ("Do you need the attorney's ID number?"), not details ("Do you want the ID number field to show up right under the attorney's name field?"). +Once everyone agrees on an MVP for this project, stick to it. Refer to the MVP description to help resolve questions about to Don't add to the MVP without a compelling justification. -**Remember: if you ask a question you will get an answer.** If you don't need an answer, asking for one is not likely to help and may complicate the project. -Finally, when showing the relevant part of the interview as part of asking a question, remind the decisionmaker and stakeholders that the interview is a work in progress and you are not ready for feedback beyond the answer to your question. +#### Create a flowchart -## Get feedback on the interview +Create a flowchart showing branching logic, follow-up questions, and changes to the output documents -Once the interview works from start to finish and you have closed all the issues that are in scope for the [MVP](#stick-to-an-mvp), it is ready for feedback. Start by getting preliminary feedback from someone with Document Assembly Line experience. After you have made revisions based on the preliminary feedback, give the interview to the decisionmaker and stakeholders for their feedback. +#### Wireframing -:::tip -For complex interviews that involve multiple forms/templates, consider doing this in stages. Start with the simplest form and get preliminary and stakeholder feedback early. Then move on to the most complex form to confirm the shape and logic of the overall interview. Then continue with the remaining forms. +Use wireframes, decision trees, and other low-fidelity tools to "sketch" the interview you are going to build. + +### Development {#development} + +#### Work planning + +The LIT Lab's interview project template can help you keep your team organized and your project on track. It is based on the [Scrum agile project management framework](https://www.atlassian.com/agile/scrum). To use the project template: + +1. Make a copy of the [interview project template](https://github.com/orgs/SuffolkLITLab/projects/22) by clicking the **Use this template** button (you'll need a free [GitHub](../authoring/github.md) account) +2. Once you have [published your interview to GitHub](../authoring/github.md#publish-your-interview-to-github), [connect the project board to your interview repository](https://github.com/orgs/SuffolkLITLab/projects/22/views/2?pane=issue&itemId=66449601) + 1. New issues will be added to the backlog automatically + 2. Issues will be closed automatically when the card is moved to the **Done** column +3. As you work on the interview, follow the [GitHub workflow](../authoring/github.md#workflow) and move issues/cards from left to right + +### Feedback {#feedback} + +Once the interview works from start to finish and you have closed all the issues that are in scope for the [MVP](#mvp), it is ready for feedback. Start by getting feedback internally, from your team. After you have made revisions based on the internal feedback, get external feednack from the decisionmaker and stakeholders. + +After getting feedback, create a [GitHub issue](../authoring/github.md#use-issues) for each change request from the tester or decisionmaker. Consider this your "punch list" to finish the project. Then get back to work on those issues! + +When you have closed all the issues/items on your punch list, send it back to the decisionmaker for further feedback. Each round of feedback should result in fewer change requests and move the project closer to completion. + +:::info +Two rounds of feedback and revision are usually enough. ::: -### Preliminary feedback +#### Internal feedback Before you show the interview to the decisionmaker and stakeholders, get someone with Document Assembly Line experience to test it with you. This will help you identify issues you may have missed and questions you still need to ask the decisionmaker. @@ -164,9 +204,9 @@ During the demonstration or testing: * Ask them to follow different branches of the interview logic * Listen carefully to their feedback and ask follow-up questions to make sure you understand it -### Stakeholder feedback +#### Client feedback -Once you have closed all the issues that are in scope for the [MVP](#stick-to-an-mvp) and tested the interview yourself, it should be ready to hand off to the decisionmaker and stakeholders for their testing and feedback. +Once you have closed all the issues that are in scope for the [MVP](#mvp) and tested the interview yourself, it should be ready to hand off to the decisionmaker and stakeholders for their testing and feedback. Share the interview with the decisionmaker and give them a few tips for giving helpful feedback: @@ -175,17 +215,7 @@ Share the interview with the decisionmaker and give them a few tips for giving h * Change requests should be specific. For example, if the text of a question should be changed, the change request should include the new text. * At the top of each page of the interview is an ID. Use the ID to refer to specific interview pages, not a page number. -## Revise the interview - -After getting feedback, create a [GitHub issue](../authoring/github.md#use-issues) for each change request from the tester or decisionmaker. Consider this your "punch list" to finish the project. Then get back to work on those issues! - -When you have closed all the issues/items on your punch list, send it back to the decisionmaker for further feedback. Each round of feedback should result in fewer change requests and move the project closer to completion. - -:::info -Two rounds of feedback and revision are usually enough. -::: - -## Get a go/no-go decision +### Launch {#launch} When the interview is complete, there is one last decision for the decisionmaker to make: whether the interview is ready to go live. @@ -193,10 +223,10 @@ If the answer is yes, launch the interview! If the answer is no, find out if further revision would result in a yes. If not, [do a retrospective](#do-a-retrospective) and try to understand what happened. -## Launch the interview - When you are ready to launch, add the interview to your production server and make sure it works as intended. +### Promotion {#promotion} + Once the interview is live, consider how people who need it will find it. * You should have a dedicated page on your website that tells people about the interview and links to it. Put some thought into this page so people can find it by searching Google. @@ -205,7 +235,7 @@ Once the interview is live, consider how people who need it will find it. It's worth investing some time in [search engine optimization (SEO)](search_engine_optimization). You can also set up [collect analytics](../components/InterviewStats/interviewstats_overview.md) to learn how people are finding and using the interview. -## Do a retrospective +### Retrospective {#retrospective} Before you start another interview-building project, pause briefly for a retrospective on how this one went. The retrospective format comes from [Agile software development](https://en.wikipedia.org/wiki/Agile_software_development), and it is a way to embrace continuous improvement by taking a moment to reflect on the project you just finished in order to improve the next one. @@ -225,6 +255,217 @@ Insist that everyone give at least one answer to each question. Even if someone Use what you learn from the retrospective when planning your next interview-biulding project. +#### Success metrics {#success-metrics} + +Consider measuring the success of your project in terms of: + +* Time saved by those who use the tool +* People helped as a percentage of total filings of the same type +* Closing an access gap by enabling people to do something they couldn't before + +You can use the [Interview Stats](../components/InterviewStats/interviewstats_overview.md) package to track usage. Usability tests, reading grade level measurements, and auditing for best practices can help you understand how your interview has affected the access gap. + +#### Transfer docs {#transfer-docs} + +## Timeline {#timeline} + +
+ Sample timeline + + This is a sample timeline with estimated **minimum** times to complete each [project phase](#overview). Your team may decide it needs or wants more time for any of these phases. + + | Phase | Estimated minimum time | + | :------------------------------ | :------------------- | + | [Kickoff](#kickoff) | 1–2 hours | + | [Research](#research) | 1–2 weeks | + | [Design](#design) | 1 week | + | [Development](#development) | See [estimating development time](#estimating-development-time) | + | [Feedback](#feedback) | 6 weeks (see [estimating feedback time](#estimating-development-time)) | + | [Launch](#launch) | 1 day | + | [Promotion](#promotion) | 1 week, then ongoing | + | [Retrospective](#retrospective) | 20 minutes per team member | +
+ +### Estimating development time {#estimating-development-time} + +Development is a function of the complexity of the interview and the development resources (developer time) available. + +Start by estimating the time required to develop the interview based on: + +* The number of templates +* The number of fields +* The number of branching points in the interview logic +* How dynamic the interview questions need to be (i.e., to account for quantity, pronouns, and relationships, etc.) +* How dynamic the output documents need to be + +Developer time depends on availability and experience: + +* An experienced full-time developer has about 25 productive hours in a week +* A beginner may take 3–5 times as long to do the same work +* Other projects and obligations may reduce the available time + +A single, fairly simple form might take about 20 hours. But if a beginner developer is going to work on it, it's safe to assume it will takek them at least 60 hours. And if the developer has only 3 hours per week, it will take about 5 months (20 weeks). + +Come up with a schedule and key dates and milestones, working backward from the target launch date. + +* Start date +* MVP and maturity level agreed on +* Ready for internal feedback +* Ready for client feedback +* Go/no-go decision +* Target launch date + +### Estimating feedback time {#estimating-feedback-time} + +Most interview projects will involve 1 round of internal feedback and revision and 2 or 3 rounds of feedback and revision, then a final punch list to finalize the interview for the go/no-go decision. + +A round of feedback includes: + +1. Demonstrating or handing off the draft interview +2. Feedback, which may be: + 1. Given synchronously (i.e., as part of a demo) + 2. Given asynchronoustly (i.e., the decisionmaker coordinates testing among stakeholders, compiles and clarifies their feedback, and delivers it to the interview-building team) +3. Revision or further development based on the feedback + +#### Internal feedback + +Internal feedback can be informal. For example, in the LIT Clinic, students demonstrate their interview in class, followed by 10–15 minutes of real-time feedback. If the interview-building team is too small for internal feedback to make sense, you could substitute a informal live feedback session with just the decisionmaker, not all the stakeholders. + +Allow at least a week for further development before the interview is ready for for client feedback. + +Assume at least 1 week for an internal feedback round. + +#### Client feedback + +One week (5 business days) should generally be enough time for the client to deliver feedback. Allow at least a week after that for further development and revision before seeking further feedback. + +Two rounds of client feedback should be enough to arrive at a "punch list" of tasks necessary to finalize the interview before launch. + +Assume at least 5 weeks for client feedback (2 rounds plus the final punch list). + +## Roles and responsibilities + +![Interview project roles & lines of communication](../assets/interview-project-roles-communication.png) + +Every interview project has several roles: + +1. **Interview builders.** The person or team responsible for building the actual interview. Sub-roles include designer, lead developer, developer, and project manager. +2. **Decisionmaker.** One person who represents the client and is responsible for managing stakeholders and converting their feedback into clear decisions for the interview builders. Similar to a product owner. +3. **Stakeholders.** Anyone who needs to have a say in the interview project, such as managers, judges, clerks, subject matter experts, IT staff, and users (self-represented litigants and lawyers). + +:::note +You may have a team of interview builders and dozens of stakeholders, or you may be the only person working on this project. Even if this is a solo project, it helps to keep your different roles in mind. +::: + +#### The decisionmaker {#decisionmaker} + +**While a successful interview project needs all these roles, the decisionmaker is especially important.** Most interview projects involve multiple stakeholders. When the interview building team requests guidance or feedback, multiple stakeholders may give multiple responses that may be confusing or conflicting and dramatically slow progress. + +The decisionmaker's job is to gather and clarify stakeholders' feedback so that interview builders have clear decisions to work from. The decisionmaker's responsibilities also include: + +* Being a single point of contact and single source of decisions +* Regular meetings with the interview building team +* Timely responses to requests for decisions and feedback +* Gathering feedback or approvals from stakeholders and converting it to clear decisions +* Making the go/no-go decision to launch the interview + +The decisionmaker must either (1) have the authority necessary to carry out these responsiblities, or (2) be responsible for getting authority when necessary. + +## Meetings {#meetings} + +Every interview building project should start with a kickoff meeting and then follow a regular cadence of interview-builder standups and decisionmaker-stakeholder check-ins. + +### Kickoff meeting {#kickoff} + +Hold a kickoff meeting for the project as early as possible. Everyone who is important to the success of the project—the interview building team, the decisionmaker, and the key stakeholders—should attend. + +The goal of a kickoff meeting is to get everyone on the same page when it comes to roles, expectations, and timeline. A good kickoff meeting sets the stage for a successful project. + +
+ Sample kickoff meeting agenda + + * Introductions + * Decide who will be the [decisionmaker](#decisionmaker) + * Review the interview-building process (i.e., refer to this page) + * Agree on a [target launch date](#timeline) + * Schedule regular [decisionmaker check-ins](#decisionmaker-check-ins) + * Decide on [communication](#communication) tools + * Ask the stakeholders to [summarize the process](#document-process) (you can follow up later to get more details) + * Discuss the requirements for this interview and the [minimum viable product (MVP)](#mvp) + * Agree on a process for changing the scope of the project (i.e., adding features) + * Discuss what [success](#success-metrics) looks like for this project + * Consider doing a pre-mortem[^pre-mortem] +
+ +[^pre-mortem]: A [pre-mortem](https://hbr.org/2007/09/performing-a-project-premortem) can be helpful on larger and riskier projects. A pre-mortem asks participants to imagine a project's failure in advance, without judgment or blame. Studies show that premortems can increase the success of projects because they make it easier for stakeholders to "correctly identify the reasons for future outcomes" by as much as 30%, reduce the risks, or reconsider the project. + +### Development standups {#development-standups} + +The interview-building team should meet frequently for a short, 5–15 minute "standup" to share progress and identify and remove blockers. It's also possible to do standups asynchronously, but only if your team works well that way. + +Daily check-ins are common on active projects, and anything less than weekly is unlikely to be effective. + +Standups should follow a straightforward standing agenda. Each person on the team shares: + +1. **Progress:** what they worked on or accomplished since the last meeting +2. **Plan:** what they are working on now +3. **Blockers:** anything preventing them from making progress + +The reason for sharing your progress and plan for the day or week is so that everyone is aware of what everyone else on the team is working on. This is necessary for the project manager, and can help interview builders avoid [merge conflicts](../authoring/github.md#resolve-conflicts) or identify when it's time to [merge branches](../authoring/github.md#pull-requests). + +The reason for sharing blockers is to get help. Some teams reserve a larger block of time and use it to solve blockers together, like we do in our Monday community meetings. Other teams prefer to solve blockers separately. And sometimes a blocker is a question you need answered by the decisionmaker before you can move forward. + +:::tip +Consider incorporating our Monday community meetings into your standup schedule. We run them standup-style, plus time for solving blockers as a group. If this is a solo project, the Document Assembly Line community can be part of your interview-building team! +::: + +### Decisionmaker check-ins {#decisionmaker-check-ins} + +Weekly or every-other week check-in with the decisionmaker and one or two key stakeholders are a chance to keep them informed of your progress and get decisions when you need them to move forward. The standing agenda is similar to the one above: + +1. **Progress:** what the interview-building team worked on or accomplished since the last meeting +2. **Plan:** what the interview-building team plans to work on between now and the next meeting +3. **Questions:** oustanding questions that are preventing the interview-building team from making progress + +When sharing progress and the current plan, it can help to give a percentage estimate. Something like: "We think we are about 30% of the way to a complete draft interview, and by our next meeting we hope to be at 50%." + +:::tip +Use [GitHub issues](../authoring/github.md#use-issues) to keep track of your questions for the decisionmaker. If you add a **question** label to issues, it is easy to pull up the list of your questions during a meeting. +::: + +
+ Tips for asking questions + + To get better answers, ask questions better: + + * **Don't ask a question if you don't need the answer.** Before you ask the decisionmaker, ask your interview-building team or consult your [style guide](../style_guide/question_style_overview.md) or other internal documentation. + * **Avoid open-ended questions.** Intead, give the decisionmaker options and explain the pros, cons, and implications of each. + * **If you must ask an open-ended question**, explain that you are trying to generate ideas, not come up with the solution right then and there. + * **Don't ask the decisionmaker to design the interview.** It is usually better to clarify goals or requirements ("Do you need the attorney's ID number?"), not details ("Do you want the ID number field to show up right under the attorney's name field?"). + + **Remember: if you ask a question you will get an answer.** If you don't need an answer, asking for one is not likely to help, and you may get an answer that complicates the project instead of helping you move forward. + + Finally, when showing the relevant part of the interview to illustrate a question, remind the decisionmaker and stakeholders that the interview is a work in progress and you are not ready for feedback beyond the answer to your question. +
+ +## Communication {#communication} + +You will need to communicate outside of meetings, of course. Agree on the tools you will use internally (i.e., within the interview-building team) and externally (i.e., with the decisionmaker and stakeholders). + +If your team does not already have a preference, here is what we use for LIT Lab projects: + +#### For internal communications: + +* Zoom for meetings +* GitHub issues in the interview repository or [project board](https://github.com/orgs/SuffolkLITLab/projects/22) +* Microsoft Teams for general communications and file storage + +#### For external communications: + +* Zoom for meetings +* Email +* In some cases, GitHub or Teams + ## Tips from the community In a Document Assembly Line workshop, members of the community shared their tips for managing a successful interview-building project: From f6891cdc42755bc45d794666659adf0baf00b340 Mon Sep 17 00:00:00 2001 From: samglover Date: Thu, 29 May 2025 16:35:12 -0500 Subject: [PATCH 3/6] Add/update Overview sections --- docs/get_started/project_management.md | 78 ++++++++++++++++---------- 1 file changed, 48 insertions(+), 30 deletions(-) diff --git a/docs/get_started/project_management.md b/docs/get_started/project_management.md index 3a97458ab..2abce6e70 100644 --- a/docs/get_started/project_management.md +++ b/docs/get_started/project_management.md @@ -8,7 +8,7 @@ toc_max_heading_level: 4 Whether you are building interviews for a court or legal aid organization, a LIT Clinic student, a recent [Forms Camp](https://www.ncsc.org/consulting-and-research/areas-of-expertise/access-to-justice/forms-camp) graduate, or anyone else building online guided interviews, this page will guide you through the stages of a successful project. -This contains the procedures, templates, and tools the LIT Lab uses on our own interview-building projects, which you can adapt to yours. +This contains the procedures, templates, and tools the LIT Lab uses in our own interview-building projects, which you can adapt to yours. :::tip If this is your first interview-building project, it may help to read more about [planning and building your first expert system](https://projects.suffolklitlab.org/legal-tech-class/docs/interview-structure/building-an-app-outline). @@ -115,7 +115,7 @@ To strike the right balance, each user persona should reflect about 20–30% of ### Design {#design} -Before you start building anything, make sure everyone agrees on what you will be building. +Before you start building anything, make sure everyone agrees on what you will be building. The decisionmaker should sign off on the requirements as well as any flowcharts or wireframes. #### Identify the project requirements/MVP {#requirements} @@ -131,62 +131,69 @@ Start by listing the requirements for your project—what it must do to be accep Different projects will have different MVPs/skateboards. -The LIT Lab's [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) is a framework for thinking about your MVP. For interviews built for legal professionals, level 1.5 is usually enough. Interviews built for the general public should usually target level 2+. Levels 3 and 4 are meant for future iterations. +The LIT Lab's [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) is a framework for thinking about online guided interview MVPs. For interviews built for legal professionals, level 1.5 is usually enough. Interviews built for the general public should usually target level 2+. Levels 3 and 4 are meant for future iterations. An MVP can be as simple as a list of requirements.
- Sample MVP description for a court form + Sample MVP requirements for a court form Maturity model target level: 2 + * The user can correctly complete every field/blank on the form * The interview flows like a natural-language intake with a new legal aid employee - * Compound questions are broken up into separate screens + * The form identifies users who cannot use the firm as early as possible, and gives them an "off-ramp" * The interview uses branching logic to skip unnecessary questions and provide a logical flow + * Compound questions are broken up into separate screens * The user is not asked for the same information twice * The interview correctly populates every field on the form * The user can sign on their computer or phone screen * Questions are written in plain language (for a 6th-grade reading level) * The user will be offered a next-steps document to download - * The form identifies users who cannot use the firm as early as possible, and gives them an "off-ramp" * The interview has been approved by key subject-matter experts * The interview has been tested rigorously with a combination of scenario-baesd user testing, random input testing, or automated testing
-Once everyone agrees on an MVP for this project, stick to it. Refer to the MVP description to help resolve questions about to Don't add to the MVP without a compelling justification. +Once the decisionmaker agrees on the MVP requirements, stick to them. Don't add to the MVP without a compelling justification. + +#### Use flowcharts or wireframes +Flowcharts and wireframes allow you to "sketch" the interview you plan to build. They may not be necessary for very simple interviews, but they are worthwhile if your interview has conditional elements or unique questions. -#### Create a flowchart +A flowchart illustrates the branching logic of an interview and can help identify hidden complexities early on. For example, a flowchart would be helpful to illustrate: -Create a flowchart showing branching logic, follow-up questions, and changes to the output documents +* Whether the user qualifies to use the interview/court form +* Which form or sections of the form the user must complete +* Whether to ask particular follow-up questions +* Which values should be provided to which variables in which circumstances +* Whether additional information or documents should be included in the output +* Which court the user should file in +* Which filing codes to use -#### Wireframing +A [low-fidelity wireframe](https://en.wikipedia.org/wiki/Website_wireframe#Low-fidelity) is a simplified prototype of a user interface element that emphasizes function over form. Wireframes are helpful if you need to design a new type of form element (i.e., one that does not already exist in the [question library](../authoring/customizing_interview/#understanding-the-question-library)). -Use wireframes, decision trees, and other low-fidelity tools to "sketch" the interview you are going to build. +Pen and paper works fine for flowcharts and wireframes, but there are plenty of software tools available. Consider using one that lets you save your flowchart or wireframe in a format you can save along with the interview. ### Development {#development} -#### Work planning +Once the decisionmaker has signed off on the requirements/MVP and any flowcharts or wireframes, it's time to start building the interview! -The LIT Lab's interview project template can help you keep your team organized and your project on track. It is based on the [Scrum agile project management framework](https://www.atlassian.com/agile/scrum). To use the project template: +The LIT Lab's interview project template can help you keep your team organized and your project on track. It is based on the [Scrum agile project management framework](https://www.atlassian.com/agile/scrum). -1. Make a copy of the [interview project template](https://github.com/orgs/SuffolkLITLab/projects/22) by clicking the **Use this template** button (you'll need a free [GitHub](../authoring/github.md) account) +To use the project template: + +1. Go to the [interview project template](https://github.com/orgs/SuffolkLITLab/projects/22) and make a copy for yourself by clicking the **Use this template** button (you'll need a free [GitHub](../authoring/github.md) account) 2. Once you have [published your interview to GitHub](../authoring/github.md#publish-your-interview-to-github), [connect the project board to your interview repository](https://github.com/orgs/SuffolkLITLab/projects/22/views/2?pane=issue&itemId=66449601) 1. New issues will be added to the backlog automatically 2. Issues will be closed automatically when the card is moved to the **Done** column -3. As you work on the interview, follow the [GitHub workflow](../authoring/github.md#workflow) and move issues/cards from left to right - -### Feedback {#feedback} +3. As you work on your interview, follow the [GitHub workflow](../authoring/github.md#workflow) and move issues/cards from left to right -Once the interview works from start to finish and you have closed all the issues that are in scope for the [MVP](#mvp), it is ready for feedback. Start by getting feedback internally, from your team. After you have made revisions based on the internal feedback, get external feednack from the decisionmaker and stakeholders. +You can also find a [beginner's guide](beginners_guide.md), [interview-builder resources](resources.md), and [extensive documentation](../overview.md) elsewhere on this website. -After getting feedback, create a [GitHub issue](../authoring/github.md#use-issues) for each change request from the tester or decisionmaker. Consider this your "punch list" to finish the project. Then get back to work on those issues! +### Feedback {#feedback} -When you have closed all the issues/items on your punch list, send it back to the decisionmaker for further feedback. Each round of feedback should result in fewer change requests and move the project closer to completion. +The interview is ready for feedback when it works, and you have closed all the [MVP](#mvp) issues. (You can also find a [checklist in the interview project template](https://github.com/orgs/SuffolkLITLab/projects/22/views/2?pane=issue&itemId=61504799).) -:::info -Two rounds of feedback and revision are usually enough. -::: #### Internal feedback @@ -196,10 +203,11 @@ Before you show the interview to the decisionmaker and stakeholders, get someone If you aren't sure where to find someone to give you preliminary feedback, try asking [the community](https://assemblyline.suffolklitlab.org/docs/get_started#join-the-community)! Come to one of the Monday community meetings or ask in the Microsoft Teams forum. ::: -Schedule a video meeting with the tester so you can watch them go through the interview. Or they can watch you demonstrate it. Record the test if you can so you can focus on the test instead of taking notes. +Schedule a video meeting with the tester. You can demonstrate it for them, or you can watch them go through the interview. Record the test if you can so you can focus on the feedback and asking follow-up questions instead of taking notes. -During the demonstration or testing: +During the demo: +* Remind the tester that they are testing the interview; they are not being tested (and neither are you!) * Encourage the tester to comment on all aspects of the interview * Ask them to follow different branches of the interview logic * Listen carefully to their feedback and ask follow-up questions to make sure you understand it @@ -215,26 +223,28 @@ Share the interview with the decisionmaker and give them a few tips for giving h * Change requests should be specific. For example, if the text of a question should be changed, the change request should include the new text. * At the top of each page of the interview is an ID. Use the ID to refer to specific interview pages, not a page number. +:::info +Two rounds of external feedback and revision are usually enough to get you to the point where you just have a punch list of final tasks to do before the interview is ready for launch. +::: + ### Launch {#launch} When the interview is complete, there is one last decision for the decisionmaker to make: whether the interview is ready to go live. -If the answer is yes, launch the interview! +If the answer is yes, launch the interview! (You can find a [launch checklist](https://github.com/orgs/SuffolkLITLab/projects/22/views/2?pane=issue&itemId=61508986) on our interview project template.) If the answer is no, find out if further revision would result in a yes. If not, [do a retrospective](#do-a-retrospective) and try to understand what happened. -When you are ready to launch, add the interview to your production server and make sure it works as intended. +When you are ready to launch, add the interview to your production server and make sure it works as intended. Now is also a good time to check and update the GitHub repository details and [add some protections](../authoring/github.md#protect-repo). ### Promotion {#promotion} Once the interview is live, consider how people who need it will find it. -* You should have a dedicated page on your website that tells people about the interview and links to it. Put some thought into this page so people can find it by searching Google. +* You should have a dedicated page on your website that tells people about the interview and links to it. [Optimize the page for search engines](search_engine_optimization.md), too! * Others might want to direct people to the interview, like courts, legal aid organizations, and other advocates. Ask them to link to your landing page from their own websites. * Paid advertising can help spread awareness, if you have a budget for it. -It's worth investing some time in [search engine optimization (SEO)](search_engine_optimization). You can also set up [collect analytics](../components/InterviewStats/interviewstats_overview.md) to learn how people are finding and using the interview. - ### Retrospective {#retrospective} Before you start another interview-building project, pause briefly for a retrospective on how this one went. The retrospective format comes from [Agile software development](https://en.wikipedia.org/wiki/Agile_software_development), and it is a way to embrace continuous improvement by taking a moment to reflect on the project you just finished in order to improve the next one. @@ -267,6 +277,14 @@ You can use the [Interview Stats](../components/InterviewStats/interviewstats_ov #### Transfer docs {#transfer-docs} +Before you set the project aside, take some time to help the next developer—which might be you! + +One of the best places to store information and documents for the next developer is in the GitHub repository. + +1. Create an issue for anything left unfinished, feedback you couldn't implement, ideas for future improvement, etc. +2. Add any other helpful notes or details to the README file +3. You can also add a **transfer** folder to hold research, flowcharts, wireframes, feedback, and other documentation + ## Timeline {#timeline}
From 8952b31a655aac788bb32c618460c8183cb8a642 Mon Sep 17 00:00:00 2001 From: samglover Date: Fri, 30 May 2025 10:12:49 -0500 Subject: [PATCH 4/6] Saving draft pending final edit --- docs/get_started/project_management.md | 170 +++++++++++-------------- 1 file changed, 74 insertions(+), 96 deletions(-) diff --git a/docs/get_started/project_management.md b/docs/get_started/project_management.md index 2abce6e70..7ae080492 100644 --- a/docs/get_started/project_management.md +++ b/docs/get_started/project_management.md @@ -31,6 +31,30 @@ Interview-building project generally follows these phases: After the kickoff through launch, the interview building team should hold regular [standups](#development-standups) and [check-ins](#decisionmaker-check-ins) with the decisionmaker and key stakeholders, with additional [communication](#communication) as necessary. +### Kickoff {#kickoff} + +Hold a kickoff meeting for the project as early as possible. Everyone who is important to the success of the project—the interview building team, the decisionmaker, and the key stakeholders—should attend. + +The goal of a kickoff meeting is to get everyone on the same page when it comes to roles, expectations, and timeline. A good kickoff meeting sets the stage for a successful project. + +
+ Sample kickoff meeting agenda + + * Introductions + * Decide who will be the [decisionmaker](#decisionmaker) + * Review the interview-building process (i.e., refer to this page) + * Agree on a [target launch date](#timeline) + * Schedule regular [decisionmaker check-ins](#decisionmaker-check-ins) + * Decide on [communication](#communication) tools + * Ask the stakeholders to [summarize the process](#document-process) (you can follow up later to get more details) + * Discuss the requirements for this interview and the [minimum viable product (MVP)](#mvp) + * Agree on a process for changing the scope of the project (i.e., adding features) + * Discuss what [success](#success-metrics) looks like for this project + * Consider doing a pre-mortem[^pre-mortem] +
+ +[^pre-mortem]: A [pre-mortem](https://hbr.org/2007/09/performing-a-project-premortem) can be helpful on larger and riskier projects. A pre-mortem asks participants to imagine a project's failure in advance, without judgment or blame. Studies show that premortems can increase the success of projects because they make it easier for stakeholders to "correctly identify the reasons for future outcomes" by as much as 30%, reduce the risks, or reconsider the project. + ### Research {#research} Before you start building anything, gain a thorough understanding of the problem you are trying to solve. @@ -285,12 +309,50 @@ One of the best places to store information and documents for the next developer 2. Add any other helpful notes or details to the README file 3. You can also add a **transfer** folder to hold research, flowcharts, wireframes, feedback, and other documentation +## Roles and responsibilities + +![Interview project roles & lines of communication](../assets/interview-project-roles-communication.png) + +Every interview project has several roles: + +1. **Interview builders.** The person or team responsible for building the actual interview. Sub-roles include designer, lead developer, developer, and project manager. +2. **Decisionmaker.** One person who represents the client and is responsible for managing stakeholders and converting their feedback into clear decisions for the interview builders. Similar to a product owner. +3. **Stakeholders.** Anyone who needs to have a say in the interview project, such as managers, judges, clerks, subject matter experts, IT staff, and users (self-represented litigants and lawyers). + +:::note +You may have a team of interview builders and dozens of stakeholders, or you may be the only person working on this project. Even if this is a solo project, it helps to keep your different roles in mind. +::: + +#### The decisionmaker {#decisionmaker} + +**While a successful interview project needs all these roles, the decisionmaker is especially important.** Most interview projects involve multiple stakeholders. When the interview building team requests guidance or feedback, multiple stakeholders may give multiple responses that may be confusing or conflicting and dramatically slow progress. + +The decisionmaker's job is to gather and clarify stakeholders' feedback so that interview builders have clear decisions to work from. The decisionmaker's responsibilities also include: + +* Being a single point of contact and single source of decisions +* Regular meetings with the interview building team +* Timely responses to requests for decisions and feedback +* Gathering feedback or approvals from stakeholders and converting it to clear decisions +* Making the go/no-go decision to launch the interview + +The decisionmaker must either (1) have the authority necessary to carry out these responsiblities, or (2) be responsible for getting authority when necessary. + ## Timeline {#timeline} +When creating your project timeline, keep in mind the experience and availability of your team—especially the interview builders. + +* An experienced, full-time developer has about 25 productive hours in a week +* A beginner may take 3–5 times as long to do the same work +* Other projects and obligations will reduce availability + +For a single, fairly simple form, it might take about 20 hours for research, design, and development. But if a beginner is doing the work, assume it will take them 60 hours. And if they only have 3 hours per week, it will take about 5 months (20 weeks). + +Modify the sample and estimation guides below based on your team's experience and availability. +
Sample timeline - This is a sample timeline with estimated **minimum** times to complete each [project phase](#overview). Your team may decide it needs or wants more time for any of these phases. + This is a sample timeline with estimated **minimum** times to complete each [project phase](#overview). Your team may decide it needs or wants more time for any of these phases due to experience, availability, or other reasons. | Phase | Estimated minimum time | | :------------------------------ | :------------------- | @@ -308,7 +370,7 @@ One of the best places to store information and documents for the next developer Development is a function of the complexity of the interview and the development resources (developer time) available. -Start by estimating the time required to develop the interview based on: +When estimating development time, take into consideration: * The number of templates * The number of fields @@ -316,26 +378,9 @@ Start by estimating the time required to develop the interview based on: * How dynamic the interview questions need to be (i.e., to account for quantity, pronouns, and relationships, etc.) * How dynamic the output documents need to be -Developer time depends on availability and experience: - -* An experienced full-time developer has about 25 productive hours in a week -* A beginner may take 3–5 times as long to do the same work -* Other projects and obligations may reduce the available time - -A single, fairly simple form might take about 20 hours. But if a beginner developer is going to work on it, it's safe to assume it will takek them at least 60 hours. And if the developer has only 3 hours per week, it will take about 5 months (20 weeks). - -Come up with a schedule and key dates and milestones, working backward from the target launch date. - -* Start date -* MVP and maturity level agreed on -* Ready for internal feedback -* Ready for client feedback -* Go/no-go decision -* Target launch date - ### Estimating feedback time {#estimating-feedback-time} -Most interview projects will involve 1 round of internal feedback and revision and 2 or 3 rounds of feedback and revision, then a final punch list to finalize the interview for the go/no-go decision. +Most interview projects will involve 1 round of internal feedback and revision and 2 rounds of external feedback and revision, then a final punch list to finalize the interview for the go/no-go decision. A round of feedback includes: @@ -345,77 +390,17 @@ A round of feedback includes: 2. Given asynchronoustly (i.e., the decisionmaker coordinates testing among stakeholders, compiles and clarifies their feedback, and delivers it to the interview-building team) 3. Revision or further development based on the feedback -#### Internal feedback - -Internal feedback can be informal. For example, in the LIT Clinic, students demonstrate their interview in class, followed by 10–15 minutes of real-time feedback. If the interview-building team is too small for internal feedback to make sense, you could substitute a informal live feedback session with just the decisionmaker, not all the stakeholders. - -Allow at least a week for further development before the interview is ready for for client feedback. - -Assume at least 1 week for an internal feedback round. - -#### Client feedback - -One week (5 business days) should generally be enough time for the client to deliver feedback. Allow at least a week after that for further development and revision before seeking further feedback. - -Two rounds of client feedback should be enough to arrive at a "punch list" of tasks necessary to finalize the interview before launch. +Internal feedback can be informal. For example, in the LIT Clinic, students demonstrate their interview in class, followed by 10–15 minutes of real-time feedback. -Assume at least 5 weeks for client feedback (2 rounds plus the final punch list). +When seeking external feedback, stakeholders will need time to test and review the interview, and the decisionmaker will need time to consolidate and clarify the stakeholders' feedback. This will generally take at least a week. -## Roles and responsibilities - -![Interview project roles & lines of communication](../assets/interview-project-roles-communication.png) - -Every interview project has several roles: +Each round of feedback should include time for revision or further development based on the feedback received. -1. **Interview builders.** The person or team responsible for building the actual interview. Sub-roles include designer, lead developer, developer, and project manager. -2. **Decisionmaker.** One person who represents the client and is responsible for managing stakeholders and converting their feedback into clear decisions for the interview builders. Similar to a product owner. -3. **Stakeholders.** Anyone who needs to have a say in the interview project, such as managers, judges, clerks, subject matter experts, IT staff, and users (self-represented litigants and lawyers). - -:::note -You may have a team of interview builders and dozens of stakeholders, or you may be the only person working on this project. Even if this is a solo project, it helps to keep your different roles in mind. -::: - -#### The decisionmaker {#decisionmaker} - -**While a successful interview project needs all these roles, the decisionmaker is especially important.** Most interview projects involve multiple stakeholders. When the interview building team requests guidance or feedback, multiple stakeholders may give multiple responses that may be confusing or conflicting and dramatically slow progress. - -The decisionmaker's job is to gather and clarify stakeholders' feedback so that interview builders have clear decisions to work from. The decisionmaker's responsibilities also include: - -* Being a single point of contact and single source of decisions -* Regular meetings with the interview building team -* Timely responses to requests for decisions and feedback -* Gathering feedback or approvals from stakeholders and converting it to clear decisions -* Making the go/no-go decision to launch the interview - -The decisionmaker must either (1) have the authority necessary to carry out these responsiblities, or (2) be responsible for getting authority when necessary. +Assume at least 1 week for internal feedback (demo with live feedback, then revision). Assume at least 5 weeks for external feedback (2 rounds of feedback and revision, plus a final punch list). ## Meetings {#meetings} -Every interview building project should start with a kickoff meeting and then follow a regular cadence of interview-builder standups and decisionmaker-stakeholder check-ins. - -### Kickoff meeting {#kickoff} - -Hold a kickoff meeting for the project as early as possible. Everyone who is important to the success of the project—the interview building team, the decisionmaker, and the key stakeholders—should attend. - -The goal of a kickoff meeting is to get everyone on the same page when it comes to roles, expectations, and timeline. A good kickoff meeting sets the stage for a successful project. - -
- Sample kickoff meeting agenda - - * Introductions - * Decide who will be the [decisionmaker](#decisionmaker) - * Review the interview-building process (i.e., refer to this page) - * Agree on a [target launch date](#timeline) - * Schedule regular [decisionmaker check-ins](#decisionmaker-check-ins) - * Decide on [communication](#communication) tools - * Ask the stakeholders to [summarize the process](#document-process) (you can follow up later to get more details) - * Discuss the requirements for this interview and the [minimum viable product (MVP)](#mvp) - * Agree on a process for changing the scope of the project (i.e., adding features) - * Discuss what [success](#success-metrics) looks like for this project - * Consider doing a pre-mortem[^pre-mortem] -
- -[^pre-mortem]: A [pre-mortem](https://hbr.org/2007/09/performing-a-project-premortem) can be helpful on larger and riskier projects. A pre-mortem asks participants to imagine a project's failure in advance, without judgment or blame. Studies show that premortems can increase the success of projects because they make it easier for stakeholders to "correctly identify the reasons for future outcomes" by as much as 30%, reduce the risks, or reconsider the project. +Every interview building project should start with a [kickoff meeting](#kickoff) and then follow a regular cadence of interview-builder standups and decisionmaker-stakeholder check-ins. ### Development standups {#development-standups} @@ -470,19 +455,12 @@ Use [GitHub issues](../authoring/github.md#use-issues) to keep track of your que You will need to communicate outside of meetings, of course. Agree on the tools you will use internally (i.e., within the interview-building team) and externally (i.e., with the decisionmaker and stakeholders). -If your team does not already have a preference, here is what we use for LIT Lab projects: - -#### For internal communications: - -* Zoom for meetings -* GitHub issues in the interview repository or [project board](https://github.com/orgs/SuffolkLITLab/projects/22) -* Microsoft Teams for general communications and file storage - -#### For external communications: +For LIT Lab projects, we use: * Zoom for meetings -* Email -* In some cases, GitHub or Teams +* GitHub issues for internal communications +* Microsoft Teams for general internal communications and file storage +* Email for external communications ## Tips from the community From 04c522cecc8485e38e54d51f6170569d26042ade Mon Sep 17 00:00:00 2001 From: samglover Date: Fri, 30 May 2025 12:49:51 -0500 Subject: [PATCH 5/6] Update to the project management page --- docs/get_started/project_management.md | 36 ++++++++++++-------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/docs/get_started/project_management.md b/docs/get_started/project_management.md index 7ae080492..a580aa825 100644 --- a/docs/get_started/project_management.md +++ b/docs/get_started/project_management.md @@ -6,13 +6,7 @@ slug: project_management toc_max_heading_level: 4 --- -Whether you are building interviews for a court or legal aid organization, a LIT Clinic student, a recent [Forms Camp](https://www.ncsc.org/consulting-and-research/areas-of-expertise/access-to-justice/forms-camp) graduate, or anyone else building online guided interviews, this page will guide you through the stages of a successful project. - -This contains the procedures, templates, and tools the LIT Lab uses in our own interview-building projects, which you can adapt to yours. - -:::tip -If this is your first interview-building project, it may help to read more about [planning and building your first expert system](https://projects.suffolklitlab.org/legal-tech-class/docs/interview-structure/building-an-app-outline). -::: +If you are building online guided interviews, whether for a court, legal aid organization, or the LIT Clinic, this page will guide you through the stages of a successful project. This page includes procedures, templates, and tools the LIT Lab uses in our own interview-building projects, which you can use as-is or adapt for your own team. ## Overview {#overview} @@ -22,14 +16,18 @@ Interview-building project generally follows these phases: | :------------------------------ | :-------------------- | | [Kickoff](#kickoff) | See [sample agenda](#kickoff:~:text=Sample%20kickoff%20meeting%20agenda) | | [Research](#research) | Gain insight into and understanding of the problem to be solved | -| [Design](#design) | Agree on an MVP | +| [Design](#design) | Agree on the project requirements\/MVP | | [Development](#development) | Build the interview | -| [Feedback](#feedback) | 1–3 rounds of feedback and further development |per feedback round | +| [Feedback](#feedback) | Feedback, revision, and further development | | [Launch](#launch) | Publish the interview | -| [Promotion](#promotion) | Ensure that people who need the interview will | +| [Promotion](#promotion) | Make sure people who need the interview can find it | | [Retrospective](#retrospective) | Identify areas of improvement for the next interview project | -After the kickoff through launch, the interview building team should hold regular [standups](#development-standups) and [check-ins](#decisionmaker-check-ins) with the decisionmaker and key stakeholders, with additional [communication](#communication) as necessary. +After the kickoff through launch, the interview building team should hold regular [standups](#development-standups) and [check-ins](#decisionmaker-check-ins) with the decisionmaker and key stakeholders. + +:::tip +If this is your first interview-building project, it may help to read more about [planning and building your first expert system](https://projects.suffolklitlab.org/legal-tech-class/docs/interview-structure/building-an-app-outline). +::: ### Kickoff {#kickoff} @@ -59,7 +57,7 @@ The goal of a kickoff meeting is to get everyone on the same page when it comes Before you start building anything, gain a thorough understanding of the problem you are trying to solve. -Work with the decisionmaker and subject-matter experts to document the process and develop user personas. Make sure they agree with your understanding before you move on to [design](#design). +Work with the decisionmaker and subject-matter experts to research the process and intended users. Consider developing user personas. Make sure the deciscion maker and key subject-matter experts agree with your understanding before you move on to [design](#design). #### Document the process {#document-process} @@ -155,7 +153,7 @@ Start by listing the requirements for your project—what it must do to be accep Different projects will have different MVPs/skateboards.
-The LIT Lab's [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) is a framework for thinking about online guided interview MVPs. For interviews built for legal professionals, level 1.5 is usually enough. Interviews built for the general public should usually target level 2+. Levels 3 and 4 are meant for future iterations. +The LIT Lab's [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) is a framework for thinking about online guided interview MVPs. For interviews built for legal professionals, level 1.5 is usually enough. Interviews built for the general public should usually target level 2+. Levels 3 and 4 are mostly meant for future iterations. An MVP can be as simple as a list of requirements. @@ -178,7 +176,7 @@ An MVP can be as simple as a list of requirements. * The interview has been tested rigorously with a combination of scenario-baesd user testing, random input testing, or automated testing
-Once the decisionmaker agrees on the MVP requirements, stick to them. Don't add to the MVP without a compelling justification. +Once the decisionmaker agrees on the requirements, stick to them. Don't add requirements without a compelling justification. #### Use flowcharts or wireframes @@ -236,7 +234,7 @@ During the demo: * Ask them to follow different branches of the interview logic * Listen carefully to their feedback and ask follow-up questions to make sure you understand it -#### Client feedback +#### External feedback Once you have closed all the issues that are in scope for the [MVP](#mvp) and tested the interview yourself, it should be ready to hand off to the decisionmaker and stakeholders for their testing and feedback. @@ -257,7 +255,7 @@ When the interview is complete, there is one last decision for the decisionmaker If the answer is yes, launch the interview! (You can find a [launch checklist](https://github.com/orgs/SuffolkLITLab/projects/22/views/2?pane=issue&itemId=61508986) on our interview project template.) -If the answer is no, find out if further revision would result in a yes. If not, [do a retrospective](#do-a-retrospective) and try to understand what happened. +If the answer is no, find out if further revision would result in a yes. If not, [do a retrospective](#retrospective) and try to understand what happened. When you are ready to launch, add the interview to your production server and make sure it works as intended. Now is also a good time to check and update the GitHub repository details and [add some protections](../authoring/github.md#protect-repo). @@ -297,9 +295,9 @@ Consider measuring the success of your project in terms of: * People helped as a percentage of total filings of the same type * Closing an access gap by enabling people to do something they couldn't before -You can use the [Interview Stats](../components/InterviewStats/interviewstats_overview.md) package to track usage. Usability tests, reading grade level measurements, and auditing for best practices can help you understand how your interview has affected the access gap. +You can use the [InterviewStats](../components/InterviewStats/interviewstats_overview.md) package to track usage. Usability tests, reading grade level measurements, and auditing for best practices can help you understand how your interview has affected the access gap. -#### Transfer docs {#transfer-docs} +#### Transfer documentation {#transfer-docs} Before you set the project aside, take some time to help the next developer—which might be you! @@ -323,7 +321,7 @@ Every interview project has several roles: You may have a team of interview builders and dozens of stakeholders, or you may be the only person working on this project. Even if this is a solo project, it helps to keep your different roles in mind. ::: -#### The decisionmaker {#decisionmaker} +### The decisionmaker {#decisionmaker} **While a successful interview project needs all these roles, the decisionmaker is especially important.** Most interview projects involve multiple stakeholders. When the interview building team requests guidance or feedback, multiple stakeholders may give multiple responses that may be confusing or conflicting and dramatically slow progress. From 5f254c10d5d139642979547fc1dd223efb21127e Mon Sep 17 00:00:00 2001 From: samglover Date: Fri, 30 May 2025 12:50:01 -0500 Subject: [PATCH 6/6] Update anchor link --- docs/get_started/development_roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/get_started/development_roadmap.md b/docs/get_started/development_roadmap.md index a3cdeed21..bdb3afb7a 100644 --- a/docs/get_started/development_roadmap.md +++ b/docs/get_started/development_roadmap.md @@ -5,7 +5,7 @@ sidebar_label: Development roadmap slug: development_roadmap --- -The Document Assembly Line is under continuous development, based on input from the courts and legal aid organizations that use it and participate in the [community](intro.md#join-the-community). This roadmap contains the master plan and current development priorities, which are made possible by our [funding partners](../../#funding-partners). +The Document Assembly Line is under continuous development, based on input from the courts and legal aid organizations that use it and participate in the [community](intro.md#join-the-community). This roadmap contains the master plan and current development priorities, which are made possible by our [funding partners](/#funding-partners). To raise an issue or make a suggestion, you can: