Monday

Hard -v- Soft Projects

We are working on a couple of paper where a concise definition of hard and soft projects would be helpful.  Most commentary on the subject seems very imprecise and based on tangible v intangible outputs.

Tangible means perceptible by touch, but a piece of artwork (say a painting) can be touched! However, if the creation of the artwork is treated as a project, in almost all other respect the project is a soft project, the same goes for most design projects. The concept of a soft project is one where stakeholder engagement and change are welcome, with a focus on achieving the greatest value or stakeholder satisfaction at completion.

We suggest the primary differentiation between the two, is the various components of a hard project have to literally fit together, this required a detailed design to be finalized for each subassembly, before necessary parts can be procured and assembled. Furthermore, the overall design has to be progressed to a stage where there is a high degree of confidence the subassemblies will fit together into components and the components will fit together to create a final product that functions correctly and meets the specified requirements.

This means a hard project needs the detailed design of each subassembly or component to be completed before the project team can start working on the component and each component has to be built to the design.  Change is a complex and often expensive process.   

In contrast, the detailed design of components in soft projects can be, and very often is, done as part of the work involved in developing the element. While the function of the component is likely to be set in the overall design, how the functionality is delivered is flexible and most changes can be accommodated comparatively easily. In essence, agile is designed to deliver soft projects.  

There is of course the added complication that most hard projects include a significant element of software, and many soft projects include some hardware.

These factors suggest the definition of hard and soft projects should be:

A hard project is one where the majority of its subcomponents require the detailed design of the subcomponent to be finalized before work on the subcomponent commences, and the subcomponent is expected to be built to conform to its design.

A soft project is one where the majority of its subcomponents require the functionality of the subcomponent to be defined before work on the subcomponent commences, but there is significant flexibility in how the required functionality is achieved.

These definitions could be reduced to:

A hard project is one where the majority of the work is dependent on a finalised design being complete for each element of the project, prior to work starting on that element.

A soft project is one where the majority of the work has a degree of flexibility on how the required functionality is achieved.

What do you think??

2 responses to “Hard -v- Soft Projects

  1. I would suggest you look into ‘complex vs. complicated’.
    You’ll find most of your answer there.

    Like as in ‘hard vs. soft’ problems in AI, where the first represents a regular expertsystem, and the second a self-learning system

Leave a comment