Scoping a Project

Project scope can be one of the more difficult aspects of product design when you are first starting out. In the broadest sense, project scope is driven by your co-designer's needs, your team's expertise, and the resources available to you (including funding, equipment, mentorship, etc). It is often tempting to try to tackle the most ambitious, or most exciting idea that is on your list, but a key factor to remember is that a good solution that is fully executed is better than an amazing solution that is only half-built.

Team exercise: Taking Stock

You came up with a set of needs and ideas in the previous section, and started doing some initial sketches of what they might look like, focusing mainly on your product and your co-designer. Now we'll turn our gaze inward, so to speak, and take a look at what you have to build with. What we're trying to do here is to get very rough estimates, to rule out things that may be a little too ambitious.

• Time

  • How often is your team planning to meet? How long is your team planning to meet each time? Will that time be constant, or change during the school year?

  • What other time commitments does your team have? Class load? Sports teams? Music practices? Responsibilities at home?

• Funding

  • How much money are you working with? What are the aspects of your design that will need money?

  • Will you need to raise funds? If so, how will that impact your project time?

• Expertise

  • What skills do each of your team members currently possess? Does your team collectively have some sense of what you need to do during various steps of the building process?

  • What experts do you have access to? Who do you know in your community who you might be able to ask about various aspects of building your product? Remember that if your team is supported directly by Beaver Works, you also have access to the technical mentors there.

Gather up these factors as a team, and compare them against your ideas. What do you have "in stock" and what would you need more of? You don't have to have everything you need at the moment, but if you are well short of some resource that is needed for your product idea, then consider how you might get more of what you need, or if another idea is better-suited for your team to tackle.

What we (generally) don't recommend

There are a few project ideas that we have seen proposed frequently in the past that are often a bit too ambitious, and/or carry higher risk. We generally do not recommend the following. If you choose to pursue something that seems like any of the following, please talk to a CRE[AT]E mentor first.

• exoskeletons (or more broadly, orthotics and body-worn actuators)

• robots (especially more general-purpose robots)

• modifications to wheelchair actuation (e.g. adding motors)

Also, a general category of products that we don't recommend are building things that have to do with safety-critical activities. One way to think about this category is "what happens if your product fails during operation?" If failure is no worse than if the product didn't exist, then you're likely okay. However, if failure leads to an unsafe situation, including being in such a situation because your co-designer thought the product was working, then you may want to reconsider. 

A typical example of this kind of product are things that are designed to help visually impaired people cross the street. Technically, product failure makes the situation no worse than if it wasn't there (likely the current way the user would cross the street), but if the user was expecting help from the product, which is now missing, then it may place them in a dangerous situation.