How long will this feature take?

Be clear on someone’s definition of done when trying to communicate what it will take to build a feature.

Planning software development timescales is hard. As an industry we have moved away from the detailed Gantt charts and their illusion of total clarity and control. Basecamp have recently been talking about the joys of using Hill Charts to better communicate project statuses. The folk at ProdPad have been championing, for a long time, the idea of a flexible, transparent roadmap instead of committing to timelines.

That’s all well and good if you are preaching to the choir. But if you are working in a startup and the CEO needs to make a build or buy decision for a piece of software, you need to make sure that you have some way of weighing up the likely costs and efforts of any new feature you commit to build. It’s not good enough to just prioritise requests and drop them in the backlog.

The excellent Programmer Time Translation Table is a surprisingly accurate way of interpreting developer time estimates. My own rule of thumb is similar to Anders’ project manager. I usually triple anything a developer tells me because you build everything at least 3 times: once based on the developer’s interpretation of the requirements; once to convert that into what the product owner wanted; and once into what the end users will use. But even these approaches only look at things from the developer’s point of view, based on a developer’s “definition of done”. The overall puzzle can be much bigger than that.

For example, the startup CEO who is trying to figure out if we should invest in Feature X probably has a much longer range “definition of done” than “when can we release a beta version”. For example: “When will this make an impact on my revenues” or “when will this improve my user churn rates”. Part of the CTO job is to help make that decision from the business point of view in addition to what seems to be interesting from a tech angle.

For example, consider these two answers to the same question “When will the feature be done?”.

1. The dev team is working on it in the current iteration, assuming testing goes well it will be released in 2 weeks.
2. The current set of requirements is currently on target to release in 2 weeks. We will then need to do some monitoring over the next month or two so that we can iron out any issues that we spot in production and build any high priority enhancements that the users need. After that we will need to keep working on enhancements, customer feedback and scalability/security improvements so probably should expect to dedicate X effort on an ongoing basis over the next year.

Two examples from my experience:

A B2B system used primarily by internal staff. It took us about 6 weeks to release the first version from initial brainstorming on it. Then it took about another two months to get the first person to use it live. Within 2 years it was contributing 20% of our revenues, and people couldn’t live without it.

An end user feature that we felt would differentiate us from the competition. This was pretty technically involved so the backend work kept someone busy for a couple months. After some user testing we realised that the UI was going to need some imaginative work to get right. Eventually it got released. Two months after release the take-up was pretty unimpressive. But 5 years later that feature was fully embedded and it seems that everyone is using it.

What is the right “definition of done” for both of these projects? Depends on who is asking. It’s as well to be clear on what definition they are using before you answer. The right answer might be in the range of months or years, not hours or weeks.

How you can be on time, on budget and on scope but still FAIL

OTOBOS – On time, on budget, on scope – is the mantra of software project managers everywhere. So many IT projects fail on one or more of these three factors that project management 101 takes  great pains to ensure that aspiring project managers learn how to stick to all three (or at least two).

But being OTOBOS is only the first hurdle to cross. Fail at OTOBOS and you fail, for sure. But there is a much, much bigger picture than simply being on time, on budget and on scope. You can be OTOBOS and still, from a business perspective deliver a big FAIL.

There are a host reasons why this can happen. Here’s one fairly common one, in enterprise software at least.

The project team has forgotten the real objective behind the IT system

There is a subtle, but important, difference between a requirement and an objective.

Here’s how the scenario plays out: A senior individual makes a proposal for an IT system to be built/implemented in order to achieve a particular business objective. Once the proposal is approved a project team is convened to implement the IT system. The team assiduously collects requirements from stakeholders and carefully manages any changes to those requirements. Eventually a shiny new system is unveiled that meets all the requirements … but which fails to deliver the business objective.

What happened?

It could just be a simple breakdown of communication somewhere along the line from the business objective to the requirements to the developed code. Usually any project objective is hidden in a project initiation document or a project charter never to be seen again by anyone until after the project has finished.

Or it could just be that business objectives have shifted since the project was initiated and no-one remembered to tell the project team. As projects get longer this risk becomes more real.

Here’s a story I heard a while ago – and I’m sure those of you in enterprise IT land won’t find it surprising. A software product was supposed to streamline a procurement process by empowering end users to place purchase requests themselves, thereby avoiding paper trails and manual approvals. The system was duly delivered, on time, on budget, on scope. It met all requirements. But it turned out that the system was too cumbersome for end users to use. They continued to place their orders on paper and have them approved on paper, and then it was someone else’s job to input the approved orders onto the new system. Far from streamlining the process you could argue that the system had ended up adding a new step and more time to the process.

How to avoid this issue?

Have a clear, simple business objective for your project that everyone, from the sponsor to the intern knows and uses every opportunity to repeat. This helps people remember what they are really trying to achieve. Team members can identify early any threats that might prevent delivery of the objective. And when business priorities change (as they surely will) these can be filtered to the project team early enough that you stand a chance of doing something sensible.

Yawntastic delays at NHS mega project

Not sure whether the appropriate word is “still” or “again” but here and here is another piece of news of failures to deliver technology systems in the UK public sector.

While I’m on the subject here are a couple of other items that popped up today. IT failure ’causes £130m arrears’  courtesy of Phynbarr. And Moody’s to investigate staff over rating bug (that “incorrectly rated about $1bn of complex debt securities”)  from the FT (free registration required).
And yet organisations keep going over the same ground with the same approaches. And wonder why they continue to fail. Perhaps Michael Krigsman should become part of the standard training for all people involved in software projects. In particular for the sponsors and managers who are (in theory) accountable for the project.