6.3 Starting the Schedule Build

< Day Day Up >

This is not to say that if you follow the process advanced in this book, scheduling is easy - it is not. In fact, let me warn you that if you wait until you are drafting a schedule to figure out how everything falls together both logically and from a calendar perspective, chances are the resulting plan will be a jumble of tasks that is practically indecipherable and essentially useless to anyone other than the plan's author.

Where you begin is with your rolled-up implementation strategy. The idea is to take its main components and lay them out with only one or two levels of detail. Critical dates are assigned to these plan segments, and any key relationships, such as dependencies or linked task dates, are identified at this time. At this point, you may only have a plan with a few dozen "tasks." That is most desirable in that the relative dearth of tasks makes it easier to maneuver major deliverables and dates without the encumbrance of all that detail.

This process should start out as a paper and pencil exercise, and will be illustrated with the Vendor Management project described in Chapter 4. That initiative's rolled-up implementation strategy had four components, three of which will be referenced throughout the rest of this chapter:

Facilities had a primary site build-out including a data center, a call center, and most of the operations support staff. A secondary, remote site was specified for the telecommunications supplier support staff. The backup disaster recovery (DR) data center was to be housed there, too.
The operations deliverable consisted of developing a staffing and operations model, hiring to that model, and implementing it.
The technology component consisted of a functional design to support the statement of work (SOW), including order processing, publishing specified data to an internal Web site, and automation of supplier communications. There was also an infrastructure component featuring requirements for networking, two data centers, a call center, and disaster recovery (DR).

At this point, I find it incumbent to draw up the project like a process flow. That way, you can really visualize and thus validate the logic behind your implementation strategy. What logic? Well, for instance, do dates work? Are you relying on a single resource or team to do too much, or be in too many places at once? Also, as you look at the project from a logistical perspective, you begin to think about key issues like lead times. That is why you start your actual scheduling on paper with only a few moving parts because it is best to validate the big picture before trying to fit in all the little pieces.

The first schedule looked like the one in Exhibit 3. ^[1]

Exhibit 3: First Draft: Vendor Management Project Plan

Month	1	2	3	7	8	9
Facilities	Call center fit out		Incorporate technology as available
	Main data center fit out		Complete data center installations, connectivity	DR test	Move into full production
	Backup data center fit out		Complete backup data center installations, connectivity		Move into full production
Operations	Staffing plan approved	HR hires against requisitions submitted by program manager
Technology development	Complete design		Develop and/or integrate hardware and software	Testing		Production
	Hardware, software ordered and installed			Testing
		Call detail reporting service bureau goes live
	Procurement Web site requirements complete		Develop procurement Web site and review with customer	Complete development and UAT^[a]		Production
	Reporting Web site developed and UAT^[a]				Production	Production
	Develop EDI^[b] requirements		Deliverables TBD:^[c] assumed rollout in year 2 or 3
^[a]UAT = user acceptance testing ^[b]EDI = electronic data interchange ^[c]TBD = to be determined

Keep in mind that now we are discussing the main project schedule from the project manager's viewpoint. Presumably, team leads are developing detailed plans for specific requirements while we are looking at the big picture. This is mentioned to give perspective to the unsettling comments about to be made about this first attempt at scheduling this extravaganza. After I made this first pass in real life, I was quite unnerved. I immediately felt compelled to find out whether team leads were addressing some painfully obvious gaps.

My problem was that I could not see how all this was going to come together. When I cast my mind's eye on the call center component of target state, I saw a room full of help desk analysts and other support personnel logging into terminals, looking things up with the technology, and conversing with end users and service providers via telephone or e-mail. After all, scope calls for this. The troubling question is: where does the schedule show when this call center vision will be constructed? If you look back at the schedule, you will discover that it does not. What, in fact, we have just uncovered is a scheduling dependency between the technology build-out and call center target state, not to mention the fact that I failed to document that in the first cut.

Speaking of the operations staff, it seems reasonable to assume that they will need training on the technology, as well as the call center procedures they will be asked to perform. When you talk about training, you think of curriculum, an instructor, a classroom full of local area network (LAN)-attached personal computers (PCs), and possibly other teaching aids as well. When does the schedule indicate this will transpire? It does not.

Our solution dictates two data centers with a DR procedure. That means that either the two sites are connected to allow data refreshes to the backup computer systems, or we overnight backup tapes from the primary site to the secondary one. When will that design be complete? What are the scheduling implications of buying a T1 circuit to connect the two sites versus mailing tapes as the DR strategy?

Although one can deduce other issues from the first draft of the Vendor Management schedule, these three should be sufficient to support this section's main thrust. Once again we are reminded that our charge was not to build a handful of finite, stand-alone technologies. Instead, we were tasked with constructing an organization that would be able to perform a specific list of functions described in the contracted SOW. To recap those duties, the target-state business tasks were to:

Process specific types of orders with clearly identified suppliers.
Validate subsequent invoices.
Process them for payment.
Charge the user for the cost.
Report on all these activities via a new Web site.
Provide a second Web site for customer procurement activities.

Indeed, we decided we would need a call center, two data centers, and a technology platform with software and a backup process to execute these duties, but that is the "how" of the project, not the "what." In Chapter 1, requirements were defined as the conditions the project must create to successfully execute project scope. This is the preeminent reality of technical projects, a reality I believe does not adequately drive the "planning process" in most projects because people tend to focus on the "how" often to the exclusion of the "what." I highly recommend another way of looking at this, which is to consider the project "how" to be the technology enablers of target-state business processes, which, in turn, comprise the project "what." Our client often stated that he did not care if we used computers, or monkeys, as long as the business deliverables were turned up complete and on time.

^[1]Kindly note that the "customer-facing process" component was omitted for brevity's sake.

< Day Day Up >