The project format is often the default way of organizing product development. Many organizations have elaborate processes for managing projects such as the UK Government’s PRINCE2 and Ericsson’s PROPS. Both are examples of the Stage-Gate process referred to in an earlier post.

Sometimes the project format is warranted, sometimes it is not. I came to think of a rather old paper of which I have faded photo copy in my (physical) binder with papers I have collected throughout the years. I happened to find it online [1] so that I can share it with you too.

The paper discusses what organizational form to choose for a project based on the nature of the project. The paper in the beginning emphasizes that it only deals with the “project organization” dimension of the project, not the “project management” dimension. The two dimensions are strongly correlated though as is demonstrated in Fig. 6 in the paper. In the functional end of the spectrum there is no project coordinator which obviously implies less focus on project management; the stronger the project organization, the stronger the project management function.

So when do we need a strong project organization and hence strong project management? This is discussed in Fig. 5 in the paper. Basically it says that when there is high uncertainty, new technology, high complexity, long duration, large size, one or a few customers, and high time criticality – in short when there is high risk – we need a clear project organization and strong project management. (See also this earlier post.)

When the opposite is true (low risk), then we can do with less project management and spend more of our resources on the technical tasks of the project. With low risk we can also think more “product” than “project” as discussed in my previous post.

When a product has been firmly established on the market (think Microsoft Word), most major customer risks, technology risks etc have been eliminated. The need for strong project management with all the risk management bells and whistles thus decreases. In this scenario the product is typically market driven to a high degree with a steady stream of new feature requests or correction requests (“bug reports”). Each such feature request or correction request needs to be analyzed on its own merits with respect to cost and benefit in a process that can manage the continous flow of requests. Once thus analyzed and decided, and given that the new feature doesn’t imply any major risk, there is less need for full-blown gate reviews and the rest of the project management apparatus when implementing the feature. We instead have a situation where Agile project management and development methods suit well. The list of approved feature requests maps nicely to the product backlog of Scrum and the informal risk management methods of Scrum [3] are sufficient.

Cold Fusion
Ready to go under the hood? (Source: Wikipedia)

It never makes sense to throw in one or a few high-risk features in an otherwise low-risk project. With other words, research and development should not be mixed in one and the same project. One high-risk feature amid 15 low-risk features may still determine the risk of the whole project and thus the required degree of project management. My favorite illustration of such a high-risk feature would be cold fusion as the suggested power source for an upgrade of an excavator or a similar machine. Regardless of how trivial the other added features are, the project will have a high risk of failure. Instead the cold fusion drive should be developed as a separate research project to remove most of the risk. (Good luck!)

For the continuos decision making and implementation of new features in an Agile process to work, the new features must thus carry a low risk. [2] and [3] describe how the residual risk can be managed in Scrum. (Note that [3] does not compare Scrum to a Stage-Gate model but some kind of very traditional everything-up-front waterfall model which may not be very realistic.)

I will write about the process of deciding and continously implementing new (low risk) features in a future post. Scrum covers part of the process but I’d like to add a thing or two.

Links

[1] Organizational Alternatives for Project Managers, Robert Youker.

[2] Managing Risk with Scrum, Vikas Hazrati.

[3] Managing Risk in Scrum, Valerie Morris.