Week2 IBS 540

1
Week2 IBS 540
2
NEEDS IDENTIFICATION CONCEPTS

• The first phase in the project life cycle
• The needs identification process is the initial
  phase of the project lifecycle. It starts with
  the recognition of a need, problem, or
  opportunity and ends with the issuance of a
  request for proposal.

3
Purpose of preparing and RFP The purpose of
preparing a RFP is to state, comprehensively
and in detail, what is required, from the
customers point of view, to address the
identified need.
Why are the terms comprehensively and in detail
so important ?
4
A good RFP allows contractors or a project team
to understand what the customers expects so
that they can prepare a thorough proposal that
will satisfy the customers requirements at a
realistic price.
5
Preparing a request for proposal occurs at the
end of the needs identification phase.
IDENTIFY A NEED
DEVELOP A PROPOSED SOLUTION
PERFORM THE PROJECT
TERMINATE THE PROJECT
6
Guidelines for drafting a formal RFP
The example starts off with an opening statement
that covers the general objective of the project
and establishes confidential treatment of the
project information.
7
Guidelines for drafting a formal RFP
STATEMENT OF WORK (SOW)
An RFP must include an SOW. An SOW communicates
the scope of the project, outlining the tasks or
work elements the customer wants project team to
perform.
8
Guidelines for drafting a formal RFP
CUSTOMER REQUIREMENTS
An RFP must include the customer requirements,
which define specifications and attributes.
Requirements should cover size, quantity,
colour, weight, speed, and other physical or
operational parameters the contractors proposed
solution must satisfy.
9
Guidelines for drafting a formal RFP
REQUIREMENTS CONTINUED ..
Required Process Details
Performance / Quality expectations
10
Guidelines for drafting a formal RFP
DELIVERABLES
The RFP must state what deliverables the customer
expects the contractor and project team to
provide. Deliverable are the tangible items
that the contractor or project team is to
provide.
11
Guidelines for drafting a formal RFP
CUSTOMER-SUPPLIED ITEMS
The RFP should list any customer supplied items.
REQUIRED APPROVALS
The RFP might state the approvals required by the
customer.
12
Guidelines for drafting a formal RFP
CONTRACT TYPE
Some RFPs might mention the type of contract the
customer intends to use. Some contracts can be
for a fixed price and some can be for time and
materials.
Due Date
The RFP should state the required due date for
proposal submission.
Schedule
The RFP should state the required schedule for
completion of the project.
13
Guidelines for drafting a formal RFP
PAYMENT TERMS
An RFP should state the payment terms the
customer intends to utilize.
A detailed definition of complete should be
defined on the contract and in terms of
measurable deliverables. This will ensure that
payment terms are tied to finite deliverables.
14
Guidelines for drafting a formal RFP
The RFP should provide instructions for the
minimum format and content required in the
proposal. This will allow the review process to
be easier due to standard format and clearer
expectations on minimum information requirements.
15
Guidelines for drafting a formal RFP
Evaluation criteria is the criteria that the
customer will use to evaluate proposals from
competing contractors in order to select the one
to perform the project. Criteria could
include Contractors experience with similar
projects, technical approach proposed, the
schedule, and the costs.
16
SOLICITING PROPOSALS
Once the RFP has been prepared, the customer
solicits proposals by notifying potential
contractors that the RFP is available. A method
is for the customer to research and identify a
select group of contractors in advance and send
them a copy of the RFP. Another method is for
large organizations like governments to post the
RFPs in standard publications (Commerce
Business Daily) or bulletin boards for viewing
by potential contractors.
17
Why would a a customer give contractors
instructions in the RFP to submit their
proposals according to a standard format?
18

PROPOSED SOLUTIONS .
The Proposed Solution process is the second
phase of the project lifecycle. It starts when
the RFP becomes available at the conclusion of
the needs identification phase and ends when an
agreement is reached with the person,
organization, or contractor selected to
implement the proposed solution.
19
(No Transcript)
20
The Proposed Solution phase is complete when an
agreement is completed between customer and
vendor.
IDENTIFY A NEED
AGREEMENT
DEVELOP A PROPOSED SOLUTION
PERFORM THE PROJECT
TERMINATE THE PROJECT
21
Project Brief

• Project BriefIncludes Business Overview
• Also called Creative Brief, or User Experience
• Target audience
• Sites Goals
• Competitors
• Provides more details about what is to be done
  than indicated RFP
• Just indicate user-system interaction
• dont specify how
• use plain English
• Important for team communication
• Very important for next phases.

22
Currently

• We are done with
• Identifying a need
• Creating an RFP
• Creating a proposal
• Creating a Project Brief
• Now that we know what really the customer wants
  we can start creating our team. But how?
• Are there enough programmers or marketers
  available within the company?
• Can I (as a project manager) work with anybody I
  want to work with?

23
FTEs

• Full Time Equivalents used for creating a
  team and estimating a project budget
• Your team has specialists in many fields, but may
  only draw on each one as needed
• Examples Designers, QA, anybody
• Link to FTE example, discuss

24
(No Transcript)
25
The Need For FTE

• You are requesting resources from the upper
  management
• You may want to include certain team members in
  your team but they may not be available
• FTE also helps you create projects schedule and
  budget

26
Process Management

• Introduction
• Information system development and maintenance
  are business processes very complex business
  processes.
• Like most business processes, information system
  development processes must be managed.
• Process management is a prerequisite to systems
  development project management.
• Process management is the planning, selection,
  deployment, and consistent application of
  standard system development methods, tools,
  techniques, and technologies to all information
  system projects.
• For most information system organizations,
  process management is built around a system
  development methodology.

27
Process Management

• Management of the Methodology
• Once a methodology has been selected (or
  developed), it must be implemented.
• This can be an enormous undertaking that requires
  the following
• Establishing visibility for the methodology by
  educating all developers, managers, and technical
  support staff in the basic development process,
  tools, and techniques to be used.
• Providing just-in-time detailed training to
  development teams as each team begins its first
  project.
• Providing consultation to project teams as they
  apply the methodology.
• Improving the methodology.

28
Project Life Cycle
29
Project Cycle
30
Jjg 5 planes
From The Elements of User Experience by Jesse
James Garrett
31
Project Life Cycle
32
A Circus!!
33
Teams-work

• Client-contractor relationships
• Broad expertise
• Communication is key

34
Client Team

• Client team members
• project leader (producer, team leader, )
• coordinates efforts of client organization
• liaison to developer
• decision maker(s)
• needs information
• webmaster(s)
• manages/maintains site hosting

35
Client Team

• Client team members
• contentmasters
• responsible for providing content
• other content contributors
• writers, photographers, artists, designers, etc.
• Timely coordination important

36
Developer Types

• Proprietors
• individual or small group
• only interested in creating site
• not much interest in administrative aspects
• Partnerships
• more serious about developing sites
• usually start with small projects

37
Developer Types

• Boutiques
• larger partnerships (10 people) that includes
  administrative and sales personnel
• many design-oriented jobs or some
  technically-oriented jobs
• Agencies
• multidisciplinary go after larger jobs
• usually outsource many design functions
• look for accounts rather than single jobs

38
Development Team

• Formal teams more productive
• IT or advertising often vie for site control
• Classification of team members
• core
• key personnel for all kinds of web development
• examples producer, designers
• extended
• personnel not always needed or have
  cross-functional roles
• examples programmer, network engineer
• special
• have skills not part of core or extended team
• examples audio engineering, security specialist

39
Developer Team

• Executive production (COO)
• Responsible for informing, empowering team
• Some skills needed
• similar project management and development
  experience (software, film, etc.)
• understanding of scheduling, budgeting, resource
  allocation
• leadership ability
• oral and written communication skills
• ability to handle stress

40
Developer Team

• Account manager
• client advocate in large companies
• handles business relationship with client
• Technical lead
• helps design staffs for all current jobs
• Production specialist
• implements website with HTML, Java, etc.
• integrates all components for delivery to client
• Production manager
• manages production staff
• schedules resources

41
Developer Team

• Creative director
• provides vision for site
• plans site with designers
• System administrator
• maintains computer/network systems
• updates, security, tools, etc.
• Designer
• makes design decisions including user-interface
  and navigation
• gives site look and feel

42
Developer Team

• Project manager
• manages day-to-day activity
• keeps project in budget and on schedule
• Creative staff
• copywriters, artists, strategists, interface
  designers, etc.
• Office manager
• handles administrative details (contracts, paying
  bills, payroll, etc.)

43
Developer Team

• Information architect
• responsible for navigation, interactive design,
  search and data retrieval, etc.
• Quality assurance lead
• assures that site produced meets specifications
  provided
• Technical support staff
• supports design function

44
Technical Support Staff

• Database Architect
• designs database
• Developers/programmers
• client-side (Java apps, scripts, etc.)
• server-side (connect HTML to databases)
• Technical writers
• document process for client and developer

45
Technical Support Functions

• Database development and use
• Extensive programming
• Security issues
• Video/audio engineering
• Webcasts

46
Building a Team

• Identify necessary skills
• Assessing skills of personnel
• Other considerations
• critical deadline?
• risks
• interpersonal skills
• Cross-functional capabilities

47
Building a Team

• Professional motivation
• task-oriented
• motivated by work
• self-oriented
• motivated by personal success, recognition
• interaction-oriented
• motivated by presence, actions of co-workers

48
Building a Team

• Work habits
• Programmers
• solitary, usually work alone
• ask about risks, concerns
• Designers
• usually perfectionists
• keep on task
• Writers
• solitary
• must know who audience is, project objectives

49
Leading a Team

• Provide motivation and support
• Balance timeline with budget
• Keep goals in mind
• Dont let personal attributes get in way of
  completing project

50
Communication Strategies

• How do you communicate the necessary information
  to a large team?
• What are the pros cons of different strategies?

51
Meetings vs. Documents

• Two of the major means of team communication
• Both meetings documents have their uses
• Both work as a dialog
• When do you have a meeting, when do you write a
  document? (discuss)

52
Have a meeting when

• People are available, but you have more questions
  than answers
• The information available is fuzzy, and may
  require clarification
• You need group communication quickly
• Communication levels are low, and/or people are
  unclear or tense (face-to-face contact is good
  for communication)
• At the beginning of every project!
• When important information has changed
• On a regular basis (weekly)

53
Write a document when

• You have the answers / information
• Youll need this info at some later
  date(detailed information, reference
  information, contractual agreements, schedules)
• The info is stable, not going to change quickly
  (project requirements, for example)
• You need precise, detailed answers, or approval
  on precise, detailed proposals
• After an important decision in a meeting
  (especially if it only included part of the team)

54
Tips for running a meeting

• Reserve a space and a time
• Make sure everyone can be there
• Have a written agenda (copies for everyone)
• Start promptly (make sure everyones there)
• Make the introductions (esp. w/clients, vendors)
• Stick to the agenda (stay focussed, but be
  flexible)
• Finish promptly (dont drag on 3hrs if you
  scheduled 30min)
• Decide on Next Steps
• Follow up with an email (notes, decisions, next
  steps)

55
Tips for writing Documentation

• Be detailed thorough, but concise (its not a
  letter to grandma)
• Use topic headings to organize subjects, make it
  easy to scan (people are busy, you want them to
  read this)
• Keep documentation current (and announce
  changes!)
• Put a date on everything (simple version control)
• Numbering is a matter of style (1.1.2, 1.2.3)
• Post documentation on your Project Site (whats
  a Project Site?)

56
Next Deliverable

• Project Briefand User Experience Includes
  Business Overview
• Target audience
• Sites Goals
• Competitors
• Customize and complete the questionnaire

57
Next Deliverable

• Provides more details about what is to be done
  than indicated in RFP
• Just indicate user-system interaction
• dont specify how
• use plain English
• Keep updated implementation will likely occur
  close to launch
• Important for team communication
• Very important for next phases.

58
Next

• FTEs create your team, and indicate how much of
  each members time you expect to need during each
  phase of your project