With a strong enough WHY you can achieve just about any HOW. The WHY is the drive behind any initiative - what do we expect to gain from this project or programme.
The problem is, some WHYs have been lost in the depths of history. Every business case documents clearly why a project or programme is going ahead, how cost-effective it is and how many strategic objectives it contributes to.
Then the outstanding Project Manager comes along, and his (or her) target is to achieve on time and on budget. If this means renegotiating any and all of the Timescale, Budget or Deliverables, then that is what the successful Project Manager will do. With an easier Deliverable, he's more likely to succeed. With a more realistic time and/or budget, he's more likely to succeed. The more success, the more negotiating power. The more determination to negotiate, the higher the respect.
Let's take for example a project to automate an invoicing process. The business case says that by automating end-to-end, a saving of $100,000 can be achieved, and on the strength of this, $25,000 investment has been authorised.
The old manual process involves collecting the dispatch notes from the warehouse, getting a paper copy of the order, checking the dispatch notes against the order, and typing up an invoice in a word processor. Finally two copies of the invoice are printed, one for the customer and one to be filed in this month's "unpaid invoices" file so that it can be chased if it gets late.
The proposed change for $25,000 involves entering an order onto a database (or confirming a quote, which is the preferred way), and warehouse then checking off the items on the order. Invoicing then prints an invoice based on what warehousing confirm they have dispatched, and the system files the invoice in ready to be used by credit control, sales and everyone else.
But the warehouse dispatch is difficult to automate - warehouse people like using paper and don't like computers. So the project manager renegotiates to install an order processing/ invoicing system which prints out a bill of materials for warehouse, then generates an invoice the day after because dispatch will always dispatch within 24 hrs. A great success- the system is delivered on time and well below budget!
Orders come in for unusual items, which aren't in stock, so the goods aren't shipped but the invoice goes out as usual. Bill of materials goes astray and things never get shipped or the wrong things get shipped, and nobody knows - invoice goes out as normal.
Costs in dispatch are exactly the same as they always were, because nothing has changed. So the anticipated savings don't materialise.
The blame lands on dispatch, when the real problem is tha project management - the project manager had clout and renegotiated and there were no benefits left to realise.
At each stage, especially whenever there is a change in scope or a change in context (the environment), the benefits need to be reappraised. This isn't a long and complicated job - once you've done it once, reviewing and recalculating is relatively straightforward.
But in the above example, it would immediately be obvious that the change in scope would leave the organisation with about 1/3 ($30,000) of benefits instead of the full $100,000. If the company outsourced its administration and warehouse to somewhere with very low cost of labour, then the business case would also change as the manual processes to be replaced by automation would cost less. If the competitors suddenly have much better processes, then the value to be gained, or benefits, may go up to $150,000.
In every case, it impacts on the decisions. If you plan to spend $25,000 and your potential return is suddenly $30,000, you'd probably ask if it is worth it. If you stand to gain $150,000, you might consider a more expensive solution which delivers more or sets you up for a better future.
But you can only do this with good Benefits Management.
So how do you implement good Benefits Management? Well that's a tale for another page . . .