My Project Development Philosophy
Everyone has their own way of looking at how it’s best to develop a project from an idea through construction. It can vary quite a bit depending purely on the type, size, and location of the project, but generally, I’ve found the way of thinking that I’m going to get into here, to be very effective.
Very often Owners haven’t put many buildings together, so an analogy can help connect the dots and frame what we are prioritizing first and why, as we move through the project.
Writing:
Writing can be a good comparison, because most people have written more papers than they have built buildings. This is an analogy I also use with students when I teach design studios, since they are in school and probably have a paper they are currently working on.
The basic structure is to start with an idea or topic, brainstorming to develop the wide-view perspective, boiling it down to a thesis and/ or outline, and then a series of drafts that become more and more polished as you move along.
This is something that most of us grew up doing, and it makes intuitive sense, because how could you expect to worry about perfect punctuation without having something worth polishing?
Films:
Another analogy that I think is even more relevant to my particular way of working is making a film. I like Quentin Tarantino, and if you look at his IMDB credits, he is cited in pretty much every role you can imagine, including actor, director, producer, editor, cinematographer, etc.
The one consistent aspect of his work, as it’s grown in scale and ambition, is that he is still the one writing the script. He may have famously started at a movie rental shop and doing all the tasks of early films himself, but to execute movies at the scale that he’s been working takes a much larger team to set up, work the cameras, deal with the sound, edit, and get actors whatever it is that they might want…
At this point, he even shows the movies in his own theatre, and reviews old movies they show, so he seems to have covered the entire lifecycle of a film, in his career.
Commonalities:
The common and key aspect to me, in these analogies, is the outline and the script. If you can get those things right, you have a chance of making something remarkable.
You can still screw it up, but the goal is to have a starting point to work from that’s intriguing, has depth to explore further, but is simple and direct enough to remain intact as you move forward.
My Project Development Philosophy:
To apply this way of thinking to my own work, I’ve realized over the years that I’m more effective at working directly with project Owners and stakeholders to boil down information, and get to the core of an idea. The part that is clear and powerful enough to persist, and won’t get eroded and disappear as you inevitably deal with the technical requirements and budget tightening that will occur every project.
If you can get that core idea correct, and translate it into an early design that everyone can get behind (or a screenplay in this analogy), that’s the thing that you can point to, and hold onto as you move forward to organize and build a much larger team, and spend a lot more money.
One way to look at that is to think, if I look at this early design, it should still look like the final project if you just squint your eyes a little bit. There’s a lot to figure out, but the “bones” of the project should be there.
“People who can focus, get things done. People who can prioritize, get the right things done.” - John Maeda
My personal development process is outlined in this diagram below. I focus on the initial stages with my “Launch” design packages and “Boost” workshops, because I’ve realized through my practice, that I can help people most in these phases. From there, I either hand this design (or “script”) to the Owner to move forward with, or I assist building and managing teams directly with the Owner, to document and build.
Our initial “Boost” and “Launch” programs are the foundation for the rest of the project, when you’re ready to hit the gas.
The most critical for me is to front load as much of this analysis, testing, and visualization into the early phases, specifically with the key team. Get the core right, develop it, look at the early designs, and commit to it.
When things change after this moment, the results can be truly catastrophic.
I’ve been involved in projects that introduce massive change at the wrong moment, and I’ve seen some of them fail as a result. At best, it will lead to delays and blown budgets because it would be like trying to stop a ship that has momentum, and it just isn’t an easy or quick thing to do.
There will be uncertainty as you work out the details over the next months or years, but you have to trust that barring a life-changing “event” of some sort, the core idea that you developed was, and still is, the right one.
We can use historical data and experience to help predict and estimate things like budgets and schedules, but to expect a fully detailed budget at the beginning of a project would be like expecting a rough draft to be not only compelling, but grammatically perfect, and that’s not the point of a draft.
It would slow you down to a crawl.
Thank you for reading,
-Chris
Please consider joining my mailing list, for weekly posts like this one.
P.S. I offer a Project: Launch program to help get things going quickly, if you’re ready to go! If you’re interested in this process, please reach out to talk. I’m always looking to meet good people and learn about interesting businesses.
