Complex IT Project Management: 16 Steps to Success

9.2 Budgetary Assumptions

As with nearly all other project facts, my advice is to validate the assumptions underlying the construction of your new "not to exceed" number, which is in the tens if not hundreds of millions of dollars on large and complex information technology (IT) projects.

• Methodology. Determine which of the five preceding options were used. Each has its obvious points of strengths and weaknesses. In the IT business, it is generally true that historical precedent has limited value, as IT projects tend to be rather unique, at least in the big leagues. Likewise, benchmarking has value to the degree that your project is not a one-off.

• Labor. Three methods are used get work done from a resource perspective:

  1. Full-time employees (FTE). Salaried employees can be assigned. Does your project get charged for their time in a real sense, or is that funny money that managers trade between cost centers to limit their "nonprofitability"? Most corporations have a standard, fully loaded rate of, for instance, $100 an hour for each FTE assigned to a project from a cost recovery perspective.

  2. Consultants. This is definitely real money. Do not forget the agency markup. You would pay $80 an hour for a $65-an-hour technician, if the agency gets a fairly common markup of 25 percent.

  3. Outsourcing. You may contract a firm to write code, move equipment, or configure servers. These charges are often fixed rates on a piecework basis, with overtime, expediting, and other potential costs spelled out in the contract.

• Design assumptions. No matter how the budget was crafted, it had to incorporate certain design assumptions. Some assumptions will consider "solutions," in other words, how project scope would be implemented by building new systems, upgrading servers, retrofitting the network with larger bandwidth, and so on. From that point forward, one would expect unit costs to be used to create cost roll ups, so quite naturally unit assumptions exist upon which the final budget amount was derived. Likely candidates include:

  • Users. This would apply to moves, new computers, software licenses, sizing servers, installing local area network (LAN) infrastructure, or fees for operations, help desk, or break-fix maintenance. In large corporations, these numbers have some precedence, perhaps contractually or based on internal charges long since established. For example, project costs are probably routinely charged within your organization for things such as moving a user to a different workspace, adding a server to the production network, and a myriad of upgrades to computing platforms. These known rates are often used to create cost projections for initiatives based on an assumed level of these activities. If it costs $5000 to certify a new server and connect it to the corporate network, and the project needs to add 17 servers to the network to support the rollout of the new payroll system, then the up charge for that piece of the project would be forecast as 17 servers × $5000/server, or $85,000.

  • Number of impacted sites. This could be used for bandwidth or connectivity, licensing, operations, help desk and maintenance fees.

  • User functionality. A software vendor may charge a fixed rate for each application deployed, such as payroll, general ledger, and sales order entry.

  • Standards. Corporate standards may dictate the inclusion of virus or security scanning tools as well as server monitoring software.

  • Tools. With or without standards, the build out of Web servers, middleware, databases, and other application infrastructure support should be based on the assumption that certain products are used.

• Politics. You would have to be pretty naïve to pose the question in these terms, but you should be mindful of the possibility that the final number had some political spin applied to it. Assuming that the executive in charge of presenting the final number for approval is relatively sane, he or she is faced with a dilemma. On the one hand, this person is astute enough to knowingly inflate the best-case number handed up to his or her to minimize the risk of showing a deficit at the end of the project. On the other hand, no one wants to price himself or herself out of the market either, knowing full well that some competing manager is likely to say, "Fifty million? Pshaw, I could do it for 35, tops."

I have witnessed or been impacted with several instances where deliverables were snuck beneath a large budgetary umbrella. In this scenario, a senior executive or program manager may take a few hundred thousand or even a million dollars from a big new project with ripe funding and divert those dollars to something else that has languished unfunded, possibly for a long time. I mention this because you might find, after your project is under way, that you suddenly have relatives you were heretofore not cognizant of, but are now responsible for, nonetheless.

Once you have cycled through this inquiry, it is time to vett the budget for yourself. Before that happens, however, it is important to have a clear understanding of the quality of data at your disposal to do that.