Despite the best efforts of Project Management guru's and the developers of Project Management systems to deliver truly global, streamlined and accurate means of managing increasingly complex projects, it would seem legislation throughout Europe it set to keep us in the dark ages.
I'm talking about the various forms of the Data Protection Act (DPA) throughout the states of Europe.
First of all let's look at a couple of the basic requirements we have in order to manage any project:
(1) the ability to communicate with team members and stakeholders; and
(2) the ability to track effort expended against effort budgeted;
(1) Project communication under DPA
So I discovered the other day from an appointed DPA officer. Most big companies run some kind of corporate address book typically in their email application. When you want to contact someone, you look them up and you probably at least an email address and a telephone number that you can use.
Did you know? That in the UK you are at liberty to ask your company to remove your entry from any such database? Therefore any such collection of project contact information should be approved by an appointed DPA officer and subject of a DPA audit? In other EU countries you are at liberty to "opt in" for your information to be held electronically, that is, the default position is that a company can not keep this information on you.
(2) Tracking effort expended on a project under DPA rules
All companies I have worked for have had some form of Time Entry System by which you record you breakdown of hours worked each week. This is typically where project cost codes are used to capture how much effort has been expended against your project and what labour charges will hit your project budget.
Did you know? Any member of your project team in the EU is at liberty to opt out of using this time recording system, thereby rendering your ability to accurately record the effort expended useless. This flies in the face of trying to accurately portray a projects position through tools, such as Earned Value, that are being touted by various PM methodologies.
So imagine the scenario...
You're the PM for a high value government project...
Your project team decide to opt out of (1) & (2) rendering your powerless to communicate across your team and unable to simply and accurately record, in a timely fashion, what work has been completed for what cost, on this huge government project.
How long would it take before the project went completely pear-shaped and some corporate officer was hauled in front of (in the UK) a Commons Select Committee to explain why this project was performing so badly?
And how well would it wash when the limitations of the DPA were brought home to roost?
Forget project insurance for Terrorism and acts of God, you can't insure against workers exercising ridiculous rights that would scupper the best efforts of the Project management fraternity overnight. Some would argue that the DPA has been around for a while and it hasn't caused the catastrophe you warn about - well thats true but find me a competent PM that gets away with evaluating risk by saying 'it hasn't happened yet'. Equally, in todays environment we are truly starting to require a global project management model, whereas previously we had only managed to achieve an aggregation of individual country projects. This move to develop and define systems that can operate across legislative boundaries as well as timezones needs to be able to remove the barriers to true global project management, if it is to succeed. Where today we are off-shoring and near-shoring more and more niche skills, we will find that in order to staff up multi-disciplinary project teams in the future, we will need to operate a global project management model that can easily communicate and collaborate using the latest tools.
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?.
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
