Whenever a new project starts, the client is excited about the prospect of a new unit or building designed for them. So much so that I sometimes think the clinicians might show up to the first meeting ready to swing a hammer or pour some concrete as though they were starting a home improvement project. But at times that initial surge of excitement and energy on the project is tempered by the information-gathering part of the design process.
In conventional design approaches, one of the most tedious parts of that initial phase is developing the program document for the project. Rather than looking at plans and discussing OR expansions or making private patient rooms, we instead focus on the nemesis of architects and clinicians everywhere, an Excel spreadsheet.
This spreadsheet becomes the focus of the next three or four meetings for each department. During each meeting, the teams review the program line-by-line to determine the size and quantity of every room type that could exist in the project. This seemingly-endless spreadsheet is usually met with blank stares from all involved. The monotonous nature of these meetings makes them feel like each one is days long rather than a couple of hours. By the end of the process, we have a document that lists every necessary space and a preliminary understanding of the size of these spaces, but very little information about the desired arrangement of and relationships between these elements.
Grossing factors are then applied to these totals to account for things like corridors and wall thicknesses, producing an educated and still preliminary estimate of the area needed for a given department. However, even then the document serves only as a guideline. Room sizes can vary greatly from the program document, or spaces might consolidate once the plan begins to develop and equipment lists are created.
Further complicating the process, architects tend to talk about spaces in terms of room area or square footage (SF). This creates confusion, as the clinical team often has trouble translating just how large or small a 100 SF space is. I cannot even begin to count the number of conversations I have had with user groups with questions like:
“How large is a typical office? 500 SF?”
“80 SF for the Pyxis equipment seems way too big, can we cut that in half?”
“The room that we have now works for us, can’t you just make it the same size?”
These questions are typically responded to by counting ceiling tiles and trying to gesture where walls would be that represent the space. This is hardly a precise way of making important decisions in the earliest stages of the project.
In the past few years, there have been many attempts to make the programming process (to put it kindly) less cumbersome. Two of the more intriguing ideas have been “visual programming” and “component-driven programming”. Visual programming uses a graphic representation of program elements to frame discussions of space instead of those mind-numbing spreadsheets. There is still a reconciliation needed between the visual program and the spreadsheet program, since the two documents don’t often connect with the other. The other concept, component-driven programming, changes the discussion of what things are needed in a given room and the space to access them.
This gives everyone a common foundation to start from when sizing a room. For example, not everyone may understand how large or small a nourishment room is at 110 SF, but if that room is defined by saying it needs a refrigerator (18 SF), sink (16 SF), Ice Machine (20 SF), a 6' work counter with storage cabinets above and below the counter (36 SF), and space for the food tray cart (20 SF); it becomes much easier for everyone to feel comfortable with that same 110 SF area.
On a recent project at Rochester General Hospital, Array partnered with Clark Patterson Lee and were able to incorporate both concepts in the programming meetings with great success. We used a relatively new web-based software, Archetris Schema, which was developed with visual programming in mind. It solves the disconnect between the spreadsheet format of the space program and the graphic representation because it uses a single database to generate both documents. As changes are made to the tabular representation of the space program, the graphic representation updates to match. This allows a co-presenter to add, remove or modify the size of each of the various room types on their computer during the meeting, which in turn changes the elements everyone sees in the projected presentation, all in direct response to the discussions being had with the clinical team. These diagrams were used to conceptualize the entire department as we defined each space’s requirements, and gave us a background to have a high-level discussion about the flows within each department.
The other advantage that Schema gave us, was that the visual programming elements were all scaled relative to each other. Being able to graphically see that one patient room was the same size as three manager offices really changed the conversations we were having. By color-coding the visual program into space usage (patient care, staff workspaces, diagnostic and clinical spaces, administrative areas, etc.), these distinctions became more apparent and helped the user groups to immediately identify that some aspects of their program were disproportionate to others.
This changed the way I led the meetings as well. Instead of organizing the meetings based on the sequence of the space program document—admittedly an indiscriminate, though logical, process - the conversations transitioned to spatial adjacencies and creation of work cells, for example, 12 inpatient rooms or 16 pre-/post-operative holding bays. Then those work cell definitions led to conversations about what was necessary to be in each work cell (team centers, supply rooms, and medication rooms, etc.) and what could be shared between work cells (staff lounges, call rooms and soiled holding rooms, etc.).
Previously these conversations happened after the space program was more developed, rarely at the first meeting. With these new concepts in place, we had some understanding of the program requirements as well as a concept of how the department should be organized by the end of the first meeting. This allowed us to discuss additional rooms, and start to arrange the diagrams to be closer to the final form of the building in the second meeting. Using a traditional spreadsheet and concept design model, we would have needed four or five meetings to have a similar result.
Another useful feature in Schema is that it allows us to size rooms either by direct definition or by defining the components within a room. This enabled us to use component-driven programming in our conversations with the users, which changed how we discussed the size of key rooms. We could ask questions such as:
“How many shelving units would you need in your supply room?”
“Would you want to keep your IV supplies? With the meds or with your clean supplies?”
“Where are your ventilators stored on the unit?”
How those questions were answered by the clinical team gave us the information to update the room size by adding, removing or modifying the various components in each room. As we updated the space program, the users could see the make-up of the department flex in response. Using the manufacturer’s dimensions and adding space to walk up to the object, the space program would better reflect the actual needs for each space.
That’s not to say there weren’t bumps in the road. Like nearly every project, there’s always some degree of program or scope creep. There were some departments that, after envisioning their ideal new care model, needed significantly more space than could be accommodated by either the building or the budget. However, using visual and component-based programming strategies, we identified these problems earlier, allowing the steering committee to respond sooner, thus reducing the impact on the schedule and budget.
While I don’t think program development will become everyone’s favorite phase of a project, using visual and component-driven programming does make the process more engaging and allows everyone involved to have a better understanding of the project’s requirements early on. If these concepts make the programming phase more bearable and save time in the overall schedule, I’ll consider that a victory in itself.
However, with changes to the programming process coupled with other improvements already integrated into our design process—empathy mapping, process/gemba mapping, using meeting account A3s and re-envisioning our overall design process (Discovery, Analysis, Creation and Solution phases)—it is apparent that Array has created a culture where we are constantly looking for ways to improve both our project outcomes and the processes we use to get there.
Blog written by Dan Russell, former principal and planner for Array.
