I love charts, and this is one I’ve used a lot. It’s designed to show resource usage to a management team that wants to start too many projects. The chart … Continue reading Resource maps for prioritisation
On and off over the last few weeks I’ve been thinking about Elaine Wherry’s painful story of hiring developers. But the thing that triggers the whole tale is worth drawing … Continue reading Your architecture impacts your business strategy
A while back I mentioned that a system’s architecture could be considered a product in its own right. In this post I want to explain that a bit more. Products … Continue reading Software architecture as a product
People I speak to often talk about “requirements gathering” and “requirements capture”. But I think this creates the wrong mindset, leading to a poor outcome. These phrases imply that requirements … Continue reading Requirements discovery
Estimates for software projects only need to be sufficiently accurate to serve a purpose, but if that purpose isn’t clear then producing the estimate can be quite stressful. Over on … Continue reading Taking the stress out of estimating
I recently came across a fresh way to help people work towards the higher level goals of a project. And while I’m not 100% sure of it, I wanted share … Continue reading Rethinking story commitments
You may very well not need a spec for your software project. I had a recent conversation with a friend in a very small (3-4 person) company, building their first … Continue reading Specs fill communication gaps
A few words on rewriting and migrating systems, based on experience. This is because the painful rejuvination of Delicious under Avos is very much at the front of my mind … Continue reading Migrating systems (such as Delicious)
Is it possible to estimate a software project well if it’s over, say, a month in duration? Or can you only give meaningful estimates to work that’s less than a … Continue reading Meaningful estimation
Lots of questions went unanswered in my last piece on putting ranges of projections into project proposals and I want to follow up on one of them here: What if our range of values isn’t something we’re happy with?
In my previous example our project had a revenue projection of £150k to £500k. But suppose the project was expected to cost £200k. Then that range encompasses both profit and loss. What can we do?
1. Collect more data
We may be very confident of our potential revenue, but perhaps we could be more confident. More research data should change our perception of what might occur, and so narrow the range of expectations. This might include customer research or research into other companies’ experiences.
Of course our findings may just serve to confuse the issue: we may collect six examples of other companies’ experiences only to find they differ wildly. In such cases we should be more discerning about how we see the data. For example it would be a good idea to learn more about each example and see which are closest to our own proposal.
2. Break down the problem
Our revenue projections (or other measurement) are likely to be a factor of several other elements. If we can break down the problem we can perhaps analyse those elements more easily. With more confidence over simpler measures we ought to be able to make tighter estimations of the whole.
For example, revenue may be seen as a factor of market size, typical customer spend, product visibility and ability of the product to meet customers’ needs. There may be market data readily available on market size and customer spend; we should be in a position to gauge product visibility if that’s a result of our own marketing; and focus groups or similar may be able to help us understand how the product is seen to meet customers’ needs.
3. Move the breakeven point
If we’re worried that we may generate £150k to £500k from a product or project that costs us £200k then maybe we should seek to reduce the costs. Of course if we reduce functionality or quality then there is likely to be some detrimental effect to the revenue. But we may be able to find high cost/low value items which change the game sufficiently.
4. Change the factors that influence the range
It may be that we can reduce uncertainty by actually influencing some of the critical elements. If it transpires that customers don’t see the product as meeting their needs sufficiently then we should change that. That may be by changing the product, or by improving our marketing.
Or we may find it’s useful to do the opposite of our previous suggestion of reducing cost: increasing quality (and adding a bit of cost) may pay extra dividends by increasing take-up. This kind of thing can be seen in places like the Apple App Store. I am at least twice as likely (probably four to five times more likely) to buy an app rated 4.5 stars than if it was 3.5 stars. Yet the difference in production cost to get to that level would have been far less than two-fold.
I’m sure there are more ways to respond to an insufficiently compelling range of possibilities in a project proposal. Overall, though, all these actions have the same beneficial effect I pointed to before: the relevant issues are surfaced so that they can be addressed appropriately and we increase the likelihood of our project’s success. And they are much more likely to be surfaced an addressed if we also surface that fact there is a range of outcomes, rather than project a single outcome.