![]() "30% of all projects are cancelled, nearly half come in over budget, 60% are considered failures by the organizations that initiated them, and nine out of ten come in late." These statistics apply to the development of computer software; but they feel just about right for building projects, too. In both kinds of projects the traditional methodology has been a "waterfall" model. One phase follows another in a sequential process. The hidden defect in this approach is that the millions of decisions that must be made throughout the course of even a small project are hard to anticipate in the earliest phase. So as each succeeding phase tries to build upon past decisions there is a tendency to cobble together a compromise that allows the process to move forward. Often you reach a point where this doesn't work, and then it's back to the drawing board. With this in mind it is easy to see why the statistics above are so grim. What is needed is a process that creates a touchstone for dealing with those millions of decisions. That touchstone is Planning. Planning is the much-overlooked initial phase of a project. Done properly, Planning sets the criteria by which to judge the success of the project. So, this same criteria guides you in making those millions of decisions. Planning amounts to a thorough evaluation of the six key issues that every project faces. Approached this way Planning will develop a complete description of what the project needs to achieve. Planning is a service that your client needs before embarking on design and one that will differentiate you from other firms. Those six key issues are
Separating an existing building from a new addition by a firewall always (it seems) has unanticipated consequences. This refers to a true firewall rather than a fire separation wall. No matter how hard you try, there is always a surprise waiting for you. Technically a firewall must be able to remain standing after the collapse of the structure on either side. This means that the wall cannot help support that structure. A favored way around this is to use two walls, each supporting the structure that is on its side. This approach triggers the need for two fire doors at each opening, one in each wall. Two doors creates all kind of collateral issues, and usually results in a vestibule to separate the doors, which in turn is fire-rated construction. The alternative is to use a free-standing firewall, which is basically a cantilevered wall anchored in its footing. Engineers tend to over-react to this situation. Maybe they should. The two drawings below show how complicated the situation can become. Click the images to download a PDF for easier viewing; or download Plans here and Sections here. We used single, self-supporting firewalls where we had to pass through the firewall. Elsewhere we resorted to the double-wall solution to avoid the underpinning required by the single wall.
The problem with a single wall that is braced by the construction on each side is that a collapsing building creates a wind load on the wall. There are ways to anchor the wall to resist the wind load; and there are ways to let the structure fall away. There just aren't any good ways of doing both on both sides of the same firewall. If your code official knows this, ... ![]() If you are designing an addition to a complicated, large building that pre-dates modern codes, you might be asked to prove that exits are adequate. The method that worked for us in this scenario was this: show the results of our calculations on a floor plan by giving the occupant load of each space, the capacity of corridors and stairs, and the capacity of the exit doors. See the enlargeable legend to the left. The building in question had six different levels including a basement and a 'mezzanine'. Previous additions had also obscured the exit strategy. The drawing below is downloadable as a PDF for better viewing. The first effort was a table to show all this information but it was impossible to follow. Once we hit on this diagrammatic approach, we had the extra benefit that the code official could spot check us very easily. The result was that the plan was accepted once we reviewed the process and how to interpret the diagram. The original diagram was also color-coded by hand to show where the numbers came from. A color plotter would have eliminated that work. ![]() This is a listing of the Apps that I use continually and that you might find useful. This first appeared in February 2013 and just four months later needs an update. Apps at the top of their group are most useful, I find, but that is personal. Text in red indicates an addition to the listings. Several links have been added to articles about some of the apps. All of these are found in the Apple App Store. Most are free. Some of these apps are offered free periodically through an app called AppsGoneFree! If you have any comments enter them below and I will answer by comment. These apps make it easy to work wherever the mood takes you. Photo-related:
Miscellaneous:
![]() This Post Is Obsolete. But Wait. Although 'Basecamp Personal' no longer exists, use Basecamp3 instead in the same way described below. You get one free project. Unlimited members. When this gets hard to manage, the paid account is now just $29/mo for unlimited projects. Or stay free by using Trello™. 'Basecamp Personal' is a scaled-down version of the full Basecamp web application created by 37signals. The main differences with the full version are that you only have one project, you are limited to 5 users, and you only pay a one-time charge of $25. All the other Basecamp versions have monthly subscriptions, multiple projects and unlimited users. Currently you have to be a Basecamp user to purchase Basecamp Personal, but it seems as though 37signals plans to remove this restriction. If you aren't a user now, I think you will be able to get Basecamp Personal soon.
Our project ID convention is to use 3-4 letters in "stock call letter format" (you know AAPL for Apple) to represent the client's name. This is followed by a dash and another 3-4 letters that represent the initial letters of the project name, e.g. FAX = Fine Arts Expansion. (We used an 'X' here instead of an 'E' ... just because.)
The upshot is that we have have most of the benefits of Basecamp for just a one-time cost of $25. Keep your fingers crossed that 37signals opens up the availability to the public. ![]() "Style Book - About Us" - revised in case the embedded document didn't work for you. Office Handbooks can be a big waste of time. The bigger they are the less likely they will be consulted. Once you set policy, you are responsible for enforcing it. Bleah! In our office Style Book (IntraNet). we opted for an About Us page containing expectations. See what you think... Download About Us here. ![]() These are the administration issues your new firm will need to consider. I list them below with my take on what a new firm might consider or the decision that is needed. This is the last article in the series. ADMINISTRATION Policies - plenty of time to address this. Deal with policies when needed. See our 6 page About Us article. Facility - working from home is how many firms started with their first moonlighting job. Delay the expense of office rent as long as possible. See our 'Why Do Architects Need An Office?' article. Consultants - no need to look elsewhere than the consultants your employer has used and that you are familiar with. However, go elsewhere if there will be weirdness. See our 'Guidelines For Working With Consultants' series of articles. Insurance - three things trigger the need for insurance: 1] an office ($500 min), 2] employees ($500 min), 3] desire for risk mitigation or a client requirement for professional liability insurance ($1,000 min). Staffing - plenty of architects have a one-person practice, so it is not a forgone conclusion that you will need employees. If you do need help, the choice is Contract Employees or Regular Employees. A contract employee may seem expensive, but a regular employee triggers a number of other expenses, like payroll preparation, workers comp insurance, an office, computers and software and so on. Delay the regular employee choice as long as you reasonably can without creating other problems. Find help that is more capable than you actually need. The greener the employee, the more time you will have to spend with them, which may defeat the whole point of having an employee. Form of Ownership - nowadays I suspect that nobody uses a pure partnership or a professional services corporation because the limited liability corporations forms seem to have taken over. In most states, the LLC doesn't really provide any or much of a liability shield for an architect. You will want to incorporate either for tax reasons or for multiple owner reasons. Neither are going to be an issue for the first few years. Continuous Improvement - take two hours a month to document what is working and what isn't and brainstorm some action steps you can take to make your processes better. Take a look at our 'Do You Have Unique Methods?' article. Benefits - this is only an issue when you have regular employees. Be creative, implement mostly non-financial benefits where you can. Benefits raise your overhead all the time, good times and bad times. Compensation - find good people and pay them what they are worth. These are exciting times. The mega-firms dominate. But every day you can read about a new tool or technology that lets the small firm provide a service that wasn't possible for the big firm just five years ago. I think the big firms are Goliaths, very vulnerable to the niche-oriented small firm. LINKS TO OTHER ARTICLES IN THE SERIES
PART 1 - PROJECTS & BUSINESS DEVELOPMENT PART 2 - MARKETING PART 3 - SALES PART 4 - FINANCIAL MATTERS PART 5 - ADMINISTRATION |
x
Archives
September 2023
Categories
All
|
Architekwiki | Architect's Resource | Greater Cincinnati
© 2012-2022 Architekwiki
© 2012-2022 Architekwiki