Category Archives: Project Management

Project Management, Resource Planning

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

Leave a comment

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.

Project Management, Resource Planning

Project Management – Resource Planning – Technology Teams and What You Need to Know

Leave a comment

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.

Interacting with Teams

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.

Project Management, Requirements

Project Management – Requirements and Why You Need Them

First off, we need to clear the air with a dose of reality. Everyone one of us in technical project management has been involved with “THAT” project…. You know the one… we need to get something in front of the client now that shows we are doing something, whether it’s a price, timeline or resource estimate. If we don’t produce SOMETHING, the client will believe we are billing without producing. Or… it’s a matter of sales and marketing folks wanting to get a jump on the sale, so we’re forced to put something together that hopefully resembles the tasks we will actually perform.

I think this comic sums up that type of situation:

For the most part, project requirements actually are provided initially in the form of an RFS, RFQ or RFP. Granted, they are not always clear, but you at least have some sort of road map to go by. Between the initial request document(s) and discovery meetings, you can detail out project requirements.

An issue arises in what I term “drive-by projects.” These are projects which arise out of hallway conversations, golf games, lunch conversations and the likes. The project manager receives the project, and there is so little detail that it is difficult to discern what is actually wanted. Now, keep in mind, I’m writing this post from the perspective of reality, not from scenarios presented during our project management training. I’ve not worked in a single company which did not have these types of projects occurring on a regular basis.

Projects fail many times because of lack of requirements, or bad requirements and “drive-by’s” are notorious for having both of these characteristics. Without some good effort to drive the requirements out of the client, there is a high probability that the wrong thing will be delivered to the client. These outcomes not only create negative perceptions of the project itself, but also of the project management team/office.

That being said, my approach in drive-by situations is to write down a few notes about the discussion, then immediately call a meeting to develop a business case and flesh out high-level requirements. I always receive push-back for this, often with phrases such as, “It’s just an <insert technology here> – can’t you just do it?” Generally, I try to respond to these types of comments carefully and ensure the client that I just want to ensure that we deliver what they are expecting and that when we are complete, they will be satisfied with the solution.

So, make sure in all cases of shallow or no requirements, you make a concerted effort to loop in the client and pull their needs out of them. Doing so will save time, cost and most of all frustration.