Project Governance has been neglected yet a governance team can destroy more value in five minutes than a project team can destroy in five weeks.

Poorly understood, poorly supported and poorly executed it is not surprising that more projects fail due to poor project governance than poor project management.

Yet while we invest millions in project management we invest next to nothing in project governance.

Even getting people to agree what ‘project governance’ is, is a challenge.

Governance support materials are sparse and usually superficial. Not helped by executives insisting they only want “the questions I need to ask,” not understanding they need much more to be effective.

So, after 20 plus years in project governance roles and over 12 years teaching, coaching and supporting executives in governance, we are providing a world-first solution that will revolutionize project governance knowledge.

THE TOP™ PROJECT GOVERNANCE KNOWLEDGE CENTER

You can find out more here.

This is both a comprehensive resource center for executives in project governance roles and a support base for those accountable for project governance performance in their organizations.

The Project Governance Knowledge Center provides the direction, information and support required to move project governance from being a potential liability to being a key driver of success.

Whether you want to confirm your understanding of project governance, build you personal competency in a governance role or develop your organization’s governance capability – this Knowledge Center will equip and support you. It is designed by executives for executives.

For example, it provides

• Charters, checklists and cheat-sheets (Tools and templates)
• Answers to frequently asked questions (FAQs)
• Short videos on how to deal with specific topics – such as “What to do if your project goes red” (Education Programs)
• Short guides on how to assess business cases, govern risk and more than 20 other topics (Guides)
• Practical frameworks that explain why projects fail, plus others that change how projects are viewed, approached and delivered (Frameworks)
• Articles on project governance – topic specific (eg How to champion your project) and some story based (eg Death by 1000 cuts) (Topics)
• Lessons to be learned – such as The Tale of Two Projects – that shows how easy it is to in good faith oversee a failure and what good project governance (and project delivery) looks like. (Topics)
• Easy-to-read books on important topics such as getting the best out of consultants – Consultants.CON (Topics).

When project delivery is not performing the natural tendency is to look at project management.

“How can we improve project management?”

“How can we improve the relationship between IT, the project and the business?”

“How do we up-skill our project teams?”

All good questions, but usually looking the wrong way.

Projects operate within a business context and environment. The wrong, inadequate or inappropriate business environment will actively prevent the project from being truly successful.

‘True success’ for a project is measured in business terms – did the business get the outcomes benefits and value it sought and expected? So, if the business is under performing its roles, it is unlikely to get the results it wants and the project cannot be successful.

Yet, this simple truth is ignored by most who are trying to improve project performance.

They, understandably, look at the project, the project team, the project methodology or whatever, but don’t look at the business, the business governance team or the (lack of) business methodology.

It is like trying to improve road safety by just improving the safety of cars. Good, necessary and does deliver some results – but road safety is also driven by the state of the roads, road laws, breath-tests, driver education, etc. Just improving the cars is not enough.

It is the same with project performance. Projects begin and end in the business. While there can be some project failures driven by poor project management, more projects failures are driven by poor business involvement, leadership and governance. In all of the analyses of large-scale project failure I’ve seen, ‘inadequate senior management support’ always sits in to the top three reasons for failure (poor project management usually comes in around number 6).

To improve project performance we need to stop looking exclusively at the project team and instead look at the business, its understanding and capability to perform its roles. You’ll often find the need for governance training, effective change approaches, simple but effective benefits processes – areas missing or underdone in most organizations.

Improving business performance is the area that VDM has been focusing on for the past 16 years – because until you improve the business’s performance, your projects’ performance cannot be successful. In fact, no one ends up as successful. And that’s failure, right?

Do we want to continue to be associated with failure?

© Jed Simms, Australia, 2010

One organization is getting rid of its pool of project managers as “you can just go to the market and buy them as necessary”.

Another organization outsourced its project managers to a major systems implementer on the basis that “we cannot give them a career path in our organization but they can.”

This seems to me to confuse function with effectiveness.

On the surface, project management is a function, a skill set or a competency. Different project managers will have different types of experience that will affect their ability to work on certain types of projects. (If you’ve ever seen a package configuration only experienced project manager take on a custom build project, you’ll know what I mean.)

But, to be an effective project manager you need to know how the organization works, who is who in the zoo, who are the real power brokers and how to get things done fast. This is not commodity project management.

Another dimension is that the same firms that outsource their project management, whether to the market in general or to specific vendors, often have methodologies that they then expect the contractors to pick up, absorb and use instantly.

Is it just me or have we lost the plot here by seeing project management as a commodity?

What do you think? – post your comments on the blog.

© Jed Simms, Australia 2010.

Project management contributes to project success, but does not guarantee it. Project management can efficiently deliver the wrong result as well as a high-value result; it is content agnostic. You, therefore, need effective project management to increase the efficiency of your project’s delivery. But you cannot rely on project management to increase the quality of your project’s outcomes if they’re not set up correctly in the first place.

PMBOK , for example, does not include either a requirements definition stage or benefits management process; these are value delivery processes and therefore not part of the project management stream (even though they are often assumed to be). As project management is about organizing the delivery of “something” a project manager is naturally pulled towards getting to the delivery stage as soon as possible. The time required to define the desired outcomes and business requirements can be as a frustration to the project manager — which is why so many projects rush off with vague scope definitions and no, inadequate or inappropriate measures of success.

Which leads us to ask whether “Scope” is a project management or a value delivery tool. Traditionally, scope and its management is seen as a key project management control mechanism with strict change controls asserted over proposed scope changes. This appears to make sense when you see most scope change proposals discuss their potential impact on the project’s resources — time, effort and cost.

However, this is a mistake; as the impacts on the business outcomes, benefits and value are usually not considered. This can lead to massive value loss.

In once recent case a project under financial pressure ‘de-scoped’ one segment to save costs and keep within the original timeline. However, our value analysis showed that this one segment delivered over 60% of the business value and without it the project was not viable. This value-destroying decision was made because no one had considered the impact of the de-scoping on the benefits. Indeed, as they had used conventional business case approaches, they could not link the components of the project with the prospective benefits!

Our view is that scope management is an integral part of the value delivery stream as it establishes the value to be delivered (through what’s in and out) and should only be changed after full consideration of the resultant business benefits and value impact. It is, therefore, a value management tool.

What do you think?

Our approach to project management translates the core project manager processes into value-contributing tasks. If you can’t contribute in to the business value being delivered then project management techniques should not be applied.

On one recent assignment I was presented with a 28 page ‘project control’ document that did not add one cent to the value of the project (but many dollars to its cost).

Project management is not always needed. Our Business Simplification Program, for example, is time-boxed to 14 weeks with set activities each week. Therefore, there is no need for planning, estimating or scheduling, this is already done. The delivery risks are pre-known and the assignment is usually fixed cost (so financial control is not necessary). So the only areas where project management can contribute value are issues and stakeholder management, and quality control.

Another example might be an office move of, say, 30 people across town. Planning and task scheduling would be valuable but many other areas of project management would only be useful at a minor level as the project is too short and too simple to enable them to deliver much value.

One problem with some project managers is their belief that its ‘one in, all in’; that once you use one or two project management techniques you might as well use them all. But any project management tool should only be used if it will contribute to the business success of the project (in excess of the costs and overheads involved). I’ve delivered quite extensive change programs with minimal project management overheads as the tasks are largely self-evident and require minimal planning, control and management.

The key lessons are that

• project management is not the same as project delivery
• project management is not part of the value delivery stream
• but project management processes can contribute to the success of the project
• but the use and application of project management processes needs to justify the value it is contributing.

When should project management be applied (and when not)?

It is not so much that ‘project management’ is the problem, its just that it is not the solution!

Too often in people’s minds ‘project management’ is seen as the same as ‘project delivery’ — but it is not. ‘Project Management’ is the set of processes that organizes, structures and controls project activities and is the equivalent of any other ‘management’ activity.

Take a production line. The operators create the goods (the value) and management organizes the work, plans the production, pre-empts or deals with problems and so on. Management organizes, structures and controls the value generating activities but does not directly generate or deliver the value.

This is why ‘project management’ has had so much difficulty trying to quantify its value. Project management is not, therefore, part of the value delivery stream (in our six stream model).

Project management has to justify its contribution. Few would argue that large, complex programs of work can be effectively delivered without effective project or program organizing, structuring and controlling. However, these processes contribute to, rather than directly deliver, value.

Therefore, before applying project management techniques to projects you need to establish that the time and effort involved in project management will be offset by the value to the project (as opposed to the business). This value can be in terms of

• reduced project duration — benefits faster
• reduced wasted effort — less cost
• more motivated, focused staff — increased productivity
• increased clarity of what is should be happening — increased (progress, financial, direction) control
• less risk — more certainty
• fewer issues — less unnecessary effort
• increased stakeholder support/comfort — greater business support

How are your project managers adding value to your projects?

Project Managers are often bemoaning that “Project Management” is not accorded the status it deserves as a profession. “Organizations just don’t recognize that project management should be a core competency they need to focus on!” it is asserted.

But does any other ‘profession’ have such a high failure rate? Do engineers design buildings, 70% of which fail on one or more dimensions? Do we catch planes with only a one-on-three chance of getting to our destination?

For all the training, standards, methods and software tools, project management success rates have not improved since 1991 when AD Little first measured project success rates.

Instead of bemoaning business narrow thinking or short sightedness in not lauding project management, we need focus on improving its performance — dramatically improving it in fact.

We need to recognise the maturity spectrum with project management and project managers, viz:

1. People with no project management knowledge or training (level 1)
2. People formally trained in PMI/Prince2 or alike (level 2)
3. People formally trained but have realized these approaches are not the answer (level 3)
4. People who have been formally trained in project delivery processes that work — ie value delivery management (level 4)
5. People who have been formally trained in project delivery processes that work and have integrated them into how they work on a daily basis (level 5).

Only when we get to level 4 or above can we demonstrate project management as having a professional status. Luckily, next year (2009) we’ll be conducting a series of formal training sessions to enable people to demonstrate that project management can be “the best profession in the world” in terms of the results delivered.

Comments? Interest?

© Jed Simms, Australia, 2008

I was with a prospective client and her top project director trying to discover what they wanted. The client was vague, scatter-gunning ideas, concepts, outputs, worries, risks and so on. So I suggested making a list of where she wanted to be in six months time. We listed about 10 items on the whiteboard.

I then had to take a pre-arranged call and left the conference room for 10-15 minutes. When I returned the project director was off and running.

This list of 10 vague, unqualified ‘objectives’ were well on the way to being organized into a program of work for the next six months. Timelines, interdependencies, resources and so on were being assigned to a list not worth printing out, let alone actioning!

However, it struck me how common it is that projects are set off and running, applying all of the rigours of project management, to a poorly thought through, vague and unmeasurable list of client objectives and goals.

This ‘action first, thought later’ approach is unfortunately aided and abetted by many senior executives who want to see ‘action’. “Don’t ask me any more questions, just get on and deliver!”

Sometimes it takes a brave project manager to, in effect, refuse to be off and running when they don’t know where the client wants them to go. Too many just take what they’re given and try to make the best of it. This is a recipe for project disaster and personal job loss.

Many years ago, when I was with Arthur Andersen Consulting, our Managing Partner had a reputation for shooting people who did work for him. They never got it right in his eyes. This was because, primarily, he could not articulate clearly what he really wanted.

So, when I was asked to do something for him, after each ‘briefing’ I went back to him with my understanding of what outcomes and end states he wanted to achieve. Three times he said, “No, no, no, that’s not what I want … I want …”. On the fourth occasion I got it right.

Then, and only then, would I start planning my project to deliver his desired outcomes.

Now, he got a bit frustrated that I ‘could not understand his needs more easily’, but I wore this to ensure I really did understand his needs correctly rather than going ahead with what I thought he wanted and then delivering something that would get me shot!

Two of the greatest threats to anyone doing a project are vagueness (lack of exact clarity) and “assumptions” (assuming you understand and know what the client wants). Combined they can be fatal to your career.

So, before starting any project, make sure you know and have agreed in detail with your client the exact, measurable ‘desired business outcomes’ to be delivered. This may require you going back again and again until you have full agreement and sign off.

Then, and only then, should you be off and running.

I was recently in a meeting with six experienced project managers. What amazed me was that none of them seemed to speak the same language or could agree on the best approach to projects. They all had their theories and could defend them with evidence of how they’d worked.

Which got me thinking about why it is so difficult to change project managers, to get them to try something new.

Imagine if you asked three project managers to get from Melbourne (Australia) to Sydney (Australia) — a distance of about 900 kilometres. One may go by car, one by train and the other by bus. All three get to Sydney and are, therefore ‘successful’. They would have all take different amounts of time and the cost will have been quite different, but they’ve all ‘proved’ that their approach to getting to Sydney ‘works’ and will, therefore, believe it can be applied successfully to the next project.

Once a project manager does something that “works” they are convinced they have the formula for project success — hence the disparate views, language and approaches to projects.

In our Melbourne-to-Sydney example above, if you then come along with a ‘take a plane for the cost of a bus’ option, most project managers will reject it. They don’t know that it works and it is an option they have not seen (personally) as successful. And their far too busy to learn.

One of my favourite cartoons is of a Medieval knight fighting with bows and arrows who does not have time to see the salesman with a machine gun because he’s “too busy fighting a war!” This so sums up many project manager’s approach to learning.

They say that the best lessons are learned from failure. You learn what does not work. But when things ‘work’, however badly or expensively, they are adopted as ‘the way’. As a result, approaches that don’t work but are buried by aspects of a project that do work are continued and thought of as ‘successful’.

So, when planning to change project managers’ approaches you need to stay away from the detail, the terminology or even the approaches, and focus on what you’re trying to achieve (the ‘desired business outcomes’) and work backwards as to how these can most efficiently and effectively be achieved.

Getting a group of project managers to define and agree the desired business outcomes for projects in general (as opposed to a specific project) teases out the different views as to what is important on projects and, often, creates new perspectives for many in the discussion.

The project manager who catches the bus may in fact not know about the cheap-fare plane option having assumed it was far too expensive or may have a belief that ‘supporting public transport’ is an important factor. The car driver may see that going by car is a far riskier approach to projects than is necessary (as well as the most tiring). And so on.

Changing change-agents is always the hardest challenge, but using the ‘desired business outcomes’ technique can change create a common language and change the discussion from “who is right?” to “what is required to achieve these outcomes?

The power of ‘desired business outcomes’ is described in “In search of the ‘holy grail’ for projects” available from www.project-sponsor.com

Discuss your experience at changing change agents.

(The Tower of Babel is credited in the Bible with causing the confusion (ie multiplicity) of languages.)

I remember attending a 3-day strategic planning conference where my role was to sum up what had been said and decided. When I pointed out that I had sat through 22 hours of presentations and discussions and not heard the word ‘Customer’ once, I was told, “The Customer was always assumed!” No they weren’t, they were ignored.

“Assumed” — is this the most dangerous thing on projects? People ‘assume’ that the project will enable the benefits. People ‘assume’ the GM who signed off the project fully understands it and its potential ramifications and therefore it is OK to approve without scrutiny. People ‘assume’ the new product will sell in the market even though they’ve not identified why they’d like to buy it. And so on.

Assumptions can speed things up in the short term, but dramatically reduce value in the long term.

A recent project team ‘assumed’ that the software could do what they wanted, bought it, installed it and then found it couldn’t. $3.4m investment for zero return.

Another project team and Sponsor could not answer any of the questions as to why anyone would buy their new product. They ‘assumed’ it would sell because other (different) products had sold.

Value Delivery Management™ declares war on assumptions as shortcuts and insists the work be done so that the true facts, outcomes and realizable value are known and delivered. This routinely shortens the duration of projects as less time is spent on rework correcting false assumptions.

VDM avoids misaligned expectations, mistaken purchases and missed benefits.

Whenever anyone says, “We assume …” the red warning lights should go on.

Let’s stop spending millions of dollars on the basis of untested assumptions.

Let’s start spending our dollars on the basis of validated business cases.

Now there’s an idea!

Jed Simms