Related Posts
Last time, I mentioned that inadequate planning is one of the key reasons why your new technology purchase might prove to be disappointing. This is true not only of planning that occurs once the project has been authorized and assigned an official “Project Manager”, but it also refers to the planning that is used to determine the validity of projects themselves. The earlier you begin to have problems with planning, the greater the potential pain.
It’s time for the second of five principle reasons why many businesses fail to derive the value they could otherwise obtain from their technology investments.
Reason #2: Unrealistic Expectations
Technology expenditures can be quite expensive, depending on the problem that is being solved, and upon the size of the organization which will be deploying it. For that matter, most complex technology-based solutions will be somewhat expensive as compared to the entity that must purchase and deploy them, when you consider that hardware, software, integration and labor are all cost components.
Due to the not insignificant nature of many of these expenditures, the key project “stakeholders” tend to be keen on “getting their money’s worth.” This can come in many forms, such as:
- Desiring assurances of IT that the new software will integrate seamlessly with every existing line of business application in the environment…
- Expecting to be able to retire many other existing applications currently in use
- Trying to wring as many concessions and customizations out of a vendor…
- Thinking that the costly deployment of security solutions today will be able to stand untouched for the next five years…
- Thinking that a solution which claims to address only 80% of ones needs, can be easily made to address the other 20%, despite those being core needs…
- Expecting any of the above to happen – and quickly – despite not having informed or involved the technology team in the procurement process in any way…
And there are quite a few others, which you will be very familiar with if you have worked in an organization for any length of time, or regularly read Dilbert.
When the wrong expectations are set, either by management or by the business, or by the technology team, much pain and suffering will follow – not to mention, dissatisfaction. And, in many cases, a scapegoat or two will be sought.
If you are unable to thoroughly articulate your current business processes, and you have no intention of documenting or changing them (or you feel you lack time), then don’t expect an expensive enterprise resource planner (ERP) or a sophisticated workflow enhancing suite of applications to do anything useful for you.
If you do not understand fully how your network is interconnected, and you are unwilling to change any business practices related to how/where people access and store corporate data, then don’t be surprised when your shiny new security solution fails to return anticipated dividends.
If you believe every vendors claims about interoperability, without considering that it might be based upon best practices that you’re not currently following, or upon scenarios which are more limited in scope that what you’re trying to accomplish, you should prepare yourself for integration pain.
If you put together a 5-year road map, and purchase a few million dollars worth of technology based on current assumptions about your organization, your industry and the global market-place, you should set a date with disappointment on your calendar at about the 12-18 month mark, unless your technology plan allowed for a great deal of flexibility.
The best way to keep realistic expectations is to manage scope. Have a small, focused goal for each technology deployment. Yes, there needs to be some over-arching strategy that drives the thinking, but this strategy must allow for changes and flexibility, and must facilitate implementation in manageable chunks.
By working towards the bulk of your projects being in the 30-90 day range, you can maintain the necessary organizational focus, avoid putting the kitchen sink into each project, better manage costs, and more easily reap objective benefits. And, should situations change, you can more easily adjust.
At least 85% of your projects should fall into this timeframe, whether your organization is small or large. (It’s even more necessary in a large org than a small one!) Another benefit of smaller projects, is that they are easier to plan for…
Next time: Reason #3: Expense vs Investments