On paper, all software requirements look achievable. But for anyone who has been involved in developing new products, software is often the villain causing overruns and budget blow outs.
As a project manager with a proud software engineering background, I see no reason why software should be the source of frustration or technical risk in any product, and certainly not biomedical products where it is increasingly becoming a critical component of the device or instrument. In fact, I would like to see the image of software transformed from the villain to the hero of your next product. Here are five strategies that I use to ensure the software team are seen as super heroes on your product development team.
1. Cut requirements that don’t directly benefit the user.
The first golden rule is to only develop what is really necessary. While it sounds obvious, traditional software development approaches can eat up a lot of valuable time and budget developing software infrastructure that doesn’t provide any tangible value to the user.
Functionality can also find its way in to the product without being adequately challenged by users. This occurs because users, even with the best intentions of cutting unnecessary functionality, find it very hard to read through software requirements on paper and confidently challenge the necessity or validity of each function. The best way to get users confidently challenging software requirements is to get them using prototypes of the software as early as possible. By running frequent user trials you can identify functionality that just isn’t necessary and cut it from the schedule and budget.
2. Think like a systems engineer and consider the impact of design decisions across all engineering disciplines.
Inexperienced project leaders who only have deep knowledge in one discipline can often make poor development choices by not thinking broadly about the overall engineering impacts.
I once worked on a product development that had a leader who really only understood mechanical engineering. Because of his limited background he had a far greater appreciation for the mechanical elements of the project than the electronics hardware or software. At one stage he made a series of decisions that saved $50k on the mechanical re-tooling but ended up costing the project over $250k because the electronics hardware had to be re-designed, causing large software delays. He did not appreciate the total cost associated with his decisions. Always ensure your project leaders have a multi-disciplinary, systems engineering approach to running projects and have the ability to think holistically about the big picture.
3. Develop software independent of your mechanical and hardware designs where required.
The software element of your project can sometimes end up starting later than scheduled because it is often heavily dependent on the mechanical and hardware electronics designs, making it prone to inheriting any upstream design delays. Obviously one solution is to avoid any delays at all in the product development, but because software is generally one of the last disciplines to be finalized before verification, it is often a risk that needs to be actively managed.
One way to avoid this issue is clearly identify and reduce software dependencies on mechanical and electronics development. By developing software on a virtual machine or on evaluation hardware platforms, independent of the actual product hardware, software modules can be built and tested earlier in the project cycle and with less dependence on other teams.
4. Test early and often — well before hardware is ready.
Well before product completion, deploy your software for user trials and testing. This should be done even before final hardware is available.
The way you run early user trials will depend on the architecture of the system but an example is using a web-based wireframe implementation of an embedded user interface to get users playing and evaluating the software design.
Unit and integration test frameworks, which can be automated, are a great way to reduce the overhead of testing time. You want to repeat this approach throughout the project applying what is commonly referred to as continuous integration. This approach addresses bugs well before major milestones. With traditional “big” release approaches, you can end up with a massive job of fixing up all the bugs that have been identified since the last release. By finding them earlier the engineer who is still thinking about that code can address the bugs in much less time.
5. Be as visual as possible
Visualizing progress is powerful. It immediately gives you, and the broader project team, a sense of how much effort is remaining to complete the project. Product backlogs, story boards, burn up and burn down charts are all great tools to aid in communicating progress.
These visual communication tools, in combination with daily stand-up meetings, make it really easy for other project members to see if they are causing bottle necks and holding up software. This will result in a better focus on delivery results by both the software team and the broader project team. This approach is part of a set of Agile development techniques which I will delve in to in future articles.
From villain to hero
Software should be a key way for you to differentiate your product from your competitors and really excite and delight your customers. It should provide you with flexibility and a path forward to release a series of winning products that continue to lead the market. Whether your software team choose to wear their underwear on the outside or the inside, I will leave to you!
