IT Project Management Basics: Initiating a Project (Part 1)

Posted on: September 13th, 2016 by Julian Lombardi

With the summer all but over and everybody returning back to their regular routines, we thought this would be a good time to get back on track with our blog posts. This month we will be starting a series of posts concerning IT project management and why it is so important. In our experience, it is often overlooked by small businesses due to the agile and sometimes fast-paced nature of these organizations. Perhaps, it is all the excitement generated by new and shiny technology that attributes to a lack of planning. Either way, project management is crucial to success and widespread adoption/acceptance of a new implementation. For the purpose of this series, some examples of IT projects you might encounter are:

  • New firewall/router configuration and installation
  • Server configuration and installation
  • Significant volume workstation installation (5 or more)
  • Replacing corporate phone system
  • New website

 

The above items should give you an idea of what we mean when talking about a new IT project. The five main process groups associated with project management are: initiating, planning, executing, monitoring/controlling, and closing. This post will start with the first process group of project initiation and while this is not meant to be a definitive, detailed guide to project management, we hope it puts you on the right track. Enough of introductions, let’s get started!

Your organization decides that it is time to replace that old, dusty server that has been chugging along for the last 10 years. Where do you even begin? Do you call your IT provider and say “Hey, can you get us a new server?” and then close your eyes hoping to walk into the office to see a brand new server in the networking closet? You may get lucky and everything works out for the best but we’re here to say that there is a better way to go about it for both your organization and your IT provider.

The first step is to choose who will manage the project. It is really important that there is someone placed in charge of overseeing the project and monitoring the status. Without this person, it will become exceedingly difficult to keep a project on track. We find that it is good practice to try and find someone well-versed in the overall topic. For example, with a server replacement project, it is good to have someone who has some fundamental IT knowledge at the very least. Also, they should have a base understanding of what the purpose is for taking on the project.

Once a project manager has been chosen, it is helpful to determine the corporate culture and the existing systems of the organization. For example, some organizations might be very cloud-centric. That is going to have a significant impact on your decision making process. Maybe instead of replacing the server with an on-premises solution, you might want a cloud solution. Knowing your organization will really help define those variables. Defining the existing systems goes hand-in-hand with knowing your corporate culture because of a theory called gap analysis. The basic concept of the theory is to understand where you are now, where do you want to be in the future, and what steps or action need to be taken to get there. Your corporate culture will often dictate or point you in the direction of where you want to be in the future while existing systems will tell you where you are now.

The next area is to understand the business case or in other words stating the case of why you think the project should be done. The reason why a business case is so crucial is because without it there is no real indication of whether the project will satisfy the needs. For example, maybe the reason for doing the project is because there is a new feature you would like to take advantage of. With a business case, you can most often clearly define whether or not, satisfying the need is going to be worth the resource investment associated. In other words, is X amount of dollars worth the investment to gain Y feature(s).

Outlining the preliminary requirements, assumptions, and risks will be a key step to starting a project. Small businesses are often sold the wrong product/service simply because this step was skipped. When you go to a supplier and present them a need for a solution, it is the responsibility of you to outline all of your requirements. Unfortunately, product and service providers are not mind readers and while they can support the process by fishing and surveying for more information, it is hard for them to gauge exactly what you have in mind. This list can be built up further at the beginning of the planning phase but at least having a starting point will help in the long run to prevent scope creep (project scope changes/increases as a result of scope not being clearly defined at the beginning of project). Assumptions and risks also need to be clearly defined as no one can account for 100% of the outcomes of a project, there will be risks or assumptions that need to be made in order to prepare for worst case scenarios, delays, or unforeseen outcomes. Not including these could account for project failure or delays at any stage of the project.

Along with the above, an effort should be made to outline measurable objectives. After all, how can you know if the project has helped improve anything if you can’t measure its impact? For example, a replacement server might be measurable with additional storage, faster hardware (better performance), improved redundancies, among other items.

The last major item of this phase will be to develop a project charter which should summarize many of the above details into a simplified format.
I know the above is a lot to process but it truly is important and should be shaped to fit your organization. As mentioned earlier, the above is a guideline to improving your organizations project management strategy.

Keep an eye out for the continuation of this series which should come sometime next month.