Managing an IT project may be the most exciting -- and challenging -- task you ever undertake in your career. This article will show you how to get started. It is excerpted from the book, IT Project Management, by Joseph Phillips (McGraw-Hill/Osborne, 2004; ISBN: 0072232021).
Interview with Kevin Kocis Name: Kevin Kocis Title: Manager of Information Technology Years in the IT field: 10
Kevin Kocis has been working in the information technology field for over 10 years. He is currently the Manager of Information Technology for a division of a Fortune 100 company, where he develops strategies for network and server infrastructure, Oracle implementation, and platform interoperability issues (Windows, UNIX, and Macintosh).
Q: What is the best part about IT project management? A: The best part about IT project management is leading an initiative that resolves a business need and/or contributes to business success. Another great part about IT project management is the challenge of leading new cross- functional teams.
Q: How do you start a new project? A: The project is usually started in response to a broad objective or a business request. Once a performance analysis and feasibility study are completed, it can be determined whether the objective or request can be deemed a project. A project can also be initiated to optimize internal processes and to leverage return on investment.
Q: When you start a new project, what is the first thing you do? A: The first thing to consider when starting an official project (assuming performance and feasibility tests are complete) is to gather requirements and document flowcharts to develop the project plan. Of course, requirements often change throughout the project, but the initial requirements will be based on current knowledge. Make it a priority to update the business champions and sponsors in regular project meetings.
Q: When starting a project, what’s the most important thing a project manager should do? A: When starting a project, the most important thing a project manager should do is to identify the business goal and determine the business champion or sponsor. The business sponsor needs to understand the project scope and help convey this process to the senior management team.
Q: How do you manage the relationship between upper management, your team, and the project? A: The IT team manager manages the relationship between the upper management team and project by acting as interpreter. One of the challenges is that senior management may not understand the IT role for the project and vice versa. The project manager should debrief both groups to ensure a synchronous understanding.
Q: How important is a project goal? A: The goal is always significant as it is essentially the initial reason for pursuing the project. However, the goal cannot be achieved without certain conditions. Factors such as scope creep, team relations, and communications will become important as the project progresses. These factors will contribute to the success of the project, so while a project manager must maintain a focus on the goal, she cannot ignore the factors contributing to the project’s success.
Q: How necessary is it for project managers to create a project charter? A: A project charter is very important for the project manager as it serves as a roadmap for the project. As its name suggests, the roadmap should define the key steps of the project, as well as the high-level deliverables. The roadmap should also include the relationship of the project to the business’ operational or strategic goals. Project charters should be well publicized (such as through an intranet web site) in addition to the project’s progress.
Q: Can you share an example of how you started a project and the steps it took for you to complete it? A: One of my projects (that saw plenty of challenges) was an internal domain migration in preparation for Windows 2000. My company was one of the first to install Windows 2000 in its production environment, and with several hundred internal Windows NT domains, there was a strong need to consolidate to a handful of key domains. To simplify the process for the scope of this chapter, we communicated heavily with our business group management. I met with senior staff to inform them the migration was a corporate initiative that would simplify a later transition to Windows 2000. I also informed them that to mitigate potential risks, we would test the migration in our test lab.
Since the timeline for this project was short (weekend transition with one week scheduled for follow-up issues), no project charter was created. We tested the feasibility to perform the migration in our lab, working with an outside vendor for our domain migration software. We communicated the transition to the user community on a weekly basis, and on the Friday of the conversion. Unfortunately, we did not plan for the unexpected power outage, nor the virus infection that occurred that weekend. As a result of these unforeseen events, our team had to branch out to maintain progress on the project. The only issues that resulted from the project were vagabond machines or users, and this essentially helped us prepare for our internal audit, so I considered this project quite successful.
Q: How do you work vendors into your timeline? A: I always notify vendors during the project proposal phase as a courtesy when a project need is identified. This enables me to arrange project-planning windows around their turnaround times. Many hardware vendors do not build or prepare hardware until they are issued a purchase order, but advance notice can help expedite the process. Vendors (depending on the project) often work in parallel paths with the project team. For example, if we are looking to upgrade our servers by replacing them, the project team can plan communications and documentation while waiting for the hardware to be built and shipped.
Q: What do you do if vendors are late on delivery, which may disrupt your project completion date? A: To avoid vendor delivery issues, the project managers should address contingency plans for any vendor-related critical path that exists in the project plan. By discussing the critical nature of the delivery, vendors can assist with providing an alternative solution before the schedule is critically impacted. These issues should be discussed prior to committing to the vendor.
Q: How do you balance the time between projects and your regular work duties? A: Unfortunately, when it comes to balancing time, there is seldom a right or defined answer. Individuals balance time responsibilities differently. In my case, I prioritize the projects and weigh them against my daily duties. Some project meetings I may not attend, and assign a team member to represent me. For the team, I prioritize their project tasks and communicate with management to ensure there is understanding that daily tasks will not maintain their priority.
For example, if a desktop support person is involved in a critical stage of the project, daily support will not be able to maintain the same expectation level. This can be leveraged with additional resources if the business wishes to maintain its support expectancy.
Q: What’s a common trap IT project managers fall into and how can they avoid it? A: IT project managers often fall victim to making reactionary decisions based on a hardship or challenging situation. Often, the response time in light of a complication is limited, and if no contingency plan was developed or an unpredictable event occurred, the project managers may be forced to make a reactionary and critical decision without business support. To avoid this, make sure contingency and rollback plans exist for all projects. Listen to the project team, and form a consensus on the issue. The project managers may also have a tendency to become too hands-on or hands-off in the process if the plan is behind or ahead, respectively.
Q: What are characteristics of a successful project launch? A: The characteristics for a successful launch include high publicity and management involvement. Start with a kickoff meeting (with goodies), and make sure all business management can participate, as well as the entire project team. Ensure that all communication standards are agreed to, and that management understands the goal of the project and its participants. Review the plan and its impacts in great detail. Listen to concerns and modify the project plan only if critically necessary.
Q: If a project has many steps to the final implementation, how do you keep the project moving and heading toward each milestone? A: For long-term projects, accountability and strict deadlines are mandatory. A key to ensuring that the team does not burn out or fade is to acknowledge their successes at milestones, regardless of the size or magnitude of their contribution. Teamwork is critical for a successful project.
Q: What advice can you offer fellow IT project managers in regard to implementing new technologies? A: My personal advice to fellow IT project managers regarding new technologies is to thoroughly understand the enhancements and changes. Make sure external resources exist (such as vendor training and demos). Test and document the technologies thoroughly.
Never underestimate how people (your users) are affected by change, even good change. Overcommunicate and focus on the positive results.
Q: What advice can you offer for aspiring IT project managers? A: My advice to aspiring IT project managers is to remember that we grew from a certain “track.” Some of us are (or were) developers, DBAs, systems engineers, and network engineers. We may not have led people from other tracks. Learn to listen and be fair. Don’t be influenced by where you’ve been. Focus on teamwork.
This article is excerpted from IT Project Management by Joseph Philips (McGraw-Hill/Osborne, 2004; ISBN 0072232021). Check it out at your favorite bookstore today. Buy this book now.