Establishing the Project Requirements

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 gripes.

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 budget.

Are There Industry or Government Sanctions to Consider?

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 work.

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 all.

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.

Possessing Multiple Personas

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 Software?

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 compatibility issue.

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 each.

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.

What If ?

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.

No Other Choices?

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 happens.

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.

Interviewing Management

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 .

Figure 1-3: Well-informed decisions result in success for everyone, not just the project.

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 example:

• 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 faster.

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 route?

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 customers happy.

Interviewing the Stakeholders

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

• Management

• The project manager

• The project team

• Project sponsors

• Customers

• End users

• The community

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.