IT Project Management: How to Executive an IT Project

Page content

Identify the Need

To ensure the success of an IT project, you go about it much the same as with any project–establishing goals, ensuring communication, and facilitating collaboration. What are you trying to accomplish, how much will it cost and how much effort will it take to reach your goals? When working in IT, some small requests can turn into large projects. How do you determine what constitutes a project versus a request or change?

I recommend setting hard limits to help define your project. When does it stand alone and when is it the subset of another project? If a task will require more than X hours of effort (20-40), has a budget over $5k, is extremely complex, or poses a large business risk to availability or reliability, I’d consider it a project. Obviously you’ll need to set your own criteria based on the size and complexity of your organization and IT group. If the request falls short of those criteria, handle it like you would any other request or change.

Once you determine a request or change will be considered an IT project, formalize it by writing a project charter.

Project Charters

Project charters are a quick summary of the project listing the overarching goal or business need for the project, the benefits of doing the project, the resources involved, milestones and high level costs.

The goal of the project charter is to document enough of the project details to convince upper management the project is worth pursuing. Is this a software or hardware project? Do you need user stories to proceed with project parameters?

If you don’t already have a template for your organization, start your charter by using a word processor and putting in the following headings while answering the heading questions I’ve listed below:

  • Business Need – Why do you want to do this project? What specific need is being targeted by doing this project? If you can’t find a business need for doing the project, you should stop now.
  • Project Benefits – What benefits do you anticipate as a result of doing this project?
  • Resources – What human resources will you need? What departments will be involved?
  • Cost – What is the capital cost of the project? What is the anticipated effort to complete the project?
  • Milestones – What are your high level milestones to ensure the project stays on task?

Once the project charter is complete, be ready to present it to management for approval. If the project gets shot down, take note of any reasons and determine whether you need to revise the plan or drop it altogether. If the project is approved, continue on with the project plan.

Project Plans

If project charters are the 5,000 foot view of a project, project plans are the 100 foot view. Project plans will cover much of the same details that are in your project charter, but with more detail. If you don’t have a fancy project management system in place, just use your favorite word processing software. Much like the above example, use the following headings and cover the questions below in your write-up. You may want to build some simple tables to house things like the milestones and work breakdown structure. You may also consider using Microsoft Project or an alternative software or method for tracking the schedule.

  • Scope Statement – How big is the project? Will this project affect several departments? How many IT systems will be affected? Will multiple systems be affected?
  • Deliverables – What specific items will you deliver? What specific items will you not deliver? Make sure these are clear so assumptions are not made.
  • Sponsors, Stakeholders and Resources – The sponsor is your customer; he will make the ultimate decision on whether or not your project is greenlighted. Stakeholders are those that the project will affect, either in the final outcome, or during the course of the project. What other personnel (resources) will you need to engage for this project?
  • Communication Plan – This doesn’t need to be anything fancy, but be sure you and your team (and sponsors\stakeholders) are in agreement about how often you will communicate about the project status.
  • Risks, Constraints and Assumptions – What risks does your project face? Do you have any constraints (time, money, quality)? What about assumptions? The goal here is to make sure everything is out on the table and can be accounted for before the project starts in earnest.
  • Milestones – They should be similar to the charter milestones.What are some of the major steps or accomplishments will you reach during the course of the project?
  • Project Schedule – Also referred to as a work breakdown structure – this lists tasks along with anticipated effort, start date, due date and assigned resource(s).

With your project plan in hand, you shouldn’t have any issues with IT project execution. Just be sure to keep everyone informed as to the project status and don’t be afraid to update your project plan if things change.