Project Proposal
Once the project manager has decided to take up the project, the project proposal has to be prepared. This is a paper/electronic document giving technical and commercial details of the project. Before submission of the document to the prospective customer, the project proposal has to be validated to ensure that it is complete in all respects. We will study these aspects in detail.
Format of Project Proposal
A suggested format for the project proposal is given in Table I. The technical proposal section shall contain the technical aspects (such as the proposed architecture), execution model (on-site or off-shore development) and the life cycle model. The commercial proposal section shall contain the development cost, development time and the terms and conditions. The management aspects such as details of project management personnel, review meetings to be conducted etc. also should be included in the proposal.
Project proposal Name of the project Name of the client organization Name of the end user organization Scope of work (brief description of the work) Deliverables (such as source code, documents) Time frame Execution model
Technical proposal
Proposed architecture giving details of external interfaces, user interfaces, with possible alternatives and advantages of the proposed architecture
Assumptions made in making the technical proposal Development process to be followed Commercial proposal
Development cost
Total person hours/months
Cost per person hour/month
Total cost of the project
Warranty period
How long the maintenance of the software will be taken up after the warranty
period
Maintenance cost after the warranty period (per month or per year)
When the software has to be retired, how much advance notice is to be given (or
whether at that time source code is to be supplied).
Project management
Project manager
The person who will interact with the client
Periodicity of the project status reports
Review meetings to be held (when, where and who will attend)
Bar chart based on the development life cycle model chosen
Quality processes to be followed
Documentation to be given to the client
Acceptance testing procedure (or time frame for preparation of the ATP document) Terms and conditions
Payment schedule
Late delivery clause
Whether source code will be supplied or not (and what is the additional price if
the source code is supplied)
Taxes and duties
In case of changes in specifications, procedure for negotiation on the timeframe and budget
Any other requirements of the client (such as declaration that the development organization is an equal opportunity employer, acceptance to sign the non-disclosure agreement etc.)
In case of any disputes, the mechanism for resolving the disputes (to be specified for technical, managerial and legal issues)
Validation of Project Proposal
After the draft project proposal is prepared, it has to be validated for completeness and accuracy.
• The proposal needs to be discussed with the project team (at least
those who did the system study and obtained the preliminary
requirements as the complete project team would not have been
formed). The team has to ensure the accuracy of the technical proposal
and also whether realistic time frames are given.
• The proposal needs to be discussed with the finance personnel for
accuracy of commercial proposal, particularly as related to taxes.
• The proposal has to be discussed with the legal expert to ensure that
the liabilities are accounted for. A casual approach is dangerous
because for some reason, if the project runs into trouble (delay,
premature closure of the project either by the client or the developer),
the liability clause will be invoked and it may prove fatal to the
organization. If the liability is more than the project cost, the risk items
need to be probed into and it should be doubly ensured that risk
resolution strategies are worked out. If the developer asks for advance
payment at the start of the project, the developer is liable for more
penalty if the project gets into trouble
Disclaimers: If the software is used in very sensitive application (such as in a medical equipment in an intensive care unit of a hospital) and if the software fails, certainly the developer has to take responsibility. In such cases, the damages may run into millions of dollars. Some development organizations get away with a disclaimer (“use of the software in medical applications is at the user’s risk”). The legal implication of such disclaimer needs to be studied—the law differs from country to country.
• Finally, the proposal has to be discussed with the client and mutually
agreeable proposal has to be arrived at in all aspects—technical,
commercial and legal.
Signing on the Dotted Line
Before finalization of the contract, the project manager has to ensure that the agreement is complete and accurate from various angles—policy, legal, administrative and managerial.
Policy Issues
Policy issues can be divided into
Organizational policies
Government policies International policies
Organizational policies: Every organization will frame its own policies for taking up project works—not to take up projects with small profit margins, not to take up projects which violate the ethical code of professional practice etc.
Government policies: The government policies include not to take up projects which involve support to factionalism or terrorism and which are against the law of the land.
International policies: International policies include the rules and regulations of World Trade Organization to ensure fair trade and non-violation of international patent and copyright laws.
Legal Issues
When everything goes fine during the software development, there will be no legal battles. If the developer and client work in a congenial atmosphere with an excellent rapport to sort out the problems, it is fine; but otherwise both parties need to take care of the legal issues.
Problems arise because of lack of honesty on one of the sides. With the over-enthusiasm to bag the order, the developer may over-commit to the client. He may not have the competency but agrees to take up the work, or he may not be able to meet the delivery schedule but accepts it, by just calling it a business risk. A calculated risk can be taken but not a blind risk. Such an attitude would put the client in trouble because he relies on the developer and if the software is not delivered on time, the client’s business is in trouble. So, he will start a legal battle.
Moreover, the software development group has to ensure that the delivered software will not cause data or information loss or damage at the client’s site. The correctness and authenticity of the information is to be guaranteed. Otherwise there will be legal suits and the developer is liable to pay severe penalties.
If the software does not function correctly, it can be due to two reasons: the specifications given by the customer are not correct, or quality software has not been developed. Before signing on the dotted line, it is necessary to ensure that the legal aspects are clear particularly if the client insists on a liability clause. Please note that the developer cannot get away just by giving a disclaimer. The risk analysis to be carried out at this stage is very important to assess the liability.
Legal clauses differ from region to region. In transnational projects, the legal clearance is a very important step and should not be ignored. The project manager has to retain a legal consultant to ensure that each proposal or agreement signed is clear from a legal perspective.
Administrative Issues
The administrative issues that need to be considered are:
• The availability of space for the execution of the proposed project.
• The issues related to the repercussions of increasing the manpower.
• The finance related issues such as cash flow. If the project is executed
without any advance payment and if the payment will be received only
after completion of the project, how the salaries and other expenditure
will be met? It has to be met from internal funds, and availability of
funds has to be ensured.
Managerial Issues
The management has to look at the project from a broad perspective. The following aspects need to be looked into before clearing the project proposal:
• Is the client genuine?
• Did the client allocate enough budget for the project?
• Are the risk items in taking up the project correctly identified? What
are the repercussions of these risk items and what is the impact?
• What are the damages if the project fails mid-way (doing the worst
case analysis is always a good approach). For every project, the
management has to consider this aspect. If the worst-case damage is
just the cost of the project, it is worth doing it.
Once the project proposal is considered acceptable from all these four angles, the proposal can be submitted to the client for further action—negotiations and finally release of the purchase order or signing of the agreement.
