Home Sitemap Back to GAMC Contacts Feedback
GuidelinesToolsWorkplace DirectionsBuilding Appraisal ConsiderationsAssistanceAcknowledgements & References
 
 
 

Addressing Change Through Alternative Workplace Strategies
by Paul Heath and Lee Thorn-Silverton (Published in FM Journal May/June 1997)

The issue in business today is change. More specifically, the issue is finding ways to address change: in the competitive environment, the organization, the nature of work processes, relationships to customers and clients, the demands on the workspace itself, the demographics of the workforce, work/life balance expectations, and anticipated recruitment and retention. In the facilities arena, a tool for addressing these changes is the use of Alternative Workplace Strategies (AWS). Coming under a variety of names and encompassing a range of options, AWS basically seeks to integrate change into the workplace.

However, the integration of change is not easy. In large organisations, there are formidable organisational, political, and personal barriers to supporting and/or effecting change in the workplace. This paper utilises Citicorp's Alternative Workplace Strategies Initiative as a case study to address: potential AWS approach characteristics, "rollout" options, support system organisational approaches, implementation characteristics, and "lessons learned".

Alternative Workplace Strategies

Alternative Workplace Strategies, "AWS", are non-traditional approaches to the workplace. They are new approaches to how, when, and where people work and respond to new business contexts, work processes, and support system relationships. The catalysts include new work demands such as work process requirements for group work (teaming), increased remote work patterns, or place/time flexibility responding to recruitment and volume fluctuations. This inclusive term describes a variety of different organisational and design strategies, including: increased use of team, more work done away from the office, more sophisticated network technologies, and increased flexibility in telecommunications technologies.

Most critically, AWS can radically change the workplace and leverage concurrent rethinking of the business organisation, process improvements, or re-engineering processes.

AWS approaches are not consistent in scale, type, or breadth from company to company. In fact, the assumptions about the workplace, flexibility within the organisation, and therefore the potential for alternative workplace approaches varies considerably between organisations. The strategies which are adopted, or even just considered, can be limited to a single approach (e.g. telecommuting) or can be drawn from a variety of approaches (e.g. non-territorial in-house settings, telecommuting, and satellite offices).

Citicorp viewed AWS as an overall approach that encompasses a range of strategies and may be combined as an overall workplace business strategy. This 'medley of solutions" approach makes it possible to customise solutions for the often diverse and unique operational needs within any given business. The medley of solutions approach allows a business to respond to changes in business practice over time, supporting transformations in business organisation and work processes.

The approach to facilities indicates fundamental change in the organisation of the workplace and workstyles, as evidenced in Citicorp's pilot case study described below. As a start, the overall planning approach organises employee work patterns in three categories:

  1. Full Time Office: The Office Denizen

    In this traditional work pattern, employees work in a centralised office, typically because they require face-to-face interaction, centralised support, organisational structures and management approaches, or tools and other resources located at the office.

  2. Part Time Office, Part Time Remote: Part Time Warrior

    Employees spend some part of their working time away from the office. These jobs vary from regularly required short visits at other local sites (e.g. inspectors) to less frequent but longer trips away from the home office on either a regular or irregular basis (e.g. auditors, some types of consultants).

  3. Most Time Remote: The Road Warrior

    These employees spend a high percentage of their time away from the office, typically travelling (e.g. sales people, some other types of consultants). The amount of time spent away from the office changes the support systems and working relationships of more traditional job structures. Current technology allows employees to be "virtual" workers who can function effectively from many locations.

Of course, these are generic categories and they describe a range along which actual work patterns can be mapped and around which appropriate strategies can be developed.

A strategy may consist of a combination of AWS for "office" and "out-of-office" workplaces, e.g. teaming areas for in-house sales support staff who require the ability to rapidly exchange information and shift tasks from one person to another; hotel workspaces for sales staff whose travel patterns take them away from the office for extended periods; and "first-come, first-served" "hot desks" for the sales staff who are in and out of the office for brief but frequent visits.

Integrated Workplace Planning

The adoption of AWS addresses the need to adapt to change. However, effectively integrating changes in the workplace is both a "delicate" and complex undertaking. We assume at the outset that effectiveness requires a broad view of the workplace where the major components are addressed as an integrated system, including: business needs; organisational, cultural, and work processes; technology support systems; and the physical setting. We also assume that effectiveness requires the active application of expertise in all four of those workplace components.

Integrated Workplace Planning, as an approach to organising and planning the workplace from a broad perspective, has recently become more broadly recognised as an effective workplace change model. Franklin Becker and Joe Ouye have identified some of the key components of the integrated workplace approach, emphasising the importance of the workplace as a system or ecology. The key elements of the integrated workplace planning approach were used as the basis for the Citicorp AWS pilot program. As will be described later, the key workplace components identified above were represented in both expertise integrated into the organisational structure of the project and into each step of the planning and implementation of the pilot group project.

"Rollout" AWS Approaches

An Alternative Work Strategy (AWS) fundamentally alters an employee's sense of workplace interaction, responsibility and task. The master plan to implement such a strategy involves careful forethought to ensure that the AWS is a congruous fit, a smooth transition and maximises all alternatives.

We can describe three general models for introducing Alternative Workplace Strategies into an organisation. The first model is a top-down approach where entire departments adopt an AWS approach applied from the leadership level. The second model is a bottom-up approach where AWS approaches are implemented at scattered locations throughout the organisation. The third model is a pilot approach where successive departments adopt AWS approaches stylised for the range of department needs with system solutions passed on from pilot to pilot.

In the top-down model, administrators within the organisation decide which departments are the most conducive to or who they want to see adopt AWS. The implementation of the AWS approach is typically done in a top-down manner applied to the entire department. Since the top-down model addresses whole departments, it is mot effective when all employees of a chosen department have homogeneous tasks that are conducive to an AWS. IBM used this approach for typically nomadic departments like sales and consultants. The approach can, however, be applied to less homogeneous groups, such as found with Chiat Day. It is a low involvement approach with high involvement implications with respect to the impacts on work process and individuals.

At the other extreme is a bottom-up model that focuses on each job and its individual personnel. The model seeks to identify the specific jobs and people who are most suitable and opportunities to change to an AWS approach. These opportunities are used as the basis for the overall AWS program which targets those jobs/people regardless of their department. USWest utilised this approach to implement an AWS where they utilised surveys from all departments to determine AWS compatibility on a job/person basis. This resulting statistical benchmark was applied to each department to determine its rollout to AWS. In this model there is no emphasis on job homogeneity throughout each department. Rather, the emphasis is on easily adaptable jobs coincident with people ready to adapt to the changes.

The pilot model contrasts from the two previous examples because it focuses on individual departments as a means for identifying group-specific AWS solutions which can be used to inform AWS approaches throughout the organisation. The earlier models typically seek out the easy transitions, the jobs and individuals that would easily transfer into an AWS. The pilot project model, however, investigates AWS possibilities for not only the easy transitions, but also the more difficult ones. Furthermore, the pilot model is business specific, and considers all jobs for AWS opportunities instead of focusing on task and individual classifications for compatibility. Overall, the goal is to develop a pilot AWS implementation process within a single department, and then rollout the process to other departments during successive AWS transitions. The process supports succeeding AWS implementations directly by identifying specific effective AWS approaches within the corporate structure. And it also allows the creation of broader corporate-wide AWS planning and implementation support systems. The pilot approach emphasises the planning and design of AWS approaches crafted specifically for each department. This is the approach Citicorp used in their pilot program, as described below.

Seeking Other Models

The integrated workplace planning approach requires the application of expertise in a range of disciplines. Historically that expertise is "discipline-specific" and resides in special, often isolated, pockets of an organisation (figure 1). Breaking out of that silo culture is a key first step in taking a full integrated approach to adopting AWS approaches as a component of addressing change. Utilising a broad view of the workplace, an integrated approach will link those major disciplines which contribute to the health of the overall workplace. However, it is a difficult task because no single group is responsible for planning the workplace from that broad integrated view. Within those traditional organisational frameworks, effective planning and delivery mechanisms have to be created to provide the tools for adopting changes which can be driven from a number of sources within the overall organisation (e.g. real estate, facilities, human resources, technology, and especially the business units themselves).

Effective integration of AWS approaches requires well thought out linkages between those traditional centralised support groups. The typical silo structure where each discipline is concerned only with the details of their expertise, often in disregard of business-specific needs, does not support these critical linkages. The goal is to establish new models, which facilitate organisational capacity to establish common support objectives and develop sets of overlapping support services which focus on specific business needs (figure 2). The creation of these cross-disciplinary linkages is difficult. A major component of the Citicorp AWS program, described below, was establishing and nurturing these relationships. These linkages provide the necessary centralised support services to create a corporate-wide AWS program responsive to the specific characteristics of each business.

Citicorp Alternative Workplace Strategies Initiative

Recognising the need to address the impacts of changes in business contexts and approaches to the workplace, Citicorp undertook an Alternative Workplace Strategies planning project to investigate the opportunities for application of AWS within the corporation. Based in Corporate Real Estate, the initial impetus for the project was the reduction of overall occupancy costs. However, the planning approach and overall structure of the project went beyond a narrowly conceived need to generate "real estate saves". Linking broad aspects of the workplace, the goals for the project sought to:

  • Support the way Citicorp works - today and tomorrow
  • Improve productivity
  • Increase employee and management satisfaction
  • Reduce infrastructure costs

The AWS project was created under an overall pilot project model described above. The specific target was to initiate and evaluate the application of appropriate AWS approaches within Citicorp through a pilot group implementation. Utilising the pilot study as a catalyst, the project sought to establish delivery mechanisms on a corporate-wide basis while investigating the opportunities and applications of AWS options within the Citicorp world beyond the pilot group. The approach was designed to answer group-specific questions in the short term, establish policies and delivery approaches in the long term, and identify within the corporation how one section/arenas drives another and can contribute to the adoption of change in the workplace. By structuring the project as a series of progressive pilots, Citicorp was able to utilise knowledge gained with each pilot to inform and improve the next, and to build the "library" of support services and in-house expertise.

As with many large corporations, Citicorp experiences a push and pull between centralised and decentralised organisational approaches. The structure of the AWS project sought to provide the linkage and support benefits of the centralised approach to an overall organisation which emphasises the business specific responsiveness of the decentralised approach. While not consciously "advertised" as an integrated workplace planning project, the planning process was also structured to address all of the components of the integrated workplace environment.

A broad-based, integrated viewpoint, the foundation for creating a cross-disciplinary planning team within the corporation, was the central organisational feature of the AWS initiative. This Steering Committee was composed of active participants from the major administrative support groups, including: real estate, technology, human resources and centralised support services. The committee was an integral part of the process with oversight and guidance responsibility for direction and content during both planning and pilot implementation. The committee members provided expertise in their respective disciplines to address specific issues as they arose. More significantly, the committee members were charged with establishing system-wide capacity to address AWS needs, standardising tools and services to support individual business AWS initiatives. This includes: identifying key issues of concern to the businesses and the corporation, establishing corporate policy or direction as appropriate, creating AWS implementation tools and approaches for use by the businesses, and developing internal capacities within each department to provide service/support for AWS implementation efforts.

Individual Citicorp businesses tend to have a vertically integrated structure, whereas a business or department will have all necessary functions integrated in a self-contained structure. While generalised job types are transferable between businesses or departments, the specific approach to the job as part of the overall business approach varies from business to business or department to department. There are relatively few departments in the corporation with large numbers of staff doing traditionally targeted AWS tasks. These vertical structures suggested the need to address the whole of each business not just specific job types. Each department or business would address its specific AWS related context and work process needs to develop group-specific solutions. These solutions become part of a growing resource for other groups, providing a library of successful and unsuccessful approaches within the Citicorp world. The initial step in the process was the identification, planning and implementation of an appropriate AWS pilot group.

Pilot Approach

Establishing a pilot within the corporation provided the tool to address the key corporate delivery issues. But it also has important implications for the individual pilot business group. From the business perspective, the central issues of change apply to a broader context than the workspace itself. It is a perspective where the resulting AWS approach for the pilot is based on expected changing demands on service delivery capacity and options. The focus is on mobility and the result is an entire staff with the capacity to work virtually. Resulting workplace changes impact the organisational structure, management approaches, interpersonal interactions, support services, allocation and type of workspace, and the location of primary office space (i.e. main, satellite or home).

Citicorp Pilot Case Study

The initial AWS pilot group was chosen for its close fit with the selection criteria. Most critically, the group was changing its business approach, developing new organisational structures and ways of doing business to address new global demands for and on their services. Leadership of the group sought out the pilot project as broader support for these changes. The group consists primarily of highly motivated professional staff with average to high level technology skills. Productivity measures related to the time needed to finish specific tasks had been in place for a number of years. The group is engaged by internal Citicorp businesses to provide specific consulting services, thus providing a working example of AWS across much of the corporation. While some members of the pilot group had traditionally spent time out of the office, most staff did their primary work in the office. The business characteristics which lead to the initiation of the AWS initiative and helped define the AWS approach are:

Mission:

  • Be a strategic partner with Citicorp businesses world-wide.
  • Deliver objective and unbiased information on risks and opportunities revealed through our analyses.

1995 Goals:

  1. Deliver service excellence.
  2. Build a client-focused service organisation.
  3. Deliver quality service to our clients.
  4. Understand expectations for innovation.
  5. Improve quality of our readiness.

Forces of Change:

  • There is more competition at customers' marketplace: cost, turn-around time, expansion of geography, contraction/re-definition of base business.
  • Number of customers is expanding.
  • Number of services being provided is expanding.
  • Staff are internally driven.

AWS Approach

The key to the AWS approach for this pilot group originates in their business model change from a geographic to a client-focused organisation where professional staff are members of a global client team based in a number of geographic locations. Recognising an increasing demand for world-wide responsiveness, staff mobility became the central characteristic of the AWS approach. All staff were given the tools to work anywhere, anytime. Layered on that change, selected staff (as a pilot within the pilot) were provided with home offices so they could do their primary work at home rather than in the office. The home office is a significant change for many of the staff, who had typically spent 90% of their time in the office. The group moved from a double loaded corridor setting to an open office, systems furniture environment with added conference rooms, a central library/research centre, full-size hotel workspaces and open team areas with drop-in support capacity.

AWS Systems Support

Looking specifically at the overall approach to implementing the Group's AWS program, both centralised and business support for the program can be outlined in four categories. It is important to note that because the AWS program was initiated by the Real Estate group, they served as lead on the pilot project, acting as both catalyst and guide throughout both the planning and implementation process. While their specific expertise was focused on the physical setting needs, their support occurred in all four areas in the catalyst role:

  1. Organisation/Management

    Support for organisational and management needs was created through three sources. The first two were the Real Estate and Support Services organisations who were members of the AWS Steering Committee. They supplied support either through direct internal resources or the use of consultants located elsewhere within or external to Citicorp. The areas of support included: overall planning coordination, workflow and organisation analysis, identification of operational issues and opportunities, hard copy management, office support services reorganisation, and modification of mail delivery systems. The third source for organisational and management support needs was the AWS pilot group itself. The management expertise of the pilot group was used to address the issues and opportunities identified through the planning and implementation process.

  2. Employee

    Resources to address employee-related issues also came from two major sources. The first was the Human Resources Group, one of the members of the Steering Committee. Human Resources support was developed at two levels, corporate and business-specific. Corporate support includes the identification of outside resources to address the specific training and other development needs of the staff as a whole. Local HR support was directed at identifying and addressing the needs of the individual staff members. The second source was again the pilot group itself. Solutions to specific staff needs both for the staff as a whole and for individual staff members requires the attention of the business leadership, particularly as the impacts of changes and staff needs links to organisational and management approaches and support.

  3. Technology

    The primary focus for technology support was with the Citicorp Technology Group who were also a member of the Steering Committee. The Technology Support effort addressed two levels of need simultaneously. The first was providing the technology solutions for the pilot group to support their specific AWS program. The second was to configure these solutions, as possible, to become part of a standard package of AWS tools which can be used throughout the corporation. As with most business groups, the pilot group had an in-house technology staff person who provided central guidance and review of technology assumptions, approaches, and linkages with existing systems. External technology consultants experienced with AWS methods and approaches were used to support the technology development effort.

  4. Physical Setting

    Not surprisingly, the primary focus for support for changes related to the physical settings, both main and home offices, was the Citicorp Real Estate Group. Supported by external consultants to address specific design problems, they addressed the design and implementation of the new offices and helped provide the individual staff with design analysis and the appropriate home furniture.

"Lessons Learned"

"It should be borne in mind that there is nothing more difficult to handle nor more doubtful of success, and more dangerous to carry through than initiating change.

The innovator makes enemies of all those who prospered under the old order and only lukewarm support is forthcoming from those who would prosper under the new. Men are generally incredulous, never really trusting new things unless they have tested them by experience." Machiavelli (1500AD) The Prince

  1. Moving the Process

    "How do you put your passion in competition with other people's passion - on completely different topics." (Kit Tuveson, Hewlett-Packard) Who is responsible for driving the adoption of changes inherent in Alternative Workplace Strategies? How do you get everyone who must be involved to consider the AWS implementation process as a critical function or at least move it to or near the top of their in-basket? The structural changes which were initiated in this AWS planning project are difficult to make. Everyone today has too much "on their plate" as a normal part of their particular discipline/silo's mandates. Making substantive changes means that everyone involved has to see the need for the change and recognise that addressing those changes must now fall on their radar screen.

  2. Creating AWS Support Systems

    Easily accessed support mechanisms are a key to effectively implementing AWS. Access assumes: 1. That the support mechanisms exist and 2. That businesses, groups, and individuals can easily utilise the support in a timely manner. Given that agreement to provide service has been developed (see lesson 1. it is not always the case that the needed service actually exists within the system, e.g. file management may be required to support remote workers and not be an expertise currently available as part of a centralised service. Then, given that a service is available either within a business or from a central group, it must be easily accessed in a timeframe which fits the particular business' overall AWS planning and implementation schedule. Lack of resources can make both the development and delivery of appropriate services difficult to fulfil.

  3. Addressing Change

    "But among the things readiest to your hand to which you will turn, let there be these two. One is that things do not touch the soul, for they are external and remain outside the soul; but our agitations come only from our perception, which is within. The other is that all these things, which you see, change immediately and will no longer be; and constantly bear in mind how many of these changes you have already witnessed.

    The universe is change; life is your perception of it". Marcus Aurelius (2nd C. AD) Thoughts

    It appears from the growing literature that change management is getting much closer to people's radar screens. The experience here suggests that this is a critical issue. The parts of change which "are external" can be provided for with some (occasionally a lot of) effort by everyone involved in the AWS implementation process. These are the components covered above under "Creating Support Systems". The internal component of change, our "perception of it", is not so easily addressed. The dilemmas in addressing these internal components arise from their origins - the individual. While common concerns and needs can often be found, experience shows that attention must be paid to the specific content, timing issues and concerns of everyone involved. The discipline of change management allows those issues and concerns to be addressed as an integral part of the implementation process. Unfortunately, change management, and the foresight to understand its relevance and importance, is not often available in traditional corporate structures.

  4. Goals Matter

    What is the impetus for initiating AWS? Where do the benefits accrue? Who pays the price? The origins of the change at the implementation level matter. At some point in an AWS implementation program the tyre eventually meets the road. The most effective AWS programs are structured to provide benefits to everyone - the corporation, the business, and the employees. Changes made solely to solve problems at the upper two levels can generate more difficult problems at the individual level, particularly if it generates heavy costs on those individuals.

  5. Walk the Walk

    Lead by example; it is expected at the staff level. The last thing people want to know is that they are the pilot (read experiment). Those who are purveying the ideas about the change should be practising those approaches. A part of the "test by experience" can be to observe others in that new setting. Whomever is driving the change process should be adopting change.

 


<back to top>

 

FooterNav