Difference between revisions of "DC2009:Client Perspective on Software Development Projects"
Line 71: | Line 71: | ||
Client needs to understand the reasons why/the roots of established business processes | Client needs to understand the reasons why/the roots of established business processes | ||
− | + | AH-HA's: | |
* My relationship with my vendor is all wrong | * My relationship with my vendor is all wrong |
Revision as of 00:42, 14 January 2016
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 w/ 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 w/ 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 nonessential items onto a wish list – sacrificing perfect to the good
Launching
- Vendor deliverable: beta testing
- Client much create testing plan
- Client must fully engage w/ 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