There are laws of nature. And as we know, laws of nature can't be broken. One of these laws has to do with management, and in my case that means software management.

The law states that there are four variables to management, and they are connected to each other. If you take control over any three of these, you cannot control the fourth. You may try, and many do, but you will surely fail. Laws of nature just won't be fooled.

These four variables are named Scope, Quality, Resources and Time, and are the four aspects of a project that you can control, though as the law states, only three at any time.

• Scope means the amount of work to be done. This relates to the number of features to implement, the number of lines to be written, the number of bugs to be fixed. The amount of anything that you consider to be work.
  
• Quality means how well implemented the work is. How bug free the code is, how user friendly a feature is, how configurable a process is, how good performance the code has, how flexible the solution is. Anything that gives the code a little extra.
  
• Resources means the size of the workforce, and also the cost. This usually means the number of developers on a project, but may also mean other resources that can have an impact on the work. Like faster computers, better tools or better working environment. It may also be a direct cost, like buying a thrid party solution that solves part of your problem.
  
• Time means the amount of time to spend on the project until delivery. This is actual days on the calendar, not the number of man-hours. If you must deliver in four weeks, that is your Time.

Interdependencies

Now, how are these connected? Consider that you have a set of features that must be implemented, and this must be done by a team of four developers. They estimate the time to four weeks. But that is far too much time, so you tell them to work hard and complete the tasks within two weeks. How tested and bug-free, configurable, well-performing and user-friendly do you think this delivery will be? Certainly less than what they would produce in the four weeks they wanted. This is because you put a limit on Scope - the features, Resources - the four developers, and the Time - two weeks. Now the law states that Quality must adjust, and so it did. They did work overtime, but tired developers aren't known to do wonders for the Quality. 

What if you demand higher Quality? You need them to test well for bugs, tune for performance and all those Quality things. Then something else must adjust. Either the Time will adjust and you are delayed, you must put more Resources, or you must decrease the Scope and deliver less features.

Limited options

Something important about these variables is that you don't always have the freedom of choice. Oftentimes someone else owns some of the varibles - typically the customer. If your customer has demanded a delivery date for a set of features, and won't accept bad quality, then all you can control is the Resources. You need to allocate enough people with high enough skills on the project or spend money on a ready-made solution, or you will have to break one of the other constraints and upset the customer.

In a typical contract, the customer has signed on a certain set of features and a delivery date. Now your options are limited to Resources and Quality. Sometimes you can reduce the Scope by finding work-around solutions to complex problems, but this can also affect the final Quality in terms of flexibility or user-friendliness.

It's not always easy

Some of the variables are easy to adjust at any time, and some are harder. Resources are hard to change further down the time-line. You may end up speding more time managing and teaching the extra resources than you gain from them. On the other hand, Time is an easy thing to change. If you add more Time, you get more work done. Scope is a bit harder. Sometimes you just need to finish what you have started, or you have nothing. Though, if you plan carefully you may have left the least important features to the end, and those you can decide to cut. Quality is an easy target. In the start you may be picky about performance and unit-testing, but as you get pressed on time you quickly drop these things and reduce on the Quality.

So, plan your Resources carefully at the start of the project since these are hard to change later. And be careful with Scope. Prioritize the most important features first so you can cut nice-to-have features if you need to. Also reduce the Scope or increase the Time before Quality suffers. Keep and eye on the progress, and make adjustments as early as possible. It is very easy to start dropping on the Quality when you are pressed on Time.

And just one more thing before we close the shop: Understand that if you get an estimate from a developer, and you tell him to reduce it, he will be forced to reduce either the Scope or the Quality. Most probably both.

Also read The King's Dinner