program it again!

construction2

the beginning

Your project began a while ago. Remember? Your architectural team asked you a lot of questions, probably using some version of a questionnaire that was distributed to the many stakeholders involved in your project. There were interviews and meetings. You told them how you would be using the designed space, who would be using the space, when the space would be used and by how many, what time of day the space would be used, what you wanted the space to look, feel, sound like. And probably a whole lot more. This was called programming and it was a bit grueling and probably kind of boring. But your architectural team pushed for answers. You were glad when it was over and you began to see renderings and samples of what your newly designed space would look like and how it would solve the problem you needed solved. You felt the adrenaline rise anticipating the completion of your project.

delays

Then there were delays. Maybe the project would cost more than you had budgeted. Or your local jurisdiction had some issues that took months, or even years, to resolve. Maybe there were stakeholders who weren’t happy with the current design which resulted in a redesign, and maybe another. Perhaps the stakeholders changed and new stakeholders had questions that hadn’t yet been resolved. There are more reasons for delays than there are for projects to begin and complete on time…expect delays.

for example

I might be the most unpopular parent in my local school district right now. Sometime around 2002 our district began planning for a new outdoor stadium at the high school. With a toddler and a 2nd grader, this was way off my radar. One delay apparently led to another, and construction has not yet begun on the stadium project. This year the bond measures needed to finance the project passed and the project is now picking up speed. Designs were created, then re-created and last week there was a meeting. Parents and local residents were invited. I now have a daughter in her third year at university and a high school junior. I attended the meeting.

One of the main goals of the project has always been to build a field that could be used year round. In 2002 artificial turf was deemed the best solution. In 2015, with many turf fields already installed, we are beginning to learn there are some very good reasons to question the use of turf. And in 2015 we have a whole new set of stakeholders, both student athletes and their parents, who have never been part of the turf vs. grass conversation. Some of them do not want a turf field, and some of them (me) spoke up at the meeting. The room got very quiet. Changing the project from a turf field to grass would require a complete re-design, and resulting additional delays, for the project. So who dropped the ball?

begin again

There are many reasons to re-visit the programming stage of a project. The two greatest reasons are the passage of time and a significant change in stakeholders. Both were at play in the example that made me the least liked parent in town. Your architectural team should drive review of programming data, but if they don’t, it is up to you.

passage of time

If your project is delayed for any reason, and the delay extends long enough that data already collected might significantly change, needs might change, or the use of the project might change, then programming should be revisited. Was your project programmed more than a year ago without forward movement in design and construction? Then someone on your project team should review the programming data and verify the data’s current accuracy. If there is the possibility that it has become out-of-date, then re-program the project. If, as in the case above, millions of dollars are at stake, it is worth a few weeks (or even months) to verify that the project is built to fulfill current needs.

change in stakeholders

Has the delay resulted in a significant change in stakeholders? In a high school situation, there is an entirely new generation of stakeholders every four years. And partial turnover every year. This is an important consideration when programming a project in this arena. Even in business, there is turnover of stakeholders over time. At the beginning of the project a list of stakeholders should be created (not necessarily by name, but certainly by position). If delays result in a significant change in these stakeholders, then conduct programming again with the new stakeholders.

do it right

Sometimes doing it right means programming more than once. Construction projects are expensive and to be successful must satisfy the needs of current stakeholders. This means getting that first step, programming, right. No matter how many times that step must be re-visited. A multi million dollar construction project (any project for that matter), that does not fulfill the needs of its stakeholders is a very costly mistake.

A construction project that does not fulfill the needs of its stakeholders is a very costly mistake. Click To Tweet

Keep in touch,
Leslie

If you are interested in the research I’ve done into artificial turf, email me. I didn’t include that information here as it is outside the scope of this article. Just be warned, it probably won’t make you any more popular than it made me!

1 reply

Trackbacks & Pingbacks

  1. […] design project begins with a program. Every failed project usually can be traced back to poor programming. This is your first […]

Comments are closed.