This is Part 1 of a multi-part article series concerning resource planning in a technology-centric PMO.

With the complexities present in today’s organizations, PMOs face many obstacles, pitfalls and challenges. In my opinion, one of the biggest challenges which PMOs face, is resource allocation. Specifically, the planning and allocation of resources while dealing with conflicting projects or job duties which require the same resources. Although human resources are those which are most frequently cited for these types of issues, physical resources must be considered as well. As far as physical resources, we are speaking of systems, networks, storage devices, etc.; those infrastructure pieces which are necessary to complete a particular portion of a project, which may be unavailable during the project task timeline due to conflicts.

As a technical project manager, you need to be keenly familiar with each distinct area of your organization’s technical infrastructure. In Part 1 of this article, I will go over the technical areas of which a project manager will need to be aware when planning for resource allocation, their order of awareness (based on my experience in the field), and potential “gotchas.” This certainly does not contain everything involved with the teams and the tasks, but does grab the essential item descriptions a project manager will need to get themselves injected into the correct processes.

Organizational Areas of Technical Infrastructure (listed in order of awareness):

· App / Dev – Commonly known as the “development teams,” this group deals primarily in the development and maintenance of either internally-developed applications or framework applications which have internally maintained customizations. In most organizations, this is the most visible group and the group around which most projects and activities revolve. Many projects and changes start with this group and move outward as it is discovered that other groups are needed in order for a project or change to be successful. Projects and changes coming out of this group can require any or all of the remaining groups. Careful requirements gathering and planning is required for anything coming out of this group. Remember that most development teams are very focused on their own areas and will generally depend on other teams to let them know what they need for an implementation to be successful.

· Database – Database teams have complicated jobs in many instances, being a combination of server administrators, database engineers/administrators and database programmers. In many instances, database teams are also part of certain development efforts when it comes to actual database programming, such as SQL. They are called upon to validate code, be available for troubleshooting, and other tasks related to development change efforts. Additionally, database teams are traditionally pretty thinly staffed, which means there are few people, pulled in many different directions. That, coupled with their day-to-day duties, makes this team’s members very difficult to reserve.

· Server – Server teams are sometimes divided into two teams, operations and engineering. If this is the case in your organization, the operations team will most likely be needed for assistance with projects involving server changes, while the engineering team will be called upon for new server builds and/or refreshes. Typically, this team is responsible for up/down and operating system functionality, as well as monitoring and alerting with respect to the server infrastructure. Additionally, this team is usually responsible not only for Active Directory (and everything that entails), DNS (depending upon the technology used), and DHCP, but also virtualization technologies such as Citrix, VMWare and Hyper-V. This would place them in the mix for anything related to hosted applications, VDI or virtual server tasks. Much like database teams, the server team is generally thinly staffed, so plan accordingly.

· Network – The easiest way to describe a network to the uninitiated is to equate it to the spinal cord of your body. The network IS, in my opinion, the single most important piece of an organization’s infrastructure. Without a functioning network, there is not much that will work in today’s world of distributed technology systems. Here is a short list of things you will need the network team for with respect to your projects: IP address assignment, VLAN creation, switch port assignment and configuration, network cabling, and new site build-outs. Unfortunately, the network team is typically the second-to-last team to be notified of a change which needs their assistance and this usually occurs when the server has arrived, has been racked, and the person performing the server build-out asks when they will have network connectivity. My advice to all technical project managers is to engage the network team first, if there is any chance that you will need network connectivity – and that is most likely, always.

· Desktop – Desktop teams can be divided into two separate teams, depending upon the level of technical expertise present in the organization. Sometimes, this team consists of “Desktop Support,” which is made up of level 1 (help desk) and level 2 (field service) support and “Desktop Infrastructure,” which could be a support level in between field service personnel and vendor support. This level will typically exist in organizations which have mature technology departments and is usually responsible for desktop management systems, such as Configuration Manager and virus protection projects as they relate to the desktop infrastructure. The Desktop teams are generally the last teams to know about any change except their own. Regardless of the change occurring, it will almost always need the assistance of the Desktop teams so it is important to involve them early in the planning process to determine if they are needed and define their roles.

In Part 2 of this article, I will discuss the various activities routinely handled by the teams mentioned above and what types of scheduling conflicts you can expect as a project manager.