CustomerOriented Development, Project Recovery and Negotiation

1
Customer-Oriented Development,Project Recovery
and Negotiation

• Customer.ppt

2
Customer-Oriented Development

• It is important to develop good relationships
  with customers (I.e. clients) -- WHY?
• System development is a partnership effort (it is
  a two-way street)
• It is difficult (if not impossible) to achieve
  high quality partnership without good IT-business
  relationships
• High quality IS-client relationships reduce
  chances of IS implementation failures. How?

3
Customer-Oriented Development

• High quality IS-client relationships reduce
  chances of IS implementation failures. How?
• management of clients expectations as to project
  scope, deliverables, development speed, etc.
• improvement in mutual understanding as to quality
  and satisfaction
• building systems clients actually use
• improving efficiency of interrelated tasks
• High-quality relationships also
• enhance professional IS credibility
• improve quality of work life for ISPs and clients

4
Customer-Oriented Development

• Poor IS-business relationships
• contribute to IS project failures
• detract from IS credibility
• hinder success of subsequent organizational
  change projects
• plant the seed for the decision to eventually
  outsource IS services to a third party contractor

5
Reasons for poor relationships

• Lack of collaboration among key stakeholders
• culture gap between technical specialists and
  their business-focused clients
• behaviors of IS specialists during projects
• failure to understand clients needs and
  incentives
• overemphasis on technical issues at the expense
  of social issues
• overall, a lack of client-oriented behaviors and
  service culture

6
High quality IT-business relationships

• Will discuss conditions under which good
  relationships evolve at the end of this
  presentation

7
Customer-Oriented Practices

• Planning
• Select appropriate lifecycle model that gives
  customers progress visibility, such as?
• Identify real customer (the boss?)
• Create a Win-Win project (Theory-W project
  management)
• Mitigate the risks

8
Customer-Oriented Practices

• Requirements Analysis
• Gather the real requirements (essential) with
  customer-oriented requirements practices
• Clients are more satisfied if they participate in
  requirements specifications. Why?
• Use methods such as JAD

9
Customer-Oriented Practices

• Design
• Let customers change their minds occasionally
• Construction
• Use readable, modifiable coding practices so you
  can change the software
• Use project-monitoring (mini-milestones) so
  customer knows you are accomplishing tasks
• Lifecycle model that shows progress

10
Managing Customer Expectations

• Prevent customer-determined schedule before
  requirements resources are known
• Manage the size complexity of features
• Emphasize that the prototype isnt the product
• Dont create unrealistic expectations about
  schedule, functionality, etc.

11
Use Project Recovery When...

• Dont know when project will finish
• Laden with defects
• Developers working burnout hours, low morale
• Nobody can control the schedule

• Customer doesnt believe project will be done
• The team is defensive, relations are strained
• Project is about to be canceled

12
Approaches to Recovery

• Cut project size to fit time effort planned
• Increase process productivity by focusing on
  short-term improvements
• Slip schedule proceed w/damage control
• Combination of all 3 Drop features, increase
  productivity slip schedule
• Get project under control FINISH it!
• Problem NOT catching up BUT finishing project

13
Recovery Plan First Steps

• Assess situation how firm is deadline?
• Apply Theory-W analysis -- make winners out of
  everyone or quit
• Mentally prepare yourself to fix the project
• Ask team what needs to be done
• Be realistic about what you can expect
• Dont promise unrealistic new delivery dates

14
THEORY- W --?? WHAT IS IT AND HOW DOES IT
WORK? WHAT ARE THE BENEFITS?
15
Theory W-Stakeholder Conflicting Goals

• Customers want quick schedule, low budget, lots
  of features, user-friendly, robust software
• Bosses want no overruns, no surprises, successful
  project
• Developers want interesting work, challenge, no
  grunt work, home life
• Maintainers want no defects, documentation,
  modifiability

16
Theory-W Benefits

• Project objectives are clearer from beginning
  because each stakeholders win conditions are
  identified up front.
• Better communication with customers
• Better requirements reduce rework
• Goal-setting produces better schedule
  expectations
• Minimizes feature creep

17
Theory-W Everybody a Winner

• Separate people from the problem
• Focus on interests rather than positions
• Invent options for mutual gain
• Insist on objective criteria
• Set project up so everyone can win - if you
  cannot set it up, then dont do the project

18
Win-Win Steps

• 1. Establish Win-Win Preconditions -
• Identify include all the stakeholders
• Establish reasonable expectations
• Assign tasks so people can achieve their own win
  conditions
• Provide environment that supports project goals,
  e.g., training, appropriate lifecycle model

19
Win-Win Steps

• 2. Structure Win-Win Software Process
• Establish a realistic plan (see Step 1)
• Use the plan to control the project (follow it!)
• Identify manage win-lose lose-lose risks
• For each win condition, identify monitor risks
• Keep people involved

20
Win-Win Steps

• 3. Structure Win-Win Product
• Internal parts that developers maintainers see
• Documentation
• Modifiability
• External parts that customers/users see
• Easy to learn and to use
• Robust

21
When is Win-Win Appropriate?

• Project recovery or from beginning (best)
• When there is a champion (upper-level support) to
  bring in all stakeholders
• Small or large projects
• Downside? -- Managers role more demanding
• Has to manage stakeholder relationships
• Negotiate with stakeholders
• Set monitor goals

22
Leverage the People

• Restore team morale
• Improve working conditions
• Clean up major personnel problems
• Replace problem leadership,
• Give managers assistance
• Change managers supervisor

23
Leverage the People

• Add people carefully, if at all
• Instead focus existing team members time on
  project
• Allow team members to respond differently
• Some work harder
• Some work slowly but surely
• See that developers pace themselves

24
Leverage the Process

• Find fix the classic mistakes
• Are you still changing the project definition?
• What about the design adequacy?
• Too few management controls to track status?
• Shortchanged quality to meet the deadline?
• Are people getting burned out?

25
Leverage the Process

• Find fix the classic mistakes
• Is the deadline realistic?
• Are people working too hard quitting?
• Is new technology a problem?
• Problem developers? Low morale? Accountability?
• Fix broken development processes
• Usually software development fundamentals, e.g.,
  version control, defect tracking

26
Leveraging Process

• Use miniature milestones
• Schedule realistically with miniature milestones
• Track scheduling progress carefully
• Record reasons for missed milestones
• Recalibrate schedules from what you learn after
  2-3 weeks have passed
• Dont commit to schedule until you have one you
  can believe
• Manage risks carefully

27
Leverage the Product

• Stabilize the requirements
• First determine WHAT the requirements are
• Trim the feature set - prioritize whats left
• Assess your political position?
• Reduce number of defects keep them low
• Get to a state you can test keep it working