A Guide to Challenging Projects
In my previous article, which suggested project ideas for engineering students to work on to expand their knowledge and experience of designing electronics, I suggested some tips for breaking down a project to be more manageable. In this article, we’re going to take that a step further and focus on how you can break down complex projects into smaller, more manageable sections. It is easy to get overwhelmed with a project that is more complex than you have handled before. Still, with some ideas stolen from the Agile Methodology, we can make the complexity easy to understand.
The strategies in this article will help you take a complex project concept and break it down into manageable chunks. By starting with a high-level feature set without getting too bogged down in technical details, we can then begin to break up the project. These high-level features can then be broken down into the technical requirements to implement them, and finally into manageable tasks. If you have trouble getting started with projects or want to make it easier to keep on track, these strategies should help you!
We’re not going to dive deep into Agile. Instead, we’re just going to cherry-pick a couple of ideas that will make your life easier. If you’re a single engineer working on a project, you may not find many advantages in implementing a full Agile workflow, as much of it revolves around teams.
Seeing the Device from the Users Perspective
In Agile, there is the concept of a User Story, which, as the name suggests, is the story of a specific portion of the project from a user’s perspective. I find this very helpful, as it is a non-technical view of what functionality a user might require. This also helps us better understand what our product/device is going to do. Rather than saying you need to have an NTC thermistor connected to your board, you are merely stating that as a user, you want to be able to sense temperature. As we break the user story down into technical features and tasks, we can evaluate what the best approach is to achieve the needs of the user.
When I break down a project idea, I like to write a single sentence from the user’s perspective for each piece of functionality I want to have in the device. There’s no technical focus, no thoughts of implementation, just some functionality I want the device to have.
As an example, I want to build an action camera, and this would be a pretty daunting task for most graduate engineers or students - you might immediately start thinking about microprocessors or image sensors and can quickly get completely bogged down in the technical details. Instead, start off thinking about the camera as an end-user, no matter how obvious the detail might be. Imagine you have asked someone what they want/need their action camera to do. My user stories might be:
- I need to be able to start and stop the recording by pressing a button on the camera.
- I would like to be able to start and stop recording remotely.
- When a recording starts or stops, I should have an audible indication.
- When the camera is recording, I need to be able to see some indication that it is recording.
- I want to be able to see the view through the lens on the camera.
- I should be able to configure the camera without any external devices or connections.
- I would like to see my recordings wirelessly on a phone or tablet.
- I would like the camera to be functional when it is not connected to a power source.
- When the battery is flat, I need to keep filming the action.
- I should be able to charge the batteries without needing an external charger.
- My video needs to be 4k and 30frames per second to capture the action.
- I need to have high-quality stereo audio in my recordings.
- If I fill up the video storage, I need to be able to keep filming by changing the storage media.
- I should be able to retrieve the recordings from the camera without removing the storage media. Retrieving the recordings should be fast.
If I was doing more than designing the electronics for this, such as working with a mechanical engineer or doing the enclosure myself I might add extra items about how waterproof it should be, points for mounting, etc.
If you can’t describe something a user needs in a single sentence, your scope for that item might be too large. Break it down into smaller pieces, such as all the items related to starting/stopping recording in my list above. If you have been able to describe the user’s requirements in a single sentence but want to provide more details about what the user expects, you could then add a paragraph to the user story. For example, on the user story about having an audible indication, you might provide details about the specific sort of noises the user might make next - this could help guide your search for components.
Now we have a list of functionality for the device without any technical details about the implementation. We have a list of desired functionality we can constantly refer back to ensure the project is on track from a user functionality standpoint. This is going to allow me to deliver a better product for the end-user. If I started from the technical side, the end-user functionality would be a secondary consideration. By starting with the end user’s perspective, we ensure the technical side of things is supporting the end goal of the product, providing that it will be successful.
Breaking Down the Stories
When reading through the list of user stories, you might have a gut feel about what sort of components you need to use to meet the requirements of the user. The next step for me is to create tasks for technical functionality associated with each user story. These functionality items are going to be the technical implementation, but we’re still going to be relatively high level at this point. After we have a list of the technical requirements to fulfil the user stories, we can break those down further into specific ICs or circuitry that is required.
The functionality list we create from the user stories is what we can then use to start researching components. You might not be able to proceed to break down the functionality further without doing further research into components. Still, you will at least have a clearly defined set of functionality you’re looking for a solution for - much more manageable than just trying to figure out a whole action camera.
Hopefully, your user stories are simple and narrow in scope, and this will mean you likely will only have one or two items for the technical requirements to implement each user story. If we look at the user story “If I fill up the video storage, I need to be able to keep filming by changing the storage media”, I immediately know I’ll want a microSD card socket, a decoupling capacitor, and perhaps some ESD protection. I’ll also need a 3.3V voltage supply for the SD Card if we don’t need one elsewhere on the board.
For the device storage user story, I might create the following tasks:
- Add MicroSD Card Socket
- Add ESD protection to MicroSD Card Socket
- Supply 3.3V to MicroSD Card
For a more experienced engineer, merely having a task to add a MicroSD card socket would be sufficient, but if you’re a student/hobbyist/graduate, it can help to break things up further. This is two-fold when planning your project: you capture your intent with a task you can check off, and during implementation, it feels terrific to check off a bunch of items as you go. It might sound a little silly saying it feels to check off lots of items, but I find it does help keep momentum and motivation going on the project. As you get more experienced, the scope of the tasks will grow, but you’ll be checking them off just as fast!
Going a Step Further
If you want to capture your ideas and design intent at the start of the project, or you’re still feeling a little unsure of the exact implementation, you can break down the tasks even further. This is a perfect time to start trawling through Octopart ®, or your favourite distributor’s website to start finding exactly which part you want to use in a design. Using the MicroSD card socket example above, we could add the Wurth WR-CRD 693071010811 socket to the task list. It might seem a bit excessive to create an item just for that part, but if your library doesn’t contain the part you want to use, don’t forget you’ll need to create a footprint and symbol for it - each of which is worth a task of its own.
While the MicroSD card socket is an extreme example if you already have it in a library, something like a power supply or analog circuitry likely isn’t such an exaggerated example. If you need to add a switched mode voltage regulator for the 3.3V supply, then a task for simulating the design is worth having. It’s more than just having to place the right symbol on the sheet, and you need to calculate the correct values for supporting components as well as determine the most suitable inductor and potentially also appropriate capacitors. Now your task list has grown to create the footprint and symbol for the regulator, capacitors, and inductors plus the simulation of the design, then the schematic capture and layout of the regulator.
The same would apply to the wireless functionality user story, and you would need the antenna, matching circuitry possibly filter circuitry as well as a potential balun to design as well, assuming the main processor contains the radio transceiver. These should be at least calculated, and probably simulated as well - and the board itself should be simulated if this was going to be a mass-produced item. By breaking down the tasks you generate from the user story, you can more precisely determine what needs to be completed to get the project out the door.
The more granular your tasks, the less overwhelming or challenging each task will be. By breaking up your user stories into tasks and then todo list items, you can get a good feel for the project as a whole, and have manageable items to work your way through. It can be a lot of work upfront, but it will save a huge amount of time as the project progresses as you have already thought about the vast majority of the implementation of the project.
Simple Tools for Project Management
It’s all well and good to talk about the concepts here, but it is probably not something you’re going to jot down in a notepad (physical or digital) and have any success with. There are some great tools out there for project management, which can help make managing your project easier.
For free, you can use Trello which is similar to an Agile KanBan board, with lists that have items under them. You can create a board per project, so each project is easy to view and manage. If you have a relatively small number of user stories, you might want to create one list per user story, then one card per feature - you can use checklists on each of these cards for subcategories giving you the ability to mark them as done. Use colours to show the state of each item on your list.
With larger projects where a considerable number of lists isn’t practical, it can make more sense to follow a more traditional KanBan style of a backlog list full of features, an in-progress list for features you are working on, and a completed list. This does make it harder to keep track of the user stories, however as we’re just stealing concepts from Agile rather than implementing it - adding another list for your user stories can let you keep track of them all. Then add Labels to each feature card for the user story it belongs to. This allows each feature to be its own card with a checklist of items that need to be completed for it to be considered done and moved to the Completed list.
If your project is getting to be complex, a tool such as Atlassian’s Jira is free for the functionality level you need. It will allow you to implement complex project management strategies. Jira is incredibly Agile friendly and will understand what you are trying to accomplish - it’s one of the most popular project management tools in the world for Agile project management. I personally use and pay for it to manage my own projects, including software development, firmware development, and hardware design.
There are dozens of Agile oriented project management tools available for free, so if Trello or Jira don’t meet your expectations, you will find something that will be without much difficulty. Most tools available for free allow three to seven users to join you working on your project. If you have some friends, colleagues, or classmates helping with the design, software development, or mechanical design they can join in to see the tasks relevant to them as well. This allows you to make the most of the planning process by including all aspects of the project.
Finally
The process above is just a suggestion of how you can get started on breaking down complex projects, giving you a starting point to figure out what works well for you. The methods that I find work well for me might not be perfect for you, so don’t feel as though you must follow my suggestions to the letter! As you work through your first projects with this method, you’ll figure out what works for you and what doesn’t. Don’t get stuck working on a planning aspect that is not working for you, as it’s just going to make your project less enjoyable and potentially dampen your momentum or motivation to work on the project. This guide is intended to help you on the path to a process that will allow you to work on bigger projects than you thought you could tackle, and make complex projects less daunting to get started on.
Whether it’s software, firmware, or hardware, all projects no matter the complexity are essentially just many small, basic building blocks stuck together in just the right way. Once you start treating projects as small building blocks, anything becomes possible.
For your next steps in project management, consider looking deeper into the Agile Manifesto. While it is targeted at software development, many of the practices and ideas can be successfully applied to hardware projects as well.
Would you like to find out more about how Altium can help you with your next PCB design? Talk to an expert at Altium.
