Is (or should) a project always be performed with the intention of achieving business change?

(And if so, does this mean that anything that isn't producing this change must be Business-As-Usual and not part of a project?)

  • 1
    Hi and welcome to PMSE, the site for expert and enthusiast project managers. Are you facing a specific problem that has led you to asking this question? If so, please include all the relevant details that can help get the answer that best fits your problem, as every situation is different.
    – jmort253
    Commented Mar 4, 2012 at 3:46
  • "Change - that activity we engage in to give the allusion of progress." - Dilbert
    – JonnyBoats
    Commented Mar 4, 2012 at 4:16
  • what is "BAU"? Since I don't know, there are probably others that don't know. Your question will be clearer if you avoid uncommon initialisms like this. Commented Mar 4, 2012 at 13:18
  • BAU == Business as Usual, probably (in this context), but yes - reminders to spell things out are good!
    – jcmeloni
    Commented Mar 4, 2012 at 13:32
  • @jonathonconway Please clarify whether BAU is "business as usual" as jcmeloni is suggesting. I think it is ok to use acronyms in a question or answer if you give the full name at least once or if it is blatantly obvious such as for example 'URL'.
    – Manfred
    Commented Mar 4, 2012 at 22:31

9 Answers 9


Not always to achieve business change. Some projects are a case of running to keep still e.g. refreshing out of date software to latest versions. Or introducing extra data-centres for disaster recovery purposes (no immediate business change, but brings benefit in the form of insurance)

This is similar to trying to run up the down escalator. There's a certain amount of running you have to do just to stay in the same place. If you want to get to the top of the escalator (increase market share / deliver more shareholder value), you then need to perform business change projects (e.g. launch new products, create new markets, new initiatives, cut costs etc.) to deliver these benefits.

  • 1
    This is exactly what we did with all the Y2K projects that changed 2 digit dates to 4 digit dates.
    – JonnyBoats
    Commented Mar 4, 2012 at 22:00
  • Y2k is a very good example of a project that may not have delivered business change, but did deliver business benefit, by reducing the risk of business failure at or following the millennium, and giving the organisation the confidence required to continue to do business at that time. +1 to JonnyBoats' comment.
    – Iain9688
    Commented Mar 4, 2012 at 22:33
  • Both of these examples are changes. New SW would likely mean new functionality, decrease bugs or failures, efficiencies, and maybe even a better performance distribution and metrics. New data centers mean a different disaster recovery strategy, different risk plan, different contingencies, all resulting in some sort of business change. Commented Mar 4, 2012 at 22:55
  • Maybe we're using the word business differently. To the business users / departments nothing has changed, they don't have to change their processes or sell different things. These changes are generally invisible to the business.
    – Kris C
    Commented Mar 4, 2012 at 23:10
  • 1
    The secret behind y2k? Trust me, I was there. Remember all the complaints about the trillions to fix it? Forget that, we managed to dump most of the previous 20 years of hard coded-out of date programs and infrastructure and really get the internet going. We're already planning for 2037 when the Internet Mark VXIIXXIXI comes out and that unix time thing runs out then. Unless its Dec 21 this year of course ;) ;) ;) Commented Mar 9, 2012 at 4:12

My view is that a project should always be performed with the intention of achieving business benefit. Change without benefit could be good or bad. One of the keys to having a successful project is to know what the desired outcome is, and to ensure that the project outcomes are 100% aligned to the organisation's goals and objectives. It is also a good idea to include benefit realisation within the scope of your project if you can: don't just deliver the tools and hope that the benefits will follow, but consciously and deliberately drive the benefits out of the project and into the business.

The corollary of this is that when the project stops delivering benefit, the project should stop. Knowing when to say "enough!" is one of the hardest, and yet most valuable, skills of a successful project executive (PM, sponsor, or whatever). And the other thing is that the project should also stop even if it will deliver benefits, where these benefits are outweighed by the costs. You should also challenge "nice to have" features within a project, if they don't contribute directly or indirectly to benefit realisation.

One final comment for the moment on benefits: they do not need to deliver only direct financial returns. There are techniques for evaluating non-financial benefits and relating those to the costs, so you should look at the total benefits case, and not just the purely financial benefits case, when deciding to start, continue, or shut down a project.

As to what constitutes BAU: different organisations view this differently. For me, BAU can also deliver change (and again, this should be beneficial change). Developing a new report from a system may be BAU, but if it delivers information that allows the organisation to make better decisions, that is a change but it probably is not a project. Introducing a minor business process improvement may also be BAU, but may also fall short of being counted as a project. However, to directly answer your question, if something is not producing business change, it could be Business As Usual (an active statement of intent), or it could be just inertia (passive, and not being challenged).


I guess the counter question would be: why would you spend valuable and limited resources on a project if you were not looking for a change?

Let's just take RSM maintenance on a real property as an example. A real property would require restoration, sustainment, and modernization maintenance over its life. Each type would be a project. With restoration, there was some type of damange that occurred and the project would return the real property back to its original state--a change. With modernization, this type of project would cause the real property to achieve a new state, e.g., an updated, more modern kitchen--a change. With sustainment, this type of maintenance project will cause the real property to maintain its original state. With this type, it seems like there was no change. But there really was. You are taking a component of the real property and changing what has deteriorated over time. So there is still a change, still a benefit and return, even though the real property maintained its original baseline.

  • My counter-question would be: if it's not achieving fundamental change in the business, then isn't it actually Business-As-Usual, rather than a project? Commented Mar 5, 2012 at 0:34
  • I guess that statement is true. Commented Mar 5, 2012 at 11:53

Well, business projects are done with the goal of business change. There are a number of areas there projects are done with a goal of improving the lives of others. Non-profits or international aid/development for instance.

But outside of that, if you consider that anything outside of general operations or routine assembly line type work could be considered "business change" or trying to improve the current state, then you could say that all projects are done with the goal of some type of business change.

And without that outcome or goal, it probably can't be considered a project.


A project may or may not introduce a business change.

A project must always have a valid business case throughout the project life-cycle and must deliver real benefits.


Change in a business environment can be a friend or an enemy. There is always some - change resistance - always. Having a good and new idea is not sufficient to guarantee the success of your innovation. There is the selling part. You have to prove your point, to put it across. Sometimes it is easy, sometime it is difficult. Sometimes your idea is stolen. Sometimes you are the trend of the month. Everything depends on the open mindedness of your managers and if they fear competence and innovation or welcome it. This is part of the global business culture of your work place. A non innovating business culture is very difficult to change, because innovators are perceived as trouble makers. In a very innovative environment, change is the daily bread of everybody (I have no company in mind for both examples). If I were a newcomer in a company, I would be careful. Some say you have to be accepted by the group first, but there again some companies will not understand why you are waiting to give your new ideas. Change disturbs habits mostly the old habits that became traditions. But, if no one dare to change anything in our current business reality in Québec, Canada and America, we will continue to go down the drain...


In my experience if there is no business value you don't start a project (or any other work). Whether or not that results in a business change is a different question. However, I think it is sensible to assume that a project without business change won't result in any business value. If a project does not change anything, why would you want to spend time and effort?

Some teams work using projects some don't because all work items are so small that the overhead of a 'project' is too much. Some teams use projects for running certain initiatives more formally. Different companies have different ways for using projects.

In general I would say that a project should not be started if it doesn't provide sufficient business value. I would also state that a desired business change may trigger a project rather than the other way round saying 'let's start a project' for the sake of it and sometimes this may result in a business change. Maybe the distinction between business value and business change helps to clarify this.


No. A project is a way of organizing resources to get something done. The format of using "projects" as a form of doing work, does not specify a particular purpose (e.g. it doesn't have to create fundamental change).


Projects typically:

  • Make Money
  • Save Money
  • Protect Money

If a project isn't satisfying one of these, it usually shouldn't exist.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.