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.
