The Art of Technology Systems Programming

EastmanBy Bob Eastman

In my previous blog on technology systems Requirements Programming, I mentioned that on any project there is always a long list of technology systems to consider, which can include upwards of 100-150 individual technology systems (the higher end applies primarily to healthcare projects). To manage this information, we use a Technology Systems Master List that is grouped into the following classifications:

  • Technology Infrastructure
  • Network/ Information Transport
  • Communications
  • Medical Information
  • Audiovisual
  • Electronic Security
  • End User Devices
  • Application Software

Within each category, system selection will be based on different criteria, depending on the system’s usage. Device–oriented systems could be selected based on best price/performance criteria. For systems that interface with an organization’s administrators, department management, and/or end-user groups, graphical user interface (GUI) and its ease of use could drive the decision. The need for ease of integration and the availability for ongoing support might factor in for systems that integrate with other systems and databases. For systems that interface with the building/space architecture, the project Architect could sway selection. For all of the systems, consideration will be guided by features, functions and options.

In addition to the Technology Systems Master List, we have established a Technology Systems Master Responsibility Matrix that we craft to a project type. In the matrix we identify:

  • Which systems are being considered/included and (for posterior proposes), which systems are not being considered/included
  • Who is responsible for designing the system
  • Who is responsible for installing the system
  • Who is responsible for procuring the system
  • Whether or not a system has an impact on the building/space architecture
  • Who the Client’s lead decision-maker/stake holder/selection influencer is
  • Cost allocation information, including:
    • Construction budgets
    • Furniture/fixture/equipment (FFE) budgets
    • Departmental CAPEX/OPEX budgets

The Technology Systems Master Responsibility Matrix will be a living document, and is a very useful tool in keeping all of the decision makers focused on the objective of identifying and accommodating all required systems early in the design process.

As I also mentioned in my previous blog, we work on establishing the budget concurrent with developing the refined systems and responsibility lists. Establishing budgets is rarely easy or straight-forward, but the accuracy of the budgets could have dramatic impact on a project’s success. As with the systems list, there are different parameters on which budget decisions can be made. Initially, budgets could be based on estimated square footage costs or derived from rough-order-of-magnitude unit costs (with the units based on square footage rules). Subsequent budgets could be based on quantity-take offs, especially when the architectural floor plans take shape and the floor and room details are developed. Meetings with the Client’s end user groups and system administrators will fine tune the device quantities, but even that is sometimes fluid, even past when construction documents (CDs) are at 100%. Sharing progress drawings with a system manufacturer can also help fine tune a budget. System options can be identified for consideration for add/deduct alternatives.

A project’s design and construction schedule can potentially last years, with the associated decision makers and decision influencers entering and exiting the process over time. Systems decisions may also shift over time, either added or subtracted from the master list. The Technology Systems Master List, Technology System Responsibility Matrix, the Basis- of-Design Narrative and the budget documentation also establish an audit trail that will preclude finger pointing on why decisions were made/not made. They can also assist in value engineering (VE) efforts if overall project budgets reach or exceed breaking points and the painful decision to reduce cost/project scope must be made.

The bottom line here echoes the conclusion about requirements programming. A well-documented project including comprehensive systems and budget information is the key to success. And once again, that’s priceless.

Follow Bob on Twitter @BEastman_WH

This entry was posted in All Insignts, Information Technology and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

One Comment

  1. Posted December 27, 2016 at 7:31 pm | Permalink

    Very soon this website will be famous amid all blogging users, due to it’s good articles

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>