Your project began a while ago. Remember?

You asked your client 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. They told you how they'd 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 they 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 to your client). But you pushed for answers.

Everyone was glad when it was over, and you began to create renderings and samples of what the newly designed space would look like and how it would solve the problem your client 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 was 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 second-grader at the time, 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 finally picking up speed.

Designs were created, then recreated, and recently there was a meeting. Parents and local residents were invited. I now have a daughter in her fourth year at university and a high school senior. 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 2016, with many turf fields already installed, we are beginning to learn there are some good reasons to question the use of turf.

And in 2016 we have a whole new set of stakeholders — both student athletes and their parents who have never been part of the turf-versus-grass conversation. Some of them do not want a turf field, and some of them (including me) spoke up at the meeting.

Changing the project from a turf field to grass would require a complete redesign, and resulting additional delays, for the project. The room got very quiet.

So who dropped the ball? Why did no one review the program with current stakeholders?

Begin again

There are many reasons to revisit 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. As a part of the architectural team, you should drive review of programming data.

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 outdated, then reprogram 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 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 they must satisfy the needs of current stakeholders. This means getting that first step programming right. No matter how many times that step must be revisited.

A multimillion-dollar construction project (or any project for that matter) that does not fulfill the needs of its stakeholders is a costly mistake. If you want your clients to trust you and to hire you again, don't let them make this mistake.