Does the Project Have a Reasonable Deadline? - Administration

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.

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.

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.

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.

Questions to consider:

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.

Figure 1-2.  Project managers must question all aspects of a 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.

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.

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.

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.

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

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.