{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.


That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.


Sorry about this, there is a problem with our search at the moment.
Please try again later.

Projects don't come about through some law of nature. They're a mental construct we've created to help ourselves manage our work.

I spend most of my time on projects.I’ve worked on projects to build e-commerce systems, projects to build and update websites, projects to create new products, even projects to define the way we do projects within an organisation.

The idea of a project as the fundamental unit of work is pretty pervasive within our industry. Many organisations structure themselves almost entirely around the portfolio of projects that they are undertaking. 

And a large industry, think of PRINCE2 and the PMI and various other project management bodies, has emerged solely to service the interests of projects and project managers.

But how real are these projects?

Somewhere along the line we’ve reasoned that dividing the stuff we have to do into discrete, tightly-bounded chunks called projects will make it easier for us to coordinate related activities, communicate with people affected by our actions, and so on.

In other words, a project is a model. It’s a mental abstraction we use to help ourselves make sense of the world. And, as the saying goes, “All models are wrong, but some are useful”.  

So the concept of a project is a simplification,life sometimes doesn’t split cleanly into projects.  Thus I often see problems such as the following:

Projects create artificial boundaries between activities. 

For example, they create a split between building and operating websites and other systems. 

One day we’re building out elements of the site as part of a project; the next day we’re making similar changes as part of day-to-day operations.  And the mechanisms we use to prioritise work, allocate resources, etc, all change completely overnight. 

This creates conflict, confusion and overheads: arguments about what constitutes a “bug” versus an “enhancement”; change management boards to classify work between the two; dispute resolution mechanisms, and so on.

Some activities don’t fit neatly into projects. 

People have to do a lot of stuff that doesn’t have anything to do with a specific project, product and customer administration, system maintenance, staff training, etc. 

Because this work isn't part of a project, we don't allocate time for it, don't set up mechanisms to resolve conflicting priorities, and otherwise fail to manage it. 

This then flows over into our projects. How often have you seen a project fail to make the expected progress because people’s time is being frittered away on other activities? 

Or conversely, how often has necessary work been overlooked because people were too busy on their project tasks?

We set up projects that are ragbags of loosely related activities. 

To avoid the above problem, we try to put everything into a project, so we end up with projects that aggregate an incoherent suite of activities into one bundle purely for the convenience of our mental model. 

And again this creates overheads, people spend time listening to status reports on activities that have absolutely no bearing on their own work, for example.

These are all signs that our model is breaking down.

It’s interesting to look at some of the trends going on in software development in this light. For example, agile development teams are going into progressively tighter iterations.

30 day sprints were the norm when Scrum first came into vogue, but seven days is much more common now. And kanban teams are moving completely away from the idea of defined projects and iterations in order to try to deliver a continuous flow of new features into production. 

This aligns with the pressure on most organisations to deliver change more rapidly, and at the same time creates big questions for the idea of a project as the defining model for organising our work. 

I think this “flow” model is going to get a lot more mileage in the coming year.

That doesn’t mean that the idea of a project is irrelevant. Some work does fall neatly into projects. And the idea of a project has served many organisations well.

I can certainly think of several organisations where lack of a well-defined project portfolio and project management structures has created an unholy mess. Interdependent activities are run independently, with consequent problems at the interfaces. 

People with common goals act at cross-purposes with each other. And no-one has any clear idea of what is going on  overall, nor of how people’s time and attention are being prioritised.

But projects are no longer the only game in town. Be prepared to adjust the model to fit the realities of your situation, rather than vice versa.

Graham Oakes

Published 17 January, 2012 by Graham Oakes

Graham Oakes helps people untangle complex technology, processes, relationships and governance. He is contributor to Econsultancy.

43 more posts from this author

Comments (4)


Chris Russell, Digital Marketing & Web Analyst at Chris Russell Digital Ltd

Great article. It seems to me that digital has created business cultures where change is fundamental, somewhat obliterating the meaning/concept of a "project".

Many digital businesses are in fact projects in themselves - it's only companies still wrestling with digital who need to follow processes that have more in common with civil engineering than software/web/app development.

almost 5 years ago



Great article, and as a Projects Director at a digital agency I agree. The problem you've not addressed is that a lot of the time the "project" model is forced by the client, who want a fixed cost at the outset. You can only supply a fixed cost for a fixed project scope.

Agile projects require an agile budget, and not all clients (especially those that are government funded for example) are prepared to agree to this.

almost 5 years ago

Ashley Friedlein

Ashley Friedlein, Founder, Econsultancy & President, Centaur Marketing at Econsultancy, Centaur MarketingStaff

As Alexander points out, whilst your article is entirely correct, the challenge is around managing expectations, setting scope and deliverables etc. Finance or procurement people, in particular, don't really like the idea of buying something which cannot be defined! If it isn't delivered how will they know? What recourse will they have if there is no 'spec'? That is why projects, specs, deliverables, are typically required.

almost 5 years ago

Matthew O'Riordan

Matthew O'Riordan, CTO at Econsultancy

We are seeing that there is in fact a way for companies, and especially agencies, to take on projects but still follow the ideas of flow and small iterations. A project needs to be thought of as the delivery of a system/application that satisfies your customers needs and aligns with your business goals. It's not a predefined deliverable detailed to the nth degree, it's a high level grouping of plans that describe the expected outcomes for the business.

Typically with projects that agencies or companies undertake, the planning is front loaded so that all planning is completed before production begins. Believing that a few PMs or planners can determine how everything should work and what each person will be doing for the entire duration of a project is simply impractical (if not delusional), but worse, leads to an inferior product being delivered because that process does not allow for the team to contribute ideas, reflect on how things are going, and refine the original concept. During a project the business requirements may change, the market positioning may need refining, and it will be very likely that your understanding of the project will increase throughout the project lifecycle thus enabling you to make better decisions at each iteration to ensure the project you deliver is the best it can be with the resources you have, rather than on spec.

Agencies, whilst trying to outwardly present themselves as adopters of agile, typically find themselves in a hard place. They need to provide a quotation to a client that describes scope, budget and timings. If you speak to most agile evangelists, they'll tell you that you simply cannot commit to all three, and that is correct, however it does not mean the client won't get what they want, or the budget will run over in terms of time or budget.

And that is what we have been seeing at easyBacklog (http://easybacklog.com) with our customers as a fundamental shift in the way agencies and even internal teams deal with this problem. By outlining the project goals at the outset, and building up a quotation/estimate from your backlog of project tasks (stories), and importantly involving the delivery team in all estimations of effort required, you can very quickly get to a point where you can estimate project costs, you can commit to a project scope, and you can predict the delivery date. Whether you and your client/boss choose to stick to all of those points is irrelevant, what is important is that you can make that commitment up front, and get buy in from your customer or boss to get the resources you need to deliver the project (which is of course a business goal, not a set of detailed deliverables). Using a product such as easyBacklog (admittedly even a spreadsheet would do so long as you want to waste time with change control management), at the start of each iteration (ideally no more than 10 working days) the scope, budget and timings are defined, however the team, the client, and the project managers can all contribute ideas to add to the backlog of tasks, remove or rewrite tasks based on the knowledge they have since acquired, and refine the project at each stage. Your team, who are experts in their domain, become involved in the creation of the project, however it's ultimately still the decision of the client/boss whether any of those changes should be implemented. If you have a tool such as easyBacklog which keeps track of changes throughout the project and allows you to predict the impact on budget or timings, and log what functionality may fall out as a result, you get the best of both worlds. You can still commit to a budget, you can still commit to a time, but the client has the flexibility and safeguards to freely and knowledgeably change their mind about what they want and see the effect of this.


almost 5 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.