On the mailing list of Agile Sweden there was recently a long thread on models for life cycle approach to software development and the Agile community received some critique for maybe not having tackled this view, and of course the favourite topic of “project” was raised. The rest of this post is a translation, with some minor edits, of a post that I did to that mailing list, where I tried to summarize my views on “projects”. This was among other things inspired by a blog by James Shore where he described his way of managing the incorrect use of the term by the rest of the world.
I think the rigid command and control mentality evident in many of models and thinking of the last few decades stems from an increasing suspicion towards larger and larger projects with continuously increasing complexity. And rightly so. As we (the engineering and technology community) have become masters of the current technology, we have tackled even more complicated and challenging projects, and of course the amount of “failures” has grown, or at least the economic impact of the failures. The natural reaction is to try to control everything down to every little detail, thinking that detailed control leads to overall control. The problem is of course that this has been the wrong solution to the problem.
Software development has characteristics that make it possible, and even natural; to handle the result of it in manners different to the way we do in other engineering disciplines. One example is that the time between a design change and its actual implementation in something that can be delivered can be extremely short, seconds, even. It is nothing but natural that “Agile” as concept was born in this environment. But many people seem to think that it is only in this environment that “agility” can exist. My own view is that “Agile” is a structured way of tackling the unknown, or uncertain, future, and despite this uncertainty, be able to deliver as good a result as humanly possible given the actual circumstances. (We have come to learn that the alternative, i.e. to guarantee the result upfront through command, control and exercise of power and forced promises, is not possible even in theory.) But it is unfair to blame the current confinement of agile principles to the software discipline on the Agile movement. It is after all the people around us that are hard to convince. And we need to face these very strong counter forces, if we intend to win over them. (Most of us have probably heard Craig Larman talk about his parallel to the bloodletting as the “true” way of fighting the diseases of the Middle Ages.) But let us work together to find methods and opportunities to break away from the grip of these powers, so maybe we can do it in less than a hundred years.
Projects, as a form for organizing work, has been promoted as the most effective for decades. I think there are a number of reasons for this:
1) a group of people working towards a common goal is more efficient than single individuals
2) if you define a measurable goal it is possible to objectively decide if it has been achieved
3) a goal can be subdivided into activities that can be estimated giving a resource budget
4) given a resource budget you can calculate the cost and thereby the ROI of the investment into the project
5) when you have an investment budget you can follow up against it
Since the term “project” can loosely be interpreted as “a number of people working towards a common, measurable, goal” it is possible to fit the term to almost anything. Which of course also has been done. So, naturally, there are projects of all shapes and forms, and we who criticise the project form (ok, I’ll only speak for myself!) occasionally get a little undiscriminating since most models has over-interpreted the term project, or at least not drawn the conclusions that the project form has some drawbacks and must be supplemented with other models and views.
I am sure that item 1) above does not imply hundreds of developers, testers and architects spread over half the globe, which is not uncommon these days. I think it means what we today talk about teams. So the current scale of projects was not even envisioned when the project form was “invented”.
Item 2) is aimed at focusing the work on a result, e.g. a delivery. But what if the goal is something more elusive? An improved enterprise, maintenance of an existing investment such as an IT system or a software product? Then the goal is no longer limited and nearly unattainable. This is obviously also a problem.
3) is often interpreted as “activities that can be performed by one type of persons with a particular competence”, e.g. 30 masons in four weeks, or 5 requirements engineers in 5 months. By doing 3) we can do 4) and 5) which obviously is very important to any investment. But it only covers the “cost” side, not actual progress or even delivered value.
My main concern with the “project model” is that its interpretations are mostly locked in “resource and cost monitoring”.
While estimating activities like analysis and requirements work, design, implementation and test etc. may be useful to get an initial cost budget, it is however no progress tracking to follow-up actual hours worked in the manner that e.g. the “Earned Value” models does it. When you actually start the project you need to turn from resource budgeting to progress tracking in real measurable results in the “product”. (E.g. software functionality, work model of the enterprise or whatever is the actual result.) These measurable results must become our items for tracking progress.
Another big weakness of the project model is when it is used in a “matrix” organisation. In such an organisation you often find allocation of people from a competence oriented line organisation to a set of concurrent projects. In this situation it does not take long before people with some important competence is “working” 20% for 5 different projects, which of course is not possible even in theory. (My presentation from the conference “Agile i Sverige 2007†contains a demonstration of this problem.) Used in this manner the project model becomes a tool to pretend to be able to cope with more work than there are resources for. This pretence does not become evident until the projects needs to signal delays (which, given the project manager “chicken race”, is as late as possible. The common counter measure is to raise the priority of the project in the deepest crisis, which usually doesn’t mean that other projects are deferred and work on them suspended or diminished, since their delivery schedules where already “committed”…
IT as support to an enterprise is a form of project that has a very high degree of continuity to it. For these projects the investment calculus is almost impossible to do in the classic project manner. Instead a present value analysis akin to the one performed for other capital assets like machinery, freighters and industrial buildings seems more appropriate. There is an investment, certainly, but also a non-negligible cost for maintaining, sustaining and operating. Active Maintenance is a good term for how to handle these circumstances. (Actually, this term, which is even better in Swedish, is the title of a report written by Peter Tallungs, then at Kentor, currently at Objectware.)
Some product development would look very much like this. I am referring to software products like Microsoft Office, SAP etc., where continuous development is the only survival strategy. Here also, Active Maintenance seems like a feasible model, even if there is some need for the investment view before taking on new product development, development of new functionality for diversifying the product or for markets where break-even need to be reached or surpassed.
There is also much product development that is very much “project”, even though it contains a great portion of software. Development of almost any product that is manufactured in larger series (mobile phones, set top boxes, cars…) is very much more goals oriented since the start of a product batch is kind of “final”. This is another facet of the project concept.
Even in companies with this kind of product development I often see a form of products that might be called the “Scandinavian model”, a kind of internal platform products. Developing and maintaining a platform of common functionality that is adapted to different customers, markets or application areas drastically reduce the “cost to marketâ€. F-Secure, a Finnish anti-virus company, presented its approach at the Scrum Gathering in London 2007 and was the most recent example I’ve seen. I don’t know how common this strategy is in other parts of the world, but I see the same strategy in many of the companies I have worked with. In these situations the standard project model is quite insufficient.
I am convinced that there are a lot of projects out there run by cross-functional teams of 10 or less full time members, working iteratively towards their delivery, tracking their progress using concrete results, not hours worked. For these projects the project model is no problem, it does not get in their way, and probably is beneficial to someone.
But problems with the project model do not only exist with organisations, customers and managers. Has someone seen a CM tool that in its “New” menu has “Product” instead of “Project”?