Complex IT Project Management

16 Steps to Success

Peter Schulte

• Publisher: CRC Press
• Year: 2003
• ISBN:
  9781135494636
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

Project Managers leading massive IT projects--defined as projects rolling out deliverables across geographic boundaries with budgets ranging well into the millions--need a unique level of expertise and an arsenal of personal and professional skills to successfully accomplish their tasks. Large IT initiatives inherently contain business conditions,

Chapter 1: A Project Is More Than Its Technical Deliverables

1.1 PROVISIONING ISDN

In 1996, I managed a provisioning project for a telephone service provider. The business driver was to push Integrated Services Digital Network (ISDN) circuits out into the residential and small business marketplace in anticipation of increased demand for reliable, high-performance Internet access. At the time, public interest in the Internet was practically nonexistent but expected to blossom, as it certainly did. Besides, the ISDN technology permitted two channels, so that the subscriber could simultaneously make a phone call and surf the Internet or use a fax machine on the same line. Our project scope was to develop a software system that would “automate” the ISDN provisioning process from end to end as illustrated in Exhibit 1.

The system would:

• Be used by customer service representatives (CSR) fielding customer calls
• Validate credit of customers wishing to order ISDN
• Determine if ISDN is available at the customer site
• Issue (once the sale was closed) the necessary orders electronically to the workers who would physically upgrade telephone network components, and reprogram the huge central office switches that route voice and data packets around the public telephone network
• Have to create a billing record so that access and usage charges would appear on the customer’s monthly statement

Exhibit 2 lists the proposed ISDN deliverables proposed by the team after months of analysis.

Exhibit 1. Workflow for Automated ISDN Service Order and Provisioning

1.2 HOW DID WE DO?

The project results were somewhat of a disappointment due to technical issues that were not anticipated, and that, once discovered, proved far too costly to overcome. The end result was a diluted sales order entry system that did not deliver workforce management or automated central office switch programming. ISDN was sold anyway, though not in the volumes predicted by the marketing department. By the way, the engineering group I worked with on this project was simultaneously piloting a Digital Subscriber Line (DSL), and, eventually, rolled it out in numbers far exceeding those forecast for ISDN.

1.3 THE PROJECT IN CONTEXT

Reflecting on this and other experiences taught me to be proactive from my first day on the project, in terms of getting the whole picture and looking for signs that might foreshadow complications, if not failure. As project manager, I take it as my responsibility to anticipate, plan for, and react professionally to all discovered impediments. I believe it makes sense to prepare for that. Much of that preparation is based on assessing potential risk factors. Deploying technology is tough enough, but, for some reason, we tend to start each new project as though the environment itself will not present issues and problems, even though it always does.

Exhibit 2. ISDN Provisioning Project Deliverables

• A client–server system that provides sales order entry, work order generation, and project tracking functions.
• A link to customer and central office databases to validate locations and billing information.
• A link to network asset inventory to check the availability of ISDN at any address.
• A set of tables correctly populated with the data required to set up any given circuit with a user-selected version of ISDN.
• A tariff for these services to be written, and submitted to the public utilities commissions in each of the states served by the telephone company to get approval to provide and bill for ISDN.
• Upgrades to the central office switch software to enable ISDN services.
• Upgrades to the central office switch ports to enable ISDN services.
• Upgrades to the work force management software to allow the dispatch of ISDN certified technicians to perform installations and maintenance.
• A handoff to the billing system to issue proper customer invoices.

The process I adopted, and have since validated many times, is a discovery process based on finding answers to the following open-ended questions. For simplicity’s sake, this process will be referred to as the Big Thirteen. Do not expect to get the final answers the first time you ask each question. You may get conflicting answers. You may change your own opinions as you meet new people, gather more information, or uncover significant nuances that color known facts. The questions are listed in Exhibit 3.

I am no longer amazed at the wealth of information this process reveals, nor suffer embarrassment when stakeholders give me grief for my persistence, or the wonder I may express at unclear responses. Obviously, there is a little stealth embedded in this process. These questions are deliberately open-ended and politely asked even though the intent is aggressive and focused. The purpose is to:

• Uncover hard facts
• Assess the maturity of the project
• Get a feel for the positions and agendas of stakeholders with whom these conversations are held

In particular, this process provides the opportunity to uncover the following:

1.3.1 Assumptions

People on projects assume a lot, much of which gets passed around and adopted as wisdom if not “the design.” This can be very dangerous if assumptions are left untested. It turns out that getting people to verbalize assumptions is the best way to air them out. Errant thought processes can revolve around deliverables, dates, budgets, roles and responsibilities, or risk; in other words, everything.

Exhibit 3. Big Thirteen Interrogatory

1.3.2 Disconnects

This is also known as “following the bouncing ball.” As you solicit and review various opinions, you might experience that somewhat odd feeling that things just are not adding up. At this point, it does not make sense to challenge anyone on these irregularities. Do, however, make note of them for future elevation and discussion as requirements, implementation strategies, and critical path elements start to congeal.

1.3.3 Issues

I listen for phrases like “We could do this, but (or ‘if’, or ‘when’).” Projects are highly dependent on time, resource, budget, and concurrent events in the business or infrastructure portions of your world. Ask enough “what if” questions, follow up with common sense, and you will uncover most if not all potential show stoppers.

1.3.4 Obstacles

The phrase “It is not going to happen” is a signal that further review of the topic is in order. This might be anything from a need for clarification all the way to a quid pro quo such as “What is it going to take to enlist your support and participation?” Other obstacles may not appear as blatant, but they are sure to come. For example, Chapter 13 studies in great detail the resistance from the end user communities you can look forward to.

1.3.5 Agendas and Personalities

Most of your team leads have control over the resource performing the actual tasks, such as router configuration, desktop computer deployment, or application code development. This is because team leads are typically managers of existing work groups with daily responsibilities in development, operations, maintenance, or support. They often feel overworked, underappreciated, and probably understaffed as well. In today’s cost-conscious business culture, they may also feel under the gun to protect or justify their turf. As you listen to their views of the project, reflect on the possibility that they have personal issues or professional agendas that could temper their answers and possibly their behavior and performance as well. Knowing this about your stakeholders is always a good thing, by the way, and can be used to your advantage.

1.4 THE BIG THIRTEEN

What I would like to do now is cycle through the Big Thirteen in detail. You will note references to subsequent chapters where individual subjects are expanded.

1.4.1 What Is to Be Done?

This is your project scope. Scope describes the key attributes of target state. It should only take a handful of declarative sentences to fully describe. Think about NASA’s project Apollo. Its scope was to slingshot Americans to the moon, and bring them back alive with a bag of rocks and some medical and scientific data. The scope was that simple, although, obviously, the project was unbelievably complex and brazen, given the timelines and challenges associated with implementation. It is that complexity that makes Apollo an excellent sample for this section. I would like to use it to clarify what scope is, and is not, and identify the confusion commonly associated with the hierarchy of scope, requirements, and specifications. We would be fine if we saw:

• Scope as the vision or target state
• Requirements as the conditions the project creates to achieve that target state
• Specifications as the deliverables enabling the conditions that create target state

Exhibit 4. Progressing from Scope to Design Specifications

Pictorially, we could represent this hierarchy as illustrated in Exhibit 4.

By applying this approach, Exhibit 5 illustrates how I would view Apollo.

It is important that you understand the following things about scope and the two subsequent generations of offspring (i.e., requirements and specifications).

• When NASA engineers sat down with the project manager to figure out how to implement scope, they first had to discover and validate the requirements, which are listed in part in Exhibit 5. In other words, the requirements elements displayed were the conditions NASA believed necessary to achieve scope, which again was getting the men to the moon and back with souvenir rocks and data.
• Once these requirements were validated, they began looking at what it would take to implement them. Eventually, the elements associated with the specifications listed in Exhibit 5 were developed.

You can think of requirements as the “what” of the project, and specifications as the “who, when, and how” of the project. From a technology perspective, there were many challenges associated with cramming reliable equipment that could withstand a wide range of operating conditions into an unbelievably constrained space. Many of you have undoubtedly heard of all the wonderful technologies that were created or significantly enhanced as a result of the space program. Probably the most well-known offshoots of this project are the silicon chip, microwave technology, the liquid crystal display (LCD), and a commercially marketed instant orange drink. If you look at Exhibit 5, you can see how these “products” would end up as specifications in that they served as the means of enabling the conditions required to achieve scope.

Exhibit 5. Project Apollo Scope, Requirements, and Specifications

The mistake that too many project teams make in the information technology (IT) world is to confuse requirements and specifications with each other and with scope. Put bluntly, it is as though the NASA Apollo team made the invention of an instant orange drink a project requirement, or even part of scope. The consequence of this common but egregious misstep is to make the invention of the drink a project dependency. Put more deliberately, the project team in this case would have decided that if a “just add water” orange drink could not be invented, no one was going to the moon!

The important lesson here is that to meet scope, these guys had to be brought home safely. Because this trip would take a week or so, clearly food was in order, thus the requirement for nutrition as Exhibit 5 shows. What that turned out to be was almost inconsequential, at least until the nutrition subteam was turned loose on the requirement, and they devised menus that would be ready to eat and take up as little space as possible.

All too often, in the IT project world, we see people take specifications and treat them as scope (i.e., the details of meeting requirements become the project). The danger is that people often rush to specifications without going through the flow described in Chapter 2 and, in a sense, ignore scope and requirements. It would be akin to Project Apollo becoming all about instant drinks, not about getting astronauts to the moon and back alive.

1.4.2 What Are the Benefits?

In other words, why are we doing this? What value is received for the investment in financial and human resource made to implement scope? Laudable government projects like Apollo or the magnificent but lamented World Trade Center are poor examples for this discussion because public projects do not normally have the same goals as IT projects. Most IT projects are largely, if not exclusively, driven by business objectives that typically are to:

• Solve problems
• Increase productivity by making data and IT processes more available
• Increase productivity through error reduction or automated audit trails
• Automate manual processes or streamline existing automation
• Consolidate processes through platform integration
• Lower costs by replacing costly-to-maintain legacy hardware and software
• Leverage newer technology for one or more of the preceding reasons
• Increase revenues and margins by improving the customer experience

This book is aimed at complex IT projects, which typically require dozens if not hundreds of team members, and cost upward of $100 million. They tie up resources for months and years. They drain corporate cash for that same timeframe, or longer, because project costs are absorbed long before benefits are realized.

As project manager, you must understand the benefits expected from the project you have taken on, because you are accountable for delivering those benefits. It is very easy to get caught up in the technology issues that naturally dominate the physical aspect of any IT project, whether it focuses on systems, networking infrastructure, desktop computing devices, and so on. Unless the development, procurement, integration, deployment, testing, and documentation activities undertaken to deliver these benefits actually do so, however, what have you accomplished? If that new payroll system you rolled out does not make the process any more efficient or useful than the 20-year-old mainframe system you replaced, what new doors has your project opened for the corporation, or for you and your key team members?

Think of it this way. Some high-level executive signed off on your project, probably after having been asked for similar or larger sums for other projects at the same time. After a while, they must get pretty tired of these requests, and ask some pretty hard-nosed questions to justify an investment they too will be accountable for, at least theoretically. If I had to go before a CIO of a Fortune 100 company or the governor of a large state, I would definitely be prepared to explain why that $50 million should be given to me over any of other supplicants lined up outside that executive’s door. Throughout the book, particularly in Chapter 13, the importance of understanding and being able to articulate the benefits of your project in the most practical business sense will be put in context.

When I took on the ISDN project described earlier, I asked and was given the following intended benefits expected from that implementation. Just as a refresher, we were tasked with creating a system that supported the end-to-end sales and implementation of a specific public telephone network service. The intended benefits were:

• Support an aggressive sales campaign by making the process of installing circuits, always a challenge in the telecom business, more efficient.
• The customer was intended to benefit from the automation through a drastically reduced circuit installation time.
• Internal work groups were expected to benefit from the automation through higher productivity, lower error rates, and access to real-time data, including the status of any given circuit installation.

You must understand and become facile at proselytizing your project’s benefits. They should guide how you interact with project stakeholders as discussions and documentation emerge in terms of designs, schedules, funding issues, and risk management. This is best illustrated with the following story. Suppose you are asked by a manufacturer of modest quality watches to manage a project where the scope is to design a new watch that falls in the high end in terms of price, elegance, and cache. When you ask about this clear departure from the standard product set, you are told that the benefits your employer seeks are:

• The right design will allow the manufacturer to break into the fancy watch market.
• Sales in that market enjoy much higher revenues with increased profit margins than the company currently generates.
• The company would be less reliant on the more volatile and competitive low end it has traditionally targeted.
• Existing customers can be “up sold” to the higher-priced model instead of losing them to the competition.

You put the team together, you hire consultants and engineers, and you labor mightily. Just before the deadline arrives, you go before the CEO and present your design for that new watch, and a factory in which it can be produced! The CEO is relatively satisfied ...

Table of contents

• Cover Page
• Other Auerbach Publications
• Title Page
• Copyright Page
• Preface
• Chapter 1: A Project Is More Than Its Technical Deliverables
• Chapter 2: Learning Requirements Is Our First Priority
• Chapter 3: Using Technologies to Meet Requirements
• Chapter 4: Devising an Implementation Strategy Precedes Scheduling
• Chapter 5: Plan B Is an Integral Part of the Project Plan
• Chapter 6: Writing the Plan
• Chapter 7: How to Status Your Project
• Chapter 8: Managing Project Information
• Chapter 9: Manage Your Dollars
• Chapter 10: Understanding and Managing Vendors
• Chapter 11: Manage Your Turnover
• Chapter 12: Handling Your Team
• Chapter 13: Managing Customers and Beneficiaries
• Chapter 14: Handle Your Management
• Chapter 15: Lessons Learned
• Chapter 16: Becoming the Project Adult