Compared to other types of projects, there is definitely a perception that IT projects find it harder to get approved from senior management. This is not an urban legend, and has more than a grain of truth to it. There are a few reasons why this situation occurs. First and foremost, proposals for IT projects are often drafted in language and form that are highly technical, making it difficult for senior management or those without technical expertise to evaluate the proposal. The second fact is that IT projects are notorious for suffering severe cost escalations, time overruns, and scope creeps. This makes project sponsors wary of committing company funds to IT projects.
There are a few things you can do to improve the chances of getting your IT projects approved. Here are some of them.
-
Spell out the business imperatives and expected business benefits of your project
Most IT project proposals are very good in terms of spelling out the technology design of the project, the technical requirements, and benefits. Not so much with detailing on the business side. It is very important that you spell out, first and foremost, the business imperatives driving your project. Ultimately, most IT projects are executed to satisfy specific business objectives and to provide tangible benefits to the business. You should always spend enough time to spell out in detail the business imperatives that are the drivers for the project. Subsequently, the expected business benefits of your project are also to be discussed in detail.
The sponsors will be looking closely at the business benefits being projected for your project before deciding whether to approve it.
-
Provide ROI projections as part of the proposal
Ultimately, it all comes down to the dollars. It is critical that you provide ROI projections as part of the proposal. While the investments needed should be fully sketched out in terms of both initial capital investments and recurring investments, the expected return must also be clearly and concisely stated. Here are some points you need to make:
- Direct savings due to reduced needs in terms of infrastructure, staff, equipment, software licenses, hardware, and material
- Indirect savings because of reduced risk, improved client satisfaction, improved employee satisfaction, reduced downtime, and better addressing of regulatory requirements. These should be analyzed and a dollar-equivalent figure must be projected.
- For instance, consider the case that a new process is being proposed that is expected to provide real-time availability of reports, thereby enabling financial risks and oversights to be discovered in real time. This is expected to reduce the number of situations in which federal regulators fine the company for breaches in fiduciary law. In such cases, a certain number of fines or penalties can be projected every year in order to obtain a figure for dollar savings from the project.
-
The project must make sense in the company’s current situation
One aspect of successful proposals that is underappreciated is the fact that the project proposal must make sense in the company’s current situation. Even a legitimate, well thought out project with a perfect business case may fall by the wayside because of a company’s current financial or management situation. In such cases, it is not necessarily the fault of the project; it may simply be that the project doesn’t fit in with the current state of the company.
Consider the case where there is an effort ongoing across the company to cut costs across all divisions and activities, including events, large dollar purchases, and travel. In such a dollar-sensitive scenario, a project that involves expenditure of, say, $50 million in one year, promising savings of $25 million every year starting three years later, is unlikely to get approved. The project, let us say for a wireless printing effort, may well have a justified business case. But it does not really matter in the current context because large dollar expenditure is simply not going to happen for a savings that is three years away, at least in this company.
-
Many small bangs instead of one big bang
There are several projects that make the mistake of projecting plans and implementing designs with a big bang approach. Very rarely do we see these types of projects being approved. And the reason is simple. Using a big bang approach significantly increases the probability of project failure and delay. This is because, with a big bang approach, invariably very large catastrophic defects occur during development and systems integration.
Always develop your proposal in such a way that it carries forward earlier work completed as part of another proposal, and which lends its work to be carried forward with another future proposal. This increases the chances of your project being approved.
-
Track record
In any IT project proposal, it is pertinent to spend some time talking about past IT projects that were granted and their execution. Project sponsors are typically very interested in seeing the track record of those making the proposal. By looking at the past IT projects that were approved, along with the associated dollar numbers and the implementation results, the sponsors get a significant idea of how this project is likely to end up.
-
Utilize industry and company standards
It is very common to use a variety of numbers and benchmarks while presenting your estimates and proposals as part of the project. These include coding productivity numbers, throughput numbers, and network bandwidth and bit rates available. Always use industry standard numbers for benchmarks, especially for coding productivity numbers. For instance, for Java coding, the industry standard benchmark would be a certain number of lines of code (LOC) per day. In the absence of reliable industry benchmarks, you should use company-wide benchmarks from historical data accumulated.
With regards to other assumptions such as network bandwidth and bit rates, always use numbers that accurately reflect the equipment that is going to be used. For both benchmarks and equipment capability numbers, ensure that you are providing sufficient justification for the numbers used. A detailed supporting explanation is to be provided.
Follow these guidelines, and your chances of getting your IT projects approved should rise.
Photo credit: Pixabay
