🕺🏼 1: Improve Project Outcomes by 37%

Today, I’m going to show you how to sequence 5 human-centered frameworks to improve your project’s requirements*.

Requirements are a team sport and the more ways you can bring perspectives to the table, FASTER, (without ChatGPT 😏) - the better off we all are.

According to the Project Management Institute, a primary cause of project failure was “a lack of clearly defined objectives…”. That’s right. 37% of project failures are because of this 1 thing.

Our world is full of human-centered frameworks to elicit just what you need to improve your chances of project success.

Here’s the playbook

Some of y’all gone be mad, but do this BEFORE you kick-off. PLEASE - Abeg lol.

1. Start with a Survey

Surveys are an effective way to gather requirements from a large group of people. They can be easily distributed and help to get quick feedback.

☕️ Start with pain. Get all the tea.

📁 Understand the operational context. Ask questions about processes and how they would like to improve them.

📈 Understand the impacts on the business, growth, revenue, people, or costs.

💡Ask people to be Steve Jobs and think differently. Ask for their craziest ideas on how to approach things if they could have anything they wanted and there were no constraints.

2. Use Prototyping

Prototyping is an iterative process that helps to refine project requirements. It allows stakeholders to see and experience the solution and provide feedback.

• You’re going to take a few ideas from the survey, a few ideas from yourselves, and a few ideas from the folks (customers, stakeholders, whoever is going to be using ‘the thing’) on how to approach this problem while weighing the pros and cons.

• Use a blind voting mechanism similar to planning poker to have the minimal viable team vote on which solution should be taken on as a prototype.

• Prototype. This could be anything. And please don’t strive for perfection. Acceptable prototypes:

  • Slide deck

  • A sketch

  • ‘The thing’ built with popsicle sticks, toothpicks, legos, or whatever you have lying around.

  • A video

  • A landing page

  • Whatever you want lol.

  
  Don’t overthink it and make it in the simplest format that you can run through with some of your target users.

3. Conduct Interviews

Conducting interviews with stakeholders and subject matter experts is a great way to gather project requirements. It helps to get a better understanding of their needs and expectations. Start with singular users to weed out biases that will pop up when groups come together.

• Invite some of your “users” to try using the prototype. No pressure. Have some free snacks on hand.

• Record your users trying to use your prototype. Where was there confusion? Questions? Feedback? ANARCHY????!!! or Nirvana?

• If there’s anarchy, please make another pass on the prototype before going to your focus groups.

• Send personalized thank you notes if possible.

• Start to group feedback by type.

4. Run Focus Groups

Running focus groups allows for a more in-depth conversation around project requirements. It helps to capture more detailed information and provides the opportunity to ask follow-up questions.

• Include your target users but also users who may integrate or interface with this tool throughout the end-to-end process. For example, if you’re creating an online application, invite not only someone using that application but also a customer service rep who may have to answer calls or guide someone through that application over the phone. Ask a fifth grader to fill out the forms & your grandma lol.

• More usability tests, but this time in groups.

• Ask meaningful questions like:

  • What’s going through your mind when you [perform action]?

  • What made you pause there?

  • How does this feel?

  • How would you improve this experience?

• Group feedback by type.

5. Synthesize Data & Feedback

Analyze data from previous projects, your prototype in the wild, & industry benchmarks to provide valuable insights into your project’s requirements. This will help to identify trends and best practices. Most importantly, your first set of high-level requirements will be grounded in a successful experiment where the organization (or early adopters) will already be on board. When you allow users to contribute to the solution, it’s a win-win.

Use AI to help summarize main points if needed. Yea, it’s fine lol. Just don’t outsource the creativity, collaboration, and decision-making to it. Own it.

6. Write Together

Schedule time with your cross-functional team to document requirements together at a high level.

It’s ok if 1 person starts a draft - but by Beyonce, make sure there’s a review at a higher level before it goes to the team doing the work.

If you’re “doing agile” these might look like epic or feature-level requirements. Leave the user stories or smaller chunks of requirements to the teams doing the work. Include links to:

• Usability testing videos

• Raw and synthesized feedback

• Prototypes and iterations of it

• Any other relevant data that helps give context to the team that will do the work

Last but not least - make an informed decision as to whether the project should even be embarked upon.

IT’S OK TO CANCEL PROJECTS.

IT’S OK TO DEFER PROJECTS UNTIL LATER.

IT’S OK TO PIVOT AND SAY WE NEED OTHER REQUIREMENTS ITERATION WITH A DIFFERENT PROTOTYPE.

Please make this decision intentionally and don’t throw prototypes over the wall.

Pro Tip

Everyone loves “doing agile”. In many cases this means scrum. If you really want to nail this, grab a minimal viable team (eng, design, prod, SME, QA, project mgr, or subset of this/whatever makes sense in your org) and have them focus on this over the course of 2-3 weeks. Timebox it so it forces people to focus on this one activity & get to “done” as soon as possible. That means they will be unavailable to their teams, other MEETINGS, training, or in-flight projects during this exercise.

• Survey before week 1 - review results

• Use week 1 as a design sprint

• Use week 2 for interviews, focus groups, and documentation of the highest tier of requirements. (In agile this may be Features or Epics)

• Use the end of week 2 or a potential 3rd week to document high-level requirements TOGETHER with the minimal viable team. Start with a template, it’ll go faster. Promise.

Further Insights

• Book: Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days | Jake Knapp

• Blog: https://www.navapbc.com/toolkits/user-research-improving-forms

_{*Footnote - If the word “requirements” is triggering, feel free to substitute that word for anything that sparks joy. Specs, user stories, whatever. Yea yea, it’s all technically different, but at the end of the day - we gotta document the things that need to get done. So focus on that and not useless debates around minutiae. Yep, I said it. Love ya!}