1. Home
  2. Training Library
  3. Project and Project Context | DAL4 V2 A3.1 |

Project and Project Context | DAL4 V2 A3.1 |



Project vs BAU

One of the main reasons you encounter user experience is when there is a need for a change and a project brief is put together to see if a project is viable or not.

Typically projects are started to improve, to add or to create new products. In project management terms products are deliverables, tangible, or intangible outcomes that you achieve after the project has been delivered.

Before a project is undertaken research must be done, to see if the proposed work benefits the organisation sufficiently for the effort and money that goes into it.

Therefore, you need to understand what a project is, how your role as a data analyst can differ depending what project methodology is being used in your organisation, and how requirements gathering happens for each method. All that is project context.

So, let’s start with the beginning.

What is a project? What is the difference between a project and business as usual?

Are the following activities classed as projects? Answer Yes, No or Maybe to the following before scrolling down to get the answers.

  1. Decorating your house
  2. Building a car
  3. Building a new extension to a highway
  4. Maintaining a highway
  5. An on-going project to improve quality
  6. Five-year building development
  7. Decorating a house as a carpenter
  8. Manufacturing 200 bicycles a day
  9. Open heart surgery
  10. Implementing new software


  1. Yes
  2. Maybe
  3. Yes
  4. Maybe
  5. No
  6. Yes
  7. Yes
  8. No
  9. No
  10. Yes

According to APM Bok 6th Edition, the main characteristics of a project are :

  • Planned set of deliverables (products) : At the end of each project there is a deliverable. There is something to be made something to show for or something to be achieved at the end of the project.
  • Transient, finite with temporary resources: in other words: short term, for a limited time resources are needed. The resources are allocated based on the job to be done, they are not fixed like overheads, tools, time, budget. They get charged to a project for exactly the amount is needed to do the job.
  • Various sizes, overheads, significant endeavour involving risk: A project can be large or small in nature, that on its own can come with its own risks budgets and skills needed to achieve it. Building an extension to a house could be a project and contains more risk of exceeding time/ budget than adding functionality on a website.
  • Objective to achieve benefits, some achieved during, but most long-term: The project’s objectives need to benefit the organisation, and that benefit needs to be of long-term nature.
  • Vehicles of change in an organisation, not repetitive in nature: projects typically are intended to implement change in an organisation and therefore not repetitive in nature.

Business as usual (BAU), is what the phrase implies: anything that is just your regular work, day to day, with fixed overheads. There is no end date to complete it, regardless of deadlines within work schedules.

The Balance of Competing Project Criteria


There needs to be a balance between all the criteria of a project. Time, Risk, Quality, Cost and Benefit are all interconnected.

Time: as Warren Buffet once said: “No matter how great the talent or efforts, some things just take time. You can't produce a baby in one month by getting nine women pregnant.”  The same applies to projects. Some projects have dependencies (things that need to be done before something else can be completed), sometimes it is too costly to hire an extra workforce to speed up a process, and we need to use the talent and skills we have available.

Risk: there is a positive and negative risk, finishing something way too early can have a risk as well as finishing too late. Identifying the probability of a risk and its impact and managing it with a contingency plan is of utmost importance to any project.

Quality: this criterion has a great impact. There is a saying that goes that you can’t have something cheap, fast, and good. As the diagram suggests, the acceptance criteria must be established at the beginning of the project. What is acceptable, fit for purpose and at the price and time that have been allocated. What is in the scope (what is included in the work) and what is not?


Cost: all costs that are directly or indirectly linked to a project must be calculated. Costs of material, labour, time, software, overheads, etc. as it is the only way to know what the project’s real cost is.

Benefit: ultimately every project must produce a positive outcome and benefits to the organisation. A project with no benefits has no use. Sometimes it is not clear what benefits a project can achieve. Also, some benefits are long term, so they cannot be measured immediately after the project has been delivered.

Each criterion influences the other. If a project takes more time than it should, that might increase the risk, it may allow for better quality yet also impacts the budget. Ultimately, if the benefit outweighs that investment, it might be the right way to go.

Ideally, every project achieves a balance, i.e., all project criteria come together in harmony.  Understanding this balance will give you as a data analyst a better context, enabling you to make better-informed suggestions to the project owners.

Using your analysis skills, you can balance costs, risks, timescales, quality, and benefits to meet the requirements of the organisation. Ultimately, the decision will be with the project owners, but that decision will be based on the data analysis you have completed.


Project vs BAU

About the Author
Training Provider
Learning Paths

QA: A world-leading tech and digital skills organisation

We help many of the world’s leading companies to build their tech and digital capabilities via our range of world class training courses, reskilling bootcamps, work-based learning programmes and Apprenticeships. We also create bespoke solutions, blending elements to meet specific client needs.