Mon, 18 Jan 2016
I recently completed an 18F
micro-purchase task. It turned out to be a very simple task, tweaking some CSS.
I spent more time on bidding, setting up the development environment, and
figuring out how to receive
payment than on the actual work.
My pull request was accepted, and 18F paid me quickly, but after my changes
were merged, Maya Benari pointed out that
a
simpler solution may have been acceptable, or perhaps even preferable.
It turns out that 18F have drafted U.S. Web Design
Standards, and have already given a lot of thought to things like vertical
spacing, the subject of my change.
As an independent contractor with no previous experience working with 18F, I
didn't know there was a U.S. Web Design Standards document, much less its
contents. Had this task been assigned to an internal staff member, they
probably would have known that the page being updated should follow the
standards, or that if the standards didn't adequately address the requirements
for the task, that perhaps a future update to the standards should be
planned.
Getting the right level of details in task requirements is often tricky. One
doesn't want to spend days writing requirements for a task that can be
completed in hours. But one also doesn't want what could have been an
hour-long task drag on for days because the requirements were ambiguous.
When working within a long-lived team structure, there is some shared
institutional knowledge that doesn't need to be made explicit in every task,
like the fact that U.S. Web Design Standards exist. Usually when bringing in
an outside contractor or new employee, one is starting a relationship that will
last weeks, months, or years, and knowledge transfer is an expected part of the
on-boarding. This investment makes sense given the size of the overall
engagement.
Micro-purchasing of software development work is unique in this respect.
Neither party is committing to a long-term relationship, and therefore unlikely
to bear significant knowledge transfer costs. Had the acceptance criteria for
my spacing fix task included compliance with the U.S. Web Design Standards, I
would have had to bid more to cover the time to read and understand the
document. And 18F wouldn't want to bear the cost of making me an expert on
U.S. Web Design Standards if I were only going to complete a single task.
It's still early in 18F's micro-purchasing experiment, but if the experiment
continues or if other organizations want to try it out, it's worth thinking
about what types of tasks are best suited for micro-purchasing, and what level
of detail in the requirements is optimal.
Some possible questions to ask about tasks you are considering outsourcing as micro-purchases:
- What is the value of this task to my organization?
- What estimate would an internal staff member give this task?
- What estimate would an individual outside my organization put on this task?
- Are the existing requirements sufficient for an outside developer to
complete the task satisfactorily? If not, how much more work would be required
to update the requirements?
As always when discussing project management, I suggest ordinal prioritization
of tasks and confidence interval based estimates. If your existing tools don't
support these, I recommend checking out LiquidPlanner
(affiliate link).
I like the micro-purchasing model, and I hope that it succeeds and is adopted
by commercial organizations.
I've gotten multiple emails from grad students doing research on Github. If
you're an economics student interested in industrial organization or open
source, micro-purchasing of open source software could be an interesting
research project.
business | Permanent Link
