Interactions between transformations, flow and value at the design front-end for Primary Healthcare...

INTERACTIONS BETWEEN TRANSFORMATIONS:FLOW AND VALUE AT THE DESIGN FRONT-END FOR

PRIMARY HEALTHCARE FACILITIES

Patricia Tzortzopoulos1, Paul Chan2, Mike Kagioglou3, Rachel Cooper4 and Erica Dyson5

ABSTRACT

Design has been conceived from an operations management perspective as a process of converting in-puts into outputs, as a flow of information, and as a process of generating value to customers. The inte-gration, alignment and balance of the management needs arising from these three views has beenhypothesised as essential to successful design outcomes, and it is an area in need for further research(Ballard and Koskela 1998). Such integration is challenging at the design front end, where uncertaintyand poor information availability are common place.

The aim of this paper is to examine the design front-end in four primary healthcare projects based onlean principles. A research hypothesis focused on better understanding the interactions between theconversion, flow and value generation aspects of the process has been developed and tested. Data hasbeen collected through 22 semi structured interviews with diverse stakeholders involved with theprojects. The ‘as-is’ design front end was mapped out and examined accordingly to good practicesdescribed in the literature. The paper identifies the influences of the procurement method used overlean design management, and the influences of design management and role definition overrequirements capture and value generation. Finally, causal relationships between issues related to thetransformation, flow and value views are discussed.

KEY WORDS

Design Management, Requirements capture, Value generation.

INTRODUCTION

In the course of research into lean design manage-ment the need for integration, alignment and bal-ance of the management needs arising from thetransformation, flow and value generation viewsof design has become apparent (Ballard andKoskela 1998). However, such integration is chal-

lenging as understanding of the flow and speciallythe value views on design is still poor. At thedesign front-end such integration is even harder,as transformation activities are also poorly under-stood (Reinertsen 1997). Ballard and Koskela(1998) pointed out that exploratory research isneeded to develop an understanding of the inter-action between the three views, as up to date there

Product Development

307

1 Ph.D., Academic Fellow, SCRI (Salford Centre for Research and Innovation in the Build and HumanEnvironment), School of Construction and Property Management, University of Salford, Bridgewater Building,Salford, Greater Manchester, M7 9NU, UK, Phone:+ 44 (0161) 2954284 FAX + 44 (0161) 2954587, e-mail:[email protected]

2 Ph.D., Research Assistant, SCRI, School of Construction and Property Management, University of Salford,Bridgewater Building, Salford, Greater Manchester, M7 9NU, UK, Phone:+ 44 (0161) 2956170, e-mail:[email protected]

3 Ph.D., Reader on Process Management, SCRI, School of Construction and Property Management, University ofSalford, Bridgewater Building, Salford, Greater Manchester, M7 9NU, UK, e-mail: [email protected]

4 Professor, Director of the Adelphi Research Institute, School of Art and Design, University of Salford,Centenary Building, Peru Street, Salford M3 6EQ, UK

5 Project Director, MaST LIFT—Manchester, Salford and Trafford Local Improvement Finance Trust, e-mail:[email protected]

is little empirical data available into what actuallyhappens in design.

The design front end has been described as crit-ical for success, as failure to define product char-acteristics before design begins can be a majorcause of both poor design quality and serious pro-cess delays (Cooper and Kleinschmidt 1996).Value through design is known to be produced byresponding to and/or exceeding client needs andrequirements (Womack and Jones 2003). Manyvalue generation activities occur during the frontend, where uncertainty and poor informationavailability are common place.

It is at the front end that product ideas gainshape (Zhang and Doll 2001). It is also at the frontend that client needs and requirements are cap-tured and described into a design brief. There aremany idealised descriptions of requirements cap-ture proposed by design methodologists, howevera disparity exists between such idealised notionsand the complex realities of requirements capturein everyday practice (Dalrington and Culley2004).

In order to get a better understanding of therealities of design management, requirementscapture and value generation, the front end of thedesign process in 4 primary care facilities wasinvestigated based on lean principles. Findingsdescribe how procurement influences designmanagement at the front end, and how designmanagement and role definition affect require-ments capture and value generation. The findingsof this investigation and insights from the litera-ture were combined in an attempt to identify theiterations between the three views, in terms ofdescribing how mismanagement from one viewimpinge or influence problems in the other views.

THREE VIEWS OF DESIGN AND THEIRINTEGRATION

A more solid conceptual foundation for designhas been proposed through the integrated analysisof design as transformations of inputs into out-puts, as a flow of information between differentstakeholders, and as a means of generating valueto the customers (Koskela et al. 1997; Ballard andKoskela 1998).

The conventional conceptualisation of design isbased on the transformation view, in which thedesign process is divided in sub-processes, eachone of them carried out by a specialist who trans-forms their perceptions of the client’s require-ments into design decisions. In the flow view, thebasic idea is to eliminate waste such as unneces-sary rework and to reduce the time waiting forinformation. In the value generation view, the aimis to achieve the best possible value from the cus-

tomer perspective. Therefore, increasing theamount and quality of information about cus-tomer needs and requirements, for instancethrough rigorous requirements analysis, is seen asessential (Houvila et al., 1997).

Ballard and Koskela (1998) have described theneed to create an understanding of the concepts,causal mechanisms and more specifically interac-tions between the views to move research andpractice forward. Based on this thinking they putforward four research hypotheses:H1: Transparency of the design process from

one view, achieved through explicitmodelling and other means, is conductiveto a successful outcome from that view.

H2: Use of systematic methodologies tomanage the design process from one viewis conductive to a successful outcome fromthat view.

H3: In design management, the managementneeds arising from each view should beintegrated, aligned and balanced.

H4: For achieving a successful outcome ofdesign from one view, orderly managementof design from the other two views isnecessary.

Ballard and Koskela (1998) have adopted a view-point of success within and between the views topropose their hypothesis. A further, complemen-tary hypothesis is proposed that, in our view,approaches the issue from a contrasting perspec-tive, i.e. failure. We propose:

• Mismanagement of design from one of theviews will lead to problems in one or more ofthe other views.

Case study data is used to test this hypothesis. Theanalysis also provides insights into H1 and H4.

INVESTIGATION METHODOLOGY

Twenty two interviews were carried out with pro-ject directors, general managers, architects, archi-tectural advisors, project managers, designmanagers, healthcare planners and clientsinvolved in a public private partnership in whichfour primary healthcare projects were developed.Interviews were tape recorded, and an interviewsummary pro-forma (Miles and Huberman 1999)produced after each interview. In addition, analy-sis of documents describing the overall initiativeas well as requirements was also carried out.

The design front end process was mapped andproblems identified. A cognitive map was used todescribe the interaction of issues related to themanagement needs arising from each of the threeviews on design. A cognitive map is a descriptionof an individual or several individuals’ conceptsabout a particular domain, being composed by

Proceedings IGLC-13, July 2005, Sydney, Australia

308 Interactions between transformations: flow and value at the design front-end for Primary Healthcare facilities

ideas and links between these ideas (Miles andHuberman 1994). The links between ideas arecausal, being understood as: (a) A is the explana-tion of B; (b) B is the consequence of A; or (c) A isthe means and B is the goal. Cognitive maps havebeen drawn from the interviews pro-forma. Thesoftware decision explorer was used to supportthe creation of the maps. The software allows theidentification of the ‘centrality’ of an idea, whichis used to identify strategic issues on a map(Rodhain 1999). The next section describes themain investigation findings.

CASE STUDY DESCRIPTION

MODERN METHOD OF PROCUREMENT FORPRIMARY HEALTHCARE IN THE UK: LIFT

The healthcare service in the UK has recentlyundergone substantial changes, reflected in thehealthcare modernisation programme (DOH1998). There is a current aim that health and socialcare should be delivered jointly, so that thepatients can assess the services they need in oneplace, on the same day. This has created an oppor-tunity to take a new, fresh approach to the designof buildings that house healthcare, as well as anopportunity to consider the impact that the physi-cal environment has on patients and on healthcarestaff.

In order to avoid a fragmented approach to thedelivery of primary healthcare facilities and toconcentrate it to the areas of greatest need, theBritish Government established a new procure-ment route, i.e. Local Improvement FinanceTrust—LIFT. LIFTs are Public Private Partner-ships set up to allow NHS Primary Care Trusts(PCTs) and their local partner organisations todevelop primary care facilities. Public FinanceInitiative (PFI) was not a suitable procurement forprimary healthcare due to the fact that the value ofany individual project is not attractive to the pri-vate sector. Through LIFT a number of schemesare clustered and delivered by a single privatesector partner, selected through bidding. The pri-vate sector partner should bring constructionskills for the developments, being responsible for:

• Designing the facilities, based on require-ments established by the PCTs as the publicsector client

• Building the facilities and financing the capi-tal costs

• Providing facilities management and othersupport services over a 25 year period

Similarly to what occurs in PFI, the intention isthat the private sector will find innovative andcost-effective ways to meet the NHS require-ments by sharing the capital and revenue costs of

primary healthcare provision (Mohan 2000). Thelocal LIFT own and lease the premises tohealthcare practitioners. In this way, both issuesof changing funding of primary care buildings andquality of provision have been recognised asessential.

The LIFT programme has been launched in theUK in 2001 with six first wave local LIFT partner-ships in the areas of Barnsley, Camden and Isling-ton, East London, Newcastle and North Tyneside,Sandwell and Manchester, Salford and Trafford(MaST). This research focuses on the 4 firsttranche schemes developed at the MaST partner-ship.

THE OVERALL VISION AND VALUES FOR LIFTSCHEMES

LIFT has a twofold objective i.e. providing localhealth and social care buildings and catalyse theregeneration of deprived urban areas. Health andsocial care involves a wide range of services, suchas local clinics and GPs surgeries, opticians, den-tistry, ophthalmology, pharmacies, along withsocial services and local authority functions,including libraries. Some of the new facilities willalso include services previously restricted to hos-pitals, such as diagnostic, minor surgery andrehabilitation clinics.

Value generation in a LIFT scheme is linked toa host of different issues. The design of LIFTschemes is challenging as the buildings are inno-vative and complex. Complexities and value liewithin the patient treatment, the need to providetherapeutic environments which are supportive ofthe healing process, and the need for a patient-centred service model (Gesler et al. 2004). Thereare complexities at the functional level of thebuildings and the operating conditions, as differ-ent services need to be delivered jointly, and theservice mix and ways of operation are varied and,in most cases, unknown at the front end. There arealso complexities at the architectural level asschemes need to be aesthetically interesting toattract people to use the facilities, promoting thehealth of the population. Therefore, LIFT aims tocreate a client driven organisation (Whiteley,1991), in which the value of buildings is based onthe needs of clients, building users and those ofthe community as a whole.

Another important concept in LIFT is that of‘value for money’. The government’s procedurefor demonstrating value for money is based on anappraisal that compares the economic costs andbenefits of alternative investment solutions, i.e.the annual cost of a LIFT scheme is summarisedand compared with those of a publicly financedscheme, called the public sector comparator

Product Development

Patricia Tzortzopoulos, Paul Chan, Mike Kagioglou, Rachel Cooper and Erica Dyson 309

(Pollock et al. 2002). In this sense, value is takenas costs, and it includes both initial costs and thoseincurring throughout the life cycle of the facility.Therefore, both economic and the use value (i.e.benefits for users) of buildings throughout timeare considered in LIFT.

THE DESIGN FRONT END FOR MAST LIFTSCHEMES

An overview process map has been developedbased on a combination of the interviewees’descriptions as well as on the analysis of docu-ments (Figure 1). The ‘as-is’ process is contrastedwith front end activities described in the literature.

The new product development literature gener-ally describes 3 front end phases, i.e. idea genera-tion, product concept and product definition andplanning (Cooper, 1994 Zhang and Doll 2001;Van Aken and Nagel 2004). The front end isdefined as the ‘cross-functional strategic, concep-tual and planning activities that typically precedethe detailed design and development of a newproduct’ (Khurana and Rosenthal 2002). It wasassumed that in a construction environment thefront end encompasses all 4 pre-project phases, asproposed in the process protocol (Kagioglou et al.1998).

The successful development of front end activi-ties depends on foundation elements, i.e. defini-tion of a clear the product strategy and setting upthe project organisation (Kurana and Roselthal2002). The product strategy and vision for LIFTschemes were defined both at the national andlocal levels. The overall LIFT strategy was estab-lished nationally. At the MaST level, PrimaryCare Trusts (the clients) developed a documentcalled Strategic Service Development Plan(SSDP), setting out the vision for the schemes in

terms of service requirements (SSDP 2002).However, the specific objectives for each schemewere in reality refined and detailed iterativelyduring the design front end.

The project organisation involved a novelstructure with more than 25 public and privatesector organisations. A strategic partnershipboard (SPB) linking 6 PCTs at the 3 local areaswas set up. In addition, there are a number ofstakeholders involved within each scheme asusers. Stakeholder groups vary from scheme toscheme in number and composition, and the groupmembership varies through time. Due to the com-plexity of the organisation both in nature and size,and to the inexperience of the teams, there waspoor clarity of the organisational structure and ofroles and responsibilities.

Phase zero aims at demonstrating the need forthe project (Kagioglou et al. 1998). In MaST,most activities of this phase were part of theSSDP, i.e. establishing the business case and keyobjectives of the schemes. At this stage there wereuncertainties relating to which schemes would bedeveloped (13 were initially proposed), and theprivate sector partner was unknown. Therefore,part of the clients’ strategic plan, i.e. prioritisationof schemes, was defined during phases 1 and 2.Also, stakeholders were not identified, neitherwas a project execution plan put in place.

Phase 1 focuses on the conception of the need,aiming to identify potential solutions to the needand plan for feasibility (Kagioglou et al. 1998).The preliminary project brief should be developedat this stage. In MaST, phase 1 focused on the def-inition of bidding for the selection of the privatesector partner. As a description of buildingrequirements was necessary for bidding, a consul-tancy company was involved to produce a ‘tenantrequirement’ document. Three to four meetings



Product strategy,Vision (High-level)PfH and SSDP

Project organisation:Structure, roles, Incentives and norms:MAST LIFT board & Selection of preferred private sector partner

Phase zero:Demonstrate the needkey project objectivesBusiness caseclients strategic plan

Phase one:Conception of needRequirements captureinitial specificationsProcurement plan

Phase two:Outline feasibilityRequirements captureOutline feasibility

Phase three:Substantive feasibilityPreliminary design solutionAdvisors input & redesignReview financesRequirements capture

- Detail design

- Construction

- Operations

- Maintenance

Selection ofpreferred

bidder

Specific buildings vision defined as part of the healthcare delivery system redesign

Foundationelements:

Front-end

Figure 1: Design front-end on 1st tranche MaST schemes

per scheme were undertaken with PCTs to estab-lish requirements, and a ‘template’ produced forall 13 schemes. However, as consultation wasineffective the quality of the final document hasbeen criticised, as it was perceived that notenough attention was given to the specifics ofeach scheme.

The goal of phase 2 is to identify a number ofdesign solutions that respond to the project briefand select some to be considered after examiningfeasibility (Barrett and Stanley 1999). Design pro-posals were developed by the bidders with a basison the information described on the (poor) tenantrequirements document. Architects had very littleaccess to the clients, and no access to buildings’users. There was poor information available onsite and environmental issues, and for some of theschemes there was uncertainty with regards to theviability of the selected sites.

Finally, phase 3 should focus on the definitionof the most appropriate design solution for con-cept design development and outline planningapproval. Within MaST, the phase was related todeveloping design sufficiently to allow the finalbidding stage. The phase should also involve arevision of building requirements based on abetter understanding of clients needs. However,while design solutions were proposed by archi-tects, requirements were captured by PCTsthrough user group meetings and open public con-sultations. As a result, requirements were inap-propriately incorporated into the designproposals, partially due to their poor definitionand partially due to pressures from the biddingprocess.

An architectural advisor was also involved toassess design quality, and changes in designs wereintroduced as a result of his feedback. However,client representatives were unaware of the archi-tectural advisor’s involvement, and there was aperception that the advisors comments did notconsider the decisions made at user group meet-ings, in which requirements were established.Therefore, wasteful redesign occurred. The poormanagement of the design front-end had a numberof consequences, discussed as follows.

INFLUENCES OF PROCUREMENT OVER DESIGNMANAGEMENT

A number of design management problems hap-pened during the development of the 1st tranche ofMaST schemes, some of which were caused bythe procurement strategy adopted, more specifi-cally the bidding process though which the privatesector partner was selected. The timescales for thefront end, determined by the bidding timescales,were inappropriate. Bidding timescales were

determined nationally, without considering thefact that PCTs needed time both to get familiar-ised with the construction process and also to con-duct healthcare service redesign activities.

Furthermore, there was a lack of clarity of whois responsible for managing design and require-ments. The PCTs inexperience with regards to thedesign and construction was well known. There-fore, it was expected that the private partnerwould support the client in understanding con-struction and managing the design front-end.However, the private sector partner was selectedafter the design front end happened. Conse-quently, PCTs were responsible for developingdesign activities, i.e. capturing and managingrequirements and dealing with land informa-tion/selection, and did not have the necessaryexpertise or support to do so. As a result, there wasa lack of clarity on requirements at the front endand also throughout design development, whichled to a number of design changes.

After the selection of the private sector partner,design management responsibility was owned bythe contractors, who are part of a joint venture i.e.Excellcare. However, it was identified that thecontractors did not have the necessary skills tomanage design, and that architects were notempowered to do so. Therefore, interviewees per-ceived that design management should have beenresponsibility of a higher level. On the other hand,contractors stated that an appropriate design briefand land information should have been madeavailable at the beginning of the process, but thatactually did not happened due to the difficultiesPCTs were having with requirements. There is ageneral perception that no one was involved fromthe beginning of the process neither to protect theinterests of the buildings’ users nor to observe ifclients and users were getting what they needed.

EFFECTS OF POOR DESIGN MANAGEMENTOVER VALUE GENERATION

The poor definition of the design management’srole and of who was responsible for it had conse-quences throughout the process. Firstly, require-ments management was inconsistent and therewas no audit trail for changes in requirements. Itwas perceived that there was no appropriate own-ership and control over requirements, as thesewere managed partially by the PCTs, and partiallyby the contractors’ design managers. Require-ments gathered and decisions made in PCT usergroup meetings were not appropriately registered,and not all requirements were identified at thefront end. Also, requirements were not ranked northe ability to deliver properly analysed.

Product Development


Secondly, designers did not appropriately con-sider requirements in design development. Thismay be due to the lack of clarity and constantchanges in requirements. Also, as there was noappropriate design brief for the schemes, therewere also no criteria available to analyse design.Thirdly, changes in requirements have been dealtdirectly by the architects and requests from userswere generally included in design without consid-ering affordability or the effects that the changeshad in terms of time delays or costs. Fourthly,PCTs faced difficulties with signing off require-ments and designs. Requirements should havebeen signed off at the front end but this never hap-pened due to constant changes of needs and alsoof the stakeholders involved.

Finally, there was a lack of strategic integrationbetween high-level LIFT health vision and theschemes being delivered. There were a number oftime consuming interactions during design,responding to changes in requirements whichwere not mature O’Brien and Smith, 1995), gen-erating major unnecessary design rework. thequality of the designs developed at the front-endwas perceived to be poor, leading to extensiveredesign after the selection of the preferredbidder, which makes explicit the large incidenceof non value adding activities. Changes wereintroduced in design to respond to a ‘wish list’which changed constantly, instead of respondingto a coherent set of clients and users requirements.This situation happened also throughout detaildesign development. Finally, redesign led to pro-

cess delays, i.e. more than one year delay to reachfinancial close for the 4 schemes.

DISCUSSION: RESEARCH HYPOTHESIS

In order to test the proposed research hypothesis,design management issues identified in the casestudy were linked to the problems proposed in theliterature within each one of the views. These aredescribed in Table 1.

A cognitive map was then developed to identifythe causal links between issues related to each ofthe views on design. The map is presented inFigure 2; shadowed rectangles represent transfor-mation related problems, ovals represent flowrelated issues, and rectangles represent valueissues. The central concepts on the map (i.e. con-cepts with a greater number of links) were identi-fied as being the poor definition of requirements,the inadequate brief, the poor identification ofstakeholders and excessive changes.

The poor definition of requirements is a valuerelated issue (V) which has had consequencesover other value issues i.e. it led to an inadequateproject brief, which resulted in design proposalsnot appropriately considering requirements. Thepoor definition of requirements has also generatedproblems from a flow perspective (F), i.e. unnec-essary redesign occurred due to the poor consider-ation of requirements. Also, long project durationand delays (T) occurred as a consequence of nonvalue adding interactions (F), which happeneddue to the poor definition of requirements (V).



Figure 2: Cognitive map describing links between transformations, flow and value issues at MaST

Product Development


Problems in the literature Case study problems

Decomposition is not sufficient to understand / improvedesign6

Short timescales for front end

Poor definition of roles

Poor identification of stakeholders

Poor definition of design management

Design management at the wrong organisational level

No ownership over requirements

Non value adding activities are not explicitly represented6,7 Not enough time for needs analysis and to generatesolutions

Long duration and not enough time to generate solutions

Lack of process visibility—activities were unknown tostakeholders

Long duration and delays

Partial design, from the point of view of one discipline only6 Segmented work: requirements and design developed bydifferent groups

Changes in requirementsExcessive changes of requirements

Business strategy unclear with evolving healthcare needs

Effort to transfer information Transfer of information ineffective

Time consuming or insufficient interactions to improvedesign7 Time consuming non value adding interactions

Uncertainty due to lack of definite information6,8 Uncertainty due to lack of definite information (req. and site)

Uncertainty due to lack of decision

Unclear project strategy

Complex decision making process at client organisation

Failure to record and stick to early decisions

Rework caused by design errors7 Rework caused by design errors detected in latter phases

Transfer of information Poor understanding of LIFT vision at lower levels

Waiting of information8 Waiting for customer decisions

Unnecessary work

Unnecessary redesign due to poor requirements maturity

Changes in design not considering requirements, leading tounnecessary redesign

Assumptions on affordability not checked prior to (re) design

Design is not conceptually related to its costumers Customer integrated but with poor understanding of whostakeholders were and who should make decisions

Not all needs are identified in the beginning of the processPoor understanding of LIFT vision at lower levels

Poor identification/definition/ understanding of requirements

Missing or evolving requirementsInadequate brief

No ranking of stakeholders or requirements

Loss of requirementsNo alternative concepts defined before design development

Designs not appropriately considering requirements

Table 1: Management problems related to each of the three views on designT

rans

form

atio

nF

low

sof

info

rmat

ion

Val

uege

nera

tion

6 Koskela, 20007 Huovila et al. 19978 Reinerstein 1997

Similarly, the inadequate project brief (V) ledto immature requirements being incorporated inthe designs (V). Consequently, clients had diffi-culties in sticking to early decisions (F), which ledto excessive changes both in requirements and inthe design (F). As a result, the LIFT overall visionwas not appropriately incorporated in the finaldesigns (V).

Furthermore, the poor identification of stake-holders, a transformation (T) related issue, hadvalue consequences in terms of obstructing theranking of stakeholders and ranking of require-ments importance (V). Finally, poor design man-agement (T) had consequences in terms oftransformation, flow and value issues. Poor man-agement of the design process led to segmentedwork (T), i.e. architects designing and clientsgathering requirements in isolation, which influ-enced an ineffective flow of information, i.e.designers were not aware of all changes inrequirements (F), and consequently designs didnot consider requirements (V).

In summary, the analysis of the cognitive mapmakes the causal relationships between issuesrelated to each one of the views clear. The mapdescribes the mismanagement of transformationissues leading to problems from both value andflow perspectives (T�V�F). It also describesmismanagement from a value perspective leadingto flow and transformation problems (V�F�T).The mismanagement of flow issues was also iden-tified as impinging problems from a transforma-tion and value perspectives (F�T�V). There arealso causal links within each view, i.e. misman-agement of transformation generating transforma-tion problems, mismanagement of flow leading toflow problems, and mismanagement of valueleading to value generation problems. Figure 3attempts to graphically describe the dynamicinteractions between the views.

Therefore, the case study results provide sup-port for the proposed hypothesis, i.e. the unsuc-

cessful management of design from one of theviews resulted in problems in one or more of theother views. However, more empirical evidence isnecessary to confirm that similar links betweenthe views occur in different environments, forinstance by analysing the design front end devel-oped under different procurement frameworks(such as PFI) and for different types of projects(e.g. schools).

Based on the results here presented, a questioncould be posed. If one consider that the causallinks between failure in appropriately managingdesign from one view really leads to problemswithin that view AND also the other views, onemay question H1 (Transparency of the designprocess from one view, achieved through explicitmodelling and other means, is conductive to asuccessful outcome from that view). It may be thecase that even though one appropriately managesdesign from one view, problems within that viewwould occur due to the mismanagement of theother views. This actually supports the need forintegration of the management needs from each ofthe views.

Similarly, the use of systematic methodologiesto manage the design process would only be effec-tive if such methodologies holistically approachall the three views. It may well be the case thatsuch methodologies need to recognise the differ-ent nature of the different design activities andstages, proposing appropriate managerial regimesfor activities with a different nature. For instance,the more uncertain, creative activities (e.g. ideageneration, concept definition) should be looselymanaged so that the creativity and serendipitynecessary for innovation can occur, while the lessuncertain activities (e.g. selection of alternativesolutions) should be developed under moreformal managerial regimes by adopting, forinstance, the ideas of flexible gates (Van Akenand Nagel, 2004).

Finally, the results here proposed provide indic-ative support for H4 (For achieving a successfuloutcome of design from one view, orderly man-agement of design from the other two views is nec-essary). Assuming that the mismanagement fromone view leads to problems in the other views, allviews need to be appropriately managed. How-ever, it may be the case that success is notachieved even though all views are appropriatelymanaged. There is an assumption that cause andeffect relationships can always be identified.However, in reality it is the pattern forming thatshould be considered and cause and effect rela-tionships cannot be identified apart fromhindsight.



Boundaries

Boundaries

Boundaries

T

F

V

Figure 3: Dynamic design interactions framework

CONCLUSIONS

This paper reported research results from a casestudy examining the front end of the design pro-cess in the development of four primaryhealthcare facilities based on lean principles.Results describe the front end process and prob-lems that occurred due to the mismanagement ofdesign from a transformation, flow and value gen-eration perspective. A research hypothesis hasbeen tested, in which it has been demonstratedthat the mismanagement of design from one per-spective conducted to problems from the otherperspectives.

More empirical research is needed to validate,better understand and extend the conceptualframework here discussed. The model presentedin Figure 3 needs further development, and somequestions are put forward for further investiga-tion, i.e. (a) what are the boundaries between thethree views, and are they flexible or not; (b) arethere design activities not explicitly linked to anyof the views, and therefore under an ‘unclassified’area? (c) what are the contextual characteristicsrelated to such activities? (d) how one could placeactivities within the right categories/views? (e) docyclical design activities change domains (e.g.F�V) throughout time?

ACKNOWLEDGEMENTS

The research reported in this paper was carried outin the Salford Centre for Research and Innovationin the Built and Human Environment (SCRI),University of Salford. SCRI is an EPSRC fundedIMRC centre. The authors would like to acknowl-edge the support for this research from all theinterviewees involved in MaST LITF projects.

REFERENCES

Ballard G. and Koskela, L. (1998). “On theagenda of design management research.” Pro-ceedings of the 6th annual conference of theInternational Group for Lean Construction,Guaruja, Brazil.

Barrett, Peter and Stanley, Catherine (1999).“Better Construction Briefing”. BlackwellScience. UK. 157p.

Cooper, R. and Kleinschmidt, E. (1996). “Win-ning Businesses in new product development:the critical success factors”. Research Tech-nology Management, 39 (4) 18–29

Cooper, R.G. (1994). “Third-Generation NewProduct Processes”. Journal of Product Inno-vation Management, 11 3–14.

Darlington, M.J. and Culley, S.J. (2004). “Amodel of factors influencing the designrequirement”. Design Studies, 25 329–350

DOH (1998). “Modernising healthcare and socialservices: national priorities guidance1990/2000–2001/2002”. Department ofHealth Publications. September 1998

Gesler, W.; Bell, M.; Curtis, S.; Hubbard, P.;Francis, S. (2004). “Therapy by design: evalu-ating the UK hospital building program”.Health and Place, 10 117–128

Huovila, P.; Koskela, L.; Lautanala, M. (1997).“Fast or Concurrent: The Art of Getting Con-struction Improved.” In: Lean Construction,Ed. by Alarcón, L. pp. 143–160

Kagioglou, M. Cooper, R. Aouad, G. Hinks, J.Sexton, M. Sheath, D. (1998). “Final Report:Generic Design and Construction ProcessProtocol”. University of Salford.

Khurana, A.; Rosenthal, S.R. (2002). “Integratingthe fuzzy front end of new product develop-ment”. In: Roberts E.B. (ed) Innovation: Driv-ing product, process, and market change. MITSloan Management Review pp 47–85

Koskela, L., Ballard, G., Tanhuanpää, V. (1997).“Towards lean design management.” In: Pro-ceedings of the 5th Annual Conference of theInternational Group for Lean ConstructionIGLC-5. Gold Coast, Australia, 16–17 July,pp. 1–12

Miles, M. B. & Huberman, A. M. (1994). “Quali-tative Data analysis. An Expandedsourcebook”. California: Sage Publications.

Mohan, J. (2000) “Planning, Markets and hospi-tals”. Routledge, London.

O’Brien C. and Smith S. (1995). “Design maturityassessment for concurrent engineering co-ordination”. International Journal of Produc-tion Economics, 41(1) 311–320

Pollock, A.M., Shaoul, J., Vickers, N. (2002).“Private finance and ‘value for money’ inNHS hospitals: a policy in search for a ratio-nale?” BMJ 324, 1205–1209 available atBMJ.com

Reinertsen, D. (1997). “Managing the design fac-tory: a product developer toolkit”. The FreePress, New York, 269p.

Rodhain, F. (1999). “Tacit to explicit: transform-ing knowledge through cognitive mapping—an experiment”. Proceedings of the 1999ACM SIGCPR Conference, New-Orleans,Louisiana, USA, April 8–10, pp.51–56.

SSDP (2002). “A Strategic Service developmentPlan for Health Services”. Manchester,Salford and Trafford LIFT, April 2002. NHSpublication.

Van Aken, J.E. and Nagel, A.P. (2004). “Organis-ing and managing the fuzzy front end of new

Product Development


product development”. Eindhoven centre forinnovation studies. Working paper 04.12,Technische Universiteit Eindhoven, TheNetherlands.

Whiteley, R.C. (1991). “The customer drivencompany”. Business Books, 308p.

Womack, J. P., Jones, D. T. (2003). “Lean Think-ing: Banish Waste and Create Wealth in YourCorporation”, Revised and Updated. London;New York : Free Press : Simon & Schuster.

Zhang, Q. and Doll, W.J. (2001). “The fuzzy frontend and success of new product development:a causal model”. European Journal of Innova-tion Management, 4(2) 95–112



Interactions between transformations, flow and value at the design front-end for Primary Healthcare...

Documents

Transcript of Interactions between transformations, flow and value at the design front-end for Primary Healthcare...