Starting IT Projects on the Right Foot

Properly approaching the initiation of a software project is crucial to the project’s success.

In the initiation phase, both you and your client, know little about the solution (and each other). Yet, will make important decisions that will determine the project’s direction. Changing this direction later may cost considerably more than the project’s foreseen cost, and will most likely cause disruption and agony to all parties involved.

Many organizations rely on RFPs (requests for proposals), or similar documents to solicit offers from vendors. One of the major mistakes repeatedly found in RFPs is to seek prices and delivery terms, without clearly and completely defining the scope of the client’s needs and expectations.

If you want to renovate your house, would you expect the interior designer to fix a budget or a deadline before you tell them what you want and expect? And if they do, what do you think their chances are in coming up with accurate estimates?

The hired designer needs to know details such as the size of the house, the number of rooms, if you prefer tiled or wood floors, your favorite colors, and your expectations in terms of quality versus time and cost.

Your requirements, objectives, expectations, and preferences will set the project’s scope. Without clearly expressing them, you are putting a very high risk on all parties involved. Your vendors will have to rely on their own preferences and assumptions, and there is little chance what you get will match what you had in mind!

The client’s input and effort in the project are as important as that of the vendor’s. Clients, who clearly define and express their needs at the right time (that is before execution begins), are more likely to end up with successful projects that meet their goals.

There are many reasons why organizations do not express their needs early enough, but one of the most common reasons is that simply they do not know how to do it.

The objective of this article – or rather checklist – is to tell you what a you should think about and include in an RFP or any type of scoping documents. The checklist will address the project from the perspective of the end product only. It will not cover service agreements such as the delivery terms.

Take some time to find the answers to the following questions in their suggested order. Each answer will increase your chances of achieving a successful project.

Here you go..

Q-1: Who will use the solution?

Defining the user groups or personas (depending on your solution nature) is your vendor’s first hint about the nature of your system. For example, the vendor can deduce a need for activity monitoring or reporting capabilities, if you mention managers and executives among the system personas.

Q-2: What are the main functions that the system must perform?

Think capabilities that users can use or benefit from. They could be entering or approving employees vacation requests or publishing news articles. You can define these functions by asking the users (defined in the first answer) to express their objectives. Their wishes will be the system functions.

Q-3: Are there any specific features that you wish to include in the system?

Features could be SMS alerts, email notifications, or anything else that would make your system more useful and attractive. Some features were already included in the previous answer. So why do it? Explicitly thinking about features will ensure nothing is missed. For example, languages support may be more easily identified as a feature not a function.

Q-4: Are there any explicit or implicit links between the different functions or features?

For example, does your vacation system affect the payroll: employees salary calculation function? This one could be difficult, but if you already have an existing system, be it automated or manual, users already know the links.

Q-5: Do you or your IT department have a requirement for a specific technology?

If you must use a certain platform because you have already purchased its license, or because it is what your support team can support, this is important information to mention from the start.

Q-6: What is the context in which the new system will run?

If you have existing systems or systems that will be implemented in the near future, with which the new system must integrate, make sure you mention that. Integration must be thought out from the beginning. Tell your vendor what data will the system need to send or receive from other systems?

Q-7: What is the expected system capacity?

That is the potential number of users who may use the system (possibly at the same time), and number of records (such as ongoing transactions) stored in the system. You can detect this number from past patterns, while allowing room for future growth.

Q-8: How complex will the system deployment be?

Are the users physically co-located? Will you want to go cloud, local, or hybrid? Do you have a special need like a VPN?

Q-9: Do you have sensitive data that you wish to protect?

Sensitive data can be VIPs personal data or credit card numbers. Ask vendors to lay out their plans to secure this data in their proposals.

Q-10: Do you have any existing data in other systems?

If so, how many records do you wish to migrate to the new system? How spread and accurate they are?

Q-11: Does your business rely on complex decision making trees (business rules)?

If you are in the business of making decisions such as determining eligibility for insurance, giving grants, or issuing permissions; it is likely you have complex business rules. For example, the criteria to determine eligibility for insurance could be a combination of applicant age, gender, location, number of family members, plus other criteria. This kind of combinations makes the decision tree complex. Roughly list the rules used to reach those decisions.

Q-12: What level of control and flexibility do you wish to have on the system?

For example, do you want a super user or a system administrator to modify the business rules (defined in the last answer) without changing in the code? The level of control you wish to have will determine how flexible the system must be. With flexibility, comes complexity.

Q-13: If you wish to build a workflow component, roughly answer the following questions:

– What are the main steps in each process?

– Do you need an execution engine only? Meaning, do you want the system to only take care of routing data to the appropriate steps and people?

– Do you expect the system to offer monitoring of the process application to detect bottlenecks and improvement potentials?

– Do you want to give a system administrator the ability to modify the process?

– Will the workflow use data from external systems?

That is it..

Your answers should be as clear and precise as possible. Requirements must be measurable to avoid different interpretations and misunderstandings. Avoid ambiguous words such as a “simple” workflow, “fast” system, or “some” reports. They do not mean anything, and do nothing but cause conflict down the road. 

While vendors work on crafting their proposals, let them talk to you to clarify issues; and be patient in providing information. Remember that you want them to have a good picture of your needs!

This exercise should not take more than one to two days. You are not expected to write detailed requirements, only basic answers.

Before signing the contract is the right time to express all your wishes, not after when the vendors have defined the project scope (based on assumptions) in their proposals.

If you can’t be sure you will get the answers right, it is time you seek the help of someone who has the experience. It is an investment certainly worth every dime you put in it. Just think about how much you would lose in terms of money, time, and peace of mind; because of re-work and delays down the road. Trust me, it is an invaluable investment that both you and your vendor will be grateful you did not skip!