Vishal BhatiaPART 2
In Part 1 we covered some of the things to ensure you have in place to be able to start measuring the success of your project. If you haven’t read it, click here to read.
How to keep a Balanced Scorecard
In the early 1990’s two doctors from Harvard Business School, Robert Kaplan and David Norton, developed a simple method to help businesses achieve their goals.
Called the ‘balanced scorecard,’ this system allows you to track the effectiveness of your efforts across four different criteria. This ensures you’re not focusing on, say, saving money at the expense of something equally or even more important, like providing a product or service your customers will come back to.
Without going into too much detail, the point is to provide a way for you to objectively measure how well your business activities are going by focusing on your ability to meet future goals rather than looking at past performance.
The balanced scorecard system involves viewing your business from four different perspectives and creating metrics to measure each one:
- Financial perspective
- Business process perspective
- Customer perspective
- Learning and growth perspective
It’s safe to assume one of your major motivations for outsourcing is the opportunity to save some money. Adopting the balanced scorecard method will allow you to reliably measure these savings while at the same time making sure your product meets your quality standards.
Money matters
In any software development project, there are financial implications outside of the initial cost of development. For a start, there’s the intrinsic cash value of the software you create both to your organization itself and the open market. Measuring intrinsic value is particularly useful when you need to decide where to allocate your resources. In other words, should you start with software project A or B.
If you’re running a software company, it’s pretty simple to assess this kind of value because you can immediately predict the revenue you’re likely to gain from selling your new product.
What’s more, if you’re a small company releasing a quality product quickly and cost-effectively, it can be a matter of life or death.
On the other hand, if you’re a large company, there are more things to consider such as the opportunity cost of choosing one project over another. Regardless of your particular situation though…
Having a very clear sense of the financial impact and financial goals of your project will give you a great jumpstart toward success. In particular, sharing this information with your vendor will create trust and a common mission between the two of you. This kind of relationship is much more likely to get good results, rather than setting seemingly arbitrary (from your vendor’s perspective) deadlines, and flying off the handle when they are missed.
Sharing your goals and making your vendor feel more like a business partner than a contractor will give more meaning to their work and make them far more likely to go the extra mile.
Process matters but…
When it comes to developing software, your business process is, well, software development, so we’ve mostly covered this point already. In a sentence, here’s what you need to remember:
The quality of your software development process will determine the quality of your product, its initial cost of production, and its lifetime maintenance costs; so please, invest in a good process.
It’s all about your users
It can be very easy to forget that at the end of the day, your real focus should always be on your users: are they going to actually like and USE your product?
Despite the rise in agile development and other such methods, a lot of software is still developed behind closed doors, away from the prying eyes of the user. This is ridiculous…
You probably have some idea of what your users want but you most likely know less than you think. Spending all your money developing your software in a blacked-out cellar somewhere in the desert hoping to reveal it in an iPhone-esque world-changing launch is a recipe for disaster.
What you really need is FEEDBACK; you need real users playing around with your software telling you what they like and don’t like. That way you know you’re creating something of value, something people will use.
With the right metrics, you can accurately track what people like and dislike about your software so you can guide them toward the kind of usage you want. You can measure this with something as simple as a customer survey or you can design more in-depth processes, like design reviews, with your developers.
If you commit to using agile development, this will be part and parcel of your design process. Gaining real validation and input from customers is considered a primary concern, and therefore, each iteration of your software will focus on solving issues prioritized by your user feedback. So, in a nutshell…
Your customer metrics should be made up directly of user feedback you acquire during development.
Talent trumps all
If you’re outsourcing, it’s fair to say you have significantly less control over the professional development of your team than if they were in-house. It’s not as if you can pay for them to take a course or give them resources to do their own learning when they’re half way across the world and employed by somebody else.
However, talent does STILL trump everything else, and you should do whatever you can to pick a vendor that values and invests in talent. Remember, you’re really looking for a long-term business partner, someone who can provide all your software development for the foreseeable future. So in effect, they are YOUR engineers too.
What should you apply the balance scorecard to?
That might seem like an odd question, but it’s an important one.
If you look at your project in isolation, applying the balance scorecard to the process of development only, you may miss how your business is impacted as a whole.
You might leave possible opportunities undiscovered or fail to spot looming disasters before it’s too late.
Obviously, your ability to apply this strategy to your business as a whole will depend on your position and the size of your organization. Where possible, try to use the balanced scorecard at a macro as well as a micro level.
The true purpose of measuring metrics
The point of measuring and tracking your progress is NOT to poke holes or point fingers.
Instead, it’s a way to encourage and facilitate constant improvement.
As a simple example, let’s say your engineers are creating bugs faster than they are solving them. At some point, you’re going to reach a major and costly bottleneck in development.
Of course, if you’ve been tracking everything properly, you’ll have seen this coming and been able to help your engineers get back on track BEFORE a major problem arises.
“But if I insist on measuring everything I will…”
There is still a surprising amount of resistance to using metrics in software development.
Younger companies, for example, are acutely aware of needing to avoid perfectionism or “paralysis by analysis” while others are afraid of quashing creativity. Truth is…
It depends. What you measure will almost certainly improve, so tracking the right metrics should, in fact, avoid the problems people fear they will create.
For example, measuring the number of features added per week puts an emphasis on speed of implementation, which is bound to avoid any kind of perfectionism.
As for creativity, you could argue that tracking how quickly your engineers fix bugs encourages them to find creative solutions quickly.
This has been a relatively brief introduction to software metrics. The key point is to start tracking SOMETHING. Ideally, you’ll at least measure how quickly features are added and how quickly bugs are fixed.
Key Takeaways
1. Decide what metrics are important to you and make sure you have them included in the written Service Level Agreement (SLA) you have with your vendor.
2. Have your vendor commit to a regular schedule for delivering work such as, X work units per day or Y features per week.
3. Then have them agree to the specifics of how you will define work units and find a productivity schedule you can both agree to.
4. Apply the Balanced Scorecard to your situation as appropriate.
