Bridging the Business-Project Divide

Techniques for Reconciling Business-as-Usual and Project Cultures

John Brinkworth

• Publisher: Routledge
• Year: 2016
• Topic: Business
• eBook ISBN:
  9781317172536
• Subtopic: Business General
• Index: Business

In organizations these days, there are two cultures, two sets of expectations, two languages; that of the business-as-usual organization and separately that of projects. These cultures need to work together effectively. Unfortunately, the natural side-effect of two such different perspectives is misunderstanding, mutual incomprehension, and despite good intentions on both sides, failure to deliver desired benefits. In Bridging the Business-Project Divide John Brinkworth tackles these issues by examining: ·

---

Chapter 1
Introduction

---

The Divide

Business and projects tend not to mix. They do not even understand each other. This often leads to problems. But what causes to this to happen?

There are two mindsets in operation these days in most organisations. They relate to the two worlds of:

• ‘business as usual’, which this book will refer to as ‘business’; and

• project management, which involves the delivery of a change using a project approach.

The Business Viewpoint

‘Business’ for the purposes of this book covers any sort of organisation or enterprise. It can be private sector, public sector or charity. What is significant here is that the organisation is focused on delivering something on an ongoing basis. It might make a product, maybe a range of products – which could be tangible or electronic; alternatively, it might provide a service. What matters is that it plans to continue to provide the product or service for the foreseeable future.

Over time, the product might change – a car manufacturer will bring out new models, a bank may offer a new type of bank account – but their business of making cars or looking after people’s money will continue indefinitely.

This expectation of a continued existence, with business stretching out over the horizon, leads to a particular way of seeing and running the organisation. Organisational structures are established and people have roles that create, support and manage the products or services. A career path develops, with the opportunity to gain skills and expertise in a particular area and over time be promoted within the organisation to take on more responsibilities. These structures, even if the post-holders change, develop a degree of permanence. There is an expectation that there will always be a CEO, a Finance Director, and a Head of Sales.

A timetable for the business evolves. The calendar tends to drive this with annual budgets, quarterly sales targets and weekly management meetings. The calendar sets up a heartbeat for the management control of the organisation. Overlaying this is a second tempo that relates to the product or service. It is driven by how long it takes to create a unit of product or service. A restaurant that serves lunches starts with raw ingredients at 9 am and finishes with empty plates by 2 pm. A car manufacturer may take two to three days to make an individual car, but due to the production line nature of the assembly work, many cars will be made each day. A call centre can handle hundreds of enquiries, each lasting just two or three minutes, every day.

These organisation structures and timetables set the framework for how the business runs. They give a set of reference points and familiarity to what happens each day, each month and across a year. There may be variation in the nature of the work, for example, finance departments preparing budgets at one point during the year and putting together annual reports for shareholders at a different time. Manufacturing runs may vary, with a clothing company producing different ranges of garments for the summer season and for the winter season. Airlines may have busy Mondays and Fridays when they fly a lot of business passengers and a different mix of travellers during weekends and school holidays. In all cases, however, the basic pattern of providing a product or service on an ongoing basis sits at the heart of the business viewpoint of an organisation.

The Project Viewpoint

Projects are different. They have a start and a finish. The people undertaking the project may not have worked together before the start of the project. The project will have a particular objective. It exists to change something.

That change can have a range of manifestations. It might be a building or a road or a railway that is constructed. It could be a new computer system that is being delivered. There might be a change to an organisation – a merger or a separation. There could be a new department that is created. The project is undertaken by a team, brought together for the purpose, and its outputs and changes are delivered to a client and in some cases a set of users.

For convenience in this book, we will describe a project as delivering a solution. This does have connotations related to the world of information technology (IT), but here we will use it in its most general sense – the addressing of a set of requirements by providing a solution to a need for a change.

The key point about a project is that the project is not part of the business-as-usual operation for the organisation.

The project team are subject to different pressures from the business team. The members of the team need to be assembled, they need to have clarity on what is required to be achieved, and they need to get hold of the means to effect the desired changes and make their deliverables. The project has a cost – each day it exists, it absorbs money that the organisation would otherwise have used elsewhere. This puts a time pressure on to the project. Some projects have ‘immovable deadlines’ – classic examples include creating a new sports facility in time for a particular tournament or fixing a problem such as the ‘millennium bug’, which needed to be resolved before 1 January 2000. Other projects have deadlines which could slip, but would involve additional costs and considerable loss of face for their sponsors.

Projects tend to be staffed by people who live in a ‘project universe’. They work on a series of projects, moving from one to the next. Sometimes they work for a provider of project services (e.g. a consultancy, a software house, or a road building company), while at other times they may be freelance and hired separately for each project. They are familiar with the project rhythm of start-up, design, build, test and deploy, which can take a few weeks or may spread over a number of years.

This lifecycle does not align to the periodic heartbeat of the business-as-usual organisation.

The Interaction between the Two Worlds

This split has a number of effects. The business part of the organisation often houses the recipients of the project. This can happen in a number of different ways. They may be the users of a new computer system or they may be the subject of a restructuring, with some staff being made redundant. In addition, some of them can become involved in the project. The degree of involvement will vary, they might be consulted about the requirements for the change, they might be part of the team testing the new system or they might be recruited as ‘change champions’ to help get their colleagues to work in a different way.

These interactions sit at the overlapping boundary of the two worlds. Both viewpoints can have difficulty appreciating where the other team is coming from. What is obvious and normal to a member of the business team (e.g. you cannot make a change during the busiest month of the trading year) would not necessarily occur to a project person. What is clear to a project person (e.g. that changing the requirements after agreeing them will delay the project by a number of months) may seem unreasonable to a member of the business team.

These differences of perspective can then be magnified by the time pressure that faces all projects. Delays, challenges and differences of opinion, whilst resolvable in the cold light of day, can be blown out of proportion during the heated process of keeping a complex project on track whilst not disrupting the business into which it is going to deliver.

The Aim of this Book

So what can be done? That is what this book seeks to address. How can the friction at the interface between the business world and the project world be reduced?

Projects follow a fairly standard lifecycle and have a number of considerations that they keep in mind for their duration (such as quality, finances and risk). This book considers each project stage and each project strand from both a business-as-usual perspective and from a project perspective. It then looks at how the differing perspectives can be brought closer together.

Readers from each world should recognise themselves and their viewpoint, and in addition gain a few ‘ah-ha’ moments as they get an insight into how the other half thinks.

It is hoped that this will bridge the divide, enabling project teams and business teams to understand each other better and, as a result, to achieve more successful projects together.

PART I
The Project Lifecycle

---

Chapter 2
Identifying a Project

---

The Business Perspective

When do businesses want to undertake a project? It may seem that projects are happening all around, but what is the underlying reason for a project to be performed?

Something needs to be changed.

Nothing stays the same for long in the world; external events, problems, challenges and uncertainties can all lead to the need to undertake a project. It is worth noting that more often than not, it is the business part of an organisation that initiates a project.

Organisational changes can often prompt many types of project – mergers, separations, new business units or a restructuring of an existing business.

Activity changes can also lead to a project. This can be a new activity. It could also be an existing activity where some characteristic of it needs to be changed, a new method for doing it, the volume of the activity – scaling up to more production, cutting back for less. The activity itself might remain the same in terms of what is provided to the end-client, but the systems that support it might need to be changed.

Sometimes a suite of projects may be undertaken as part of implementing an organisation’s strategy. The identification will have already been done as part of putting together the strategy. This may include creating a schedule of projects grouped into a portfolio.

There are other situations when sometimes it is an existing project team, or maybe an external supplier, that approaches an organisation and persuades it to undertake a project. But even in this case, the project identification will be undertaken by the business. In short, unless the business agrees that the project is needed, it will not happen.

The Project Perspective

The project perspective on identifying a project is associated more with a number of factors that the early members of the project team need to know as soon as possible.

Who will be the sponsor?

From the point of view of the project team, who is their client? This may well be different from the recipients and users of what the project delivers.

What is the scope of the project? What will it do and what will it change? Where is the boundary line, what will it not change or deliver? Are there any other related projects that will also be making changes at the same time? Does the project rely on any of these other projects for inputs?

What are the actual deliverables? This is the core essence of the project from the project team’s perspective.

What are the timescales – when does the project need to be finished? Are all the deliverables provided at the same time?

What methods will the project follow? These can include widely available good practice management methods (such as PRINCE2^® (TSO for AXELOS 2009),¹ Managing Successful Programmes – MSP^® (TSO for AXELOS 2011)),² but also organisation-specific ways of working. Does the business impose these methods explicitly on the project? Is there an implicit assumption from the business that the project will work in a particular way?

Determining whether an organisation is effectively operating in a way that matches its strategic goals is an important early step for a project. Strategic goals can relate to how the current day-to-day business functions, what it does and provides. Separately they can also cover how the business wants to grow or change, what it wants to be or do differently and when it wants this change to happen. The members of the project team need to gain clarity on this as soon as possible so that they are able to shape the project accordingly.

Bridging the Divide

Identifying a project may appear obvious to many. However, to avoid a gap opening up between the business and project teams right from the start, a number of aspects are worth addressing.

Clarify the scope as much as possible – what is within scope and expected to be delivered, what is on the edge and may or may not form part of the final deliverables, and what is definitely out-of-scope and not being provided by the project? This final out-of-scope category can be the trickiest, as different stakeholders, across the business and also at the business-project boundary, will tend to have different tacit assumptions about what is out-of-scope. Surfacing these, in workshops or in definitive lists of ‘out-of-scope’ items as early as possible, will give the project clarity and the business greater certainty on what it can expect from the project. It may transpire that once the business realises that something that it thought was in scope turns out to be out of scope, then rather than enlarge the project, a separate project should be established to undertake this other work, taking care not to introduce any gaps or overlaps in scope. This clarification of scope can be a very valuable discovery. The more that everyone is ‘on the same page’ as early as possible, the better it will be for all concerned.

Clarify uncertainty – it is not unreasonable for some things to be uncertain, but what is important is that everyone – in both the business and the project – is clear on what is currently not fully known. Identifying the methods and timescales for reaching clarity would be helpful. Identifying who will undertake the clarifying activities is useful. Another key point is identifying the consequences of continuing not to know particular pieces of information. These consequences could vary over time, i.e. they may not be too much of a problem for a while, but when the project reaches a particular point in its lifecycle, the risks and therefore costs of not knowing could escalate dramatically.

It is worth defining the team boundaries, all the players and roles – even if these are not yet filled. Include the business side of the wider team.

Figure 2.1 Identify the teams involved

Maximum clarity of what does or does not change as a result of the project is central to making sure that everyone involved knows what the project is going to achieve.

Figure 2.2 How the project changes the business

Perceptions of timing can be different; it can feel to the project team as if sometimes the business organisation seems to be suffering from a flip-flop mentality. This tends to involve a rather unpredictable switch between two opposite states: drift and panic. Neither state is conducive to an effective project, but the middle ground is sometimes hard to reach. The two parties need to find a way to discuss relative priorities. It is quite common for a day-today business to find that what was a ‘change priority’ becomes overwhelmed by emergent urgent actions, or that a gradual increase in the volume of day-to-day activity causes the ‘change priority’ to drift off into the in-tray labelled ‘pending’ and after a while to be forgotten about and in effect end up on hold, without this ever being the deliberately intended outcome.

Another aspect of timing is the concept of immovable deadlines. This book will mention this in a number of chapters, as it is the absolute bugbear for a project manager. A classic example of this is when projects are sometimes driven by acquisition or disposal timeframes which do not suit them. If the business does not understand what is entailed in a project, it can inadvertently set deadlines for a particular activity without reference to how long the project will take. The project is then presented by the business with a ‘fait accompli’ that forces a near-impossible timeline on to the project team. In the real world, the number of projects that actually have truly immovable deadlines is very small. Legislation can create some – if a legal obligation exists for a particular service to start on a given day, then that is in effect fixed, while major events (sporting, cultural) that run to calendar cycles are also fixed. However, most other projects can have their deadlines moved. The reasons for a timeframe choice by the business may be political (something has to be delivered before a political sponsor is next up for election) or it may be financia (the business wants something on or off its ‘books’ by the start of the next financial year). Alternatively, it may be reputational (the business sponsor puts their name to a date – maybe plucked out of the air – and now it is in the public domain, so face must not be lost and therefore the date must be kept to even though it is completely arbitrary). From a project perspective, the earlier that project team members are involved with the business, the more they can explain convincingly to the business what is involved and why a project needs a certain timeline, the greater the chance that they will not find themselves painted into a corner and faced with an impossible timeframe. In practice, when this happens, project teams tend to acquiesce to the deadlines they are given, knuckle-down and just work as hard as they can to deliver. This can have awful consequences for the work-life balance of the project team and the levels of stress within the team. The error and problem rates in the deliverables tend to go up as a result. A dysfunctional working environment, riven with conflict, can arise. There is a real incentive to avoid this and both business and project teams need to get together early to establish how a mature and sensibly timetabled project can be established that can still meet the aspirations of the business.

Sorting out who is in charge and who has the final say when a dispute arises can be inva...

Table of contents

• Cover
• Title Page
• Copyright Page
• Table of Contents
• List of Figures and Tables
• About the Author
• Preface
• Acknowledgements
• List of Abbreviations
• 1 Introduction
• PART I THE PROJECT LIFECYCLE
• PART II COMMON STRANDS
• Bibliography
• Index