Juggling Project Time in the Real World

In the scope of our experience, the various IT teams we've worked on have been small-ish and incredibly overburdened with projects. On top of that, very little time could actually be devoted during the day to working on projects due to user problems and what we've begun to call 'drive-bys' (more on that in a minute). If, in fact, a person did find time to work on a project, it was usually after working hours when there was time to fully concentrate on the tasks .

As for project planning and good quality systems analysis and design? Fuhgeddaboudit! Generally speaking, based on the size of the organization, IT shops are either:

• Heavily segmented into IT job categories such as application development, open systems (UNIX, Linux, and Windows) server support, mainframe and mid- sized computer support, help-desk and PC-technicians, database administrators and so forth, or

• An all-one-shop that has one or two people working each type of the above job duties .

We have never run into a company that has a dedicated project team staffed with individuals from various IT persuasions, ready and anxious to work on projects, but we don't suppose that's an altogether bad idea. In any event, most companies staff IT with an eye toward maintaining the day-to-day IT activities and then only secondarily with IT projects in mind.

Drive-Bys-the Non-Project Project

In the IT world, people are often involved with very small teams of people that have an expertise in a given subject here or there and that contribute to the overall health of the network, application development unit, or customer care center simply by bringing forward those bodies of expertise. You may, for example, be on a team of server administrators that has an email admin who basically does nothing but handle the email server farm on a daily basis.

Additionally, you've probably got a backup person, someone who manages the file-servers, probably a database server administrator, and a security/perimeter person (running the antivirus, firewalls, DMZ, etc.). Additionally, you probably have some enterprise-class apps running such as an ERP system-requiring some specialty administrators.

The point is, none of these individuals have time for projects! And yet, if you work in shops like I've worked in, you must make time for projects that come your way. So you somehow apportion your day in order to get your routine server work done, plus your project work. But then, your boss comes by and wants you to drop everything so that you can go work with the guy in the attorney's office who's having a problem connecting to the email server.

Ever had that happen to you? Things are going along fine, and then, wham-o, you have to spend the next (important) two hours working with someone who doesn't understand how to drive Windows XP and Outlook 2000. Now you're way behind in both your project and your routine work.

Someone I work with gave these little boss re-directions a great term : 'drive-bys.' The boss swings by on his way to another meeting and says 'By the way, can you run by so-and-so's office and check what's going on with his computer? He keeps calling me!' You're not on the PC technician team, but today you're a PC technician and everything else suffers for it!

Here's the important element: How do you project plan for the inevitable drive-bys? In the scheme of things, when thinking like a project manager who has at your disposal a small team of admins, how do drive-bys fit into the whole resource-planning scheme?

This is tricky and, I think, somewhat isolated to IT shops. There's just only so much expertise to go around.

One way to deal with drive-bys in your resource planning efforts is to create a 'project' called 'non-project work.' Your human resources will keep track of the time that they spend on drivebys by keying in tasks that they perform on a day-to-day basis that have nothing to do with the actual project itself. Included in these tasks will, of course, be the hours spent on the task. Thus, as the end of a pre-designated period, you can easily show how the drive-bys erode the total time allotted for a project, the result of which is a project that ends after its designated due date.

 

Since that's the situation, and you're concerned with juggling a busy IT shop's time so that you can get projects done, you need to understand time appropriation in the average IT shop's day.

Server Administrators Most server administrators begin their day by checking each of the servers' log files to make sure there are no glaring errors. If there are errors, then, of course, they have to spend time figuring out what happened and how to rectify the situation. After that, server admins usually have several trouble calls they have to work on. (For example, so-and-so can't log on because his password has expired or the account is locked out due to too many login retries.)

After all that, if there's time left in the day, a server admin is available to work on new projects.

Database Administrators Database administrators (DBAs) also begin their day by checking each of the database log files to make sure nothing's wrong. If there are errors, they also have to spend time figuring out what happened and how to rectify the situation. After that, DBAs work on performance tuning, writing stored procedures, maintaining indexes and triggers, and working on new requests for column additions or deletions.

DBAs begin any new project work by developing a database schema , the initial layout and design of a new database. The whole database design component can be quite lengthy because it entails taking what the customer is requesting and converting that into a sensible database layout. Part of this effort includes the task of normalizing the database-reducing each table in the database to the elements that most logically belong to it. Also, the notion of relating the tables by one or more keys also takes a great deal of time, especially when dealing with substantial databases.

Application Developers Usually you don't have the luxury of scheduling your applications programmers because they're sitting around waiting for something to do. Most programmers are busy working on other projects so it can be quite challenging to round up the help you need to get some development work done.

On top of that, your programmers may have different languages they're familiar with as well as different levels of experience. For example, your project might require a Java programmer with a good body of background experience-one who's able to quickly get several modules written and functional while operating under a relatively short deadline. Clearly, a C# programmer couldn't fill the bill, nor could one with very little Java experience. You don't have the luxury of waiting while a more junior coder figures out how to write a certain piece of code.

Additionally, development shops typically aren't staffed to maximum capacity and, as if that's not bad enough, the senior, highly experienced folks are usually heavily engaged. They barely have enough time to answer a question from the junior folks, let alone take on another project module. The whole of this leaves you as a project manager scheduling key project tasks very far out there unless, of course, your project takes priority over everything else and managers tell the development department to drop all other work until your project is complete (not likely).

Telecommunications and Internetworking Specialists Very frequently telecommunications and internetworking folks are not even considered to be a part of the IT shop-they're a separate arm, reporting to a different manager. But just as frequently they're needed for your IT projects. And just as frequently they're extremely busy with other priorities and projects.

Data Normalization and Conversion Takes Serious Time!

Some engineers in your company have created an Access database system that has become quite useful to their department. As a consequence, two things have transpired: The system has been significantly tweaked and refined so that it's extremely complementary of the tasks the engineers are trying to accomplish and, as a result, there are between 30-50 people at any one time trying to access the system.

The problem is, Microsoft Access just doesn't scale well to such large concurrent user numbers . Access wasn't designed for that kind of use.

So now you're faced with an engineering department business request to take this system and convert it to a Microsoft SQL Server-based environment. SQL Server has a cool utility in it called Data Transformation Services (DTS), made just for the purpose of migrating data such as Access databases into SQL Server.

During your business requirements analysis, you ask a DBA to take a look at the database itself. She brings back some startling news: the engineers have done a great job of assembling a system, but they clearly have no idea about data normalization. The screens and reports are nice but the database itself is a mess and is going to take significant time to convert to a well-crafted SQL Server layout. She'll have to examine the Access database in order to figure out the best schema for the SQL Server database, then perform complicated data conversion routines to get the data into the proper tables and columns. Her estimate is 3 weeks just for this part of the project! Then there's the whole issue of recoding the reports (because they point to a new data source with columns that are in different tables) and screen redesigns.

There are also difficulties in making sure that the current SQL servers can handle the additional load and setting up new ODBC connections.

Microsoft Access (and to some extent programs such as dBASE, FoxPro, and FileMaker Pro) has made it very easy for neophyte users to create quick and dirty systems that meet a business need. But very often the number of users outgrows the capability of the system to meet everyone's needs. It is then that the IT shop has to get involved and spin up a project to convert the system to something with a little more horsepower. Users are almost always surprised at the amount of time that the project's going to take. It was simple to build-why isn't it that simple to convert?

 

All of this may sound very doom and gloomish. How can you ever expect to get a project fully staffed and going if you have to wade through a labyrinth of scheduling difficulties? Part of the answer has to do with corporate priorities. If your project is an important one and you have a clear mandate to bring in the deliverables on a certain date, then you've got leverage power to get the people you need to help. However, this leverage depends on whom the mandate is from. If, for example, the project emanates from the marketing department, you might be given a huge sense of urgency by the department's manager, but others in the organization don't share that same rush-rush feeling about it. If, on the other hand, the project you're on is something that the CEO wants to see happen right away, then you're going to have fewer problems lassoing the folks you need.

Managing projects in IT environments can be quite challenging simply because you don't have dedicated staff and the people you do have available may be unavailable for certain lengths of time. It's important that you clearly examine project schedules based on current workloads and communicate real expected finish dates as opposed to those that are overly aggressive .

Case Study: Chaptal Wineries-a Closer Look at the WBS

After looking over your manually created WBS (Chapter 3) and thinking about the dependencies and dates, you've realized there are areas you need to expand, timewise. For example, if you're going to be the one doing the server installation and user training, you're going to have to fly to each location, do your business, then fly to the next. Considering a flight from France to Australia, you've got a minimum of 2 days on the airplane, plus the configuration time to get the server up and running. Then, you have to turn around and do the same thing again for user training, again planning on flight time as a huge part of the task time estimates.

The server installation itself should go fairly smoothly. Using Microsoft Windows Server 2003 and Exchange Server 2003, you'll set all locations up as distinct sites in the same organization. Provided WAN connectivity is set up and working, you should have few issues with the actual software installation. You'll also be setting up Internet Information Server (IIS) 6.0 as the intranet base web server while you're at each foreign location. You believe you can accomplish all installation work in 2 days' time per location and you've given yourself an additional day for any issues that might arise.

You're trusting the local internetworking vendor to handle the internetworking gear installation, as part of the contractual provision. Who better to install a Cisco router and get it working in France than a French Cisco system engineer (SE), for example?

Provisioning the WAN connectivity through the various local telcos seems to you to be the sketchiest part of the whole project. You have to work hand-in-hand with the local winery representative, mostly to provide you with telecommunications company contact info , to relay you important documentation, to give you anticipated installation lead times, and to make sure that the contracts are signed and installation dates set. Still, T1/E1 circuits are the bread and butter of most telcos-you don't anticipate major delivery problems in the 30-day time constraint you've placed. Budget is not a huge priority relative to the WAN circuits. Kim knows you need them, and you're not asking for anything huge in terms of bandwidth (a T1 circuit runs at 1.544 megabits/second).

After installing a copy of Microsoft Project 2002, you whip up your project schedule, keying in the changes and setting up what you believe are accurate task durations and predecessors. The graphics below show the output: the WBS and Gantt chart, respectively. A Gantt chart is a bar chart that shows the relationship between the project tasks and time. Project managers like to use Gantt charts because they quickly give people a visual representation of the tasks and how they play out over time. Project management software can automatically generate Gantt charts , along with the coupling lines that show interesting project features, such as milestones. The main program window in a Microsoft Project screen shows the tasks in the left-hand pane and the Gannt chart in the right-hand pane. In the graphics below we show the two panes one beneath the other.

You've included the Early Start, Late Start, Early Finish, and Late Finish columns so you can understand how Project calculates them (based on the predecessors) and what your floats are.