This week, we continue our ongoing conversation about the best way to value development projects. To recap, our 4 steps center around setting expectations, balancing risks, outcome analysis, and ongoing communication.
Hopefully at this point, we're on the same page with some of our default expectations with every relationship we build. Have any expectations or questions we didn't answer? Reach out to us to continue the conversation on twitter.
Even after expectations are set, there are still risks in every relationship. If you've been in a development relationship before, you will probably recognize a lot of this information. For the client, the risk evaluation can take a lot of different forms, usually with negative sleep-dampening questions:
What if the developers don't understand the requirements?
What if the developers deliver late?
What if they never finish?
Will this fall in with my budget?
What if there are tons of bugs?
What if I lose my user's information to a security hole?
What if we don't jive well together?
All of these questions are completely valid and should be asked at the beginning and throughout the relationship. There's also a lot of risk entering a new relationship on the developer's end. Since we've done this so many times, we have a very specific set of pointed risk-evaluation questions we ask:
Will we be able to provide a strong ROI for this client?
Will the client be happy? Will we be happy?
Is there any risk of getting compensated for our work? Other development teams may have a lot of risk-analysis questions they need answered before starting a new relationship, including:
Will our scope creep throughout the relationship?
How little can I work to make the most money?
When will this relationship end so I can move on to the next one?
Hopefully you'll notice some themes here that we've already answered. Fortunately, most of these risks are offset by the expectations we set previously. For example, some developers look at scope creep as a risk, but we've already set the expectation that scope creep doesn't exist in our world. If we weren't as flexible and dynamic, many more risks would exist.
For those risks that we don't address with expectations and an optimized process, we examine who is at risk and what tools we can use to offset those risks. Most of the time, it comes down to 3 points: project success, relationship happiness, and budget alignment.
Luckily, we've already come up with great answers for these 3 problems.
Will this project be successful?
Commonly, this is successful in a profitable sense, but there are many other metrics of success like user growth that may matter. At Vaporware, we look at the earning potential to measure our potential impact, and relate that to a range of potential investment. We'll discuss the details of this process next week, but it's safe to say that this is a risk owned by the client and needs to be offset by Vaporware as much as possible.
Will both parties be happy?
This is a crucial analysis for new relationships, and is often like an interview. We don't believe that the answer can be found until the relationship starts. While some people may believe that you can have a gut-feeling driven answer within the first few minutes, we strongly feel that people may have off days, come from toxic previous relationships, or just need a little communication and understanding.
We've been most successful at starting each relationship with a trial period (usually under 100 hours of cumulative work). This model allows the client to walk away from Vaporware without any loss, since the scope is for a functional piece of the project, standard deliverables are easily transferrable to a different development company, and the capital required is for only a portion of the overall project. For Vaporware, this gives us the ability to gracefully remove ourselves from a potentially long-term toxic relationship, as everyone understands that we're testing the waters before we begin. This is a risk that's owned and needs to be offset by both parties throughout the relationship, through ongoing communication (more on this later).
Will this project remain within budget?
Probably the one question that isn't answered with dynamic payments and is how to stay on budget. Budgets, like scopes and plans, are arts of divination more than scientific methods. While Vaporware would rather ignore budgets, our clients with classic business training do not.
To overcome this risk, which is owned by the client and offset by Vaporware, we break projects down into small iterative pieces that can be budgeted as a run rate, sometimes referred to as burn rate or velocity. This way, clients know exactly when they can expect funding to run out, and watch overall progress as we move through each stage of development. This process enables the development of products the market will use, which is much more valuable than a predetermined budget.
During project valuation, it's key to focus on the risks of keeping the returns high, relationship healthy, and budget on track. At Vaporware, we use financial tools such as trial periods, low upfront investment, and dynamic rates to offset these risks. We also keep our process and deliverables in line with finances to minimize risk in projection and assumptions. Without these tools or methods the risk and expectations can often become misaligned quickly and the project can stagnate.
I hope this has been a helpful introduction to some of the risks you may face during development relationships and our approach, including the tools and processes, that we employ to overcome these challenges. Check us out next week for details on how we can minimize risk through ongoing communication as we continue this series of valuing development. And as always, reach out to us on twitter or in person to continue the discussion.
