IT Project Management

IT project management has the potential to be a complex process as it involves the business and the technical sides of IT management. SCRUM, which is an agile methodology practiced by developers, is a subset of IT project management that usually does not consider the business side of project management. However, this document explores more deeply the business side of IT project management and the complex cost considerations involved with implementing technology systems. Well-implemented technology systems have the potential to save a business considerable money, improve efficiencies, and enable management to scale the business quickly. However, poorly-implemented technology systems may expose security vulnerabilities, result in down systems, affect the reputation of a business, or become an expensive burden. 

Project management documentation and planning should always be scoped to the size of the project. Small projects may not require as much planning and documentation as what is contained in this document, since small projects have few working parts and the risk of failure is low. However, large projects that have thousands of working parts and large teams may require much more documentation, financial analysis, and planning as they present more risk. Such projects are beyond the scope of this document and should be handled by qualified and degreed professionals. 

Projects may be divided into five phases. The material contained in this document mostly pertains to first two phases, which are necessary for the success of the remaining phases:

Stakeholders include anyone who benefits from the project. These include the project sponsors (i.e., those who want the project to happen), project managers, customers, clients, contractors, team members, or anyone involved in the project. The project team includes leadership, technical experts, administrators, business analysts (BAs), subject matter experts (SMEs), and anyone else required to complete the project. 

When initiating a project, the project manager (PM) should do a requirements analysis. This usually involves gathering as much information as possible about the project. The PM or analysts will, then, obtain examples of the expected deliverables, which will help to make a determination about the size and scope of the project.

Performing a requirements analysis involves collecting information about the deliverables, what those deliverables will do, how they will function, and what they will look like. If the job involves writing software, some of this process may include what types of information the software will collect, the appearance of the user interface (UI), and whether the software will be hosted on-premise or in the cloud. These are all important implementation details that need to be considered before the project begins. The project team does not want to spend a great deal of budgeted time and money on mistakes, only to spend twice as much time and money correcting those mistakes.

This will help the team to collect a list of deliverables that will be necessary to calculate time and budget requirements. When calculating those requirements, this assumes that subject matter experts who provide cost and time estimates are being truthful and accurate. This also assumes that key components required for the project will be delivered on time, in addition to addressing technical and regulatory requirements.

Requirements Document

The project manager should create a document that outlines the roles and responsibilities of everyone involved in the project. These include the project sponsor’s role in influencing the direction of the project. It includes the roles and responsibilities of team members, including software developers, systems analysts, security analysts, business analysts, among others who contribute to developing the end product. This document should also clarify the team structure, work hours, and hours of operation. 

The PM also needs to be accountable to the project sponsor, who may provide a performance appraisal. The PM needs to understand one’s own scope of authority in shaping the project deliverables. And the PM needs to provide hours of availability for communication and decision-making to the project sponsor and project team. 

Project feasibility refers to whether a project is even possible from a technological or financial perspective, and whether the tools and resources are available to build the project. During this phase, the PM needs to determine the approximate costs, schedule, and payback period. This may be a complicated process since it involves calculating the labor, materials, licensing, vendor contracts, subscriptions, and overhead costs associated with building complex systems over an indeterminate amount of time.

When trying to understand the project scope, the PM needs to understand the background of the project and the business justification for the project, so that the goals of the project team are aligned with those of the sponsors. The PM also needs to clarify the project requirements and final deliverables, in addition to any industry or government regulations that apply. And lastly, receive feedback from the project sponsors on how they envision a successful project in terms of team performance and a final product.

During this phase, the PM should attempt to create a strategy for the project deliverables that will help to create an accurate budget. This should include the required personnel, hours of work, tools, licenses, vendor agreements, unexpected events, and other resources. From this strategy, the PM may generate a rough estimate for the completion date. These estimates should help the project manager to plot out milestones and review. They also help the PM to factor in variables, such as contingency funds and reserves, and understand the consequences of exceeding the budget. This strategy may also be used to perform a risk assessment of things that could go wrong and worst-case scenarios. This information will be used to create the project scope document that goes in the project book, which should be reviewed and approved by the project sponsor. 

Project Scope Document

IT projects always present a number of risks. The requirements for the project could change, the technology could change, or one of the subject matter experts could leave. Depending on the industry, the project itself may be subject to governmental laws or regulations. So, one part of assessing these risks is to have team members and subject matter experts identify potential risks as they apply to their work. This helps the project manager to quantify the risk severity, the likelihood of those risks occurring, and the time and monetary impact if those risks did occur. The project manager could, then, document that information in a “risk probability-impact matrix.”

After these risks are identified and quantified, the project manager should create a risk response, or contingency plan, for dealing with those risks. This would involve understanding how those risks impact the “critical path,” which is the shortest amount of time required to complete the project. Having these contingency plans in place helps to dramatically mitigate the risk of exceeding the project budget or experiencing failure. 

Project viability refers to whether the project will be profitable, or may be completed within the given budget. The process of assessing project viability has a variety of factors, including assessing the expertise, tools, and resources required to complete the job, and whether the financing required to cover those expenses is available. And accurately estimating the project expenses is important to avoid falling short and exceeding the budget, which could potentially result in failure. That may be complicated because as the project progresses, the project may accumulate unexpected expenses from labor agreements, vendor agreements, employment expenses, material costs, licensing, and subscriptions. 

A statement of work (SOW) defines the scope of the project team’s responsibilities, which helps to limit the team’s responsibilities to only those related to the project. This should include a change-management process to ensure project changes are approved by project sponsors. This ensures the sponsors are getting what they expect and are satisfied with the final deliverables. 

One way to determine the project viability is to calculate the return on investment (ROI), which provides an approximate measure of the project’s payoff, or whether it will stay in budget. 

ROI = ((Present Value – Initial Cost) / Initial Cost) * 100

An example may include deciding whether to host an on-premise solution or host the solution in the cloud. While an on-premise solution may have a greater upfront cost, it may save money in the long term as a result of not having to pay a regular subscription fee. However, the business will still have to replace their on-premise systems at some future time as all hardware systems eventually fail. And that will require additional labor and expertise.

The project book contains all documentation related to the project. This may include some of the following:

Common Project Documentation

The Project Charter should contain an outline of the business justification for why the project is being considered. For example, the project may involve moving a specific business application into the cloud. It should also appoint those who are responsible for the project. It may establish an account where funds will be appropriated with a way to track those funds. It may define a way for the project sponsors to monitor the project and for the PM to receive feedback. And lastly, this document will be used to obtain approval and sign off for the project to officially begin.

The project plan consists of all the components necessary to complete the project. These include, but are not limited to:

Once the initial steps are complete, including the project book and forms, the PM should pitch the project in a meeting with the sponsors. In this meeting, the PM should review the project charter, including the details, phases, team members, and roles and responsibilities. This meeting is important because it gives the PM the opportunity to receive stakeholder input, ensure that the project satisfies their needs, and determine any scope changes that need to be made before the project begins. 

This meeting should be followed up on a regular basis with additional meetings, sometimes called steering committee meetings, where stakeholders are updated on the progress of the project and have an opportunity to provide input.