1.4 The Big Thirteen

 < Day Day Up > 



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

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

Exhibit 4: Progressing from Scope to Design Specifications

start example

click to expand

end example

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

Exhibit 5: Project Apollo Scope, Requirements, and Specifications

start example

click to expand

end example

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.

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 with the watch design, but is stunned that you have also created a factory design she would have to invest hundreds of millions of dollars to build. When she asks about the factory, you say:

Well, we think we came up with an excellent watch, as you can see. Upon further investigation, however, we determined that our current manufacturing processes cannot produce this design at a profit. In fact, no one in the world could, so we went ahead and figured out the best way to produce the timepiece!

I think it is reasonable to say that you completely missed the boat. There was no mention of creating a new factory as part of scope. Plus, the proposed factory cannot be associated with any of the professed benefits, and, in fact, violates the intent to enhance company profitability. Too many times, we see this happen in real-world IT projects, although it is not usually this easy to see through the thick clouds of techno-babble hanging over complex projects, particularly at the beginning. What happens is that designers get so far into innovation that they lose site of the intended benefits. The project manager should have asked, in the watch scenario, if we could produce it at a profit in our current factories. Once told that was impossible, the design should have been scrapped, and the designers instructed to come up with something that could be profitably made with legacy processes.

If the design is so innovative despite the manufacturing issue, it might make sense to go back to the CEO, early, and tell her about the exciting new product that would require a new manufacturing process. Perhaps she would buy into it, though she probably would not.

This common project "flight of fancy" can be detected and deterred many ways, but keeping project benefits in mind is perhaps the best one. Remember, the initial presentation of this benefits question is: "Why are we doing this?" Proposed requirements, designs, and future state operating models, all normal components of the design process, must always be vetted against scope and intended benefits, among other things, to keep this sort of debacle from happening. Brainstorming is great, but someone has to apply the rules of logic and common sense, no matter how complex the project is. That person is you, as project manager. Understanding your intended benefits, and using them to "sanity test" emerging design proposals, is an extremely powerful tool.

1.4.3 Who Benefits?

If we follow up on the previous question, quite naturally we want to know who is targeted to receive these benefits. In complex projects, there may be multiple beneficiaries who are variously intended to receive some or all benefits, so using a precision questioning technique is imperative. Do not stop asking questions once you learn, for instance, that the finance division, or manufacturing plus the European sales force are the beneficiaries. Find out what they do so you can get a context for how these benefits fit into their legacy worlds. We will develop these thoughts in later chapters, but it is not too early to start getting a feel for what these folks do and how they do it so you can begin attacking the planning tasks coming your way.

Be aware from the outset that beneficiaries cannot be assumed to be passive, willing to participate, or enthusiastic about your project. They will eventually reveal their intent to be active players in your complex project and will probably try to dictate the final shape of the project, up to and including major changes to scope and the project calendar. They are also likely to feel inconvenienced by the changes you will impose on their world. Not that it is easy, but you should make the effort to turn them into partners. Do not allow them to maneuver themselves into the position of project victims, a common tactic to be examined later. Should they do so, you are looking at costly and possibly very damaging scope creep.

The actual beneficiaries may surprise you, and for any number of reasons. I participated in a project that connected an existing transportation system at an airport to nearby commuter rail lines served by two railroad agencies. They turned out to be the most vocal of beneficiaries, even though the traveling public was considered the real beneficiary.

1.4.4 Who Is the Customer?

The customer funds the project, although in major projects the customer is generally not the beneficiary. This is because big initiatives are usually dictated from on high to support strategic business objectives that the end user or beneficiary plays little part in determining. This could be the result of a consultant's recommendation, or the way a committee determined how to address an issue like Y2K, which in many instances was akin to swatting flies with a sledgehammer. Suffice it to say that understanding the relationships between customers and beneficiaries will go a long way toward helping you filter out the noise and negotiate your way through the swamp of scope creep. See Chapter 13 in particular for additional information on this fascinating group of topics.

1.4.5 Who Is the Sponsor?

This person is often called the "program manager." Regardless of title, it is best to consider it a political position, not a turbocharged project management slot. Sponsors typically have many projects on their plate that may comprise a program, even though the projects may have few interdependencies or other familial linkages. Normally, you would expect the sponsor to be motivated to evangelize your project. You might ask this individual to smooth ruffled feathers for you when organizational boundaries are compromised, or beneficiaries or customers start flexing their muscles. The sponsor would normally be your first point of escalation for challenges to your scope and budget as well.

I would consider all these expectations as the best-case scenario when it comes to sponsors. Due to the position's political nature, minimizing bad press is usually the sponsor's biggest concern. That is followed closely by juggling moneys among his or her various projects as contingencies and other misfortunes arise. Ensuring that the results of your initiative are picture-perfect will, of course, be important to your sponsor, but to what extent your sponsor will go on your behalf is largely dependent on how visible your project is relative to the other initiatives on your sponsor's plate. Having said all this, does it not make sense to check out your sponsor in this regard to understand how solid his or her support will be? Chapter 14 contains tips on how to do this.

1.4.6 How Will the Deliverables Fit in the Legacy Environment?

It is quite possible that your rollout will raise compatibility concerns or other potential conflicts within the legacy environment. In the ISDN project, our software development manager decided to build the system using a client-server architecture. This made sense because the back-end processing was on mainframes, and, in 1996, this was how such things were done. Our problem was that we were ultimately forced to replace hundreds of desktop personal computers (PCs) for employees using the new system because their legacy PCs had less processing power than today's cell phones and were, therefore, incapable of handling the demands of the proposed system architecture. So, while the choice of client-server was an enlightened design decision, it resulted in the budget taking an unplanned and significant six-figure jolt. This made the system design a not-so-welcome choice from a project management perspective.

Perhaps you have experienced more current but similar fit conflicts with desktops, operating systems, browsers, or emulation packages. The point is not to disparage any product, but to alert you to the common project challenge caused by the churning of technologies that sometimes creates design or integration issues. Do not fail to ask this question many times because the fit issue can show up embarrassingly late, and require significant money and too many meetings to resolve once it lands on your doorstep.

If you recall the watch design project mentioned in Section 1.4.3, you can see how the logic applies to the question of compatibility, too. Sure, the new watch design is dynamite and perhaps breaks new ground, but we have no way to produce it without building a new factory. It sounds like a poor fit, does it not?

However, do not be cowardly on this issue. Some projects justifiably push the envelope in terms of fit, whether or not that was the intent. In other words, the challenges of working around fit conflicts may well be justified by project benefits. This is, of course, why we must understand presumed benefits before looking at fit. It could turn out that our hypothetical watch company CEO becomes enamored of the groundbreaking watch design and decides to invest in the new factory based on the enormous potential the CEO sees in your watch. One does not expect the corporate world to be that entrepreneurial, but it does happen.

If potential fit issues come to light, you, as project manager, are obligated to capture and analyze them. They are likely to emerge in the following:

  • Usability. On one of my projects, the programmers chose to use a certain browser technology that best suited our needs. It turned out that this particular brand (and revision level) was not as ubiquitous in the global environment into which our application was to be deployed as we initially thought. The expense of upgrading the whole environment could not be cost-justified by the benefits of our initiative because we were talking about having to upgrade tens of thousands of desktop computers. Instead, we had to rework our system architecture using the legacy product that was back-revved practically to the level of obsolescence. This caused us a great deal of trouble because the functionality we were tasked with delivering was far more difficult to achieve with the older technology.

  • Compatibility. Historically, when manufacturers upgrade their operating systems (OS), backward compatibility (i.e., the ability of older applications to work flawlessly in the new operating environment) cannot be assumed. If your rollout is based on using the latest and greatest OS or other base workstation client applications or tools, significant investigation, testing, piloting, and rework should be anticipated.

  • Business considerations. Business as usual (BAU) activities that your project has zeroed in on may be extremely complex. In another project, we were tasked with converting call detail reporting (CDR) from paper to CD-ROMs and an internal Web site. CDR is a process whereby outbound long distance calls are captured from individual site telephone switches so that the cost center associated with the originating caller can be charged for each call. This was not a trivial task given that the volume from the hundred or so in-scope sites was millions of calls per month! Plus, there were other uses for this data, including budget forecasting and fraud investigation. The legacy process from which we thought we were converting was far more complex than we understood, so simply converting the publishing process from tons of green bar paper to the electronic media of CD-ROMs and the new Web site was just a third of the total work effort we should have examined.

  • Support. The question of support is number 12 of the Big Thirteen, but deserves mention in the Fit area. With complex projects, the ability of your organization's BAU support infrastructure to absorb your deliverables is a concern you should proactively eliminate rather than assuming it to be a nonissue.

  • Calendars. There will be times when your project calendar is your most important reality. Never assume that it will synchronize with the environment in which your project is gestating, however. I once had to delay one of our significant deliverables by 3 months because the e-mail infrastructure of the whole company was undergoing a significant change. The nature of this upgrade required that we delay the changes to the corporate network we were about to make. Making matters worse was our learning of this conflict at practically the last minute. This led to some tricky recalibrating of our timeline, as well as a few tweaks to our design.

Although you are no doubt cognizant that a lot of projects are going on in your shop, never assume that there is a really smart person sitting atop the heap who understands the potential conflicts that can result from all these concurrent activities. Not that those at the top are not smart, but it is fair to presume that they are not technically savvy enough to look down at all these activities and recognize pending issues that can derail one or more of the multimillion dollar changes that are constantly under way.

As a good project manager, you should be on the lookout for this risk. As you go through this book, you will read of many such instances and the lessons learned. The bottom line is that, once educated on fit, you may need to ensure that the appropriate changes in plans, schedules, budgets, and possibly even scope are made in consultation with stakeholders and executives. These changes may be required in other projects as well. Naturally, you will be tempted to lobby for your own needs to the detriment of other initiatives. There is no good answer as to whether this understandable parochial behavior will work out for you. You need to elevate these kinds of issues, but be prepared for the eventuality that your project winds up taking the hit and you are forced to make changes. Competing cliques, technologies, and calendars are usually resolved politically. These outcomes are unpredictable and most certainly beyond your control.

1.4.7 How Much Will This Cost?

The bigger the project, the stranger the stories behind the formulation and funding of its budget. Be that as it may, understand what commitments have been made to the project in terms of funding. Keep a running tab on estimated costs that will surface as your team develops designs and implementation plans, and compare that sum with the budgetary bottom line. Later, when you start analyzing risk, of course you will recognize that deflecting or responding to potential risks can become extremely expensive, so you need to bounce those potential expenses against the budget as well. See Chapter 5 for additional information on risk funding.

Unless you have just completed a major project with the same players, make the effort to divine how procurement works. Your organization's procurement procedures are bound to change, particularly in the fiscal fourth quarter when executives are looking to eliminate costs, or at least push them out to next year. This can obviously impact your schedule if not your ability to render scope, so take nothing for granted in this area. Be advised that original budget approvals may disappear the first time you cut a requisition for anything over, for instance, $100,000. You can take a peek at Chapter 9 for additional information on budget management.

1.4.8 What Is the Timeline?

During this discovery phase, what you are looking for is key dates we often refer to as milestones. Individual task dates can come later, so, for now, you want to focus on major events. Think of these milestones as the stepping stones one uses to traverse the creek without getting wet feet. Even the largest project has only a half dozen or so. These would typically be things like site availability, network turn-ups, software releases, User Acceptance Testing, and production-ready dates. This question is one of the Big Thirteen for two reasons:

  1. Obviously, you are trying to understand what dates are critical to the corporation. Many dates are somewhat arbitrary, but you need to understand the expectations surrounding them nonetheless. In the case of projects like Y2K, or those mapped to specific business cycles or events, however, key dates are nonnegotiable, and have that "must finish by" quality about them. As you proceed with your analysis, some dates are going to appear impractical for any number of reasons. The sooner you understand the original schedule, the sooner any issues or conflicts can be uncovered and addressed.

  2. Second, as you begin meeting with your project team, customers, and beneficiaries, it is quite important that you understand the project's key dates. The user community has their own business rhythms or cycles that could pose conflicts with your dates. Typical user constraints are accounting closes and manufacturing cycles. Most organizations prohibit changes to the network or to network-attached devices at year-end. Mergers, acquisitions, new product rollouts, and other business events may also create issues that make your project's favored dates problematic, to say the least.

1.4.9 What Are the Key Dependencies?

Every big project has a handful of events or conditions beyond your control, upon which you depend to happen on time and meet other requirements to achieve your project goals. These are project dependencies. They can come from any part of the corporate world, including IT, finance, marketing, and so forth. Do not overlook potential dependencies from the outside world, such as vendors or external customers.

I did a Web project a few years back that relied on a separate middleware project to complete so we could use that new service to draw data our project needed from the mainframes. Our programmers provided specifications that I verified with the middleware project manager as being available once that project wrapped up. Her intended completion date was far enough ahead of our "must have by" date that we felt comfortable this was one dependency we should not lose sleep over.

Had our technical requirements not matched up with the middleware project, however, I would have been tasked with negotiating those changes with the other project. Were that the case, I could not fault the other project manager if she reacted to our request for changes to her project as forcing scope creep on her, and would have subsequently expected a whole round of talks between us as well as at the technical and management levels to clear that up. [1] Although we got lucky in this specific instance, I have gone down the road of trying to change the deliverables or calendar of other projects and can testify as to the difficulty of getting the job done without causing a great deal of unhappiness.

In a new construction project, availability dependencies can be extremely critical. I have had to manage around conflicts over when:

  • Data center grade electrical power and air conditioning is available.

  • Circuits linking the site to the corporate backbone are up.

  • Elevators can be used to haul a hundred servers up to the fifth floor.

Some dependencies will require considerably more research and analysis than others. At the very least, you need to dig long enough to ascertain how a late or subpar occurrence of that dependency could impact you, and how reliable the execution of that dependency will be in terms of timing and completeness. Once you have identified the critical dependencies, plan on circling back to their owners as many times as you deem sufficient to ensure that your understanding of their progress remains current.

If that dependency is, itself, the planned output of another project, keep in mind that, as a project, it is as vulnerable to delays, funding lapses, resource constraints, and all the other project risks that you have to deal with in your initiative. What you thought was true and wonderful in July regarding the status and timing of that dependency may be radically different by the Fall. Experience tells us that change is more likely to be for the worse, so be sure to stay in close touch with that other project team. If possible, touch base with the sponsor or senior manager in that group, or have your manager do that for you, so there is some agreement or sensitivity at that level that the dependency exists and will be bird-dogged.

1.4.10 What Is the Risk?

This is somewhat of a tricky question because the answer you are looking for will change as the project transitions from vision toward implementation. When first handed a project, I have two questions:

  1. The more obvious question is: "How hard will it be to get this thing done?" This is a question you will revisit many times, and is covered in great depth in Chapter 5. These discussions will revolve around proposed technologies, the environment into which your project will deploy, and so on.

  2. The second question I have, and the one that is more useful at project start up time, is: "What happens if this thing fails, if we cannot get it done?" Responses to this question might reveal:

    • Regulatory or other business issues you should be aware of

    • That your project is a stopgap (see Section 1.4.13, "What Is the Shelf Life?")

    • The need to develop an alternate solution if the risk is highly probable

Suppose, for instance, the assumed means of meeting scope are based on a very iffy dependency, such as an unproven technology, or an acquisition or merger occurring (or not). Should this risk happen and essentially render the original project solution unworkable, you need to go on the attack immediately by crafting a detailed "Plan B." That means, in addition to getting used to the current thinking, you need to start hunting for additional political cover, funding, and quite possibly, a most senior technologist to formulate a clever alternative solution.

I sometimes believe one needs to have suffered a disaster or two to appreciate how important it is to be skeptical and proactive in this regard. Projects are not always well vetted at the time they are proposed, funded, and handed to someone like you to midwife into reality. How many times have we seen projects, which have good purpose and appear to be workable, turn out to be incredibly difficult if not impossible to deliver? If this new project of yours is a big one, you should satisfy yourself that the project can be done well with the resources at your disposal. Should you find gaps in this regard, it is wonderful that you identify them at the outset, when you and the sponsor can devise the best means of accomplishing your goals. For instance, I can recall many projects that were thrown out to vendors, and others brought back in-house, for this very reason.

In a general sense, when you are chasing down risk, you are looking for things that can go wrong and how to indemnify against such misfortune. I recommend during this discovery process that you also evaluate the risk of not getting certain things done at all. Big projects have multiple deliverables, some of which may not truly be needed on Day One. Identify these, and hold them as possible things to delay or delete later on when time, resource, technology, or budgetary pressures make delivering them as originally planned not the most desirable of circumstances. This information can prove to be a real lifesaver. Look to Chapter 5 for much more about risk.

1.4.11 What Are the Success Metrics?

I have heard pilots joke that a good landing is "any one you walk away from." When you ask the typical project manager what makes for a successful project, you will probably get the old "deliverables on time and at budget" cliché. In truth, projects are usually declared complete when the clock runs out or the money well runs dry. That sounds more like a timed sporting event or a trip to Las Vegas than good project management to me.

Initially, I like to kick off the process by asking stakeholders what results they believe would deserve high fives, a free golf outing, or getting that consulting contract extended 6 months. Although I am kidding a little, in truth, defining success metrics is not a simple exercise. Most people resort to anecdotes, such as "the new network screams," or "the customer did not go postal on us." The bottom line to success metrics is:

  • Being able to articulate your benefits

  • Finding relevant ways to describe how well you delivered them

Whereas this may have soft components (e.g., "the new network really does scream"), look to include hard metrics, such as:

  • Average processing time is reduced from 3 days to 7 hours.

  • Peak hour wide area network (WAN) latency is less than one millisecond.

Over the past several years, quality assurance methodologies such as Six Sigma have found their way into project management to support the thought process I call "success metrics." This is a welcome development so long as its use is tempered with business acumen and cognitive skills. It any case, it is good practice to develop your success metrics during the planning stage. Doing so puts the team on notice that effective implementation is expected and will be measured and published. After all, putting in a new payroll system on time and at budget that missed three key requirements and is a slovenly performer does not sound like a job well done.

It is a clever idea to identify what would constitute a good job long before the real work begins. It also helps to keep the project focus on benefits, which presumably led to the project being approved and funded. I was once tasked with helping reduce the error rate in provisioning voice mail for retail customers. There was too high an incidence of these mailboxes not being available to customers within the time frames dictated by the service level agreement (SLA). As a result, there were an awful lot of meetings about process, technology, and so forth held in an attempt to fix this very serious problem. The team came up with several proposals that would cost millions of dollars through the following typical process reengineering paradigms.

  • Training

  • Upgrades to network elements

  • Standardization of nomenclature

  • A new asset management system

This was all great stuff and not without merit, but my supervisor and I were getting increasingly frustrated with the whole business. In truth, we just could not see how the commitment of constrained resources to this degree would guarantee that a single minute or penny spent on these solutions would actually deliver the benefit of a significant reduction in the error rates plaguing our BAU processes.

During this time, I noticed that one of the key operations managers, to whom I shall refer as Mike, had stopped participating in these unproductive planning sessions. Having perceived Mike to be knowledgeable and conscientious, I took his withdrawal as evidence that he agreed with us that the project team had gone into that dreaded "solving world hunger" mode, that is to say, was losing touch with reality. Mike's job was overseeing the "back end" piece of the voice mail provisioning process. This clearly identified Mike as a key stakeholder, so his self-imposed exile from the project suggested to me that something was definitely wrong, not only with the project, but also with the systems he was stuck with operating.

Throughout the book, I emphasize the value in developing relationships beyond the setting of meetings, so I reached out to Mike. He was not all that approachable; but once he came to believe that I was trustworthy and could possibly help him, he gave me a pretty useful education regarding the issues as he saw them. He gave me access to the systems so I could poke around the error logs that I eventually downloaded to the tune of nearly one hundred thousand error records and ported into a tool I was able to use for statistical analysis.

The technical implications of the resulting frequency distributions were not readily apparent to me, but thankfully the charts and graphs meant something to the engineers. It turned out that approximately 90 percent of the errors could be traced to a manual data entry process that we could repair with nineteen thousand dollars in programming. So, after 5 months of project dithering, 3 weeks of mindless number crunching revealed an answer that barely took a month to implement and test.

The moral of the story is this. Had we begun the project with a reasonable success metric like "lower the error rate to 1 percent," and stayed focused on that metric, chances are we would not have looked to reengineer the whole environment at a cost of millions. Instead, we would have done the analysis I stumbled through much sooner, and identified the correct solution with a price tag that was, as they say, "chump change."

1.4.12 How Will We Support This?

Virtually any project creates some new support wrinkles, the most likely of which are:

  • Staff headcount

  • Staff skill sets

  • The ability of the help desk to absorb a significant increase in user calls

  • New conditions that the fault management team must monitor for and respond to

  • Introducing new products or vendors to the support culture

  • Introducing more rigorous service levels

  • Disaster recovery

  • Business continuity

Based on my own experience, effecting stellar results in this area will challenge your negotiating skills. Designers often ignore this requirement, leaving the project manager to clean up the huge mess this oversight can cause. That being the case, it is best to get this problem, which it is, in front of everyone early. Keep as many stakeholders as possible involved in its resolution. Understand how your support organization assimilates new responsibilities, no matter how disinclined they may be to do so.

The term "support" has many interpretations based on your specific corporate culture. I use it in the broadest sense, and pose it as the following question: "What has to be done, both on a regular and periodic basis, as well as in a pinch, to keep project deliverables functioning once they go into production and the project team moves on?" Besides the areas listed or implied previously, do not forget to consider backups, password and license administration, security, and anti-virus protection. Another potential challenge in this area, if you are dealing with applications and servers, or network elements like switches and routers, is transitioning your gear from the lab into the data centers or computer rooms across your enterprise.

Chapter 11 is dedicated to this somewhat Machiavellian topic of operations turnover.

1.4.13 What Is the Shelf Life?

The answer to this strange-looking question creates potentially life-saving value to the savvy project manager. Either by design or serendipity, one or more of your "deliverables" may actually represent a short-term solution to a long-term problem, i.e., whatever you are building will be undone or replaced in the foreseeable future due to business conditions, a pending merger or divestiture, or product life cycles.

This is a direct means of testing whether a proposed deliverable, as inferred from scope, does not truly deserve the full-court press you and your team think it would take to accomplish. I have been on projects where certain components were either diluted or jettisoned, despite loud protests from those clinging to design elements being exiled, because:

  • Something better loomed on the horizon.

  • The original "solution" was not worth the fuss its rollout would create.

  • Excluding it would not impact scope that badly, if at all.

Because every complex project I have been on has had one or more original requirements tossed aside, delayed, or neutered, I go into new projects wondering aloud which assumed deliverables are likely prospects for the axe once reality sinks in. An interesting image to use in this regard is to ask yourself whether discarding a requirement, or even a few of them, will make little more difference to the project than the effect of throwing a deck chair of the Queen Mary ocean liner would change its level of flotation.

[1]Viewed from this perspective, not all scope creep is "bad."



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net