GPM First
Chapter 2 of Project Delivery in Business-as-Usual Organizations (978-0-5660-8629-8) by Tim Carroll

Business-as-Usual Organizations

Chapter 2

Roadmap for Chapter 2

This chapter introduces business-as-usual organizations, contrasting them with projectized companies (in areas such as construction). While some of the different challenges in delivering projects in BAU organizations can be attributed to the ‘soft’ nature of business change projects, it is proposed that there are distinct, cultural differences that are more important to consider.

The banking sector is highlighted to demonstrate that these differences also apply at an industry level, to reflect particular cultural factors and behaviours in each industry.

The chapter concludes with three propositions that underpin the rest of this book. A hypothetical example will hopefully convince the reader that these propositions are probable and worthwhile of further consideration!

Roadmap for Chapter 2



1 Project Management Moves into New Territories

Project management grew as a discipline in companies involved in capital projects where the delivery of projects was the prime, corporate aim. They are ‘project management companies’.

Other companies that have been in the forefront of project management did not have projects as their sole, corporate aim, but they recognized early on that their business depended fundamentally on the ability to deliver new products to market in a timely and effective manner. Defence agencies were early enthusiasts, particularly in the USA where project management disciplines and techniques were shaped on critical defence projects in the 1960s and 1970s. Pharmaceutical companies also adopted project management techniques to provide discipline on drug developments, where timescales are long and each project is a speculative venture requiring a major proportion of the company’s resources.

Consultancy organizations and IT solution integrators recognized the value of the disciplines in the 1980s and 1990s to manage the delivery of their solutions and related tasks such as re-engineering business processes.

In the last two decades, project management has progressed from these organizations into a very different type of organization; organizations whose primary purpose is the day-to-day BAU management of production, processing or sales activities.

While some of these organizations have long used project management disciplines within specialist areas (product launches, premises as examples), over the past decade they have generally adopted project management as a core discipline to better manage their investments in business change projects:

  • re-engineering business processes

  • internal reorganizations

  • transferring work to outsource partners

  • integrating acquisitions

  • driving cultural change

  • changing brand identity

  • responding to new regulations

  • improving IT systems and infrastructure

  • improving how customer relationships are managed.


The volatility in today’s business world is increasing this demand for discipline in managing business change, as executives know that the world will change around them and any shortcomings in delivering change projects are likely to reduce the desired benefits arising from such investments.

For example, in the 1980s and 1990s there were many studies on the business aspects of corporate mergers and acquisitions. Most have focused upon the strategy and business drivers for the merger or acquisition and whether the desired benefits (synergies, costs, revenues) have been realized. More recently, the focus has shifted somewhat to look at the approaches that lead to success during the implementation of the acquisition – how it is integrated into the acquiring organization in such a way that it delivers benefits on a sustainable basis. The benefits of clear goals, good planning, disciplined control of progress and careful attention to managing the affected staff (all classical components of a change project) have been correlated with improved benefits and the creation of greater shareholder value.

This move of project management into business change is reflected in the focus of the project management profession (see Figure 2.1). Project management techniques evolved as a means of managing complexity. Critical path networking and then more integrated project control systems looked for the balanced management of cost, time and scope. The concept of a project life cycle gave structure to projects, and key processes for managing a project were defined. The focus of this project management competency was very much on the delivery of a solution – some tangible deliverables such as a new bridge, road, or petrochemical facility. As project management moved into the field of business change the solutions were still described in terms of their tangible deliverables – IT systems, process models or new products.

In addition to the technical aspects of project management (the science of project management, as it was often termed) the project management profession paid increased attention to the skills and behaviours required to motivate and lead teams on the delivery of projects. The various organization structures that could be used to deliver projects were the subject of research, as were the personal skills and attributes of those who lead projects. We often called this the art of managing projects.

As project management started to make inroads to projects that deliver information technology or to re-engineer internal business processes, this focus on the people aspects of project management evolved to address the challenge of managing change – the less tangible deliverables of the project. We recognized that these types of projects needed attention to the involvement of affected staff and to clear communication of the goals, or staff would not be supportive of the endeavour.

The project management profession realized that it must widen its definition of the scope of the project beyond the delivery of a ‘solution’. The delivery of the project’s tangible deliverables (such as some new technology or redesigned process) is only a part of the whole project process. The concepts of programme management and benefits management have gained in prominence to address these broader implications of change, including the realization of the benefits that the organization sought in return for the project investment.

Figure 2.1 The evolution of project management


In the early stages of this attention to the organization-wide value of project management, the term ‘management by projects’ was coined. It was the first indication that the sum of projects in an organization might equate to its agenda for change and growth. This was a concept that has now become more applicable in practice through the development of programme management and portfolio management.

In recent years, this focus on engagement of the business has broadened. There is an increased emphasis on the right sponsorship and governance that will provide not only the support of individual staff whose working life is directly affected by the project but also broader, corporate support for the project so that it can deliver its objectives despite a changing business environment and competing priorities.

This growth in the use of project management for business change has led to greater prominence of the discipline and this has been mirrored by the entry of project management into the curricula of business schools.

What is so special about delivering projects in this new territory of BAU managing change in organizations? Is it merely the type of project that is typically undertaken or is it a wider, cultural difference from projectized organizations? Let’s look first at the types of projects.


2 Hard and Soft Projects

We often call projects either ‘hard’ or ‘soft’. Definitions of hard and soft vary, but hard projects are typically based on solid, scientifically defined objectives where there is limited scope for interpretation (building a road, for example, where the final deliverable can be clearly measured against its planned scope and specification). Soft projects might have less tangible goals or might have outcomes that are more oriented to people, open to interpretation or subject to differing expectations by stakeholders (embedding a set of corporate values across an organization being an extreme example).

It is generally accepted that considering projects in varying degrees of hard or soft is a useful aid to establishing the right project approach, the required skills of the project team, the management methods adopted and how much of the team’s effort is applied to the technical or human aspects of the project.

Figure 2.2 Hard and soft projects


As Figure 2.2 shows, there is a spectrum of hardness and softness and most projects are a blend of both. On the face of it, a move of an organization to new office premises is a hard project, with building selection, construction and fit-out being key elements of the project. The contractors working on the project will see their scope of work as a hard project. However, anyone who has worked on such a project from within the owner’s organization will be keenly aware of the softer aspects, such as where the building should be located to suit employees’ preferences, how space will be allocated in the new office, what style of interior space will be best. All of these discussions involve many stakeholders, office politics and differing points of view. Eventually, while the goal of the new office will include hard outcomes such as cost reductions, it will also include softer outcomes such as teams working more closely together. If the staff are not happy in their new facility (a very soft measure!) then the project will have failed.

The implementation of IT systems is a similar blend of hard and soft aspects, where the specification is open to interpretation and the right engagement and perceptions of stakeholders are critical to overall project success.


3 Business-as-Usual Organizations

It is tempting to consider the use of project management in its traditional (engineering) and new (business change) applications as simply the difference between hard and soft projects.

While this distinction is certainly part of the issue, there is a more fundamental and critical point to consider. This is that these business change projects are taking place in organizations whose primary aim is not the delivery of projects. The culture of such organizations is shaped by everyday business activity, not the delivery of projects, and this difference fundamentally affects the way in which project management, as a discipline, must be carried out.

Let’s consider some of the differences.

Management Focus

In organizations such as banks, the primary focus of the senior management each working day is the conduct of business as usual. A bank’s management team will be concerned with:

  • how well customer transactions are proceeding;

  • competitive pressures and responses;

  • sales and marketing activity;

  • regularly assessing the risk profile of the bank’s loan portfolio;

  • managing the cost base;

  • motivating and leading staff;

  • ensuring compliance with expected practices and regulations.


Of course the senior management will also be considering how to grow the organization and how to make significant changes in the business portfolio and efficiency of operations. They will be spending time steering such endeavours. At the more senior levels of management an increased proportion of time will be spent on the future of the organization rather than its present-day operations. The majority of management time, though, will be spent on directing BAU activity, and rightly so. For a UK plc, the martketplace measures the success of the company twice a year through its annual and interim results and the management team will lose the confidence of the marketplace if short-term progress is unsatisfactory.

Projects are relatively long-term endeavours (perhaps a typical implementation timescale is six months to a year, with a further one or two years until the project breaks even and starts to generate profit). So projects will always come lower down the corporate agenda (and the executive’s diary management) than myriad BAU activities.

There is also an argument (which I accept will vary by industry) that in some cases the cost of project investments is actually less worthy of management attention than BAU activity. In a bank, for example, the difference between good and bad performance on the bad debts from the loan portfolio is likely to be an order of magnitude larger than the difference between good and bad performance in managing project costs. Where would you spend your time and energy as you drive your team towards year-end performance targets?

So we can argue that such companies are right to be spending their time primarily on managing BAU activity.

To make matters worse for a champion of project management, we should reflect that most senior managers of such organizations have not participated frequently in the conduct of business projects. During their career they might have directly led a project, but it is more likely that they will have participated in projects less directly as line managers, either being in some way accountable for a project or being affected by the results of the project. They are not likely to be receptive to a set of new techniques and practices if they have little empathy with the trials and tribulations of project teams.

In summary, this is a difficult point at which to start a campaign to improve project management in such an organization! It is also a shock, and I speak from personal experience here: despite the project management profession’s views of the importance of projects to an organization’s development and the undeniable logic that the portfolio of business change projects helps drive the organization’s strategic change agenda, the reality is that project delivery comes some way down the daily agenda of such organizations.

Projects Disrupt BAU Activity

This ambivalence to projects would be a challenge in itself. The situation worsens, though, for any champion of project management in such organizations, for projects actually disrupt current BAU activity. Any change project needs a core team to drive activity and needs varied involvement from subject matter experts and line managers who will be affected by the project. This business input is critical, as we see in the post mortems of the many IT-based projects where the lack of sufficient user involvement is a common source of project failures.

Allocating the time of internal staff to a project causes tensions:

  • The business has to reorganize its resources to address both the project and BAU. Using short-term, external resource to provide business expertise to the project rarely works well because of the lack of ongoing ownership, so the usual approach is to second internal staff to the project and backfill them with temporary staff on BAU work. This transition must be carefully managed if the quality of BAU work is not to suffer.

  • These project secondments also cause concerns on a personal level. They take the staff away from their place in the internal hierarchy, which is an uncomfortable experience, and place them into a project process of which they might have little prior experience. If not carefully managed, the reintegration of the staff back into BAU activity after the project can also lead to staff dissatisfaction.


These issues can lead to projects being discussed in quite negative terms, as diversions from BAU, as assignments that are personally unattractive, as ‘outside BAU’.

(I carried out a benchmarking exercise recently with 11 banks. The banks varied in their project management maturity and in how enthusiastically they had adopted project management as a discipline, but there was an almost universal view that, despite the organization recognizing that projects were important to the business and investing in project management practices, the projects were considered as being ‘outside BAU’. This is a long way from our profession’s view that the projects are an integral part of how the business grows and manages its affairs.)

If a project impedes upon and disrupts BAU activity, then the role of a project manager is also likely to impede upon the area of responsibility of line managers affected by the project. Even if the efforts of the project manager are intended to be constructive, there will be sensitive areas, particularly when the business case, stakeholder management or the honest portrayal of project risks are involved. This can have a negative impact on how the project manager and the discipline of project management are perceived.

The Challenge of Being the Client

In traditional areas of project management, such as construction, the client or owner of the delivered project solution is often (but I accept not always) experienced in acting in that capacity. The client knows the life cycle that a project follows and appreciates the issues that arise during the life cycle. But BAU organizations spend most of their time on BAU activity, so when a project arises it is likely that they are either inexperienced in acting as the client or find it difficult to access whatever knowledge they have gained from projects in other parts of the organization.

As Figure 2.3 shows, the client’s life cycle for the project is long (longer than the implementation process upon which project managers typically focus) and includes a number of politically-sensitive responsibilities, from gathering support for the project in its early stages through to realizing business benefits. These broader aspects of project delivery are still challenging to those in the project management profession who spend their working lives on projects (as examples, benefits realization is still difficult to achieve in practice and whether the project manager should have responsibility for the business case is still debated in publications). If these areas are challenging for the project management professionals then I would argue that it is not surprising that anyone who is involved only occasionally on projects will find them very daunting.

Figure 2.3 The client’s project scope


As it is focused upon BAU activity, the organization is also poorly equipped with systems and processes that would help the management of projects. Most BAU companies have limited capability in project control tools or in project accounting (either as a concept or in the form of suitable accounting systems.)

Another aspect of being a BAU-focused client is that the organization has a structure and hierarchy that is tailored to the BAU needs of the organization. Whereas projectized organizations have developed organizational models that particularly suit the needs of project delivery, these are difficult to create in BAU organizations. For example, many BAU organizations have limited experience in acting in a matrix fashion, where the organization aligns itself to both functions (for consistent technical standards and quality) and projects (for focus and clear objectives).

It is often very difficult for the project to gain the right attention from affected functions when the existing organizational hierarchy is so much stronger than the project structure (which is of course temporary in nature). Sometimes this strength of the existing structure, together with political considerations, can overpower the project, resulting in decisions being driven by BAU managers who do not have the requisite skills or whose agenda is not the same as that required for the success of the project.

See Table 2.1 for a summary of the differences in the delivery of projects between projectized organizations and BAU organizations implementing business change.

Table 2.1 Contrasting the delivery of projects in projectized and BAU organizations


Business change in a BAU organization

Primary focus of the organization and organizational design

Project delivery

BAU service delivery

Typical project

Hard with soft areas

Soft with hard areas

Business case

Limited to profitability of delivering a solution

Subject to risks in solution delivery

Depends on broader engagement within the organization

Subject to risks in the business environment

Staff affected

Localized, dedicated

Includes dispersed, part-time contributors

Short-term profitability of the organisation is impacted by...

Project management efficiency

BAU business performance

Experience of senior management



Learning from previous projects




‘Our business is the sum of our projects’

‘Projects are our BAU’

‘Projects are outside BAU’

‘Projects disrupt BAU’

The Scottish Parliament construction project was completed in 2004 (significantly late and over budget) and has been the subject of much press comment and a published governmental report. We can consider this as an example of a project delivered by a BAU organization, for while governments deliver many projects they are primarily BAU in nature. Although a full analysis of the project is outside the scope of this book, the published report highlights a number of the features that have been discussed above, including unrealistic expectations, poor organizational structures and control processes, together with inadequate project delivery skills of BAU line managers (see the panel on the next page).


4 The Financial Services Sector as an Example

The descriptions above of BAU organizations will apply to many different industry sectors and I believe that the lessons and approaches in this book are relevant to many sectors. However, each sector and company also brings a unique culture that reflects its needs and history and this culture must also be recognized when applying the disciplines of project management. We can use as an example the financial services sector and banking in particular, considering some cultural factors and behaviours that can appear on business change projects.

Scottish Parliament

The project has been criticized for its procurement method, the management structures put in place to deliver it and the lack of adequate budgeting or cost controls for what was described as a uniquely complex building.

The choice in 1998 by Scottish Office civil servants of a ‘construction management’ procurement vehicle to deliver the building was made under considerable pressure from political sponsors to build the parliament fast.

Officials chose this route because it allowed work on the building to begin before its design was finalized. The alternative of hiring a lead contractor to build to a fixed price was deemed too slow for a completion date originally set for July 2001. But construction management was a vehicle unsuited for most public sector building projects. This was because it left most of the risk with the client rather than contractors and required considerable construction industry expertise to manage – mostly absent among the project’s civil servant (BAU) managers.

The complex project required a single point of leadership but responsibility was instead divided among several parties, including both officials and politicians.

There was no attempt to set a cost ceiling and the official report concluded that it was not clear how important cost was compared with time and quality.

Volatility/Time Horizon

These organizations exist in a volatile environment. Some functions, such as trading, are extremely volatile and this leads to a short-term view and short planning horizons. It is very difficult for a project team to engage users as it is difficult for a long-term project to compete with immediate BAU demands from the trading floor (in contrast, insurance and pension companies tend to have a longer-term view, consistent with their organizational focus).


Many financial services organizations are also international, so any projects that are strategically important are likely to have global application. There is a perennial balancing act to be achieved between global standardization and localized business needs as each country operation will also have its own views on how the project should be conducted. This provides an extreme example of the challenges of managing stakeholders. This international dimension makes projects extremely challenging and has implications for the level of skill required, the tools and techniques used to conduct the project and how communications are managed.

Politics and Stakeholders

As a generalization, banks are relatively political organizations with strong, established hierarchies and a performance culture that results in a significant proportion of a manager’s income arising from performance bonuses. Where an organization’s structure is also relatively federal rather than centralist (often the case in banks) and the project team has to engage varied parts of the organization in the project, this will dictate the styles of leadership and communication that the project team must employ. Attending to stakeholders (both supporters and opponents of the project) is critical to project success. Engaging affected staff becomes a key challenge.

Profit and Cash

All companies, in any sector, have to manage business performance through the profit and loss account, cash flow and the balance sheet. Projects affect all three:

  • cash costs for the investment cost of the project;

  • immediate impacts on the profit and loss account (where the project’s cash costs cannot be capitalized);

  • the eventual impact of the capitalized costs on the balance sheet and profit and loss account;

  • the eventual benefits from the project, in both cash and profit terms.


When compared with other sectors, banks have huge balance sheets. This is because their assets and liabilities include sizeable loans made to customers and funding received as customer deposits; the much smaller fees and interest charges drive the profit and loss account. So, balance sheet considerations drive projects much less than in other sectors.

Cash is readily available and acquired at relatively low cost, but in contrast the marketplace pays very close attention to the profit and loss performance of the banks and to their cost/income ratios (operating costs as a proportion of income). This attention to the profit and loss account rather than cash or balance sheet leads to interesting dynamics in the management of business projects:

  • A tendency for project timescales to be adjusted to minimize the impact on the current profit and loss accounting period. An example would be the delay of a go-live date into the next period, when the capitalization of costs will also be deferred. The risk when making such changes is that the impact on the overall business case for the project is not properly considered. In addition, the impact of any delay or slow-down upon the cost of the project is also ignored or under-estimated.

  • The annual window that is used for setting business targets and cost budgets also leads to ‘annual projects’. These start in January (or whatever month represents the start of the new financial year and the availability of new funds) and they typically and conveniently are estimated as taking 12 months to deliver (usually an estimate based on hope rather than fact). Of course, some projects will take longer than a year to deliver, in which case the project merely seeks a new budget in the next financial period to complete the project. The danger is that the organization loses sight of the overall cost and business case of the project, merely seeing a series of annual slices of the project. These annual projects run a serious risk of not being run as projects with a defined goal, but as BAU departments.

  • The flow of cash through the project is a measure of the work being undertaken. It results from the costs of the project team and external purchases. The profile of cash spend over time obviously varies from the profit and loss profile where costs are capitalized as assets on the balance sheet. One issue for banks is that their focus on profit and loss measures tends to give misleading information as to how far the project has progressed towards completion.



The above analysis does not imply that financial services organizations do not manage their costs, just that their culture and business environment force particular behaviours onto project teams. In fact, financial services organizations pay great attention to managing costs – for managing money is what they do for a living. If we consider the project manager’s three objectives for managing cost, time and scope/quality (the classical project management triangle of objectives), there is a tendency for banks to manage the costs very tightly but to allow both time and scope to flex. If this is done informally then there are risks to the overall business case (for if the delivered scope is reduced this might have a significant impact upon the flow of benefits that is not always appreciated by the project team).

Such informal reductions in scope can cause great problems in multi-country rollouts of new systems and processes. In the team’s rush to achieve the launch in the pilot location, some short cuts are taken, some functionality might be sacrificed and some tasks will be done superficially. It is easy to fall into this trap on business change projects – reducing the effort on communications or training might have limited initial downside on the pilot site and will attract little attention (while not completing the last span of a road bridge tends to attract attention!). However, when the project team moves on to other locations, the exclusions start to cause real problems:

  • Temporary fixes or short-cuts impede roll-out activity and require remedial work.

  • Multiple versions of the solution to cater for remedial work create complexity and extra costs.

  • Poor change management is the result when the project team cannot give the same undivided attention to multiple sites as it gave to the pilot site.


Once the pilot phase has gone live (much publicized, no doubt), the organization has a tendency to assume that the hard work has been completed and the rest of the rollout will be quite simple. It comes as a shock when the project team returns to request more funds to address the increased complexity of the roll-out and this in turn often results in a slow-down of the roll-out to reduce the short-term cost impact. This increases total project costs and might defer the delivery of the full, steady-state benefits from the project.

Technology as an Enabler

Banking operations are underpinned by information technology. Of course this is true for BAU organizations in all sectors, but particularly so for banking where there is no physical product and where a huge number of transactions occurs daily. Hence, much of the project workload is made up of IT resources, software, hardware and communications networks. Business change projects might have 50 to 80 per cent of their costs allocated to IT work, with the balance being on process re-engineering, change management and project management. The IT work can overshadow the other elements of the project (which are just as important to project success) and can even overshadow the business rationale for projects. The danger signs are that one hears people in banks talking about ‘IT projects’ or of particular projects as being ‘owned by Technology’. These perceptions dilute the business ownership of projects and focus the attention on technology deliverables (just a part of the project solution) rather than the business case (the project outcome).

In conclusion, these observations about the financial services sector serve to demonstrate that different industries will exhibit unique cultures and issues, which will affect the risks of projects and the behaviours of project teams as well as influencing the maturity of project management practices. We could draw up a similar analysis for other sectors, for example the government sector where our analysis would highlight characteristics including:

  • the huge size and implementation complexity of infrastructure changes, which result in very lengthy timescales;

  • the influence of changes in policy as governments react to priorities and public opinion;

  • how making policy is still regarded as more career-enhancing than the delivery of solutions;

  • political desires for sharing funding with private enterprise, leading to very complex commercial and risk-sharing models for project delivery;

  • the impact of public-sector funding approaches;

  • politicians’ desires for ‘quick wins’ and the impression of immediate action.



5 Propositions

There are three key assertions in this book.

First is that most business change projects in industry today are taking place in organizations whose primary aim is not the delivery of projects and that these organizations provide a different and in some ways more challenging environment within which to deliver projects than is provided by a projectized business.

Second is that because the culture of such organizations is shaped by everyday business activity, not the delivery of projects, different approaches are required to deliver projects and to engage the organization in building a generic project management capability. These approaches must include demonstrating the business context for projects across the organization.

These views have been shaped by personal experience. I have delivered projects in both projectized and BAU organizations and built the project management capabilities in both types of organization. The differences between projectized and BAU organizations have become more evident during these experiences. What has also become evident, and is my third assertion, is that our project management profession has not paid sufficient attention to the unique nature of BAU organizations when attempting to migrate traditional project management approaches.

This is not an area that has received much structured research, so there is no scientific evidence at hand. Let’s adopt the next best approach and use a hypothesis to test out these views.

Let’s take a construction management company, a projectized organization where managing engineering projects is the prime goal of the organization, and now consider how it delivers an unusual project – a project that delivers to the organization itself rather than to a client. An example would be the implementation of a new system for accounting and financial control. If my assertions are correct, then we could assume that:

  • The construction company will be more successful than a BAU organization in implementing the technical core of the system (software, IT infrastructure). This is because the construction company is more attuned to the life cycle and issues of project delivery. There will be a clearer focus on the initial planning stage of the project than in a BAU organization and project risks will be considered more carefully.

  • The construction company will still find it difficult to clearly define all the requirements of the new system (a softer project issue).

  • The construction company will also find the broader aspects of the implementation difficult (re-engineering processes, engaging staff from all departments in ensuring the success of the project, training staff).

  • Staff will complain that the project is distracting them from their primary daily business activity (which in this case is managing construction projects).

  • It will also be hard to get an internal candidate to run this important project as it takes them away from BAU activity and the added value to their careers is not clear. So leadership might be given to external parties and this will lead to other tensions on the project and issues related to transition of the new system into operations.

  • Sponsorship will be strong within the Finance function but the construction management function will delegate ownership to fairly junior staff that can be spared from (‘more pressing’) BAU activity. This will lead to delays in escalating and resolving issues.


Does this hypothesis ring true? I suggest that it does and shows that the construction company will:

  • be more attuned to the project process than a BAU organization, which will improve its chances of success in delivering the new system;

  • have more inherent capability than a BAU organization to manage such a project…


but will still suffer from a number of issues, only some of which reflect the soft nature of the project; others reflect the unusual nature of the project when compared with BAU activity in the organization.

(One can sometimes see the same issues when a software company tries to implement its own business software applications within its own organization. While the company is well attuned to delivering solutions to customers, in which case the customer usually undertakes most of the change management, applying the software to itself is difficult and the change management challenges are considerable.)


6 Conclusions

BAU organizations are different to projectized organizations and offer unique challenges when delivering projects. Since they are also the focus of much of the project management profession today, they are deserving of closer analysis, but to date they have received limited research attention other than work on the nature of soft change projects. As I have described above, BAU organizations offer a range of challenges, many of which are due to their corporate culture, not the character of the project. The rest of this book outlines how we can improve project delivery in BAU organizations by:

  • building the project delivery capability of the organization and tailoring project management disciplines to reflect the culture of BAU organizations (Chapter 3);

  • aligning projects more closely with the strategic agenda of the organization through the use of programmes and addressing some of the issues that impede the implementation of programme management in BAU organizations (see Chapter 4);

  • implementing portfolio management to improve this alignment and the effectiveness of project investments (Chapter 5);

  • using these approaches to demonstrate both the business context for projects and their contribution to the organization’s agenda of strategic change, leading to an organization that is more supportive of project delivery as a valued business capability (Chapter 6).


Submit your own content for publication

Submit content