Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

Why Projects Don't Make Sense

10.07.2013
| 8419 views |
  • submit to reddit

 In the last few months Steve Smith, myself and others have been Tweeting a lot with the hash tag #NoProjects. We have independently come to believe Projects are a smell, they are bad for our industry (the technology industry). Steve set out his thinking and now it is my turn.

Right now this is little more than a bullet point list, I’m presenting to PROMS-G in February (“The End of Projects”) where I will present a more coherent argument. Until then here goes.
Lets start of by defining “A project”.

The Project Management Institute says:

what is a project? It’s a temporary group activity designed to produce a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. … The development of software for an improved business process, the construction of a building … — all are projects.
And all must be expertly managed to deliver the on-time, on-budget results, learning and integration that organizations need.”
PRINCE2 defines a project as
A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.
Actually, PRINCE2 has two definitions of a project:
“project management is the way of managing change. Everything from the Olympics to organising a wedding can be considered a project. It describes the activities that meet specific objectives and can be used to introduce or improve new or existing products and services.”
Bearing this in mind I suggest the project model does not fit software development:
  • Projects have end dates - successful software doesn’t end, it not temporary. Finished software is dead software, software that isn’t used and doesn’t change
  • Successful software is continually developed and improved, the team is not temporary, it continues to exist (although it might change composition and the imposition of the project may at times destaff it)
  • Resources change: sometimes the people decide to leave of their own accord, sometimes the wider organizations decided to remove people or add others
  • The project model implies we can define what needs doing before we begin and that it won’t change. Software development uncovers need as it proceeds.
  • Project thinking implies that the problem can be defined independently before the solution: in software development the creating of a (partial) solution can lead to a redefinition of the problem being addressed.
Those points might be enough to persuade you the project model is not a good fit for software development. I go further, I think the project metaphor actively damages software development and destroys business value:
  • Project success criteria are “On time, On budget, On scope” and not business value. These criteria become a distraction and a barrier to hide behind - a “social defence” to use the jargon. Work should be value seeking and judged by the value/capability/benefit/[whatever you want] rather than arbitrary criteria which seemed good one day in the past.
  • Corporate Psychopathy: why disband a performing team just because a project has ended? Why start a project by pulling together a new team who have never played before?
  • Destroying team destroys knowledge - knowledge has value, knowledge exists in heads not documents
  • Project thinking induces short-termism - around quality, around productivity and around teams especially. Project thinking builds pre-fab houses when it should be building to last
  • Large batch size: projects lump lots of work together and attempt to manage it all as one large unit. This is inefficient (software has dis-economies of scale), breaks flow and delays delivery which delays value realisation
  • Project thinking makes BAU a dirty word; BAU is not a dirty work, BAU is where the action is: if it is worth doing it is worth doing more of, if it is not worth doing then close it down. Use portfolio management rather than pre-defined cut-offs
  • Projects inflict change on people (employees): why not seek their involvement? They own the work, they are BAU, the work stream should be seeking to improve itself as part of its daily work
  • Continuous improvement is continuous. Projects stop continuity, projects break flow and reduce effectiveness. Continuous improvement should be part of the fabric of everyday work, supported if need be by technologists.
  • Project thinking create scheduling projects: “Project B after Project A has finished, but if A is late….” - define work streams and feed them work
  • Projects confine change to projects and freeze change elsewhere
  • Start-up costs: bureaucracy, administration, etc. of starting a project mean the project model is expensive and slow at taking action. Project setup costs detract from value and the time it takes to “launch” a project detract from responsiveness. On a small work effort the costs of creating a project may be disproportionally high which may detract from attractiveness of doing the work. Similarly the time it takes to get a project scoped, a team assembled, everything kicked-off, performing and delivering creates a barrier to seizing value.
I recognize that a lot of what is called “a project” isn’t, it doesn’t fit the definitions at above. That simply makes things worse. Calling something a project when it isn’t is at best sloppy thinking, at worst it imports the problems listed into work that would otherwise be free of them.

Then there is scaling: so much of the “scaling agile” debate revolves around projects. If instead you accept standing teams dedicated to improving business as usual many of the scaling issues simply go away.

Projects are accounting codes to bill work back to. Projects are for accountants. Leave them at that.

Ask not “When will it be done?” ask instead “When will it start delivering value?”
Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

dieter von holten replied on Mon, 2013/10/07 - 9:35am

what you say sounds comfortable from a software developer's standpoint.

however - how will a software developer get an answer to the question 'does it deliver value?' ? most programmers i know are at home with nice, self documenting code, application of the latest and greatest toolkits/frameworks/languages. but few of them are aware of the cost of a single line of their code, their work-time, or the TOC of what they produce.

managers asks accountants for numbers. then they look at them and say 'if we could do this step of our business process more efficent, we could increase revenue by x % (by firing n people...). so, lets check feasability and then decide if we should start a project to implement it'. 

and then they find a project-manager, put him in charge, give him a bugdet and a deadline and the show starts. if all goes well, soon after the deadline (we are practitioners, aren't we??) the pm says 'mission accomplished', rolls out the changed system and everybody's happy.

how else could it be done?

what industry does your wisdom apply to? hardware? software ? embedded devices - consumer or industrial ? apps for ios or android ? a flight booking system? a web-shop? payroll-software? inhouse? shrink-wrapped on dvd? some opensource framework? what price-tag - what numbers?

the ultimate (simplified) consequence of your approach is, that the programmers are attached to their software - and are indispensable (enhancing this, tuning that - adding a little value every day...).

from a company standpoint this is the wrongest of all possibilities....



Rusi Popov replied on Wed, 2013/10/09 - 11:05am

Let's start from the end:

Ask not “When will it be done?” ask instead “When will it start delivering value?”

What is the value to deliver?

For the company the value is to have a new product version 1.0, (OK, not the best one) on time and hopefully on budget and on scope and start doing their business. This brings the revenue and the value for the company, a product for the customers and pays your salary - the value for you.

The process of continuous improvement you describe should have started from somewhere, from something already built and working, in order to improve it. This is exactly the version 1.0. But version 1.0 (and any other major version) is not built continuously improving ... mockups.

The methodologies based on  the product life cycle and the software development process refer this period as support and maintenance phase of that product. There the company has the stability of the existing product (a real value),  has the alignment of the product with the company goals (a real value), has some feedback from the customers which as a result defines the new value(s) and goals. This phase gives the company the ability to fix, mend the existing version, issue maintenance releases, service packs, name it i.e. apply the continuous improvement, based on the real needs and feedback. Here the changes are small, narrow and mostly isolated, which makes them suitable to be handled by separate, independent developers. But again, building a new product, a new major version, implementing new business processes in systems by teams of many developers is just another thing. Those methodologies refer it as inception,elaboration, design, construction, name it phase. And they need the strategic thinking in advance and planing of the resources, tasks and time what only the project organization provides.

The value referred in the article is the value for the user from the point of view of the developer, not even the point of view of the business analyst or the product manager and it is other than from the values above. Ask yourself which values are "more valuable" for the company, for the customer, for you at the end of the day.
Destroying team destroys knowledge - knowledge has value, knowledge exists in heads not documents
The knowledge of the product legally is the intellectual property of the company and wasting it is just a hostile act against the company. Yes, destroying teams is a pain, but the teams that have no documentation and thus no way to keep the company knowledge and property do not deserve anything else from the point of view of the organization and the business continuity.

The quotes above and actually the whole article demonstrate lack of understanding of the software development process and perceiving it as self-organized, just happening, when they happen activities of independent developers doing improvements with no goal and design. This is just a direct reflection of the wide spread and naive Agile hype, pretending to impose the experience from small projects and teams to projects of any sizes and scales. This hype will pass and only the proven practices and tools will stay to improve the software development process and project organization.

Allan Kelly replied on Wed, 2013/10/09 - 3:08pm

Thanks Rusi, I like it when someone is moved to respond.  And I actually agree with some of your points.

Let me come back on a few points you made, in reverse order.

First I didn't use the word Agile, I agree there is a lot of "agile hype" out there but generally agile hasn't challenged the basic idea of projects.

Second "The knowledge of the product legally is the intellectual property of the company and wasting it is just a hostile act against the company."  True the knowledge may belong to the company but it exists inside the heads of people who learned it while creating the system.  Until it can be removed and stored electronically the legal position is at odds with reality.  And since it is the company which destroys the team it is the company that is inflicting self harm.

Third, "need the strategic thinking in advance and planing of the resources, tasks and time what only the project organization provides."  I'm all for strategic thinking but I think this emerged over time and it isn't planned in advance.  If it planning was ever going to save the day we would all be living under a Soviet system with 5-year plans.

And where strategic thinking is most required is right with your first question "What is the value to deliver?" if you don't understand that how can you deliver value.  But make no mistake: on time, on budget, on scope has nothing whatsoever to do with strategy.

Allan Kelly replied on Wed, 2013/10/09 - 3:12pm in response to: dieter von holten

Dieter,

I think you got the arguement:


"the ultimate (simplified) consequence of your approach is, that the programmers are attached to their software - and are indispensable (enhancing this, tuning that - adding a little value every day...). "


Yes, I think that is the ultimate conclusion.  A software system may well be a life's work.  You can dispense with every other role in software development and still create software except for programmers.  You don't need project managers, testers, analysts, you can still create something.  I wouldn't advise trying it though.

No matter how much we might want to divorce programmers from the process you can't.  The sooner we stop trying and face reality the better.


Rusi Popov replied on Thu, 2013/10/10 - 1:33am in response to: Allan Kelly

Hello Allan,

Let me just comment the 5-year plans (despite the fact that I live in the former Eastern block and I well know what they were):

  • the software development methodologies I refer above elicit phases of the SDLC (see Scott Ambler, "Process Patterns", Cambridge 1998; also http://ambysoft.com/)
  • each phase has its own specifics in terms of activities, deliverables and dependencies
  • my practice shows that planning in advance of the later phases is not accurate (at all) until the previous phase has been completed
  • in addition, some activities within the phase (depending on the actual organization) may redefine the phase itself, for example the design gives the basis for the project's work break-down structure, thus redefining the construction, implementation, code, name it phase. Thus the project cannot be planned and cast in stone from the beginning.
  • anyway, from the beginning some of the resources and activities are well known like the target production configuration, the organization, the needed servers, the needed developers, etc. Planning them and the corresponding activities to deliver, setup, configure is really possible.
  • furthermore, the well known organization, architecture and framework (which were elicit iteratively in the years) pretty well narrow the options to do the things and give real hints on the kinds of the needed activities
In general our project planning practice is that from the beginning
  • we plan the phases as a whole (some methodologies refer it as iteration 0),
  • plan the well known activities (see above)
  • put placeholders for the other activity kinds to come (see above),
  • put general estimates of the resources
  • after each activity that may define the plan we put an explicit activity to improve the plan, based on that activity's outcome. Yes, the rough estimates of the time and resources are never precise and could not be kept, but anyway the deviations are within the norms.
The fact that there is a plan for that development project also helps the company to plan its overall operation and even strategy, serve as a common agreement between the company management and the projects' leadership and save the latter time and nerves to be spent in the actual development.

Allan Kelly replied on Thu, 2013/10/10 - 6:26am

Rusi,

I don't argue with much of what you say.  What I will say though is: planning is not projects and projects are not planning.

Planning is just one technique used in by a project manager, planning and some other techniques can just as well be lifted and used in a BAU environment.

You can plan the work almost exactly as you describe in a non-project situation.  You just have one of your phases after another.  The difference is you don't expect one day there to be a final phase so you keep one eye on the longer term.

My original post deliberately said very little about planning.  Planning is a whole other discussion!

allan

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.