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.