by Louise Worsley

Not just a means to an end

Benefits Management

The PMSA biennial conference and the local practice groups taking place across the country are a great opportunity to share ideas, as does Heather van Wyk here.
Benefits Management

The PMSA biennial conference and the local practice groups taking place across the country are a great opportunity for project managers to share ideas and generate discussion.

Organisations may differ in the ways they do things and use terminology, but the desired result is the same – successful project delivery.

What sharing allows us to do, is to ask those important ‘why’ questions.

Why does this practice work in this situation and how would I recognise when to apply which approach.

These questions must be answered if we are to grow the knowledge and competence for high performance project management.

The Engen Petroleum benefits journey

Heather van Wyk, a benefits analyst working at Engen gave a presentation at the national PMSA Biennial conference in September 2012 and later at a Cape Town branch meeting of the PMSA.

In this talk she described the progress Engen had made in its journey towards improving the value returned from its IT project portfolio.

Heather’s review and case study provides insight into the organisational issues at Engen as well as the opportunity to see what can be adopted and adapted from their experience.

The starting conditions are familiar: IT-enabling projects rarely had a good business case – the documentation could be typified as a dash for the solution.

It was often being called a business requirements specification, but was in practice, a thinly disguised solution document.

No hint of the problem; no test for value; little stakeholder engagement; the only risks focused around whether the solution would work or not – leading to documents couched in ‘IT-speak’.

The business ends up feeling the solution was foisted on them by an overbearing and non-listening IT group.

This is a common scenario: business blaming IT, while IT feels aggrieved and isolated that the business will not step up to its responsibilities of engaging with them and defining the business needs clearly enough.

This ends up with IT having to do the best it can under the circumstances.

The solution: Engen introduced PiCubed’s hourglass analysis and benefits modelling approaches.

These techniques focus attention on the problem or opportunity sitting behind the motivation for a project, and also on why the problem or opportunity is worth addressing.

What the company will get in return from its investment is also considered.

The technique is, as you might have guessed, a bit of a trick. It works because the only group that can provide this information, and validate its truth, is the business.

Moreover, by focusing on the problem and the value – and not the solution – it is in a language and style that is immediately accessible to the business.

Initially there was some reluctance. Getting business sponsors to attend a project workshop was difficult and everyone suspected it would be a waste of time.

But within just four of these workshops, word got out that this was different and that for the first time business was getting across what it wanted to!

In fact, within two months business people demanded that this approach was adopted: they wanted to identify the problem; they wanted to understand the value of solving it; they wanted to take the control back from IT – who was only too willing for it to give it up. It became a new rule.

Heather worked up the rule into a practice: business cases were the product of collaboration between business and IT counterparts.

The motivation for a change can be facilitated by IT but it is essential that it be written by the business.

Options must be provided, and each must be a ‘real’ solution that addresses the requirements, which doesn’t necessarily need to involve IT.

Ownership was characterised by commitment, made visible in a forum that included peers and senior executives.

This became the new way. Business analysts (acting as analysts not as process experts) facilitated the workshops.

If solutions were mentioned they were ‘parked’, not ignored, but not chased down either; the time for solutions was recognised as a ‘later’ thing, and the focus was on why. Why is there a need? Why is it valuable?

So far, it sounds like process – the real problem is getting the political dynamics right.

So we might ask three questions: What did Heather do? What did Engen get right? How did it happen that the business sponsors stepped progressively up to the plate, with a backward, graceful relinquishing of action and direction-setting by IT?

The answer to the first question is simple: the language had to be the language of the business.

The second is trickier: the problem or opportunity statement had to be recognised and agreed to be correctly expressed by the business.

This could be facilitated by someone with analytical skills and carried out by someone in IT, but it had to be the work of the business sponsor.

The business case had to be presented and championed by the sponsor, and the sponsor had to agree a contract for its achievement – simple project delivery was not enough.

The third, was translating the governance concerns of a project sponsor into the benefit realisation concerns of a change sponsor. 

There were process steps and structures that were put into place to help but the critical part was realising the need to focus attention on the change aspects and giving them precedence over project delivery concerns.

Certainly one thing that helped was the progressive elaboration at the front end of the project to determine how best to govern it, as well as what the threats were to achieving the outcomes before it disappeared into the project delivery processes that ultimately focus on producing outputs.

The progressive elaboration boiled down the project to a series of concise and unambiguous success factors, which could be used as the control document for senior managers directing the project.

Once it has been established that the business case (not the project plan) is the governance document, it becomes easier for the sponsor to understand how to exert their influences on the project.

As Heather commented, “the journey from benefits realisation is not yet complete because along with change management, they still need to become much more tightly integrated.

But with the purpose of the project seen as the return of value; with the sponsor in charge of the project; and the business responsible for the delivery of value, the train is now on the right track with a much greater chance of delivering projects successfully at the right depot!

For more info:

comments powered by Disqus

This edition

Issue 29


TPM_Editor Old boy brings new life to Joburg school buildings using Corobrik’s quality face bricks 4 months - reply - retweet - favorite

TPM_Editor Global pump manufacturer obtains level 1 B-BBEE certification 8 months - reply - retweet - favorite

TPM_Editor IDT works on Tshwane inner city heritage project for Public Works 8 months - reply - retweet - favorite