Introduction

In earlier chapters we looked at methods for forecasting the effort required for a project - both for the project as a whole and for individual activities. A detailed plan for the project, however, must also include a schedule indicating the start and completion times for each activity. This will enable us to:

• ensure that the appropriate resources will be available precisely when required;

• avoid different activities competing for the same resources at the same time;

• produce a detailed schedule showing which staff carry out each activity;

• produce a detailed plan against which actual achievement may be measured;

• produce a timed cash flow forecast;

• replan the project during its life to correct drift from the target.

To be effective, a plan must be stated as a set of targets, the achievement or non- Project monitoring is achievement of which can be unambiguously measured. The activity plan does discussed in more detail in this by providing a target start and completion date for each activity (or a window Chapter 9. within which each activity may be carried out). The starts and completions of activities must be clearly visible and this is one of the reasons why it is advisable to ensure that each and every project activity produces some tangible product or

Invitation to tender

Having produced the requirements and the evaluation plan, it is now possible to issue the invitation to tender to prospective suppliers. Essentially, this will be the requirement document with a supporting letter, which may have additional information about how responses to the invitation are to be lodged. A deadline will be specified and it is hoped that by then a number of proposals with price quotations will have been received.

In English law, for a contract to exist there must be an offer on one side that must be accepted by the other side. The invitation to tender is not an offer itself but an invitation for prospective suppliers to make an offer.

Certain new problems now emerge. The requirements that have been laid down might be capable of being satisfied in a number of different ways. The customer needs to know not only a potential supplier's price but also the way in which they intend to satisfy the requirements - this will be particularly important where the contract is to build a new system from scratch.

In some relatively straight-forward cases, it would be enough to have some post-tender clarification and negotiation to resolve issues in the supplier's proposal. With more complex projects a more elaborate approach may be needed. One way of getting the detail of the suppliers' proposals elaborated is to have a two stage tendering process.

In the first stage, technical proposals are requested from potential suppliers who This approach is do not necessarily quote any prices at this stage. Some of these proposals can be recommended by the dismissed out of hand as not being able to meet the mandatory requirements. With CCTA in the United the remaining ones, discussions may be held with representatives of the suppliers Kingdom, in order to clarify and validate the technical proposals. The suppliers may be asked to demonstrate certain aspects of their proposals. Where short-comings in the proposal are detected, the supplier may be given the opportunity to remedy these.

The result of these discussions could be a Memorandum of Agreement (MoA) with each prospective supplier. This is an acceptance by the customer that the proposed solution (which might have been modified during discussions) offered by the supplier satisfactorily meets the customer's requirement.

In the second stage, tenders are invited from all the suppliers who have signed individual Memoranda of Agreement. The tender would incorporate the MoA and would be concerned with the financial terms of a potential contract.

If a design has to be produced as part of the proposal made by a supplier in response to an invitation to tender, then a difficulty would be that the supplier would have to do a considerable amount of detailed design work with only a limited prospect of being paid for it. One way of reducing this burden is for the customer to choose a small number of likely candidates who will be paid a fee to produce design proposals. These can then be compared and the final contract for construction awarded to the most attractive proposal.

The ISO 12207 has a rather different approach. Once a contract for software construction is signed, the supplier develops a design, which then has to be agreed by the customer.

Evaluation of proposals

This needs to be done in a methodical and planned manner. We have already mentioned the need to produce an evaluation plan, which will describe how each proposal will be checked to see if it meets each requirement. This reduces risks of requirements being missed and ensures that all proposals are treated consistently. Otherwise, there is a risk that a proposal might be unfairly favoured because of the presence of a feature that was not requested in the original requirement.

It will be recalled that an application could be either bespoke, off-the-shelf, or customized. In the case of off-the-shelf packages, it would be the software itself that would be evaluated and it might be possible to combine some of the evaluation with acceptance testing. With bespoke development it would be a proposal that is evaluated, while COTS may involve elements of both. Thus different planned approaches would be needed in each case. The process of evaluation may include:

• scrutiny of the proposal documents;

• interviewing suppliers' representatives;

• demonstrations;

• practical tests.

The proposal documents provided by the suppliers can be scrutinized to see if they contain features satisfying all the original requirements. Clarification might need to be sought over certain points. Any factual statements made by a supplier imply a legal commitment on their part if it influences the customer to offer the contract to that supplier. It is therefore important to get a written, agreed, record of these clarifications. The customer may take the initiative here by keeping notes of meetings and then writing afterwards to the suppliers to get them to confirm the accuracy of the notes. A supplier might, in the final contract document, attempt to exclude any commitment to any representations that have been made in precontract negotiations - the terms of the contract need to be scrutinized in this respect.

Where the delivered product is to be based on an existing product it might be possible to see a demonstration. A danger with demonstrations is that they can be controlled by the supplier and as a passive observer it is often difficult to maintain full attention for more than, say, half-an-hour. Because of this, the customer should produce a schedule of what needs to be demonstrated, ensuring that all the important features are seen in operation.

With off-the-shelf software, it should be possible to have actual access to the application. For example, a demonstration version, which closes itself down after 30 days, might be available. Once again a test plan is needed to ensure that all the important features are evaluated in a complete and consistent manner. Once a particular package emerges as the most likely candidate, it needs to be carefully investigated to see if there are any previously unforeseen factors that might invalidate this choice.

A frequent problem is that while an existing application works well on one platform with a certain level of transactions, it does not work satisfactorily on the platform that the customer has or at the level of throughput that it would be subjected to in the customer's work environment. Demonstrations will not generally reveal this problem. Visits to operational sites already using the system will be more informative in this respect. In the last resort a special volume test could be conducted.

How would you evaluate the following aspects of a proposal? Exercise 10.6

i. The usability of an existing software application.

ii. The usability of a software application that is yet to be designed and constructed.

iii. The maintenance costs of hardware to be supplied.

iv. The time taken to respond to requests for software support.

v. Training.

Eventually a decision will be made to award the contract to one of the suppliers. One of the central reasons for using a structured and, as far as possible, objective approach to evaluation is to be able to demonstrate that the decision has been made impartially and on merit. In most large organizations, placing a contract involves the participation of a second party within the organization, such as a contracts department, who can check that the correct procedures have been carried out. Also the final legal format of a contract will almost certainly require some legal expertise.

In any case, not only should the successful candidate be notified but the unsuccessful candidates should also be told of the decision. This is not simply a matter of courtesy: under GATT or EU rules, there is a legal requirement to do this in certain circumstances. It makes dealing with unsuccessful bidders easier if they can be given clear and objective reasons why their proposals did not find favour.

Where substantial sums of money are involved, legal advice on the terms of the contract is essential.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment