Two years ago, I wrote an article titled, The Art of
Delivery.
I wanted to post a few updates based on how our process has evolved
since then (and continues to).
Over the past few years, we’ve been fortunate enough to work on quite a
diverse collection of projects. This has enabled us to work with many
different clients and solicit feedback on our process. This has given us
an opportunity to evolve a set of best practices that fulfills the
long-term project goals/budgets of our client while making sure that
we’re able to maintain a design and development process that is agile.
As I’ve mentioned in previous posts, our team typically bills work
per-iteration on projects rather than per-hour or a flat-bid
per-project. Since iterations are bite-sized pieces of the entire
project and limited to 1-2 weeks, our teams estimates are much more
accurate and we’re able to keep things rolling and on track.
{width=”500”
height=”333”}
The basic structure of our project looks like this.
- A Project has many releases
- A Release has many iterations
- An Iteration has many deliverables
- A Deliverable has many tasks
Before we begin working on an iteration, we outline a set of goals that
we want to create solutions for. This process comes out of discussions
between our client and us until we agree on what is the highest
value/most critical to the success of the project, based on our shared
understanding of where we are today. These goals translate into
Deliverables, which in a typical iteration might require Interaction
Design, Interface Design, or Development. We tend to break our process
up into stages so that Interaction Design on Module XYZ would be
implemented in a following iteration. This is because it’s unrealistic
to expect someone to provide an accurate estimate on how long it’ll take
to implement something before you know how people will interact with it.
Within any given iteration, our team is spread across several sets of
deliverables. As a team, we breakdown these deliverables into smaller
sets of tasks. It’s our aim to keep tasks smaller than a full days worth
of work as it’s much easier to measure progress across the iteration
when we can track tasks at a granular level.
Essentially, tasks are the individual steps needed to achieve these
goals. We don’t go out of our way to list each one of those during an
estimate process as some tasks take less time than it takes to generate
an estimate for them. Each person providing estimates should avoid
getting too granular and aim to find a good balance that compliments
their workflow.
Like most things… mileage may vary.
Through this process, we can get calculate the estimated costs for each
deliverable, which then provides us an cost for the entire iteration. In
addition to deliverables, we also budget a set of hours/days so that we
can be compensated for handling small requests, bug fixes, and project
management. It’s important to factor these things into your process.
In future posts, I’ll discuss how we’re handling this process while
working on multiple projects… as that’s where it can chaos can start
if you’re not careful. ;-)
{width=”500”
height=”333”}
How does your team work? As we’re always evolving our process in an
effort so that we can be more efficient and speed up our delivery cycle,
I’d love to learn from those in the community.
{width=”500”
height=”333”}
{border=”0”
height=”250”
width=”300”}
{width=”500”
height=”333”}
{width=”333”
height=”500”}
{width=”500”
height=”333”}
{width=”500”
height=”333”}
{width=”500”
height=”333”}
{width=”500”
height=”333”}
{width=”500”
height=”333”}