5 Differences Between Projects and Business as Usual

5 Differences Between Projects and Business as Usual 5 Differences Between Projects and Business as Usual Are you working on a project? Or is what you are doing part of the daily operations of your business? When I speak to people in teams, they often tell me they aren’t sure whether theyre working on a project or a business as usual function. Both are required in an organization and are equally valid, but it helps to understand what youre working on so you can better see where it fits in the organization. There are five main differences between project work and business as usual (often abbreviated as BAU) work. Changing vs. Identifying Business First, there’s a difference in how change is handled. Business as usual operations run the business. They keep the lights on, serve customers and hit targets. BAU teams are also the first to know when the existing processes aren’t working and are no longer useful. When that happens, the BAU teams identify the need for change. A manager, as part of a strategic review, can suggest what changes need to be made for a unit to reach its goals. Or a team member may make a suggestion for change. At the other end of the spectrum, you may have a full business case produced by a senior manager to deliver changes required to help their division reach its annual targets. It’s not just streamlining business processes. Those working in BAU roles may also realize change is essential because of shifts in the regulatory framework or as part of the competitive landscape for the organization. Frontline staff works to deliver strategy and it knows what it wants to be different to get there. Projects, on the other hand, help implement all of this change. Projects deliver change to and through the BAU functions using project management. Well clarify what project management is further. The project organization works on delivering the change BAU teams have identified. This happens once the project has gone through an approval process, which is normally ?a business case and senior management approval. That isn’t to say people in a project role can’t ever suggest improvements to business practice, but they’ll be doing so under their role as an employee rather than as part of their project role. This split, which you’ll also hear summarized as change the business, run the business, is noticeable at the end of projects, too. The change a project implements is to deliver an output. That could be a piece of new software, a building, a new service or something else. The BAU team is responsible for taking that and making good use of it to deliver benefits. In other words, the project delivers the capability to get benefits, and the BAU operations use that capability to get the benefits. Managing vs. Mitigating Risk For business as usual functions to be effective, you’ll find BAU teams seek to mitigate all risk to operations. Taking the  uncertainty out of business for better organizational stability and repeatable processes is a good thing. By their very nature of being unique and uncertain, projects require an element of risk. The company is making a bit of a leap into the unknown just by doing a project as it introduces change and delivers something that wasn’t there before. Project teams, therefore, approach risk in a different way than BAU teams. Project managers seek to manage risk - both positive and negative - to get the best outcomes. That might include mitigating risk to try to limit the likelihood that it is going to happen, but it includes other risk management strategies as well. It’s unlikely you’ll ever extinguish risk on a project, but you may be able to do that for good operational reasons for your BAU work. One is Time-Bound, the Other is Ongoing Projects have a start, middle and end date, and are a one-off event. This is the project life cycle. In fact, the most defining characteristic of a project is that it finishes. The project manager and the team work on the project during this time. At the end, the team is disbanded. BAU doesn’t stop and is ongoing. You can, of course, close down a function or stop a process if its no longer required for the business - although that would be managed as a project! A BAU function produces ongoing work with no foreseeable end date. To Capitalize or Not to Capitalize Projects can be capitalized and often BAU cannot be â€" you rely on operating expenses for your ongoing business as usual work. In other words, the accounting treatments for projects and other tasks are different. Project funding often relates to bringing an asset into service - meaning the costs can be capitalized.  In some cases, depending on where you are in the world and your local accounting regulations, you can even take project costs below the line. BAU costs are normally considered opex  (operating expenditures) and are tracked in the profit and loss accounts of the company. Project funding and business funding, in general, is a very specialized area so it’s always best to take advice from your finance experts before making judgments about what should and shouldn’t be capitalized in your organization. Accounting rules vary by country, and even by organization where individual businesses have particular processes and ways of doing things. When in doubt, always check! Cross-Functional vs. Functional Teams Finally, there’s a big difference in the makeup of project teams. Projects tend to involve multi-disciplinary teams of experts brought together to deliver a particular output. Knowing how to motivate a project team is important because not everyone may know the specific goal at the very beginning. If people don’t have a clear understanding of what theyre working on, then they tend not to do their best work. Project teams are made of people filling particular roles. These aren’t job titles but positions within the project with distinct responsibilities. The main roles on a project team are: Project sponsorProject managerSenior supplier (the organization responsible for doing the work, which could be an internal team like IT or an external contractor or vendor)Customer (this could be an internal customer such as a different department manager, or, in a client services organization, the customer for whom you are delivering the project)Subject matter experts (people brought onto the team either for the duration of the project or part of it who use their expertise to contribute to the project’s success). Find out more about the roles in a project team. BAU work, on the other hand, is managed by functional teams. They are experts in their own right but grouped together as a division. There is normally less cross-functional overlap to other departments than project teams. It’s normally very clear what BAU teams are supposed to work on and the objectives are clear. They will have defined targets and a vision for the role the department plays in the company. An example would be a customer service team that works as part of a larger customer service division handling calls and emails from customers about your product. It is complicated because there can be overlap. For example, a team leader in that call center is a specialist in the field. They may be seconded to a project team to manage a work package and the resources related to delivering part of a project that relates to customer contact. But in their project work, they are taking the role of subject matter expert, not customer services team leader. As a project team member, they will be responsible for their part of the project budget and have a high degree of discretion around how the work is carried out to meet the end goals. They might not have this in their BAU role. BAU and Project Conflicts Project work and BAU work can sit nicely alongside each other, but there can often be tension. It happens because projects try to change the status quo. The status quo works pretty well, and, for the most part, people don’t like change. Second, when you are asking people to join your project team, they can suffer from a conflict of loyalties. Is their first responsibility to their day job or to the project? Clear objectives and a strong commitment to the project from management can help here, as well as keeping lines of communication open so they know what the priorities should be. Third, keeping the business running is always the priority. It has an implication for project teams who might see their funding cut, key resources pulled back to BAU roles and timescales delayed because keeping the day-to-day operations of the organization going is pulling focus. Project managers can get frustrated with this but it’s always going to be like that, and it should be. There’s no point in delivering a fantastic project if the company has gone bust in the meantime and there is no one left to use what you have built! With these guidelines in mind, it should be easy to see if you are working on projects or BAU or both.