Everyone in Software is familiar with the “Iron Triangle”, the triumvirate of Time, Features (Functionality, or Scope), and Resource. In summary, these are the three factors that control any project, altering any one of them always alters the effect of the others, with enough Features, Time, and Resource, you have a high Quality product.
In recent years all the various methodologies have focussed on trying the win the “Time” argument, to stop the idea of time limits being set up front and thus reducing the Functionality as the Resource is generally fixed (which even if increased may have less benefit) which may in turn lead to a lower quality product.
This has lent some credence to a new myth, that projects don’t need to have deadlines or set time limits, and in fact shouldn’t have in order to create good “Quality” software.
And in the real world…
This is a joke. Let’s start from the very beginning, suppose you are asked to deliver a project, you will generally be asked three questions, never mind all the ones you should be asking, those three are:
- How much ?
- How long ?
- Who do you need to hire/what do you need to do it (you could suggest this is how much) ?
Consider that everything you do has a deadline, even if this deadline is not the one for delivery. It is important to set a goal, and often this represents a line in the sand, where you can evaluate the progress and determine if you can proceed.
If you doubt this, consider what you ask the guy who comes to install your cable. If (s)he fails to turn up when they say or takes 2 weeks to wire a plug, you are not going to pay them. When you bought your house, your bank didn’t give you money that you could “pay back when you wanted”, they attached a timeline to it that reflected a best guess according to your capability to pay.
The Punchline
Your project has a deadline. It will always have one. Your aim is to have a realistic one, and that assumes the business understands what it is trying to have delivered. Even then a deadline is not your enemy, it marks a decision point for others to determine if they want the deliverable. It also acts as a focal point for your efforts, provided that the focus is not panic. There is no point in the argument of “it’s done when it’s done”, the money running out stops that dead. Remember the bank who lent you the money for your house, they don’t stop the clock because your job did. The bad news is that the bigger the organisation, the larger the number of levels that the deadline has been established over… so maybe the idea started at the board, so the CEO has a point in time in mind, then the Architects get the idea, and at some point there has to be a business case, and this will always need a deadline!
Practically, you have the following options:
- Cheap and quick – may never get upgraded/fixed, but will do, soon find out how import the deliverable really is
- No time at all – build a prototype, be upfront about it, if it works out, you can work on the full system, if not, well software doesn’t take up landfill.
- No resource – establish your own timeline of what you need to achieve – if the shortfall is obvious, either you get more resource, or time.
- Work nights! – this is not an option. Unless you are 20 and can work on 3 hours sleep, you’ll start spending 50% of your productive time fixing what you thought you achieved. Don’t do it. The odd hour fine, night, no.
Or hopefully:
- Just enough of each of the three parts of the triangle – due to the business understanding what needs to be done and having funded/invested appropriately
Conversely:
- Too much time – things wander and all three parts can be wasted.
Good luck with the deadline
