P. 1
Hacker's Guide to Project Management

Hacker's Guide to Project Management

|Views: 997|Likes:
Published by Nauroz Khan
Methods that how to manage a project at any level.....
Methods that how to manage a project at any level.....

More info:

Categories:Topics, Art & Design
Published by: Nauroz Khan on Mar 12, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/19/2013

pdf

text

original

There are several reasons why you might want to procure something from outside

your own organisation, including the following:

£

You may not have the skills or resources to develop the system yourselves,

£

You may want to supplement your skills with external resources but retain

control of the development,

£

You may believe that there are good “package” solutions to your problems -

you’d be daft to write your own word-processor, for example,

£

You may want to use an existing system either as a basis for development or as a

prototype to further investigate the requirements.

You must understand why you are running the procurement, because that will affect

its objectives and structure. If, for example, you have decided on a procurement

because a package will be a cheap solution of known quality, then you will be quite

within your rights to question the justification of user requests for “customisation”

which could destroy those benefits.

If you are buying a system (or some

part of one), the procurement

process will follow a structure like

that in the diagram. The Analysis

stage will produce one or more

documents which define what you

require, you will find a suitable

supplier, and establish a contract.

The supplier will then either

undertake his own development

process, or sell you the products of

an earlier development. You will

have to monitor progress and

control communications with the

supplier.

You will take this product into

Transition, performing tests to accept it, integrating it with other systems, and

preparing it for live use by the users.

STRATEGY

ANALYSIS

DESIGN

TRANSITION

PRODUCTION

BUILD

DOCUMENTATION

PROCUREMENT

CONTRACTING

SUPPLIER’S
DEVELOPMENT
PROCESS

A Hacker’s Guide to Project Management

131

If you are buying a service such as consultancy, the process is similar, but the

specification will define what the supplier is going to do, and you will manage their

tasks just like the other tasks within your project.

There are two central documents in a typical procurement process: the Invitation to

Tender and the Contract. The Invitation to Tender (or ITT, also known as a Request for

Proposals or RFP) is a document which presents the requirements, asks a number of

questions about the prospective supplier’s ability to deliver a solution, and the terms

on which they are prepared to do business.

Most large organisations have a template or checklist for an ITT, and a defined

process for issuing it and reviewing the responses (called Tenders, or Proposals). If

not, then the following brief checklist for its contents may help:

1. Background to the procurement, and its objectives.

2. The functional, technical and quality requirements, derived from the Statement

of Requirements.

3. Required deliverables from the development or supply, including support and

maintenance services, training and documentation.

4. Required proposal format. It’s quite common to suggest a format in which

sections of the proposal match the sections of the ITT they answer.

5. Procedures for responding to the ITT, requesting clarification etc. This should

include an indication of the selection criteria.

6. Expected type of contract and cost structure. Definition of the form in which

prices should be quoted.

7. Qualifications of the supplier. Questions about their size, financial stability,

development and quality practices etc.

8. Schedule for the submission of proposals, and their evaluation.

Make sure that the roles, responsibilities and dates in the ITT are sensible and clear.

Ensure that the potential supplier can clearly see the timescales you are working to,

the interfaces which you require between this system and others, and has some idea

(possibly pessimistic) of your budget. Get absolute clarification from the users on

mandatory and desirable requirements: if a package solution meets all the “musts”

and relatively few of the “shoulds” it is a viable solution and the users should not

expect to make many changes to it.

You will, hopefully, receive a number of responses to the ITT, and can select the one

which best meets the overall objectives (but it need not be the best technical solution).

You will then have to agree a contract with that supplier, and control their work

through to acceptance.

A Hacker’s Guide to Project Management

132

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->