DC2009:Client Perspective on Software Development Projects

From Managing Nonprofit Technology Projects Wiki
Revision as of 00:43, 14 January 2016 by Miriam (talk | contribs)
Jump to navigation Jump to search

Description

This session will examine what it is like to be on the receiving end of a software development project. Dealing with vendors, making sure implementations match needs, and managing technology issues that are controlled by others will all be covered, and participants are encouraged to share their own stories.

Session Notes

What Clients Need to Know About Working w/ Vendors - Oksana

Key point: Client needs to take ownership of their project.

Homework

  • Define your task
  • Assemble your team
  • Document everything (expectations, strategy, reasons for decisions, risks, project work plan)
  • Establish process for future management communications strategy

You don’t need technical skills to run an app dev project

Kick-off meeting with vendor

  • Build a relationship
  • Vendor introduces project methodology (project life cycle)
    • Discovery/project planning
    • Design
    • Development
    • Delivery/launch
  • Establish communication channels
  • Balance: the client is always right vs. vendor expertise

Discovery/Project Planning

  • Establish communication channels:
    • Vendor: weekly project status report; budget update
    • Client: info about current processes and system in place (use prepared documentation)
  • One POC: vendor project manager to client project manager
  • Keep track of all communications
  • Be realistic about scope and deadlines
  • Vendor deliverables: maps, wireframes, requirements, timeline, budget
  • Client must sign off on all of this

Design Phase

  • Have a small number of people who will sign off on design
  • Share org’s design guidelines with vendor
  • Kick-off design meeting (design questionnaire, number of design rounds)
  • Vendor deliverables: mock-ups or HTML
  • Client must sign off on design and code

Development Phase

  • This is the phase where things go wrong – this is not the phase for the client to disengage
  • Vendor must present weekly updates and scope changes
  • Client: be thoughtful about number and scope of changes – sign off on any changes that adjust timeline and budget
  • Will vendor deliver on time?
  • Will vendor deliver on budget?
  • Client must monitor: launch date, moving non-essential items onto a wish list – sacrificing perfect to the good

Launching

  • Vendor deliverable: beta testing
  • Client much create testing plan
  • Client must fully engage with testing
  • Launch
  • Repeat testing

Importance of client testing: they should be motivated to try to break it (whereas the developer just wants to see it work)

Shared responsibility for sharing expertise/best practices – common interest in success – it is a partnership

But it’s hard for a small, overstretched Nonprofit to engage sufficiently to create/fulfilling that partnership

There can be a need for the vendor to do some of the client’s tasks for them

But there need to be clear boundaries and role definitions in the relationship

Client needs to understand the reasons why/the roots of established business processes

AH-HA's:

  • My relationship with my vendor is all wrong
  • Importance of doing thorough testing
  • We’re all dealing with similar issues
  • Importance of speaking up when the relationship isn’t working
  • A good client is a passionate client that asks clients
  • Clients need to take full ownership of their projects
Retrieved from "https://mntp.aspirationtech.org/index.php?title=DC2009:Client_Perspective_on_Software_Development_Projects&oldid=551"