p(update). Update: Picked up on a thread on “TheServerSide”:http://www.theserverside.com/news/thread.tss?thread_id=41092, 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.
magpiebrain 
23 Responses to “The Five Variables of Project Management”
Interesting that you don’t list ‘quality’ or ‘cost’. Along with ‘scope’ and ‘time’, they’re the common variables listed by the agile literature.
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 🙂
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).
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.
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.
[…] In my post, The Five Variables of Project Management, both Marty and Richard used the term ‘quality’ rather than my prefered term ‘process’. I didn’t do a good job of justifying the term process in the post, so felt a followup was in order. […]
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 🙂
Does this sound as if it has been taken from the PMBOK.
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.
maybe you should chat to Jeff De Luca some time 😉
http://www.featuredrivendevelopment.com
ricky and Madhavi – any chance of a full link (and title) for PMBOK? The only project management book I’ve ever read was “Managing Agile Projects(Amazon.com – Managing Agile Projects by Sanjiv Augustine)”:http://www.amazon.com/gp/product/0131240714/ref=pd_lpo_k2_dp_k2a_1_img/102-4460430-0308923?ie=UTF8 which I found to be incredibly boring and woolly (I don’t count the Mythical Man Month as being a Project Management book!).
Oh, and I’ve tried ginvg some concrete examples of altering process in “another post(magpiebrain.com – process, not quality)”:http://www.magpiebrain.com/blog/2006/06/26/why-talking-about-process-is-more-important-than-talking-about-quality/
Sam,
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’
Cheers
Hi Vitaly,
Thanks, I’ll fix those now.
I’ll overlook your typo while I’m at it (‘you’ rather than ‘your’) 🙂
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.
The link to my article seems to have been lost in my previous post: http://www.basilv.com/psd/blog/2006/understanding-project-schedules
Project managers are anal.
[…] magpiebrain » Blog Archive » The Five Variables of Project Management (tags: management project projectManagement agile development) […]
[…] In this blog post, I would like to share with you the five variables in project management as discussed in the magpiebrain blog. […]
[…] Excellent Article about next Gen. office tools. The Five Variables of Project Management […]
[…] 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. […]
It is a good article though I read it late. By chance I have seen during search!
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.