Project management

1
Project management
2
1. Understand the Project/Define the problem

• Why is this project being done?
• Who are the players? Who wants it? Who has
  fought against it?
• Whats the clients priority for the project?

3
Define the Benefit/Cost

• Justification is quantified by dollars saved, by
  goals (not predictions)
• If a benefit cant be quantified, it has no
  implicit target and it is not a justification
• If client cant define benefit, create a set of
  benefits and share them

4
1. Understand the project/define the problem

• Produce a Client Contract
• state goals, costs and benefits
• quantify projects justifications
• establish ground rules for communication, input
• clarify deadlines, deliverables and criteria for
  success

5
Control Client Expectations

• Bring me a rock. ..I need a book about cancer
• ask neutral questions
• If I gave you what you wanted, how would it
  look/what would it do?
• When you use the current system, where does the
  problem occur?
• Tell me how you are hoping to use the
  system/service we create.

6
Control Client Expectations

• Built right at the outset, clients expectations
  are an enormous support at the end!

7
Defining the Deliverables

• Planning and getting started
• project plan, statement of work, cost-benefit
  analysis, list of deliverables, definition of
  scope, work plan, schedule, project overview and
  approach, criteria for success
• Design deliverables
• logical or physical data models and physical
  process models, case studies, etc.

8
Defining the Deliverables

• Acquisition, development and implementation
  deliverables
• RFP, hardware/software capacity, maintenance,
  system test, training, operating procedures,
  cut-over and phase-out

9
2. Plan the project

• Define risks identify mitigating factors
• SWOT
• Organize structure, identify dependencies
  determine methods
• Identify schedule and milestones
• Determine individual tasks
• Begin writing the final plan/report

10
Project Management by Technical Function
Project Manager
Project Support
Technology Architect
Functional Architect
Systems Architect
Programming Leader
Business Analysts
Systems Analysts
Programmers
11
Project Management by Integrated Development Teams
Project manager
Product support
Quality control
Leader of online function
Business analysts
Systems analysts
Programmers
Leader of batch reporting
Business analysts
Systems analysts
Programmers
Leader of interface function
Business analysts
Systems analysts
Programmers
Leader of implementation
Business analysts
Systemsanalysts
Programmers
12
Many ways to organize

• by technology (per previous slide)
• by operations (file maintenance, data entry,
  authentication, reporting)
• by function (accounting, inventory, sales
  analysis)

13
Risk management

• Staff
• Equipment
• Client
• Scope
• Technology
• What are YOUR projects risks in these categories?

14
3. Execute the plan

• Work breakdown structure
• Consider resource leveling
• Estimates at completion
• Use a project management tool Gantt, Critical
  Path Analysis, for example

15
Remember

• A schedule is a consequence of planning it is
  not a primary deliverable
• Change schedules only by changing activities
  activities determine the schedule
• A schedule is a three-stage process
• create the initial schedule
• assign resources to each activity
• align the schedule to clients expectations and
  requirements

16
Gantt chart
1/1 1/15 2/1 2/15 3/1
3/15 4/1 4/15 5/1 5/15
Process Doc
Contract
Plan/Get data
Perform tasks
Write report
Test/deliver
Legend critical path not critical
path slack time
17
Critical Path Analysis
Form team
1 week
1 week
Determine project
Client contract
Perform work
Present project
4 weeks
2 weeks
1 week
Draft final report
8 weeks
18
4. Monitor and control progress

• Determine a reporting structure to keep everyone
  informed use WebBoard match progress to your
  schedule
• Consider control
• control power over others
• control comparing progress to plan so
  corrective action can be taken when deviation
  occurs the use of INFORMATION
• self-control define objectives, personal plan,
  feedback, and authority

19
Evaluate

• People learn more from mistakes than from
  successes!
• Check your work at each milestone the final
  evaluation should accumulate your best learning
  to pass on to future teams or take with you to
  new assignments

20
Project Audit

• Audits should include
• current project status
• future status expected deviations
• status of critical tasks critical tasks, high
  risk, new circumstances
• risk assessment highlight liabilities
• information relevant to other projects
• limitations of the audit suspect assumptions,
  missing data

21
5. Present to client

• There should be no surprises
• Client should be present for final presentation
  prepare appropriate documentation and turn-over
  materials
• In SI505, final presentation will include
  practice with video tape and observance of
  professional presentation protocols (yes, we will
  tell you whats expected!)

22
Success is generally measured by implementation

• In this class, that may not be possible
• Projects should have a final ceremony of closing
• CELEBRATE! You have a right to feel good!

23
Calculation, simulation, and design
24
Outline

• I. Design in a culture of calculation
• II. Design in a culture of simulation
• III. Design as bricolage

25
The culture of calculation

• Abstract
• Rule-based
• Planned

26
Prof. Koffmans Pascal course

• Flowcharts!
• Structured code
• Modularity and re-use

27
Derive a calculation design aesthetic

• What makes a design good?
• Who does the designing?
• What are the signature design achievements?

28
Possible answers

• Universality, transparency
• Credentialed experts
• online library catalogs

29
The culture of simulation

• Concrete
• Exploratory
• Improvisational

30
The cottage cheese story

• A diet conscious cook is allowed a half cup of
  cottage cheese per day
• Recipe calls for two-thirds of daily allotment
• Cook forms circle of cottage cheese, divides into
  thirds -- scrapes two segments into mixing bowl

31
Derive a simulation design aesthetic

• What makes a design good?
• Who does the designing?
• What are the signature design achievements?

32
Possible answers

• Mutability
• Tinkerers (just plain folks, users?)
• the Web

33
Users as bricoleurs

• They make sense of the world in light of
  experience
• They need to play with applications to appreciate
  their function
• True requirements may only become apparent after
  false starts

34
Design as bricolage

• Empathy -- can you see things through the users
  eyes?
• Flexibility -- can you experiment?
• Bricolage -- can you find and assimilate
  successful innovations from other systems and
  services?

35
What keeps designers honest?

• Give users objects to think with (scenarios,
  mock-ups, prototypes)
• Be patientlet users convince themselves
• Know where youve been (collect baseline data)
  and whats changed (collect data as you go along)

36
(No Transcript)