Do These 10 Things For Better Product Development
For more than two decades I have been an independent consultant for the high-tech and medical devices industry, for established high-profile clients as well as fledgling startups. Having been brought in to advise these companies on the management of troubled, underperforming projects and engineering operations, I’ve come across quite a few of the challenges and pitfalls faced by modern day manufacturers.
Here, I’ve listed 10 of the issues I’ve frequently come across, along with ways to mitigate or avoid them
1. Nail Down Interfaces
Describe in detail all system and sub-system interfaces, be they physical (hardware) or non-physical (such as software or indirect couplings between a system and its local environment). Assign interfaces to one or more interface managers to keep track of demarcations and manage all agreements and issues related to these interfaces. This is especially relevant when your team is not solely responsible for the development of the product or system, and you need to cooperate with development partners. The boundary of your deliverable is where things typically go wrong.
A clear definition of the scope of your project is essential to establishing exactly where these potentially troublesome boundaries are. Don’t assume the scope is clear to all; it is not. Clarify, write it down, and share with teams and stakeholders, and do it before development work begins. During these scope discussions, you’ll experience first-hand just how creative people can be in interpreting scope, absent explicit documentation.
2. Don’t Over-Define Relationships With Temporary Co-developers
Alongside permanent staff, project teams often include temporary workers, brought on either on contracts or who belong to partner organizations. (These latter workers often come as a complete team.) A common approach is to start off the relationship with these workers by specifying their sub-projects, establishing deliverables as well as deadlines. After all, this is how you keep them on their toes and keep them from stalling to bill more hours, right?
Wrong. What these (often vague) contractual agreements will do, is trigger endless arguing about contract variations, scope discussions, and constant escalations that lead nowhere and will only result in mistrust between both sides and even more delays.
Instead, a more productive way to co-develop is by integrating these temporary co-workers and teams into the project and treat them as if they were regular part of your organization. Using integrated teams offers more flexibility, more effective cooperation, less miscommunication, and less misunderstanding—in short: higher development speed. Integrated teams are happier and more motivated, and therefore more productive. Also, using integrated teams frees up management bandwidth to focus on other things than fighting with your partners and suppliers, ultimately adding value to the business.
3. Insist on Realistic Quality Management
Elegant technical solutions are terrific but usually the eureka part of product development work is rather limited; the humble fact is that ensuring quality in products is mostly painstaking work: following carefully thought-out processes and taking care of the associated documentation—the stuff that few like to do. Do you have business processes in place for developing and launching new products? Do you actually follow them—meaning you have an active verification mechanism? “Oh yes, we have a quality management system,” is the often-heard answer. But do you and your team members thoroughly understand and apply it? Take a step back and be brutally honest: does it date from the eighties with a few tweaks here and there? Does it really satisfy present-day business needs? Does it still make sense? Is it bloated, full of boilerplate and waste—the stuff you do solely because that was the way you always did it?
A quality management system whose description spans over 800 pages across more than 100 documents is not workable. That’s a real-life example, although not every page had to be read as most of the documents were just empty shells containing nothing but preformatted text, which is arguably worse. Keep it short, 50 pages max.
And don’t let the rules become a straight jacket. If you need to deviate from the quality management system for good reasons, by all means, do so—but document the changes, and see if you need to revise the rules permanently to match present-day needs.
4. Don’t Confuse Planning With Scheduling
Many people conflate planning and scheduling. But they are not the same. Planning comes first: what do you need to do to finish the project? The plan is basically a summing up of all the steps it will take. Make it explicit. List all steps (e.g. work-breakdown elements, work packages, backlog user stories) in as much detail as possible. Don’t worry if not all details are crystal clear right from the start; refine as you go. This forces you to think upfront about the challenges ahead and plan for their resolutions, including skills, people, resources, and budgets needed to resolve them. But once you have a plan, don’t just add dates to create a schedule and drop it on your people.
The team members that will actually be carrying out the work need to give input on their work packages’ respective lead times. Don’t do this for them; you’ll miss the mark, and the team will not feel committed to the schedule. Also refrain from inserting buffers everywhere; just make it as realistic as possible—it is a best-guess estimate, after all, and everyone, including stakeholders, will need to treat it as such. Not treating it as such and creating an atmosphere where missing deadlines has implications for careers—a “heads must roll” mentality—will just motivate team members and sub-project managers to load up schedules with all sorts of unrealistic buffers upon buffers. At the same time, missed deadlines should be analyzed and the reasons for missing the mark fed back into retrospective sessions, so the team can improve.
5. Train the Whole Team in Project Management
Contrary to general belief, project management is not carried out by (nor is it the sole responsibility of) the project manager(s). The truth is that projects are managed by the entire team, whether you acknowledge this or not. Put another way, you can have a team that cares nothing for structure and control, and add a great project manager, and you’ll still end up with chaos. That’s why I am a firm believer in training the entire team, down to the most junior member, on project control techniques.
6. Separate Research From Development
Don’t incorporate research into your product development projects. Product development should be about combining state-of-the-art—though proven—technology in new ways. The innovation lies in new combinations. Don’t try to innovate by incorporating technology that hasn’t proven itself yet. Maturing new, unproven technology takes years or even decades. This doesn’t mean a company shouldn’t try to break new ground or come up with wild ideas. Just don’t go pretending the new stuff will hit the market next year or the year after—unless, that is, you want to trick unsavvy investors or corporate leadership into embarking on highly risky, endless voyages with no destination in sight nor even a clear idea of one. (Word of warning, though—such voyages can end in jail.)
It is okay to have a team work on research alongside development—but separate the research from the regular development work and mark the research items as such. Thus, the associated risks and full weight of the challenges ahead remain fully transparent to all involved. And if the research doesn’t pan out, you’ll save yourself the resources you would otherwise have wasted on dead end development.
7. Demos Are Not Enough
Demonstrations are a great way of getting the whole team and all stakeholders updated and involved; they are more engaging than dull presentations stuffed with tables and graphs. But use of demonstrators is no excuse for skipping documentation nor does it dismiss you from thoroughly understanding your product and the underlying science. Otherwise, demos will just lead to development by trial-and-error: something more appropriate for a pastime rather than professional development.
8. What A Steering Committee Should—And Shouldn’t—Do
The purpose of a steering committee is to help with impediments developers and project managers cannot resolve themselves. This includes navigating around roadblocks within the organization and mitigating high-level issues such as those related to capacity or personnel availability, requests for additional budget, and conflicts with strategic development partners or underperforming suppliers.
What a steering committee should not do is “help” the project team by doing its work for it. In other words, if you have a strong opinion on the market requirements, the technical specs, the way the engineers broke down their electronics design or set up their code base, get off the steering committee and join the project team. Otherwise, you’re just holding up the project, creating a lot of frustration, and ultimately possibly even sink the entire endeavor.
9. Don’t Get Hung Up Analyzing Which Stage A Project Is In
Don’t fuss too much about whether the product under development is now in this phase or that, for example, pre-development versus prototyping. Stages are used to avoid wasted effort and resources on products that won’t make it to market after all, creating checkpoints where would-be flops can be terminated early on. That’s why all variations of staged development follow the same principle: they go from high risk/low costs to low risk/high costs. Initially, you try to eliminate the risks of not making it to market at all; then in the final stages you pour in the big money and resources to build up the production lines and set up the field sales and service organizations that will supply and support the market. As long as you keep that in mind, you’ll find that whether the project is in phase two rather than phase three of ten is really not that big of a deal; avoid senseless arugments, fix any particular missing deliverables associated with a phase at a later stage, document the deviations from the process, and move on.
Project staging enables making go/no-go decisions early on. Giving the go, however, is always easier; it takes courage to terminate a project—the main reason many dead-on-arrival projects tend to drag on. Be bold if the signs are mostly red, and be bold as early as possible.
10. Product Development Is For Marathon Runners, Not Sprinters
Product development can be painstaking and dull drudgery at times. Despite what the public might imagine, there is nothing fancy or flashy about developing, say, an electric car. Your team has to work through failure after failure, set-back after set-back, and spend long hours on the factory floor getting the design successfully transferred into production. Make sure you have the right people for the job. If someone is complaining this or that work is beneath their ivy-league training or superior intellect, get them off the team and put them up for promotion to a management job. Product development is for die-hards, ladies and gents who don’t complain, who keep at it no matter what, who understand that, yes, not the most exciting job in the world perhaps, but that cable plug needs to be engineered as well else the whole product falls apart; yes, the screws currently used screw up regulatory electromagnetic compatibility, let’s try these different screws, redo all testing, and see how it holds up. The mentality, the will to do it, along with a healthy dose of curiosity, is more important than an impressive resume or the fancy titles on someone’s business card.
IEEE Spectrum
