Project Management–Resource Allocation–Technology Teams and What You Need to Know, Part 2

This is Part 2 of a multi-part article concerning resource planning in a technology-centric PMO. You may read part one of this series here:

Resource Allocation, Part 1

In today’s world of malicious hacking groups, vendors and organizations spend a great deal of time worrying about and dealing with security vulnerabilities. Many times, dedicated groups are assigned to deal with nothing but researching and dealing with these types of vulnerabilities across hardware platforms, operating systems, software applications, peripherals and majors devices. Unfortunately, most organizations cannot afford the additional staff, and thus, the research and policies are the responsibility of a one or two-person security team, while the “patching” tasks are added to various support teams. Patching can take many forms, including security updates, services packs, routine updates, and BIOS and firmware upgrades.

Security Updates

It is important that a project manager to be in tune with an organization’s security team, as they will know the established organizational release schedules for standard security updates. It is also important to note that most security update calendars are NOT adjusted for a typical project or task change, unless those changes have a direct effect upon the revenue stream. In mature technology organizations, security is far more important than project or task changes. Also, a project manager you realize that firmware upgrades, which are hardware-related, not software or operating system-related, are generally not tied to any set schedule, but are planned as part of a major change. Areas and types of changes involving various security updates are described below.

· Desktop – Probably the most visible of deployed security updates within any organization, endpoint security updates are typically released once per month with the release date determined by the vendors. The most well-known security updates are those by Microsoft, which are released on what has become known as “patch Tuesday,” the second Tuesday of each month. When you receive a notice stating something along the lines of, “Your Technology Department is installing important updates,” you are most likely receiving security updates. Security updates can be distributed to the desktop operating system or the COTs (commercial off-the-shelf) applications installed throughout the environment. Examples of COTs applications are Adobe Acrobat, Microsoft Word and WinZip. As a project manager, you must be aware that patch days will render all involved workstations virtually untouchable, as most security teams want to ensure that nothing interferes with patch day.

· Server – Another of the more visible events involving security updates are those affecting servers. The primary reason behind this is that most security updates require a restart, which will disrupt any application hosted on the affected server. Another reason is that many older applications can be rendered non-functional upon the installation of security updates which affect specific OS functionality or framework operations. For Microsoft server operating systems, in-band updates are also released on “patch Tuesday.” Server updates are typically applied over a weekend and occupy all members of the team. Additionally, server updates will require support from members of specific application teams (for those application servers being patched) and desktop teams which support those applications. Network team members may also be on-call to validate that any issues encountered are not network-related. Server patch day will pull the affected servers offline during the process and any servers which depend upon the functionality of those servers. (e.g. A web server connecting to an application server which is being patched.)

· Database – Quite frankly, one of the more complicated groups for security updates, in my opinion. With this team, you could have a combination of server updates and/or database engine updates which could occupy both the human and physical resources. Typically, the database team will favor performing database engine updates during the same weekend as general server patching, considering their team would be required to be on-hand for the server updates anyhow. Do not plan on reserving any database resources during a patch weekend. Any servers depending upon the database servers being patched will also be non-functional. (e.g. An application or web server connecting to a database server.)

· Network – Although not as well-known, network security updates are not uncommon, but are more rarely applied. Typically referred to as firmware upgrades, network security updates have the potential to bring down an entire network segment, and thus, are generally tested thoroughly, and then only installed if absolutely needed. Many network firmware upgrades are accompanied by a disclaimer that they should only be applied if the described issue is readily occurring. Needless to say, if a network firmware upgrade is occurring in your infrastructure, you will more than likely have no access to the network team during the outage. All devices connected to, or depending upon the network devices being upgraded will have no network connectivity, and thus will be not be accessible, unless you have direct console access.

· App / Dev – In my experience, I have yet to see an application team ever address a security vulnerability affecting an internally-developed application. From the perspective of applications built upon frameworks and customized for the organization, updates are generally rolled up as part of major system upgrades and performed only when needed for access to additional functionality or remediation for specific issues. Typically, during major upgrades all aspects of an application and its connecting systems will be offline and those application engineers responsible for the application will be unavailable. Additionally, server and database team members assigned to the application and database servers affected by the upgrade will be unavailable during the change window.

In Part 3 of this series, I will discuss non-security activities requiring change requests.