We do this by first forecasting the number of person-hours it would take to build the system. Then we put a certain monetary value to these person-hours, which is usually the average salary of the software engineers that will be hired to build the system plus a little overhead. We then put all the other necessary materials to finish the system such as cost of servers, peripherals, etc.
We then estimate the yearly cost of maintaining the system, which we usually approximate at 20% of the initial build cost. After which we pick a discounting rate ranging from 8% to 12% (10% is usually the sweet spot), and do a Net Present Value (NPV) calculation of the Total Cost of Ownership (TCO) of the system from year 0 (today) to year 4. We top it off by adding another 10%-20% contingency reserve margin to cover for ‘other unseen costs’.
After doing all that, we go window-shopping. We go through a list of cloud-based solutions and ask them for their subscription costs. We compare the yearly subscription cost for cloud-based solution A, B, C…. and the cost of building the system. Finally, we are ready to make a decision: do we develop our own custom application, or do we lease or subscribe to Software as a Service (SAAS) solutions?
If this is how you do decision analyses, I encourage you to look at the past 5-10 build-or-buy decisions you made. You will find yourself that often you decided to build the application either in-house; or, using outsourced development partners. Rarely (perhaps 10% or even less probability), have you decide in favor of cloud-based solutions.
I think this is because many of us forget to include in our decision analyses the “full cost”, including the cost of risks, in custom application/system development. Failing to account for project risks, and mitigating them, leads to costly IT Project failures.
Even worse, the true cost of custom application development only appears later, when project s are mid-way done, risks are starting to materialize, and your project stakeholders’ patience are taxed.
Here is a list of the usual items we fail to consider as part of the costs, and risks when developing applications and systems of our own. Make sure we account for all of them before making a decision. If we are relying heavily on financial analyses tools to such as NPV, payback, IRR, and TCO to make a decision, then it is imperative that we put dollar values into these risks such as approximating person-hours, including executive hours; hiring additional consultants and project implementers; and, cost of sub-projects required to complete the IT system such as infrastructure upgrades.
1. Scope-creep and/or incomplete Requirements Specifications
Undoubtedly, scope-creep is the number one risk associated with IT build-out projects. Often, we are lulled into a false sense of belief that the required application or system is simple and thus will only take X person-hours, when in fact, it actually takes (X+Y)^Z person-hours.
Scope-creeping is when the project’s requirements kept changing even during project implementation. There are two main reasons for this: (a) the project is so delayed that the initial requirements are no longer relevant; and/or, (b) the project manager failed to fully understand the business requirements.
We should be obsessively detailed in gathering the project requirements. Immerse with the department sponsoring the project and discuss with as many stakeholders as possible. Define conflicting requirements from different stakeholders and resolve them properly. Make sure the business problem that the project wishes to address is fully understood. Define the current state versus the ‘future-state’ of the process once the IT project is in place.
2. Failure to Consider Cost of Required Infrastructure Upgrade
Now that we are confident about the requirements, consider the load of the new system in the IT infrastructure. What are the system availability requirements for the new system? Will a Disaster Recovery Plan (DRP) be required? Do we need to increase WAN segment bandwidth due to heavy influx of users? The new system will require, power, rack space and IP addresses (private or public). At the least, an on-site web-server will need changes in the firewalls and edge routers. If we are unlucky, we may need more changes in the network routes, and Quality of Service (QoS) configurations.
We should identify and include the cost of these upgrades, including the person-hours and executive time required to implement the infrastructure changes. Remember that changes to the network often requires a lot of executive time. Change requests need to be discussed and approved, and a lot of documentations need to be accomplished before we can even add one configuration line in any of the network equipments. We should note this in our decision analyses.
3. Underestimating the Strategic Relevance of the IT Project Resulting in Redoing the System/Application Over and Over again
The head of the Supply Chain Department came to the IT Head’s office and said: “we don’t really want a complicated system, just something we can use fast.” The IT department checked the requirements, and considered the minor infrastructure changes required; and they delivered the IT system fast, but a little messy – as requested. They authorized the cutting of corners and ransacked the best practice rule-book. No one’s the smarter. The department requiring the system loved it, despite its many bugs and the IT Head became their hero.
A couple of weeks after the system went live, the COO drops by the same IT Head’s office and told him the system worked so good, that the COO now wants it integrated into the entire Materials Planning and Manufacturing Divisions. The IT department now has two problems: (1) to be able to integrate the two systems, they have to recode at least 40% of the new system, then add additional modules required for the integration; and, (2) since this will be used by the entire operations team, they now need to fix those bugs which were previously ‘acceptable’ by the Supply Chain Department’s standards.
Six months later into the project, the CFO drops by the same office, and before the IT Head realizes it, they are now building an entire ERP system. The build-rebuild-integrate-rebuild cycle is costing their company huge amounts of time, and resources. Their IT department is also now exposed to the vicious cycle of firefighting – The IT operations teams kept resolving bugs, while the software engineering team keeps developing new modules.
We cannot emphasize more than enough the role of executive involvement (all of them, not just IT) in IT projects. The IT roadmap must be clear, and our role as IT executives is to communicate this roadmap. When one department asks for a quick solution, look back at the roadmap and communicate back when the solution will be made available. Building an enterprise system is like building a skyscraper. We can’t start building the penthouse without first building the lower floors. We should never fall prey to the ‘quick-and-dirty’ mantra – they don’t exist! An IT project can be finished quickly if it must, but never should it be dirty. We do not compromise quality.
When ‘forced’ to expedite the building of a system due to business necessities, we must take the larger picture into consideration. Of course we build it, but never lose site of the roadmap. Think of it as delivering the same roadmap but in phases. The system requested should scale to the larger requirement when the time to build the latter arrives. And the cost of the entire ‘build-scenario’ should reflect that.
No comments:
Post a Comment