I don’t know about you, but I invest in the stock market, and I want to know the payoff – not just the potential. How much did I really make from that investment? Yet, in a good 80% of the PMO’s I’ve worked with, post-project benefits are not tracked. There are a couple of major culprits for this problem.

First up is the “close the project” mentality. As project managers, we want to have a clean close to the project – usually when the new system is deployed. We’ve delivered the goods, lets do our lessons learned, dismiss the project team, and move on to the next project. But benefits often don’t accrue for months or even years. After an ERP project deploys, productivity actually goes backwards for a good 3-6 months. Those promised productivity improvements don’t get realized until after the adoption period.

Culprit number 2 is the lack of measurement. Remember the old maxim “if you can’t measure it you can’t manage it?”. How often do we start a project with projected benefits (say a 10% improvement in PO processing time) without measuring the metric before the project begins? Which means even if we do measure it after deployment we have no baseline and thus no means of measuring the increase.

Now there is one methodology that measured benefits quite well – Six Sigma. This process improvement method is built on finding the weak link in a process through measurement, improving it, measuring again, and then continuing to improve.  You can’t even start the Six Sigma improvement portion of the project without having measured. And you can’t close it without measuring again – to see if it actually worked. What a concept!

So, a simple proposal for regular project and portfolio managers. First, before selecting a project for the portfolio, make sure the business sponsor has defined not only what the benefits will be, but how to measure them – and the “before” measure. At PeopleSoft IT we had reached a point where we were requiring all project requests to be preceded by a Six Sigma effort to detail the solution and the benefits.

Second, add a phase after “close” called “benefits realization”. The project team can be dismissed, but the portfolio team can record the results of the post-project benefits. And then, we can roll up the actual returns from projects to see how our investments are actually paying off!

I know – there a lot of situations where the benefits are “soft” and hard to measure. And I agree. I’ll deal with that in another blog post

That’s my idea – but how are you dealing with this always challenging subject? The more we hear from each other about what works/doesn’t work, the better! So, please share your ideas and add your comments.

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.

1 – The information is too late. That’s right, while purchase orders and invoices are both entered into ERP systems as they hit accounting, project managers don’t see this data for up to 45 days. Why so late? Data extracts sent to PMs and other managers tend to come out after the books close. In most companies, this is a 15 day cycle after month-end. So, a PO that was issued July 1 won’t show up until the Aug 15 report. Way too late to take any corrective action!

2 – Finances categories are useless to PMs. While finance wants to slice and dice costs by cost centers and accounts, project managers need different categories. Typical would be hardware, software licenses, software maintenance, contract labor, etc. Many ERP systems do not have their account structure set to reveal this valuable information.

So – what’s the frustrated PMO and project manager to do?

 My first suggestion is to ask finance to run the purchase order and invoicing data out on a weekly basis. When they balk that the data is not yet official and/or those documents are not yet approved, simply let them know you are using it for planning, not official reporting.

As to how expenses are categorized, it is important that standards be agreed and set for project cost accounting, and these implemented in the ERP costing structure. After all, and Enterprise Resource Planning software should be used as a planning tool – not just a financial record keeping tool.

If the latter fails, at least get your data feeds from finance more frequently, import them into you tool of choice, and slice and dice from there.

What’s your experience with project cost control and ERP? Is it working for you, or do you have a “workaround”  system in place? Please share your thoughts and approach so we can all learn from your valuable experience!

Dave B.

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.

My point , however, is that even the PM lost sight of the business target in the middle of the project. What a PM really needs is a laser focus on this target. There are several benefits to a well thought out and clarified business target.

First, it’s easier to reign in scope creep. If we need taxes to be right come January 1, but HR wants to add some new vacation tracking functionality, it’s easier to say no – especially if that might endanger the Jan 1 date.

Second, the odds of success are much higher. Back in my programming days, I remember a project where we did a great job of defining requirements, and even added mock screen-shots and reports to the specs. The customer signed off on the spec, we delivered on-time and on-budget, only to hear “it’s exactly what I ordered, but not what I need!” Ever heard that one?

By focusing on the business proposition it’s easier to work with the customer along the way and even make suggestions that would better enable the project to deliver against the proposition. This may require some course adjustments. In the case above, we would have changed the design for a smoother work-flow, rather than sticking to the original specs. These adjustments may well have caused the project to be both late and over budget. But isn’t a little late and over budget better than delivering something useless that happens to meet the original requirements?

One project manager I spoke to recently put this idea quite succinctly. He was taught that for any project, he should be able to give the “elevator pitch” for the project. An elevator pitch is a sales term, and every salesperson can give you that 15-30 second pitch for why you should buy their product. If you can successfully give a 30-second elevator pitch for your project, you’ll be well on the way to a truly successful project with happy stakeholders.

Now, viewing projects as business outcomes has some serious implications for how portfolios are managed. More on that in my next post . . .

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 another issue in this conundrum: sometimes the business customers of a project think they know what they want in technology terms, and try to input their requirements in that manner. Something like: “We need a new sales force automation system that is web-based, syncs with MS Outlook, and integrates with the finance system”.

Why? Perhaps they are trying to increase the efficiency of the sales force. Or, perhaps increasing their visibility into credit issues through finance. Or, they need better visibility into the sales pipeline.

My point here is simple: For a project to be successful, a clearly defined business target is required. This is a vision that sits above the requirements. Indeed, if specific requirements don’t help produce that vision, they may not belong in the scope of the project. It also helps to separate the critical items from the “nice to have” requirements.

Given a business target, the project needs a Project Manager that understands the target and can drive the team to deliver. Why the project manager? Because business is a fluid undertaking, and the requirements may indeed change – but the vision should not. The project manager needs to be able to collaborate with business stakeholders – on their terms – to help sort through the shifting landscape and determine if and when changes to the project are required.

I was once asked to manage a large payroll system enhancement project. Lots of detailed requirements, lots of good business reasons to upgrade, including changing tax regulations and international expansion. And over 100,000 people on the payroll. I asked the VP in charge: “Why me? You have plenty of qualified project managers in IT.” Her reply: “Because, at the end of the day, come hell or high water, I know you will make sure all of those employees get paid.”

Now that’s a business target.

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. They are also afraid of exposing the “meta-data”, mostly related to performance of their projects. The PMs do not like the added administrative overhead, including signature gathering, regular status reporting, and the like imposed by the PMO. Finally, PMs do not appreciate the portfolio view of projects and would rather be left alone to manage their specific projects to success.

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, and are therefore fully supportive of the work of the PMO, and readily comply with and enhance the work of the PMO. They also understand that good portfolio management is key to their own success. If their projects are low priority, lack sponsorship, etc, then their chances of success fall accordingly.

Naturally, yours truly has weighed in on this debate. I have found that which camp a project manager falls into can be heavily influenced by how the PMO is implemented. If the PMO adopts a rigid, one-size fits all SDLC methodology (see Common PMO Mistakes on this blog), project managers will have a difficult time succeeding. This kind of “police state” PMO almost always fails, with PM dissatisfaction being one of the primary reasons for failure.

On the other hand, a truly strategic PMO that implements a flexible, multi-tracked methodology, properly prioritizes project demand, and matches that to available capacity, becomes the project manager’s best ally. These PMOs also listen to input from their PMs to constantly improve the organization’s project management processes and culture. Finally, proper automation can go a long way toward relieving any additional administrative overhead, while increasing visibility and collaboration. In short, professional project managers feel they are an integral part of these successful PMOs, and that the PMOs are critical to their own success.

What’s your experience? Please feel free to weigh in on this debate! I’m sure we all have a great deal to learn about making PMOs more “PM friendly”.