Properly approaching the initiation of an IT project is crucial to the project’s success.
During the initiation phase of the project, both you, and your vendor, know little about each other, yet will still need to make important decisions that determine the project’s direction. Changing this direction further down the road can cost the organization considerably more than the project’s initial cost, and also cause disruption and agony to all parties involved.
Many organizations rely on RFPs (requests for proposals), RFQs (requests for quotations), or similar documents to solicit offers from various vendors. One of the major mistakes repeatedly found in RFPs or RFQs is that organizations seek prices and delivery terms information without precisely defining the scope of their needs, expectations, and objectives.
If you decide 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 would you think their chances are in coming up with accurate estimates?
Most likely, your hired interior designer will need to know information 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 these, there is a high risk placed on your project, because your vendors will have to rely on assumptions; and every assumption equals a risk on the project!
Experience shows that the client’s input to the project is as important as that of the vendor’s. Clients, who know how to clearly define and express their needs “early on”, are more likely to end up with successful projects that meet the organization’s objectives than clients who do not.
While there could be many reasons why organizations do not express their needs early on, one of the common reasons is that simply they do not know how to do it.
The objective of this article - or rather checklist – is to lay out what should go in this type of crucial documents. This checklist will only address the project from the perspective of the end product. Other perspectives such as the delivery, implementation, or maintenance terms will be addressed in subsequent articles.
Take some time to find out the answers to the following questions. Each answer will increase your chances of achieving a successful project.
Q-1: Who will use the system?
Defining the user groups (personas) ahead is your vendor’s first hint about the nature of your system. For example, the vendor can easily detect a need for activity monitoring and 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 something like entering or approving employees’ vacation requests, or publishing news articles. You can easily 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. You might find out that features were already included in the last answer. So why do it? Explicitly thinking about features will ensure no key functions are overlooked.
Q-4: Are there any explicit or implicit links between 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, it is quite possible that your 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 your IT support team cannot support any other, this is important information to mention early on.
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 so. Integration is a tricky business and it must be thought out from the beginning. Tell your vendor what data will the system need to send or receive from the other systems?
Q-7: What is the expected system capacity?
System capacity means 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 some room for future growth.
Q-8: How complex will the system deployment be?
Where are the users physically located? Are they in one office or spread over different offices in many locations? How will they be connected? Do they have/need a special communication mean such as a VPN?
Q-9: Do you have any 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 the proposal.
Q-10: Do you have any already existing data from legacy systems?
If so, how many records do you wish to migrate to the new system?
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 very likely you have complex business rules. For example, the criteria to determine eligibility for insurance could be a combination of applicant age, gender, location, income, 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 going back to the vendor? 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 work flow component, roughly answer the following questions:
- What are the major 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 any external systems?
Your answers should be as clear and precise as possible. Requirements must be measurable to avoid different interpretations and misunderstandings. Imagine how many interpretations different people would have for the words “cold” or “hot”. Ambiguous words such as a “simple” workflow, “fast” system, or “some” reports do not mean anything and do nothing but produce ambiguity and conflict down the road.
While vendors work on crafting their proposals to you, let them talk to you to clarify issues; and be patient in providing information. Remember that you want them to assume as little as possible!
These questions may seem like a lot of work; but they are not. This exercise should not take more than one to two days. No one expects you 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 (for you, based on assumptions) in their proposals; and, trust me, it is an invaluable investment of time. Both you and your vendor will be grateful you did!
