(The article is written with
respect to RFPs floated for e-Gov (e-Governance) projects by different
governments in India; however, some of the points may be generic in nature and
may be relevant in general)
The requested proposal in
RFP (Request for Proposal) for e-Governance (e-Gov) projects (floated by
different governments) are usually turn-key projects intended to improve governance.
These projects are generally related to provisioning of delivery of services,
automation of internal processes, enhancement of available IT Infrastructure (product
or services) or development of MIS (Management Information System intended to
enhance decision making). Usually, e-Gov projects are executed under
Contractual PPP (Public Private Partnership) on BOOT (Build, Own, Operate and
Transfer) model. Mostly, preferred model for selection of vendor through RFP is
QCBS (Quality and Cost Based Selection).
Preparation of RFP is very
important in tender management process for e-Gov projects. This is so, not only
because RFP becomes basis for selection of best possible bidder to do the job
(project(s)) but also because whatever is scoped in final RFP (the one released
after pre-bid meetings including addendum to the one floated for the first
time) usually becomes part of contract (after selection of successful bidder)
with either no change or with a minimal changes. Technically this approach is
reasonable and this may also be legally appropriate.
However, it is practically
difficult to scope a project (with precision in terms of time-budget-quality)
at the time of RFP preparation to executable precision. If an attempt is made
to accommodate all the practicalities of execution in RFP, probably too much
flexibility will need to be incorporated to scope and estimates (of the project)
through introducing possible conditions (with corresponding controls) to be applied
under future circumstances. This will make RFP complicated for clear
understanding by responders and at the same time may induce greater risk of
ambiguity for evaluators.
In this regards, it is
mention worthy that many RFP experts suggest that when designing government
projects, they find difficulty in developing thorough understanding (of the
project dynamics) to minutest detail, which is usually required for conceiving
large projects. Probably this is so, because of the complexity induced by
diversity and volume government projects usually cater to. Things become much
more challenging, when it comes to e-Governance projects, which involves
fundamental change in way of doing things.
Further, it may be noted that
contract is designed to remain static and therefore clauses are purposefully drafted
to remain well defined to the best possible precision. But, it turns out, that
neither projects (that too, complex projects with big budgets) remain static in
nature (during execution) nor can corresponding estimates be expected to remain
static throughout the life-cycle of the project. It is noteworthy that quite
often Progressive
Elaboration, reveals unprecedented circumstances
before the project management. To respond to these situations, in the best
interest of the project, project management has to resort to scope management. With
contractual obligations closely tied to the scope of the project, corresponding
contract management also needs to be carried out. Making changes to a contract
(in which any government is a party) is very difficult and time taking. Also,
vendors show resistance to changes in contract, especially when the changes in
contract impact their financials in negative way (reduced contract amount).
Similarly, another
related aspect is that contract insists on divided accountability (based on
respective scope of contracting agencies – usually successful bidder and the
organization, which floats the tender) but to meet the objectives of the
project it is important for all the contracting parties to assume shared
accountability and put joint efforts.
Thus, putting significant
part of project details (taken from RFP) in contract would need flexible
contract management to accommodate changing dynamics of any project. Project
managers are (professionally) groomed to work strictly in the interest of the project
they are undertaking and they are trained to be flexible in decision making
(even if, this means taking deviations from contractual obligations). But,
organizations (implementing the project) are more comfortable to see progress
of project work in interest of contractual obligations (strict adherence to
contractual obligations) and have huge resistance to initiate process to change
the contract. Even though (as discussed above), these two interests (that of
Project Managers and Organizations) seldom align (with expected precision) in
practice, all the stakeholders want to see the final objectives of the project
met within budget, well in time and with expected quality and most importantly
without changing the contract (without taking into account how far the
situation on ground has drifted away from what was conceived). This illustrates
the dilemma of a project manager on one hand and on the other hand this is
considered as one of the possible reasons e-Gov projects do not succeed to
expected levels (when operating in usual working environment). Further, in a
way, this also throws some light on success of the e-Gov projects, which are
related to issues placed at the center of political spectrum in the state. For
such projects, the criticality of outcome of the project prompts for quick and
flexible decision making in the interest of project with reasonable
justifications supporting the decisions. Therefore, in such projects, the
project management is more empowered to act in the interest of the project (either
at a permissible deviation from strict contractual obligations with suitable
justifications in larger interest of the project or by getting contract changed
according to needs of project).
In a nutshell, above
discussions suggest that drafting an RFP could be one of the critical aspects
to consider for success of e-Gov projects. Nevertheless, it is a big challenge
to write an RFP that is flexible (with respect to assumptions), accommodative
(with respect to changing project dynamics), precise (with respect to outcome),
aligned (with respect to scope/objectives) and requires minimal monitoring and
control throughout the life cycle of the project (as it is observed that mostly
governments do not have human resource with appropriate skills required to enforce
strict monitoring and control of technology intensive projects (like
e-Governance)). The other challenge during execution of project (in accordance
with RFP), is convincing the leadership of contracting parties to show
flexibility towards contract management.
With this discussions on
RFP, contract management and project management, I will like to jot down some
of the points, I feel are important to consider, when drafting RFP for e-Gov
projects:-
1.
Link
the Big Six for Clarity and for Coherence but with suitable
provisions to accommodate Change Management
Mapping
the following six critical aspects (of RFP) with adequate precision articulates
the RFP to the prospective bidders with clarity required to strategize the best
possible response:-
Objective ßà Scope ßà Deliverable
ßÃ
Acceptance ßÃ
Payment ßÃ
Penalty
Objective(s)
– Drawing clear objective(s) with precise description of problem(s) is of prime
importance. Elaborating expectation(s) and exception(s) from solution(s) helps design
of Scope for RFP designer and at the same time helps respondents with design of
A & M (approach & methodology). Abstract objectives may be avoided to
the best possible extent.
Scope –
Scope must be cleanly linked with objective(s) such that any alteration in
objective(s) should make it possible to clearly alter scope (accordingly).
Scope usually may not be altered in most cases, however a provision for logical
scope management may turn out to be helpful.
In
government projects, at times, the time gap between conceptualization and
execution of project is quite big. Therefore, in some cases, it turns out that
when project execution starts, some part of the objectives of the project is
already met by some other related project either of the same department or some
other department. In similar cases, objective or scope need to undergo changes
to avoid duplication of work (and avoid unfruitful expenditure).
Deliverable(s)
– Adequate number of deliverables should be clearly defined. Detailed
description of features of every deliverable must be listed. Attempt should be
made to map each and every deliverable to clause(s) in scope.
Acceptance
Criteria for Deliverables – This is a complex aspect. Acceptance Criteria
(whether confirming to end user expectations or the use cases or to technical
specifications or to agreed service norms or other quality parameters related
to product or services rendered) must take into account Cost, Time and Quality
triad in some way. Assuming a reasonable approach towards accepting the
deliverables with deviations on the above mentioned triad (with suitable justification)
is at times found to be in larger interest of project. Charting out a suitable
metrics for accommodating different types of deviations with no or with calculated
impact on objectives of the project could be helpful.
Payment
Terms – Payments are done against deliverables and penalty is imposed on amount
to be payed (based on acceptance assessment of deliverables on acceptance
criteria). Therefore, payment terms must be synchronized with corresponding deliverables
on one hand and with penalty clauses on the other hand. If a vendor could get
the payment on the day the deliverables are accepted (after suitable deductions
of penalty – if any), this will close the part of project delivered for all
parties.
In
turn-key projects, a due consideration to capex (capital expenditure) and to opex
(operational expenditure) from the point of view of vendor(s) could be
considered. Significant part of capex is related to purchase of equipment
(hardware). Making upfront payment for such purchases (of equipment)
immediately after delivery, testing and installation could make the tender look
lucrative for vendor community (resulting in increased interest in the tender).
Therefore, where ever possible, higher percentage of payments could be
considered to be made at earliest against capex.
Whenever
deemed appropriate a suitable consideration to time value of money could be
helpful. This could include provision to pay interest to vendor(s) against
payment for services, in case of any procedural delay in making payment (to
vendor) by the office taking services from vendor(s).
Penalty
Clauses – Penalty are assumed to work as a deterrent for vendor to abide with certain
contractual terms of critical importance to the project. The idea of penalty
also assumes that the all the possible ways things can go wrong in a project is
attributed to avoidable mistakes committed by any vendor. This very assumption
does not hold true most of the time. More so, for large projects with either
prominent service components or projects dealing with the latest technologies.
e-Gov projects usually have both characteristics, they have prominent service
components and are technology intensive in nature. In my opinion, whether
implemented or exempted, provisions of penalty seldom serves the purpose of
being a deterrent or a supplementing factor to effective monitoring and control
mechanism. It fails as a deterrent because mostly vendors (through their expertise
and experience) are able to make out when do they have chances to fail in
penalty clause(s) and therefore, they include penalty as a cost in the
financials (financial section of RFP). Imposition of penalty are retrospective
in nature and therefore cannot supplement monitoring and control during
execution of project. Therefore, very judicious use of penalty should be
considered and must be closely synchronized with payment terms for ease of
operation.
2.
Maintain
Flexibility in Estimates and Provisions – Estimates are
based on assumptions. It could be helpful to mention the important assumptions
with estimates of critical importance for giving implementers some flexibility
to get the estimates revised, when the assumed conditions fail to hold true in
due course of time. This is true for financial estimates as well as
non-financial estimates.
Many
times in implementation of e-Governance projects in developing countries, the
technical specifications recommended in RFP (like – electronic interface
devices (mobile phones, tablets), application servers, hardware equipment) are
outdated (or are no more in supply in market) by the time project starts
getting executed. Therefore, wherever possible, putting different types of
standards (any equipment must comply with) in RFP instead of specification may
make negotiation with vendors easier for making changes to proposed equipment.
3.
Draft
a suitable Responsibility Matrix for stakeholders
participating in execution – Once tender is awarded to a successful bidder, it
(successful bidder) represents the implementing agency (vendor) for the
project. But, it should be understood that for an external agency to do the job
as critical as implementation of e-Governance project (which involves
multi-level and multi-dimension co-ordination) is not possible unless all the
stakeholders (internal and external) extend required support to the vendor. Therefore,
vendor management team (of the office, which floats tender) must be well aware
about the complexities of shared responsibilities (inter-weaving the dynamics
of project) and must be adequately empowered to drive different stakeholders in
the interest of the project. Leadership of vendor management team should ensure
that their office owns the project and the vendor are one of the partners in
the project.
A
signed off responsibility matrix by the highest authority of the office of
vendor management team can be helpful in making different stakeholders
(including the vendor) more accountable towards their respective
responsibilities towards the project.
4.
Synchronize
with varying Execution Speeds and Procedural Compulsions pertaining to various
participating organizations - Extra care must be taken
when defining timelines for deliverables (or activities) having dependencies on
more than one organization. Mostly, different organizations have different work
culture, different approach to projects and more importantly different
priorities for a particular project in question. Thus, realistic execution
velocity of projects requires accommodative approach for varying execution
capabilities of various participating organizations.
5.
Try
to make M & A (Methodology and Approach) a test of understanding of the
project (by prospective Bidders) – M & A should be
the one of the most critical aspect for bidders to show their understanding
about the project, their domain expertise and their grip on required tools,
technologies and methodologies.
Significant
weightage must be given to a bidder for developing an in depth understanding of
the environment and circumstances on which the project is going to operate,
calculations related to risks and possible mitigation plans, understanding of
project dynamics and stakeholder management.
Special
attention must be given to maturity of tried and tested methodologies of the
bidders and their ability of alter (customize) these methodologies in the
context of the project they are bidding for. Similarly, extra effort put by the
bidders for suggesting different alternatives or some innovative ways of doing
things must be appropriately rewarded through bonus points.
But,
all these evaluations must be through objective means (with minimal
subjectivity in assessment) to the best possible extent. This may take a lot of
time and multiple rounds of discussions with different stakeholders by the
tender committee, but the effort may worth taking for truly executing the QCBS
model of procurement.
It
may be noted that M & A tests differentiation in the products and services
of the prospective bidders for best suitability. Unless M & A is able to
capture and express these differentiations through suitable variance in
technical points given to the bidders, truly capable bidder may not get
properly screened through the QCBS approach.
6.
Choose
Professional Skills or Choose Organizational Capabilities –
In human resource intensive projects (projects requiring skilled workforce), usually,
there are points (towards technical evaluation score) for deployment of
suitable professionals. However, in my opinion, RFP writers should be very
clear on whether they want to buy Professional Skills to be harnessed by
project management team of the organization (which floats the RFP) or they want
to buy services of a company for promised value addition as per its brand.
Companies
train their employees to utilize the intellectual capital (accumulated by these
companies) through internal organizational process to deliver the promised
product and services. So, if the project need organizational capabilities
(demonstrated through services and products) from vendor, leaving the decision
to select profile of resources to be deployed on project on vendors could be a
better idea.
7.
Measureable
Metric System for Monitoring & Control – Service Level
Criteria (or any other Monitoring and Control mechanism) must be well defined
and must be easily measured against a sensitive and representative indices.
Optimal service level criteria, which make clear business sense in respect to
the project, should be chosen.
8.
Simple
Pre-Qualification Criteria – Pre-qualification criteria is a
yardstick to allow companies to compete for any tender. This means, though the qualification criteria must
be specific and unambiguous, yet they must ensure a fair competition.
Many
times relatively small players (may be SMEs (Small and Medium Enterprise) ) with
equally good capability (with respect to requirements of the project) do not qualify
in Pre-Qualification phase (of tendering process) due to criteria chosen for
Pre-Qualification relating to past performances like (say) criteria related to
company turnover or past experience of similar work. Therefore, so far as the prevalent
practices/guidelines permit, every attempt should be made to accommodate every company
capable to perform and willing to participate.
9.
Detailed
Cost Calculations – The financials section requesting cost
from bidders must be a very detailed, unambiguous and easy to understand for
the bidders. Taxation for products and services must be cleanly outlined. Special
considerations must be taken for components like transportation cost,
mobilization cost, logistics cost, cost of office space (work-station) and
administrative costs.
Thrust
of financials in RFP must be towards value for money rather than bias towards
lowest cost. Establishing value for money could be a very difficult task. It is
believed that QCBS to some extent helps in ensuring value for money.
Reference:-
http://uk.practicallaw.com/2-386-8761?service=publicsector#a101987
/********************************/
