This is an all too familiar questions I often see asked. In fact it popped up on LinkedIn Q&A the other day and I couldn't resist diving in with two feet, especially when I saw all these people running off and naming this and that.
Here's how it went:
Question: What is the best project management software out there for a novice and considering that financial/budgeting tracking is not important?
My Answer:
To be honest I often find that I can do all the basics of Project Management by just using MSExcel.
Please bear in mind that 'back in the day' our forefathers built dams, skyscrapers, railways, managing these projects using... paper!
So I have upgraded from Paper 1.0 to MSExcel and find that for the sake of putting a simple schedule down and ensuring that a small number of resources are correctly allocated; it does it all nicely. I have can and do use MSProject to a relatively advanced level quite regularly and have also used Primavera as well.
But to be honest, by the time you set up all the parameters, unpick the things that the software wants to do automatically for you and then find that not everyone on the project has the right software to read it - you could have actually spent all that time working on delivering the project. This type of software is a classic time waster for a novice and my advice if you do go down the specialist software route, is to start out whiteboarding/writing down the project plan before you enter it into the software.
I have only really witnessed the power of PM software come into its own on typically multi-million dollar programmes running over 12 months with teams of over 70 personnel. What I also observed with these types of programmes is that there are few people who need that powerful overview and computational capabilities, so everyone else breaks the programme down into little manageable chunks that can be easily run on... a Excel spreadsheet!
Hope this helps.
They liked my answer and rated it the best *blush*, arguably against a bunch of people wanting to recommend OTT packages that would befuddle a novice, or even seasoned PM!
Now don't get me wrong, Project Management is an evolving technical skill and needs to be treated as such. I am certainly an advocate of adopting a rigorous technical approach to Project Reporting (such as metrics and Earned Value etc), as well as an analytical approach to Risk Management
- but PM's really need to grasp the first principles of these disciplines before they engage software to do it for them.
I am often reminded of the Officer in charge of Logistics for the entire British Land Forces during the Gulf War - this man needed to ensure that every soldier got his bullets, beans and bayonet. He ran the entire Logistics Battle successfully from the back of just four Landrovers.
Now if he can do that, I think we can get by with a few simple Project Management tools, can't we?.
A layby on the Information Superhighway for all things Rob Gourdie.
"Each of us is at the centre of the universe. So is everyone else." EE Cummings
Showing posts with label Risk Management. Show all posts
Showing posts with label Risk Management. Show all posts
Monday, 13 August 2007
Thursday, 29 March 2007
Assessing Composite Residual Risk in projects
This is an interesting answer from Alan Ashton-Jeanes in repsonse to my LinkedIn question on Assessing Project Risk.
Alan wrote:
Risk is the main reason why projects exist. A dynamic approach to managing the risks affecting the project is an integral part of managing the project. It is the approach to risk management that should determine the value of the risk assessment approaches that feed into it.
I wish I could take it as read that the project will have one or more planned levels of residual risk exposure at the completion of each phase. DO THIS! If these targets are defined in measurable terms, then tracking of composite residual risk should use the same scales of measure. The assessment of the residual component of individual risks is then an extension of the approach to composite residual risk.
For example, the individual risk is viewed as the project's only risk and the project's composite residual risk measurement in that hypothetical case is taken as the individual residual risk measurement. An advantage of this approach is that composite residual risk is then equal, by definition, to the sum of the individual residual risk levels. A disadvantage is that multiplier effects (of one risk on another) are not naturally handled. However, by assessing the multiplier effects as individual risks, this disadvantage can be mitigated.
Another disadvantage is that the assessed risk levels are necessarily estimates, so there is uncertainty in the implicit or explicit range of values that applies to an individual risk, and hence (even more so) to the composite risk values. I find that using percentages helps here: an individual risk currently represents between, say, 4% and 12% of the phase completion target. You can only make interesting observations like this if you have numeric assessments, of course. That could be monetary value, other numbers such as mandays, or just "points".
HML or RAG approaches can easily be adapted by scoring the different levels. This needs to be done by reference to your targets for composite residual risk. If your target is "all risks Green", for example, then a Green risk makes zero contribution to the the project's residual risk, so it should have zero points. Conversely, if your target is "no risks Red", then each Red risk represents at least 100% of your risk quota. It is this type of feedback loop that leads me away from RAG and towards HML or genuine numbers. The RAG status is then some function of the relationship between the individual risk and the target.
Sunday, 25 March 2007
The argument for Quantative (Financial) Risk Assessments on Projects
Question Details: How does your organisation assess project risk?
Chris Phillips-Maund (chris_phillips-maund@hotmail.co.uk) wrote:
Hi Rob,
I have used many methods over the years.
Normal process is:
Have a project risk register
Identify risks - through brainstorming/workshop
Analyse the risks - Rate for Impact, Rate for Probability
For all risks at and above Impact = Medium and Probability = Medium identify mitigation plan and contingency plan
Optional - identify scale of impact (cost or time) if risk becomes an issue
Review on a regular basis - review top risks/issues at least weekly
Escalate top 3 or 5 risks and issues (and action plans) to senior management
I hope this helps
Regards
Chris
--------------------------------------------
Chris,
Like so many others, you identify the standard way of managing risks and emphasise the importance of mitigation - nothing new there. However without being able to measure the 'impact' of the mitigation against the impact of the risk, how can you decide what is the best course of action?
In simple terms; if the impact of this risk materialising is $100k, but the only mitigation you arrive at actually costs $110k - why would bother? Why not let the risk materialise and pocket the $10K you didn't spend?
Also, when you are working on a project with (or often against) a client, it can be sensible to price up a weighted risk (ie. risk impact $1M, probability 10%, weighted impact $1M x 10% = $100k) and say that we can take that risk for the existing price of the project, or the client can keep that $1M risk and we will knock $100k off the price of the project. At the end of the day, in environments where you deliver projects for clients; it all about taking risk on their behalf.
Multiplex where predominantly hired to take the risk of cost over-runs and delays on the building of Wembley, not because they're good builders. [They're not builders at all, they sub all the work out and in doing so parcel up the risk for their subcontractors.]
The other benefit of using financial analysis is that, at the programme level, it is often very difficult to do anything about risk that is managed at the project level and below (apart from rubbing your hands together in a concerned fashion in front of the project sponsor). Using a 'risk budget' approach enables you at the programme level to put a risk budget aside (maybe it doubles as the salary bonus budget?) and use financial tools like Earned Value to track the programme risk profile. When you get to the end of the project there should be very little risk of anything else going wrong and your risk budget should be close to zero.
I see little value when my colleagues say a risk is rated as 'medium impact' and 'medium probability' - whatever that means to you may not mean the same to me and chances are you'll burn time trying to define each low/medium/high with every new project and client.
Appreciate your thoughts on this topic Chris.
Regards
Rob Gourdie
Chris Phillips-Maund (chris_phillips-maund@hotmail.co.uk) wrote:
Hi Rob,
I have used many methods over the years.
Normal process is:
Have a project risk register
Identify risks - through brainstorming/workshop
Analyse the risks - Rate for Impact, Rate for Probability
For all risks at and above Impact = Medium and Probability = Medium identify mitigation plan and contingency plan
Optional - identify scale of impact (cost or time) if risk becomes an issue
Review on a regular basis - review top risks/issues at least weekly
Escalate top 3 or 5 risks and issues (and action plans) to senior management
I hope this helps
Regards
Chris
--------------------------------------------
Chris,
Like so many others, you identify the standard way of managing risks and emphasise the importance of mitigation - nothing new there. However without being able to measure the 'impact' of the mitigation against the impact of the risk, how can you decide what is the best course of action?
In simple terms; if the impact of this risk materialising is $100k, but the only mitigation you arrive at actually costs $110k - why would bother? Why not let the risk materialise and pocket the $10K you didn't spend?
Also, when you are working on a project with (or often against) a client, it can be sensible to price up a weighted risk (ie. risk impact $1M, probability 10%, weighted impact $1M x 10% = $100k) and say that we can take that risk for the existing price of the project, or the client can keep that $1M risk and we will knock $100k off the price of the project. At the end of the day, in environments where you deliver projects for clients; it all about taking risk on their behalf.
Multiplex where predominantly hired to take the risk of cost over-runs and delays on the building of Wembley, not because they're good builders. [They're not builders at all, they sub all the work out and in doing so parcel up the risk for their subcontractors.]
The other benefit of using financial analysis is that, at the programme level, it is often very difficult to do anything about risk that is managed at the project level and below (apart from rubbing your hands together in a concerned fashion in front of the project sponsor). Using a 'risk budget' approach enables you at the programme level to put a risk budget aside (maybe it doubles as the salary bonus budget?) and use financial tools like Earned Value to track the programme risk profile. When you get to the end of the project there should be very little risk of anything else going wrong and your risk budget should be close to zero.
I see little value when my colleagues say a risk is rated as 'medium impact' and 'medium probability' - whatever that means to you may not mean the same to me and chances are you'll burn time trying to define each low/medium/high with every new project and client.
Appreciate your thoughts on this topic Chris.
Regards
Rob Gourdie
Friday, 23 March 2007
LinkedIn: Question: How does your organisation assess project risk?
LinkedIn: Question: How does your organisation assess project risk?
I would like a quick poll of the complexity of risk assessments for project risk. Does your company have a project risk register with Impact and Probability listed a High/Medium/Low? Or does it attempt to financially assess the impact (ie. put it in dollar terms) and then fund a separate project risk budget/trade risk funding with the client? I see both ends of the spectrum (and everything in between) being used in my organisation and would like to put the project risk management culture on a more professional footing. Please feel free to share you experiences of assessing project risk.
Tom Clark wrote:
We started to go down the route of financial impact and then using portfolio management techniques to look at your overall project investment. However, it is a leap for some PMs to make. Directionally I would advocate a dollar value approach, but backed up by a formal risk management training programme i.e. give the PMs the skill first, followed by the process - and then back this up with tools.
I would like a quick poll of the complexity of risk assessments for project risk. Does your company have a project risk register with Impact and Probability listed a High/Medium/Low? Or does it attempt to financially assess the impact (ie. put it in dollar terms) and then fund a separate project risk budget/trade risk funding with the client? I see both ends of the spectrum (and everything in between) being used in my organisation and would like to put the project risk management culture on a more professional footing. Please feel free to share you experiences of assessing project risk.
Tom Clark wrote:
We started to go down the route of financial impact and then using portfolio management techniques to look at your overall project investment. However, it is a leap for some PMs to make. Directionally I would advocate a dollar value approach, but backed up by a formal risk management training programme i.e. give the PMs the skill first, followed by the process - and then back this up with tools.
Subscribe to:
Posts (Atom)