Difference between revisions of "DC2009:Client Perspective on Software Development Projects"
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
== Session Notes == | == Session Notes == | ||
| − | What Clients Need to Know About Working | + | What Clients Need to Know About Working with Vendors - Oksana |
Key point: Client needs to take ownership of their project. | Key point: Client needs to take ownership of their project. | ||
| Line 17: | Line 17: | ||
You don’t need technical skills to run an app dev project | You don’t need technical skills to run an app dev project | ||
| − | Kick-off meeting | + | Kick-off meeting with vendor |
* Build a relationship | * Build a relationship | ||
* Vendor introduces project methodology (project life cycle) | * Vendor introduces project methodology (project life cycle) | ||
| Line 39: | Line 39: | ||
Design Phase | Design Phase | ||
* Have a small number of people who will sign off on design | * Have a small number of people who will sign off on design | ||
| − | * Share org’s design guidelines | + | * Share org’s design guidelines with vendor |
* Kick-off design meeting (design questionnaire, number of design rounds) | * Kick-off design meeting (design questionnaire, number of design rounds) | ||
* Vendor deliverables: mock-ups or HTML | * Vendor deliverables: mock-ups or HTML | ||
| Line 50: | Line 50: | ||
* Will vendor deliver on time? | * Will vendor deliver on time? | ||
* Will vendor deliver on budget? | * Will vendor deliver on budget? | ||
| − | * Client must monitor: launch date, moving | + | * Client must monitor: launch date, moving non-essential items onto a wish list – sacrificing perfect to the good |
Launching | Launching | ||
* Vendor deliverable: beta testing | * Vendor deliverable: beta testing | ||
* Client much create testing plan | * Client much create testing plan | ||
| − | * Client must fully engage | + | * Client must fully engage with testing |
* Launch | * Launch | ||
* Repeat testing | * Repeat testing | ||
| Line 63: | Line 63: | ||
Shared responsibility for sharing expertise/best practices – common interest in success – it is a partnership | Shared responsibility for sharing expertise/best practices – common interest in success – it is a partnership | ||
| − | But it’s hard for a small, overstretched | + | 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 | There can be a need for the vendor to do some of the client’s tasks for them | ||
Latest revision as of 23:21, 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 with 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