The Small Fish in a Big Pond

Copyright © 2015 Float Mobile Learning. All rights reserved. www.ﬂoatlearning.com
The Small Fish in a Big Pond Some Things We Learned Working with Large Clients Daniel Pfeiﬀer • @mediabounds

How do we support people   to build great software   which in turn provides opportunities   to build up great people?

The Roadmap Before You Get the Work Working the Work Delivering the Work Finishing the Work

Use Quad Charts to Convey Ideas Before You Get the Work 1

Concept What is it? What does it look like? Cost (ROM) and Schedule What is this going to cost and how long will it take? Deliverables What is the end product? Contact How does someone contact you? Technical Approach How will it be built? Capabilities What are the notable or new features? Who needs those features?

Quad Charts are… • The MVP of the proposal and the TL;DR of white papers • Often more eﬀective at communicating an idea • Good conversation starters • Easily shareable

Expect Some   Red Tape Before You Get the Work 2

Supplier/Vendor Onboarding • Vets your reliability as a supplier • Can feel intrusive – but it helps you in the long run • Grants you access to submit invoices for payment • Introduces you to their software standards and requirements • Trains you on the client’s Code of Ethics • Establishes a Master Services Agreement (MSA) • And more!

The Master Services Agreement • This will likely be provided by the client for you to sign • Governs your future relationship with the client • All future work falls under the umbrella of the MSA • Consider bringing a lawyer in to explain the agreement

The Security Assessment • An extensive questionnaire about your company’s computing practices • Good opportunity to evaluate your company's security practices • Some questions may seem ridiculous or simply not apply • Will likely require a few rounds of revisions

Don’t disqualify yourself during onboarding   by being diﬃcult

Protect your Intellectual Property Before You Get the Work 3

IANAL I am not a lawyer. Seriously. Not even remotely.

Protect your Intellectual Property • Be sure you understand... -who owns the code at the end of the project? -who has the rights to use the code in the future? • You want the freedom to reuse and build upon your innovative solutions • This may be decided in the MSA

Create an   Hours Estimate Before You Get the Work 4

Estimates • Even if you don’t base the price on the estimate,   you need to understand how much time this will take • It is very likely the estimate will be wrong, but that's okay

Risks and Contingency • Risks are variables that could cause the project to fail • Anything outside of your control is a risk • Account for risks by placing a contingency in your budget

Plan an Easy   First Deliverable Before You Get the Work 5

The First Deliverable • Most big companies do not allow you   to invoice upon signing the contract • Kickoﬀ meeting notes, initial node maps,   use case drafts all count as deliverables

Net 10? Net 30?

Expect Net 60 or Net 90 • Many large companies have net 60 (or longer) payment schedules • Some even have set payment dates for invoices • If you miss a due date for an invoice, a net 60 may become net 120 • Plan to use their invoicing system

Deﬁne Unique Roles for   Team Members Working the Work 6

Plan Together

Document Tasks and Due Dates

Avoid   Scope Creep Working the Work 7

Scope Creep ≠ Value Add

Scope Creep ≠ Value Add • Don't make assumptions about value • Discuss impact with client • Trade features or backlog ideas • Produce a change order

Avoid   Rabbit Trails Working the Work 8

Am I headed in   the right direction?

Experiment • Similar to a spike — designed to further understanding • Fueled by a single question — “Can I do X with Y under Z conditions?” • Answer within one day • Break big questions into smaller questions • Pre-deﬁne when an approach should be abandoned

Invest • Commit to solving the problem in the chosen approach • Get it working, then get it working well

Log Time Spent to a Deliverable Working the Work 9

Remove Burdens of Time Reporting • Ensure no one feels compelled to lie about time spent   (especially new team members) • Never punish for exceeding an estimate • Use the diﬀerence to determine what (if any)   improvements need to be made • Find a tool that makes this easy

Frequently (Re)Evaluate   Time Remaining Working the Work 10

Burndown

Burning Down?

When Things Get Oﬀ Track • Something needs to change: -Time frame -Scope -People • Respond quickly and wisely

Avoid Entering Survival Mode Working the Work 11

Do not be controlled   by your to-do list

Produce Accurate Documentation Working the Work 12

Accurate Documentation • Inaccurate and incomplete documentation draws out the QA process • You can still be “agile” and produce great docs -Agile has never been about making it up as you go along -Keep docs in a wiki where developers can update as needed

Do Not   Deliver Late Delivering the Work 13

Do Not Deliver Late • Delivering “on time” is largely about meeting client expectations • Being “on time” demonstrates expertise • It’s okay for dates and scope to shift (just not on the due date)

Do Not Allow Revision Cycles Delivering the Work 14

Do Not Allow Revision Cycles • Require client to sign-oﬀ "with changes" • Give the client tight, but realistic, approval windows

Help the Client Release to   their Customer Finishing the Work 15

Help Prepare for Change • Make app onboarding delightful • Help produce fun, short marketing videos • Make the change optional, but provide enticement • Let people provide feedback • Include analytics and measure usage • Plan to build version 1.1

Check-in with   the Client Finishing the Work 16

How do we support people   to build great software   which in turn provides opportunities   to build up great people?

The Small Fish in a Big Pond Some Things We Learned Working with Large Clients Daniel Pfeiﬀer • @mediabounds

The Small Fish in a Big Pond

The Small Fish in a Big Pond

More Decks by Daniel Pfeiffer

Other Decks in Programming

Featured

Transcript