Gathering Project Information
Everybody talks about project management, but what is it
exactly? In some organizations, any task or duty is considered a project that
requires someone to manage it. Puh-leeze! Project management is the ability to
administer a series of chronological tasks resulting in a desired goal. Some
tasks can’t be completed until others are finished, while other tasks can be
done in parallel. Some tasks require the skill of a single individual; other
jobs in the project require that everyone chip in and lighten the load.
A project, technically, is a temporary endeavor to create a unique
product or service. Projects are an undertaking outside of the normal operations
of an entity. For example, you might roll out a new application, install new
monitors, create a new portion of a web site, or establish a new call center for
application support. In some organizations, such as ones comprised of
application developers or consultants, or IT integration companies, everything
they do is a project because they complete projects for other organizations.
Consider a company that creates custom applications for other organizations.
Their operation is an ongoing series of projects. The organization that
completes the project work is called the performing
IT project management is the ability to balance the love and
implementation of technology while leading and inspiring your team members. Of
course, the goal of project management is not technology for technology’s sake,
but rather a movement toward things like improved customer service, enhanced
product quality, and increased profitability. As you can see in Figure 1-1, project management is a
high-wire balancing act.
Figure 1-1: A project
manager must balance the team and the technology.
Before the actual project work can begin, the project
manager must establish the project requirements with the project stakeholders.
Stakeholders are any individuals, groups, or communities that have a vested
interest in the outcome of the project. On some projects, the stakeholders may
be just one department. On others, when projects may affect every department,
the stakeholders may be throughout the entire organization. Identifying
stakeholders is important because their input to the project requirements early
in the project initiation can ensure the project’s success.
Of course, on most projects there will be key stakeholders who
influence the project’s outcome: department managers, customers, directors, end
users, and other folks who have direct power over the project work. With the
input of these key stakeholders, specifically their requirements for the
project, constraints on the project, and time and cost objectives for the
project, the project manager will be able to gather the project requirements to
begin building a project plan to create the project deliverables.
Clarity is paramount. When the decision has been handed down that
your company will be implementing some new technology, and you’ll be leading the
way, you need a clear, thorough understanding of the project’s purpose.
Ambiguous projects are a waste of time, talent, and money. Before the project
begins, you need to know what exact results signal the project’s end. A project
truly begins when you know exactly what the project will produce.
Once the project is defined, you need a clearly stated start and
end date. The role of a project manager is not permanent but temporary. You, the
project manager, are responsible for seeing the goal, developing the steps to
get there, and then leading the way for your team to follow.
How will you know what the end result of the project is to be?
Ask! Who do you ask? People like the project sponsor can answer these kinds of
questions. More about that later! You must have a clear vision of the end
result, or the project will drone on and on forever and you’ll never finish. Too
often IT projects can roll into project after project stemming from an original,
indecisive, half-baked wish list. Whether you are a full-time employee within an
organization or a contract-based project manager, you must have a clear
understanding of what the end results of the project will be.
Imagine your favorite archeologist maneuvering through a labyrinth
of pitfalls, poison darts, and teetering bridges to retrieve a golden statue. In
the movies, there’s always some fool who charges past the hero straight for the
booty and gets promptly beheaded. Don’t be that guy. Before you can rush off
toward the goal of any given project, you’ve got to create a clear, concise path
to get there.
To create this path, you’ll have to interview the decision makers,
the users the change will affect, and any principals involved in the development
of the technology. These are the stakeholders—the people who will use the
project deliverables on a daily basis or will manage the people who will use the
project deliverables. You must have a clear vision of what the project takes to
create it or you’re doomed. Often projects start from a wish list and evolve
into a catalog of complaints about the current technology. One of your jobs in
the early stages of the project will be to discern valid input from useless
As you begin your project, consider these questions:
Does the Project Have an Exact Result?
Projects that are as indecisive as a six-year-old at an ice
cream stand rarely are successful. As a project manager, you must ensure the
project has a definable, obtainable end result. At the creation of the project,
every project manager, project sponsor (the initiator of the project), and team
member should know and recognize the end result of the project. Beware of
projects that begin without a clearly defined objective.
While you should be looking for exact requirements that a
project is to include, you must also look for requirements that are excluded
from a project (for example, a project that requires all mail servers to be
upgraded in the operating system, but not the physical hardware). As the project
takes form, the requirements to be excluded will become obvious based on
management, the time allotted for the project’s completion, and the given
Are There Industry or Government Sanctions to
Within your industry there may be governmental or
self-regulating sanctions you will have to take into account for your project.
For example, in a banking environment there are regulations dealing with the
security of the technology, the backup and recovery procedures, and the fault
tolerance for the hardware implemented. Government regulations vary by industry,
and if your company is a government contractor, there are additional
considerations for the project deliverables.
Within your industry there may be standards and regulations.
Regulations are “must-haves” that are required by law. Of course,
pharmaceuticals, utility companies, and food packaging companies have
regulations that dictate their practices. If companies break regulations, fines
and lawsuits may follow. Standards, however, are generally accepted guidelines
and practices within an industry. Standards are heuristics, rules of thumb,
which are not laws but are usually followed. The project manager must be aware
of regulations and standards that affect the project’s work and deliverables.
Does the Project Have a Reasonable Deadline?
Massive upgrades, software rollouts, application
development, and system conversions take teamwork, dedication, and time.
Projects that don’t have a clearly stated, reasonable deadline need one.
Projects should not last forever—they are temporary. Acknowledge the work. Do
the work. Satisfy the user with deliverables of the project. Once you’ve
accomplished this, the project is done.
We’ll talk more about project scheduling in Chapter 7, but the project manager
must be aware of the project calendar and the resource calendar. The project
calendar defines the hours in which the project work can take place. For
example, if your project is to rewire an entire building with new network cable,
the project calendar may specify access to the building between the hours of
8:00 P.M. and 6:00 A.M. Resource calendars are specific to the project team
members. They take into consideration the hours employees are available, their
vacations, and company holidays.
In addition, the project manager must consider how many
working hours their project team members will be able to devote to the project
in a given day. Six hours of productivity is typical of an eight-hour day
because of impromptu meetings, phone calls, and other interruptions. These
factors directly influence the project schedule and if the project can meet the
project deadline with the given resources.
Is the Project Sponsor Someone Who
Has the Authority to Christen the Project?
Most IT folks hate politics, but we all know politics,
personal interests, and department leverage are a part of every company. Make
certain the project sponsor is the person who should be initiating the
project—without stepping out of bounds. Make certain this individual has the
resources to commit to the implementation and has the support of the people up
the flowchart. And do it with the full knowledge and support of management.
The project sponsor should be an individual within the
organization who has the power to assign team members, allocate funds, and
approve decisions on the project work. The project sponsor is typically above
the functional managers of the project team members assigned to the project
Does the Project Have a Financial Commitment?
If you do not have a clear sense of a financial commitment
to the completion of the project, put on your hard hat and don’t stand under any
fans. Technology costs money because it makes money. The goal of a project, in
the corporate world, is the same goal of any company: to make or save money. A
tech-centric project requires a financial investment for quality hardware,
software, and talent. If the project you are managing has a budget to be
determined somewhere down the road, you’ve got a wish list, not a project at
Is Someone Else Doing This Already?
In large companies, it’s easy for two projects to be
competing against each other for the same end result. This comes back to
communication among departments, teams, and the chief information officer. In a
perfect world, IT projects fall under one umbrella, information is openly shared
among departments, and everyone works together for the common goal of a company
(to make money). This process can be administered through a Project or Program
Management Office where projects are tracked across the enterprise. Of course,
that doesn’t always happen. You should do some initial research to ensure this
project isn’t being accomplished elsewhere in the company before you invest
time, finances, and your career in it.
Are you an optimist? A pessimist? A realist? A project
manager has to be all of these. You have to be an optimist so you may lead your
people, manage the resources, and implement the technology according to plan.
You have to be a pessimist, secretly of course, because you need to look at the
worst-case scenario for each piece of the technology implementation. You have to
be a realist because you need to look at the facts of the projects completely,
unattached, unemotional, and unencumbered.
When your project is developing, you should play devil’s advocate
to each cornerstone of the project. You need to question the concepts, the
technology, and the time it may take for each step of the implementation. As you
can see in Figure 1-2, you should
question everything before you begin.
Figure 1-2: Project
managers must question all aspects of a project.
Questions to consider:
How Will This New Technology Affect Your Users?
Not all technology you implement has a direct effect on your
users, but most of it does. Your life may be IT, but the accountant in the
finance department doesn’t like change. She likes everything the way it is now;
that’s everything from having to click OK on a redundant error message to
installing her favorite screen saver. If your technology changes her world, you
should let her know ahead of time; otherwise, she’ll be certain to let you know
after. Your primary objective must be to make her job easier.
As technology has become integrated in practically all areas
of an organization, users are becoming more tech-sophisticated. They will want
to know why the change is happening, why the change is needed, and how it will
help them. This brings us back to requirements gathering and communication.
Ninety percent of the project manager’s job is communication. If the project
manager wants buy-in from the stakeholders, particularly the users, he must
communicate the benefits and rationale behind the technical project.
Will This Technology Have an Impact on Any Other
How many times have you installed software without testing
it, only to discover it disrupts something as unrelated as printing? I hope
never, but it happens. You must question and test the ability of the new
technology to work with your current systems. Of course, if you’re considering a
100 percent change in technology, then there really isn’t a software
Will This Technology Work with Any Operating System?
How many operating systems are in your organization? While
the goal may be just one, I’d wager you’ve got two or three different OSs
floating around. Think about those graphic designers and their Macintoshes.
Remember those salespeople and their Windows XP laptops? And what about those
mainframe and server-based Linux users? If your company has multiple operating
systems, you’ve got to question the compatibility of the technology for
What Other Companies Are Using This Technology?
The assumption is you are buying this solution rather than
building it. Therefore, is it a bleeding edge solution? Are you first in line?
No one likes to be first, but someone has to be. When embracing and implementing
a new technology, ask that question of the vendor’s salesperson. Hopefully, the
salesperson will be happy to report about all the large companies that have
successfully installed, tested, and implemented the vendor’s product. That’s a
good sign. If someone else has done it, you can too.
Does the Vendor of This Technology Have
a Good Track Record in the Industry?
From whom are you buying this technology? Has the vendor
been around for a while and implemented its product many times over? Does the
vendor have a history of taking care of problems when they arise? This is not to
say you should not buy from a startup—every major IT player was a startup at
some time in its history. You should feel fairly confident that the vendor
selling the product today will be around to support it tomorrow.
What Is the Status of Your Network Now?
You may not always have to ask this question, but with so
many network-intensive applications and new technologies today, it doesn’t hurt.
You don’t want to install the latest bandwidth hog on a network that’s already
riding the crest of 90 percent utilization. You and your company won’t be happy.
By asking this question, you may uncover a snake pit that needs to be dealt with
before your project can begin.
Finally, you need to dream up worst-case scenarios and see
if there are ways to address each. You need to find out how the technology will
react when your servers are bounced, lines go down, and processor utilization
peaks. You want to ask these questions and have answers for them now rather than
when the crisis hits during your four-week vacation to Alaska.
At the start of a project, in its very genesis, ensure that
the proposed technology is the correct technology. Of course, sometimes you have
no control over the technology that is to be implemented because some vice
president decision maker heard about the product from his golf buddy who is CIO
at another large firm and is now having you install it everywhere. It
Other times, hopefully most of the time, you have some input
to the technology implemented to solve a problem. You are the professional, the
IT guru, so you should have a definite say regarding the technology that you’ll
be in charge of delivering. You’ll need to create a list of questions and then
find the appropriate technology that offers the needed solution, works with your
current systems, and fits within your budget. Having the right technology to
begin with ensures success at project’s end.
To have a successful project, you need a clear vision of the
delivered result. You need to know why the project is being implemented. You
need a strong commitment of management to the project. You need to share
management’s vision of how the end results will benefit the company. How will
you discover these facts? Ask!
When your boss comes to you, for instance, and reports that you
are to manage a project to upgrade the mail servers, you need to find out why.
It may not be that the manager really wants the mail servers upgraded; he could
just be having trouble opening a cartoon his frat brother from Utah sent him and
blaming it all on the company’s e-mail system.
When you approach management to find out why the project needs to
happen, you aren’t questioning their decision-making ability. You are, however,
questioning what their vision is for the project. In your company, your
immediate manager may be the most technically savvy genius in the world and her
decisions are always right on target. In others, if not most, managers know that
a technology exists and can be implemented. However, they don’t know exactly
which technology they’re after. Figures 1-3 and 1-4 show the difference between effective
decision-making abilities and poor decision-making abilities.
Well-informed decisions result in success for everyone, not just the
Figure 1-4: Decisions
based on complaints, wishes, and sales spiels miss the mark.
As the project manager, your job is to ensure the
success of your project and your career, and a successful impact on the bottom
line. When you speak with management about the proposed project, you are on a
fact-finding mission. Ask questions that can result in specific answers. For
What do you want technology so-and-so to do?
Why is this technology needed?
How did you discover this technology?
What led you to the decision this was the way for our
company to go?
Sometimes a manager may come to you with a specific problem for
you to solve. In these instances, the project is wider, more open-ended, and
you’ll have to drill deeper into the problem presented. Let’s say for example
that a vice president is complaining about the length of time it takes her to
retrieve information on customers through your database. She just wants it
Your questions may be something like this:
Can you show me how the process is slow?
Is it slow all the time or just some of the time?
How long have you experienced this lag?
Have others reported this problem?
There are several things we can do to increase the speed of the
process. Each may require a financial commitment initially, but would result in
faster responses for all of the database users. Do you want to investigate this
Notice how you’re thinking like an executive. It’s not
technology for technology’s sake. A new multiprocessor database server,
gigabytes of memory, and faster switches are all cool stuff, but if they don’t
earn their keep, they are just toys. When you are inventing a project, think
like an executive of a company and show how the investment in software,
hardware, and talent can create more dollars by increasing productivity,
safeguarding data, or streamlining business processes and ultimately making
As you know, stakeholders are individuals, groups, or
organizations that have a direct interest in the outcome of the project. Your
project’s success or failure will directly affect the way they complete their
work, use their existing technology, or continue to buy from your company.
Stakeholders can include
The project manager
The project team
In a technical project, the largest group of stakeholders is
typically the users. Any project that has an impact on users needs to be
discussed with them. This can be done several different ways. The most popular,
and sometimes most disruptive, is a focus group. Fair warning: focus groups have
a tendency to engage in gripe sessions about the problem rather than the
solution. If you choose this route, take control of the discussion and keep the
participants focused on the solution.
A focus group allows you to take a sampling from users from each
affected department, present the project to them, and then listen to their
input. You need to explain how the proposed technology will be better than the
current, how it will solve problems, and, if necessary, why the decision is
being made to change. Input from focus groups can alter your entire project for
the good or the bad.
Another way to interview users is through an intranet site. This
method can be an effective form of communication because users have the
opportunity to share their opinions and have some say on your project. Of
course, with this route, it’s best to have your intranet site request responses
to a survey so the results can be tallied quickly. See Figure 1-5 for an example of an online survey.
Figure 1-5: An online
survey can quickly tally users’ input to a new technology.
Some project managers rely on the Delphi Technique.
This approach is often used in risk management, but can be applied to any
consensus-gathering activity. The participants and their comments are anonymous.
The participants are allowed to freely comment on the technology, their
concerns, and desires for the requirements. All of the comments are then shared
with all of the participants, and they can agree or discount them based on their
opinions and experience. Because the process is anonymous, there is no fear of
retribution or backlash, or offending other participants. After several rounds
of discussion, a consensus is formed on what is needed. An intranet site can
automate the method and keep users anonymous.
Finally, learn how the users do their work now. This is
especially important for situations like new software development, application
upgrades, and new hardware technologies. This can be accomplished in a usability
laboratory where mock screens, resembling the technology being implemented, are
made available. Feedback from users helps design the solution to be implemented.
By working with a user one-on-one, you can experience how the user is using the
current technology, how the new technology will affect the user, and what the
ultimate goal of a technical change should be: increased productivity and
increased profits. Don’t lose sight of that fact.
Did you enjoy this article?
(total 11 votes)
Comments (1 posted)
Please Comment On This Article
(Posted on November 3, 2011, 2:58 PM Philip Beekley)
- Great text, but the image links don't seem to be working.