OK – so the whole idea of project portfolio management stemmed from the concept of treating projects like an investment portfolio. Since companies invest a lot of money in these projects, we should monitor them as such. In most PPM practices I’ve come across, this metaphor is applied to project selection (which projects will give [...]
|
||||
With all the PMOs we work with month in and month out, one surprising trend has emerged. Almost none are relying on their ERP system for project cost control. Come again? Aren’t ERP systems designed to control costs? Aren’t they the source of record for all things financial in a company? To this former CFO, they certainly should be! Instead, we find client after client using excel spreadsheets to track planned and actual project expenses. And our Daptiv clients are using Daptiv applications to the same purpose. So – why are these PMOs (both IT and non-IT, btw) using unofficial and sometimes kludgy tools to manage project finances when the source of record is readily available? Turns out there are two main causes of these “workaround” financial systems. When we’re heads down in the middle of a project, it’s often easy to focus on staying on task, on budget, and on scope – and all too easy to lose track of the original business proposition. Truth is, all projects start with a business value proposition in mind. This is what I like to call the business target. A while ago, as an exercise in a project management class I was teaching, I asked each of the PMs to tell us the purpose of their project. The first PM said “to upgrade the payroll system”. Oops – that’s not much of a purpose. Why would we want to spend lots of dollars just to upgrade a payroll system? Turns out there were new tax rules coming in that the old system couldn’t handle. So – the real purpose of the project was to enable compliance with new tax regulations. Obviously, if this could be done with a few minor tweaks, that would be better than a full upgrade. Given it could not, the upgrade was on. An oft-heard refrain in IT Project Management circles: If the business would get their requirements right, we’d be able to deliver this project on-time!” How many project delays have come from shifting scope and requirements? More than a few, based on my experience. So how does one approach this problem? Part of the answer lies in the question itself. It assumes that the business is responsible for imparting their requirements to IT in such as manner that IT can successfully deliver. Yet “the business” often knows little about the underlying technology, and thus has a hard time articulating their requirements in terms the technologists in IT will understand. What is needed – and what works in successful project and IT departments – is a translator. We often think of the business analyst role fitting the bill perfectly. Their job, after all, is to understand the business issues and help determine the technical requirements that will fit the bill. The problem is, they are not driving the project – the project manager is. There is a raging debate occurring on the PMO board at PMI about the relationship between Project Managers and PMOs. It was all started by a gentleman who posited that most PMs hate PMOs, and asking for input as to why. This has lead to two camps on the subject. In the first camp are those who agree that PMs hate PMOs. Their line of argument is that PMOs and the methodologies they impose are seen as a threat to the creativity of PMs, who would rather follow their own tried and true processes than conform to a rigid methodology. The other camp says this is pure nonsense – professional project managers are known for bringing good, sound project management processes and discipline to the table… |
||||
|
Copyright © 2010 Lessons from 100 PMOs - All Rights Reserved |
||||