Needs analysis and project scope

The college library project begins with a kickoff meeting in a borrowed classroom. The college's facilities director wants to know how big the telecommunications rooms must be so that the architect can finish the floor plans. The head librarian wants wireless that works everywhere and enough outlets for a maker space. The IT manager wants the new building tied into the campus network with no single point of failure. The finance officer wants a number. Daniel fills four pages of notes and realizes that nobody in the room has said the same thing twice. Turning those four pages into a scope that everyone can approve is the work of this lesson.

What a needs analysis is

A needs analysis is the structured process of finding out what the owner and users need from the ICT infrastructure, now and over its life, and turning those needs into requirements that a design can meet. It comes first because every later decision depends on it. A design that meets the wrong requirements perfectly is still the wrong design. And because ICT infrastructure lasts much longer than the equipment that uses it, the analysis must look ahead: not just at today's devices and applications, but at how the building's use may change over the next fifteen or twenty years.

The needs analysis is also where the designer manages expectations. Owners often begin with goals that conflict with each other or with the budget. Uncovering those conflicts early, while they can still be resolved by discussion, is far cheaper than discovering them in a bid that comes in over budget or a building that disappoints its users.

Identifying stakeholders

The first step is to find out who has a stake in the outcome. On most projects, stakeholders include the owner's executives, who set goals and budgets; facilities staff, who will operate the building; IT and network staff, who will run the systems that use the cabling; end users, such as clinicians, teachers, librarians and office staff; security staff; and outside parties such as service providers, regulators and neighbouring tenants. Each group sees the project differently and knows things the others do not.

The designer should also identify who has authority to decide. A long list of stakeholders with conflicting wishes needs a single owner's representative who can resolve conflicts and approve the scope. On Harbourview, that was Ines Kowalczyk for technology, with the architect coordinating everything else. On the library project, Daniel asks the facilities director to name one person, and the college appoints its IT manager.

Gathering information

Information comes from several sources, and a thorough analysis uses all of them.

• Interviews with each stakeholder group, using prepared questions so that nothing important is missed.
• Questionnaires for larger groups of users, such as faculty or clinical staff, whose needs vary by department.
• Workshops that bring groups together to agree priorities and resolve conflicts.
• Review of existing documents: the owner's standards, network plans, previous projects and technology strategy.
• A survey of existing conditions when the project involves an existing building or campus.
• Benchmarks from similar buildings that the designer or owner has experience with.

Good interview questions ask about activities, not technology. Asking a librarian how many outlets she wants produces a guess. Asking what happens in each space, how many people use it at the busiest time, what devices they bring, what equipment the library lends, and what the library expects to do in five years produces information the designer can turn into outlet counts, wireless density and pathway capacity.

Surveying existing conditions

When a project connects to or reuses existing infrastructure, the designer must find out what is really there, which is often different from what the old drawings show. A site survey inspects existing telecommunications spaces, entrance facilities, pathways, outside plant, bonding and the condition of existing cabling. It records available space, power and cooling in each room, spare capacity in conduits and duct banks, the type and condition of cables, and any hazards such as abandoned cable, missing firestopping or overloaded pathways.

The library project connects to the campus network at an existing building 300 metres away. Daniel's survey finds that the campus duct bank between the two buildings has two spare 100-millimetre ducts, but one is blocked by a collapsed section near the old building. The college's drawings show both as clear. That single finding changes the campus link design and the cost estimate, and it is exactly the kind of fact that a desk study would miss.

Abandoned cable deserves special attention. The Canadian Electrical Code and many provincial and municipal requirements generally require accessible portions of abandoned cable to be removed, because abandoned cable adds fuel load and clutter to ceilings and shafts. A survey that finds abandoned cable should note it, because removing it adds cost to the project.

From needs to requirements

Needs are what the users say. Requirements are what the design must achieve, stated clearly enough to be measured. The designer translates one into the other. A librarian's need for wireless that works everywhere becomes a requirement for coverage at a defined signal level and capacity throughout the public floors. An IT manager's need for no single point of failure becomes a requirement for two diverse campus pathways and two backbone routes to each telecommunications room. A finance officer's need for a number becomes a construction budget with a stated contingency.

Requirements should be specific, measurable, achievable and tied to a reason. They should also be ranked. Not every requirement is equal: some are mandatory because of codes, standards or the owner's policies, some are strongly desired, and some are nice to have if the budget allows. Ranking them early makes later value engineering, covered in lesson 10, much easier.

The basis of design and the owner's project requirements

The results of the needs analysis are recorded in a document that the owner approves. Different organizations use different names. A basis of design document, or design brief, records the requirements and the design concepts chosen to meet them, with the reasons. Many projects also use an owner's project requirements document, a term from building commissioning practice. In Canada, CSA Z320 describes building commissioning and the role of the owner's project requirements, and ASHRAE Guideline 0 is widely used as well. Whatever it is called, the approved document becomes the standard against which the design and the finished building are judged.

Defining the scope

The scope defines what the ICT project includes and, just as important, what it does not. A good scope statement lists the systems in the project, such as structured cabling, pathways, telecommunications spaces, bonding, outside plant, wireless cabling and cabling for security and audiovisual systems; the areas covered; the interfaces with other work, such as power for telecommunications rooms or furniture feeds; and the items explicitly excluded, such as network switches, wireless access points or audiovisual equipment, if those are purchased separately.

Interfaces cause more disputes than anything else. Who provides the conduit from a ceiling to an outlet in a wall: the electrical contractor or the cabling contractor? Who provides the power outlets in the telecommunications room? Who installs the access points that the cabling serves? A responsibility matrix answers these questions by listing each item and assigning it to a party for design, supply and installation. Writing that matrix during the needs analysis avoids a great deal of argument during construction.

Planning for growth

A needs analysis must look beyond opening day. Owners rarely know how their use of a building will change, but they can usually describe trends: more wireless devices, more Power over Ethernet equipment, more cameras, more building systems on the network, more space used flexibly. The designer turns those trends into allowances for growth. Typical allowances include spare outlets in flexible spaces, spare capacity in pathways and sleeves, spare rack space and power in telecommunications rooms, and spare backbone strands. The allowance should be stated as a requirement, such as pathways sized for a stated amount of future cable, so that it is not cut later as if it were waste.

Growth allowances need reasons as well as numbers. When the library's budget tightens, the finance officer asks why the pathways are bigger than today's cable needs. Daniel points to the requirement in the approved basis of design and to the cost of adding pathway later in finished ceilings, and the allowance stays.

Reading the owner's standards

Many owners, especially universities, hospitals and governments, have written standards for telecommunications design and installation. These standards may specify cable types, manufacturers, outlet counts, room sizes, labelling schemes and testing. They save the designer work and make the owner's buildings consistent, but they can be out of date or conflict with current codes and industry standards. The designer should read the owner's standards early, note any conflicts with codes or with the project's requirements, and agree with the owner how each conflict will be resolved. Where an owner's standard is stricter than an industry standard, it usually governs; where it conflicts with a code, the code governs.

Managing scope change

Scope rarely stays fixed. Users think of new needs, budgets change and other designers move things. Changes during design are normal, but they must be managed. Every change to the approved scope should be recorded, its effects on cost, schedule and other systems assessed, and the owner's approval obtained before the design changes. Uncontrolled growth in scope, often called scope creep, is a common cause of budget overruns and of designs that try to do too much with too little.

On the library project, the head librarian asks in design development for a recording studio. Daniel records the request, estimates its effect on cabling, pathways and cost, and sends it to the IT manager as the owner's representative. The college approves the studio but drops the digital signs, which were ranked nice to have, to stay within budget. Because the requirements were ranked, the decision takes one meeting instead of a month.