6.11 Managing Team Lead Plan Detail

< Day Day Up >

So, although you are tasked with building a master schedule that documents the critical path and its milestones, you still should be concerned about the subteams' plans and schedules. They are responsible for the quality and timeliness of their work. Obviously, you need to have a level of comfort that their planning is adequate in terms of feasibility and coherence. How do you do that, especially if you are not all that familiar with how to construct a network, for instance, or build multiple Web sites?

First, let us define the mission of which two components are intended to determine whether:

All bases are covered in the subteam plans
Those plans are realistic

Never assume that either is true until you have undertaken some kind of inspection process. Let us start with completeness first. Virtually any technical project implementation has a generic, ritualistic quality about it. In other words, the elements listed in Exhibit 10 should be embedded in any project calendar. You can inspect for these elements and engage the team lead in conversations regarding the status of his or her scheduling for each of these "events."

Exhibit 10: Required Elements of Detailed Scheduling

Gather requirements.
Create design.
Get technical, business, and financial approvals.
Order equipment, licenses, tools, consultants, etc.
Build or install, and "unit" test.
User acceptance testing (UAT).
Train users and support staff.
Put into production.
Complete documentation.
Hand off to operations support.

This list should not be construed to precisely represent each subteam's project plan. Depending on the deliverables, some of the preceding items might be minimized, if not trivial, while others, once detailed, would make the Manhattan phone book look as simple as the bill of fare for a hot dog stand. Be that as it may, each item requires exposition and validation. When reviewing a subteam plan for completeness, examining these ten areas is a relatively simple process. Because you do not want to come across like an Internal Revenue Service auditor, it is best to take a conversational approach. For example, when reviewing item four, procurement, consider asking questions such as:

How long does it typically take this vendor to perform once they get our purchase order?
Is this product constrained?

At some point, you should be comfortable enough with the process that you can get a good feeling about the schedule and move on, or move in with more pointed questions if a subteam plan component appears deficient to you.

Unfamiliarity with a technology can make you feel ill prepared to engage in this process. If this is the case, you might care to revisit the self-education process in Chapter 3, especially that section named "Understanding Implementation Requirements." In that discussion, IP Telephone was used as the technology straw man. I had never worked with it before, so I queried the IP Telephone team leads and skimmed the administrator's manual on the manufacturer's Web site. From an implementation perspective, I learned that, with the exception of the back office infrastructure, rolling out IP Telephone was pretty similar to installing more traditional telephony in a corporate site. That is a process with which I was familiar; it is fairly well documented in the trade press as well. As a result, I understood IP Telephone basics enough to at least have an intelligent conversation about their implementation plan.

The other thing you want to review subteam schedules for is feasibility. Not everyone who puts a plan together steps away from it far enough to see if it really makes sense. In fact, offering to lay your eyes on their plan, as a quick sanity test, is a good approach to getting access to their plans. To a large extent, that is what feasibility is all about - wondering aloud if the schedule hangs together, or whether there is possibly excessive wishful thinking over and above the optimism one would expect to find in any schedule. Here are five fertile grounds for exploration:

Dependency. When a schedule is linked to the output of some other process, two concerns arise:
- Timing. Can any dependency reasonably be expected to occur at the date your project needs it to? An example is waiting for a global update to middleware that delivers mainframe data to Web servers, a process where you need to put up new Web sites as one of your project deliverables.
- Actual output. Are we certain that the dependency will deliver as promised? If that middleware dependency is critical to our project from a data perspective, can we be certain that the middleware will deliver the data in a format, time cycle, and completeness that meets our specifications?
Resource allocation. For many IT processes, such as application development, estimating timeframes is notoriously difficult. Chapter 9 presents some specific ideas on this topic. From a scheduling standpoint, one should take heed that not every problem can be solved by throwing dollars at it. In this case, that would mean adding programmers after panic over deadlines sets in. There is always a learning curve associated with recruits. Toward the end of the schedule, the curve can be quite steep. This is doubly dangerous because incumbent staff productivity diminishes when tasked with bringing the rookies up to speed. Therefore, it is best to walk through resource assumptions with the team lead when reviewing this portion of his or her plan.
Resource skill. Superstars are in short supply, so overcommitting a key manager or subject matter expert can lead to the point of diminishing returns. If this key individual hits the wall before the work is complete, misfortune may soon follow.
Scheduling logic. You might feel hamstrung if the subteam's technology is not well known to you. There is no crime in reviewing a schedule and asking this very simple question: when does this thing come together? Ask team leads to walk you through their critical paths, and to highlight the key features of their milestones.
Contingencies. Engage the team lead in a discussion about where their schedule is tight and where slack might be found. You want to avoid the intimidating air of a military white glove inspection. Try to identify with your project partner where trouble may crop up and, conversely, where cushions may exist that could be borrowed from later.

I once had a very complex project for which I put together my first schedule 6 months before implementation was to start. After eyeballing it for a while, I went to the Networking team lead and said, "It looks to me like your team will have to wire up one floor a week for 37 consecutive weeks to meet the schedule. Am I right? And if so, is that doable?" He appeared a little taken aback at the question, perhaps because it was so early. Eventually, he came back and requested funding for additional resources. This is how you want it to work. Although I was fairly sure that he would have to knock off a floor a week, I had no clue whether he thought so too and, if so, whether he was adequately staffed for that workload. I did not know this manager well at the time, so I definitely wanted to avoid creating the impression I thought he was dumb or unprepared. It turned out he was neither, but one cannot expect to be that fortunate all the time. Remember, my job was to help him and all the other team leads to be successful with any means at my disposal, so that requires tact while not being too bashful about checking everything out as far in advance as possible.

< Day Day Up >