Sam Newman's site, a Consultant at ThoughtWorks

p(update). Update: Picked up on a thread on “TheServerSide”:, so there may be some more discussion over there.

In my experience (and more so that of my more experienced colleagues) there are five variables over which you can exert control to decide when – and with what functionality – you can deliver your software.

h3. Scope

In simple terms, if you deliver less functionality, it will take you less time. The problem is that often the decision as to what _not_ to deliver happens during the development process itself. This means that prioritisation of functionality from the outset is important. if half way through you need to cut scope, but the only stuff you have left is the stuff your users simply *must* have, and you spent the last three months delivering things they’d only _like_ to have, your options are limited. Priorities can change, but core functionality tends not too – concentrate on delivering that and you’ll make it easier for yourself in the long run.

h3. Time

Typically the thing over which technical people have the least control (anecdotally it seems as though the go-live date for software is defined more by sales and marketing than by need), but you can decide to deliver later to get what you want.

h3. People

Adding more people to a project _can_ make it faster – to a point. However in software adding people very rarely tends to result in a linear increase in productivity. Hiring the right people can be more efficient, but is far from easy.

Some organisations take the ‘lots of dumb people being told what to do by one or two smart people’ route, others the ‘a few smart people all knowing what to do’. I’m sure most of us (myself included) believe we hope for the later. I’ve certainly seen examples in the consultancy world where an organisation with a lower charge rate but lots of people ends up costing much more deliver than a small number of people with higher charge rates.

h3. Process

Reworking one’s process in order to be more efficient is an obvious thing to do, but hard to achieve. Depending on the flexibility of your organisation changing your process might not be easy, even if you know what it is to change. Changes mid-project – for example in order to deliver faster – tend to be limited, small changes. Retrospecitves can be a good tool for identifying what the team thinks is required, but don’t discount seeking outside help – someone from another team might have a different take on things.

A far more common type of process change occurs when people make what is often claimed to be short-term sacrifices in terms of software quality to deliver on time. Changes could involve writing less developer tests, spending less time performing manual tests, stop pairing, or spend less time ensuring consistent technical vision. When these changes really are short-term, and time is set aside afterwards to repair the damage done, this may be a viable technique. However those organisations which tend to drop quality in order to deliver faster tend to use this technique more than any other, and frequently never spend time playing catch up – leading to a team spending most of their time running from one disaster to another.

h3. Risk

Risk Management is something I’m personally becoming aware of. Making sure you have situations in which potential risks can be raised is important (a daily stand-up might be one). Periodically risks should be assessed, in terms of how likely they are to occur, and also in terms of how much damage they can create.

Some risks can be mitigated, some eliminated entirely, and others cannot be addressed by you. In any case once prioritised in terms of likelihood and potential damage, they can be mitigated or communicated to your business sponsor accordingly.

23 Responses to “The Five Variables of Project Management”

  1. Marty Andrews

    Interesting that you don’t list ‘quality’ or ‘cost’. Along with ‘scope’ and ‘time’, they’re the common variables listed by the agile literature.

  2. sam

    I do mention ‘quality’ – I’ve put that in process. For me cutting back on quality (or improving upon it) is a result of a change in process.

    As for ‘cost’, that is an impact of much fo what I’ve listed. A change in process, manpower, or risk all has a direct cost impact. Simply deciding you want to spend more money only helps you deliver faster if you vary one of the other things as well. Some variables can have a zero cost, many don’t.

    I was also hoping none of this was specific to agile – I tried to avoid mentioning the term at all. These variables seem equally real in all the software projects I’ve been involved with, me they waterfall, agile, or rapids 🙂

  3. Richard Jonas

    I’d have Scope, Time, Budget and Quality. Budget would include People, and Quality would include using an appropriate process and taking steps to mitigate risks.

    You should make sure you understand which of these are fixed, and of the others which are considered more important. You might have a fixed deadline and budget for example, but delivering a quality release is considered better than implementing all the features. If you’re told that all of these are critical and equally important, then that’s a recipe for project failure.

    Once you understand which variables are fixed, you can choose the best process as appropriate (whether this be agile or waterfall).

  4. sam

    How can scope be seperate of budget? If budget is fixed, then how can scope be increased? The problem with budget (and really it means cost – certainly in consultancy terms) is that really it cuts across these things. A cost to me (a consultant) is different to a cost to you (a customer).

    Process can also define cost. Some processes require more people of a certain kind, which can cost more – some organisations have lots of low paid people being told what to do by a few ‘smart’ people – this can have a different cost compared to a smaller group of ‘smart’ people being told what to do. Both are different types of process that cost different amounts.

  5. bill

    But without listing budget a a variable, aren’t you ignoring it as a constraint? Many of the projects I work on are limited by budget and we are forced to choose process, scope and people to match.

  6. sam

    Budget/cost/money is a cross-cutting concern (sorry for the AOPism). If you don’t have the money, you can’t hire the _People_. If you don’t have the money, you can’t affort to take more _Time_. If you don’t have the money, you may not be able to afford more _Scope_. If you don’t have the money, you can invest in your _Process.

    There are other constraints which don’t need seperating out. One might argue that space is a constraint. Without Space you can’t hire the people. Without Money you can’t afford the space. Without Time you might not be able to wait for the Space to be available.

    Or Technology. Changing Technology might enable you to deliver faster – but if your Customer won’t let you change, or you can’t afford to invest in it, you can’t change it.

    The reason I didn’t seperate it out, is that simply saying ‘spend more money will help deliver faster’ is not true. You have to spend that money on something – either Process, People, Time, mitigating Risk or on Scope. And when talking to a someone who holds the purse strings, it’s a lot easier to define the requirement for more money in terms of what they’ll be getting 🙂

  7. Madhavi

    Well, I too felt this is from PMBOK when I read through this. All orgnizations that are strong with processes would be addressing these as part of their project management processes. It would be interesting to know practitioners views/experiences apart from the known theoretical stuff.

  8. Vitaly


    Proof-reading, or another form of QA, should be part of the Process (pun intended). Here are a couple of you typos:
    – priotisation
    – ‘lots of dumb people being told what to do my one or two smart people’


  9. sam

    Hi Vitaly,

    Thanks, I’ll fix those now.

    I’ll overlook your typo while I’m at it (‘you’ rather than ‘your’) 🙂

  10. Basil Vandegriend

    Funny, I wrote about this topic a while ago in my article on Understanding Project Schedules. My four factors were time, resources, scope and quality. And I have a cool Java applet to visually represent this relationship.

    My focus was on project schedules, rather than project management. So items like process or risk management are aspects of project management, but not something I’d consider directly impacting project schedules.

    Anyways, I’m glad to see others writing about this tradeoff between variables. I believe balancing between these competing variables is one of the essentials of good project management.

  11. » Quality is a bogus variable

    […] Sam Newman writes, correctly in my opinion, that quality is driven by process. Here, they way you do things determines how good the result is. Quality is an “output” variable more often than not. Introducing test-first development is a process change; allowing post-development testing time to be reduced because the development phase has overrun is a consequence of an unfortunate project management process; introducing or eliminating performance testing is a process change. In all these cases quality is not an independent variable; it is driven by other things. […]

  12. PKS

    It is a good article though I read it late. By chance I have seen during search!

  13. PM Hut

    IMO, Quality is affects and is affected by the time, the cost, and the scope. Additionally, I agree with the comments here, cost/budget should’ve been there.


Leave a Reply to sam Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

%d bloggers like this: