9.3 Budgetary Source Data

 < Day Day Up > 



9.3 Budgetary Source Data

Inherent in any cost projection is a set of assumptions on unit data upon which the preponderance of estimates are based, as the previous section illustrated. I would like to zero in on this discussion by reflecting back on a project I served on as program manager for a vendor seeking a network migration project from a huge and geographically scattered customer. The proposed scope was to take a very mixed bag wide area network (WAN) connecting a few hundred sites to seven data centers and migrate it to a single transport type (Frame Relay) tying all sites to each other and to two data centers separate and distinct from the original seven. The current state was such that:

  • Few sites were interconnected.

  • The prevalent circuitry was 19.2 kbs leased lines.

  • The communications protocols used were mixed.

  • Nobody on the client or vendor side could stipulate with much precision what all these differences were, hence my previous use of the term "mixed bag."

My assignment was to generate a detailed design, with associated pricing, to effect these changes within several specific business, real estate, and technology constraints. The challenges we faced were:

  • Identifying the legacy LAN and WAN infrastructure components at each site

  • Identifying the applications and other IT processes required to support business as usual (BAU) processes plus the customer's intent to roll out centralized applications such as payroll and accounts receivable

  • Understanding how to replace the centralized services currently housed at the data centers that would be disconnected from all users after the new network was in place and the new data centers were ready

  • Creating a technology migration plan that met all requirements for current and future connectivity, performance, and access to centralized or standardized IT services

It soon became apparent that although the target state was reasonably well defined, the path leading to it was going to consist of:

  • At least one plan for each of the hundreds of sites, due to the wide variance in application and infrastructure characteristics across all locations

  • At least one plan for migrating and consolidating centralized processing services from the seven legacy data centers to the two new ones

For example, some sites would have to be rewired for newer LAN and WAN technologies. In most sites, the desktop personal computers (PCs) and servers would have to be replaced because they were incompatible with the proposed new technologies. There were protocol issues at some sites that did not lend themselves to the any-to-any network requirement. The risk associated with this latter requirement was quite high, given the nature of the business. Also, it was clear, at least to me, that multiple subcontracting firms would have to be engaged to ensure that an adequate quantity of specifically skilled technicians would be available to meet an incredibly aggressive, if not unrealistic, timeframe being tossed around a few layers above me.

Making matters worse was that the detailed site and user data the customer graciously shared with my team was woefully inadequate in terms of being able to quantify risk and develop a pricing mechanism that would be fair to both parties. The absence of centralized documentation in this regard was understandable, given that the client corporation was the result of a wave of recent multiple acquisitions within an industry in the midst of a consolidation frenzy. Before long, at my request, the customer-funded site surveys to determine the actual state of their IT environment.

This anecdote presents all the key challenges to effective budgeting of complex IT projects. It is quite difficult to devise a workable, priceable plan if you do not have an excellent understanding of the project starting line and all of its characteristics. In my simplistic way, I look at such a challenge on a "from-to" basis. This comes from the practical experience that you need to understand:

  • Where you are coming from

  • Where you are going

  • What it is going to take to get there

The significance is that this view allows you to develop a fair unit cost for each site, application, or business unit to be converted from present to target state. Customers find this view much easier to understand and contemplate. Once you get the hang of it, you will find it is not all that difficult to produce.

The "what it is going to take to get there" piece can be divided into three parts:

  1. Implementation strategy

  2. Implementation costs

  3. The success metrics that have a significant impact on the service levels and other telltale signs of the target state's quality and complexity [1]

In Chapter 6, I recommended that you understand and comprehend your critical path before you do any real scheduling. This approach is preferable to trying to make sense out of thousands of finite tasks. Budgeting complex projects is similar. Sure, at some point we want to count routers, servers, or users, and apply a number to that, but first we need to understand what we are doing before we start counting. So, as with designing and scheduling, budgeting is an iterative process intertwined with the other planning processes.

To see how this works, let us return to the current network migration example. As with risk, I prefer to take the worst-case scenario and educate myself back toward a simpler, less onerous, and cheaper solution than to build a best-case budget and add 5 or 10 percent to insure against the unknown. In practical terms, this means breaking the project down by its core implementation strategies and developing unit costs for each implementation strategy. That way, you or anyone else can:

  • Review the resulting financial proposal

  • Come to understand it

  • Work to validate and eventually gain approval for it

Exhibit 1 provides a diluted version of the first pass we took at our budgeting scenario from an implementation perspective. As you review the detail, note that we broke down requirements into discrete tasks that we could derive average costs for, in other words, unit pricing.

Exhibit 1: Network Migration Budget Planning Worksheet

start example

Requirement

Cost Elements

Create frame relay WAN with meshed topology and redundant access to two data centers.

Managed router network

Specified bandwidth circuits (permanent virtual circuits [PVCs])

Data center routers and switches (× 2)

Network management hardware and software, including authentication

Connect each remote site to WAN.

Remote site routers, digital service units /channel service units (DSUs/CSUs)

Upgrade site LAN as required.

Hubs and data cabling

Servers

Retrofit PCs to meet new requirements

Replace PCs that cannot be retrofitted

Migrating legacy applications to upgraded LANs (for local applications).

Flat rate per application, plus user tax

Roll out centralized human resources (HR) applications.

Data center server and infrastructure costs

Disaster recovery infrastructure

Site licenses

Site installation and testing

Roll out other centralized applications.

Data center servers and infrastructure

Disaster recovery infrastructure

Site licenses

Site installation and testing

end example

Working with a team of two dozen engineers, I created this ala carte menu that showed pricing associated with each implementation element. Lest you think this sales scenario is inappropriate to a discussion of project management, let me bring this into sharper focus. From a budgetary perspective, the only difference in the pricing given to this external customer was the estimated cost marked up for the purpose of generating a profit. Otherwise, the number-crunching aspect of this is identical to the process you would undertake as a project manager validating costs for an internal customer, or a corporate cousin, if you will. [2]

What is even more relevant to your circumstance is this. Customers or beneficiaries, whether internal or external, tend to think of project costs in lump sum terms. Suppose the total project cost was originally pegged at $50 million. What subsequently emerges is this two-pronged expectation on the customer's part:

  1. Everything they believe scope implies will be delivered in the timeframe, and to the extent that they originally envisioned.

  2. The $50 million commitment they originally made is more than adequate to meet those expectations.

This mindset is so typical that you can count on it being held by your customer set. Unfortunately, in the case of complex projects, such thinking is generally a bit far-fetched, the nature of aggressive initiatives being what they are. The very important lesson to be learned from the sales environment is this. No sane salesperson would knowingly allow a customer to think that their expectation of getting everything they want for the price they are willing to pay is okay, if that expectation is ungrounded. To dramatize this scenario a little bit, from the salesperson's perspective, the customer is looking for "champagne on a beer budget," whereas the salesperson wants to state, "Mr. Customer, you can only get what you pay for!"

Of course, this disconnect between customer expectations and a fair assessment of cost by the provider is handled more professionally than that. Still, the emerging delta between expectations and a realistic price tag based on a detailed analysis of the implementation strategy, risk, and other project realities must be managed. In the sales scenario, the sales person is obligated to reveal any gaps to the client. Unfortunately, this is far less likely to occur in the internally delivered project scenario, for two reasons:

  1. Internal project managers are not often capable of uncovering these gaps through a detailed analysis as illustrated in this chapter.

  2. A salesperson is far more motivated to find these gaps and address them than is the internal project team because the jeopardy associated with the relationship is far different. A salesperson lives in fear of losing the deal before it really gets started, so discovering and addressing this delta is a normal part of his or her professional workflow. An internal project manager does not have that fear and, thus, is less likely to worry about this delta because the assumption is that any budgetary or deliverables shortfalls will be absorbed through the normal give and take of corporate behavior.

I submit that as an internal project manager, you should feel compelled to demonstrate with reasonable certainty what the upper limits of your project output are going to be, based on committed funding. This should include a reasonable delineation of the features, functions, and benefits that you honesty believe can be produced with the resources granted to you.

At the beginning of this chapter, I presented a list of assumptions that typically drive budgetary estimates. There was one deliberate omission - the assumption that the business can afford to completely implement scope as originally conceived with that estimated dollar amount. The fact of the matter is that, with the exception of technical and logistical feasibility, nothing alters the scope of huge projects more than a rigorous budgetary analysis. Therefore, I see two benefits to this approach:

  1. The budget is put together most accurately because it reflects the implementation strategy (i.e., what it is going to take to get from here to there).

  2. It allows the customer to reflect on this and make hard choices about how best to spend whatever money they actually have. This is especially important if the budgetary "not to exceed number" is inadequate to accomplish everything stated or implied by scope. In the network example, the customer could plug the numbers into any deliverable and decide, for instance, if they really wanted to spend $X per legacy application to enable it at every site on the new network. That might have been a desirable target state requirement, but if implementing it could break the bank, perhaps they are better served by rethinking their goals.

One decision made as a result of this presentation was to upgrade local PCs only for a few needing access to the new human resources (HR) application, instead of making it available to the tens of thousand of users we identified through our site surveys. The customer realized it was cheaper and in many ways more practical to hire an office administrator to run those applications for everyone else at each site, rather than upgrading dozens if not hundreds of PCs at all these sites so that everyone could complete their time sheets online.

In summary, once you get ready to finalize your budget or to validate it, it is best if your implementation strategy, or some reasonable approximation thereof, is already prepared such that you can have a realistic shot at generating appropriate numbers.

[1]This is another rationale for including success metrics in the Big Thirteen interrogatory.

[2]This is why, in addition to maintaining confidentiality, costs are not listed in Exhibit 1.



 < 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