- Project, Programme and Portfolio Management
- No comments
There is currently a push within the project management community to extend the use of agile methodologies, such as Scrum and Kanban, to other industries beyond software development.
Whilst being agile is, in principle, obviously a commendable quality to aspire to, there are good reasons why agile approaches came about for software development rather than for hardware development. The cost implications of reacting to changing specifications are generally much lower when dealing with software than with hardware, due to the tooling and prototyping costs associated with the latter. Also, the rectification costs of products released to the market that subsequently give quality issues are generally much lower for software than for hardware items.
We are all familiar with the strategy of software vendors whereby products are released to customers as soon as possible (having undergone limited testing) and then later providing an upgrade pack to rectify all of the bugs that the public have found (having paid good money for the product!). They may even provide an option to pay an ongoing cost for ‘support’, for when their product crashes or isn’t behaving as it should do! Savvy consumers know to wait some reasonable time before buying a software product, after which it should be more robust.
With hardware products it isn’t so easy to roll out updated components, say, to customers, to resolve issues that they have found after purchasing the product. For example, when a motor vehicle manufacturer has to recall all of the cars of a particular model due to such an occurrence, the logistics are very difficult to arrange and the associated costs are huge. As a result, the detrimental effects on the brand are generally far more extensive than they are for software, for which we are surprisingly accepting of ‘flaky’ products.
The prime driver for agile methodologies is to enable changing requirements to be accommodated during the lifecycle of a product development project, whilst enabling both cost (budget) and time (schedule) constraints to be achieved. The well-known project management triangle of Quality, Cost and Time is useful here for highlighting that Quality is therefore the project management variable when applying agile methodologies to the development phase. We have already established that dealing with quality issues on software products, which have been released to customers, is generally far easier and cheaper than dealing with issues on hardware products. When developing hardware products, the Cost and Time elements of the project management triangle are, in fact, more likely to be variables than Quality. There is a well-established MoSCoW approach to dealing with requirements with agility, that is a simple and effective and can be invoked on such projects.
We can only logically conclude therefore that agile methodologies should only be applied to software development projects, unless the rectification costs of a hardware product will be acceptably low which, until we create an internet that handles easy transfer of hardware as well as software, this will be very rare. We have 3D printers now, so maybe it won’t be too long!
If you found this article interesting and would like to read more about how to keep project management simple, please read my blog post on Simple Project Management.