Initiating the Project - From the Field (
Page 6 of 7 )
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. |