Every project starts out as a ‘great idea’ that is sure to make things better, meet a need, launch a new product, maybe even ‘save the world’ – as long as you deliver it on time, within scope and to budget, right? Not all projects survive, of course, and one might blame exceeded budgets, schedule delays or not delivering to the defined scope. But what if the problem with many ‘failed’ projects was something else entirely? What if your organisational culture was to blame?

Understanding the foundation
What is this thing we call ‘culture’, anyway? Merriam-Webster defines it as:

(noun) “A way of thinking, behaving or working that exists in a place or organisation (such as a business).”

In practical terms, people say “that’s just the way things are done around here”. That can be a problem if it means “go away, things are fine just the way they are”.

Your culture may be open and accepting to change and new ideas, like freshly turned earth accepting new seed, or hard and unyielding like sunbaked clay, resistant to any new and different ideas taking root.

The culture of your organisation has a significant impact on every project you attempt to deliver. It provides the foundation for what types of projects will be viewed as acceptable in your environment, given the risk tolerance level of your organisation, attitude towards change and other factors. It also affects the developmental stages of your project, as you work with some stakeholders who are supportive, and others who feel threatened and will throw up continual obstacles in your way – or try to stop your project entirely. Even if you manage to finish your project, you can still face failure if the organisation refuses to adopt and use the fruits of your labour.

So how can projects not only survive, but grow and even thrive if the cultural environment is less than ideal?

Wisdom from an ancient profession provides an approach that can help your projects succeed. In order to survive the culture, you need to cultivate your projects. But what does it mean to cultivate something?

Merriam-Webster defines cultivate as:

(verb) “To foster growth; To grow or raise (something) under conditions that you can control; Culture”

We all try to control our projects within defined boundaries and objectives, but the conditions – the environment and the culture – can ultimately decide if we are successful or not. However, you can’t simply ignore the culture and hope for the best; you need to help prepare the culture for change. You need to till the soil.

Breaking ground
Every farmer knows that very few seeds cast on hard, dry ground will take root – most will be blown away or eaten by birds. A farmer must first loosen up the soil so the seeds have somewhere to start growing in safety.

If the culture of your organisation is hard, unyielding and unprepared for change, your project is unlikely to get the support it needs to get started. You need a project sponsor who is engaged, supports the project manager and is willing to help open doors, break through the soil and plough the first furrow – all so you can plant that first seed.

Taking root
Dry ground, no matter how soft, won’t germinate the seed. The farmer knows that additional resources are required, moisture and warmth from sunlight, in order for the seed to take root and start to grow.

In project terms, you won’t get very far without a vision, goals, a spark of imagination, staff, budget and a plan, many of which should be enabled by the project sponsor. Without the resources and support you need to begin growing your project, it is unlikely the project will ever see daylight.

Grow, baby, grow!
Once the first shoots reach daylight, growth can be quite rapid as they absorb sunlight.

These can be heady, exciting times on your project, as many things start happening at once and the future looks bright. When everything is going well, it can be all too easy to forget your dependence on the underlying culture – but you do so at your own peril.

Digging deeper
Growth is good, but in order to sustain it the roots need to expand and dig deeper into the soil for strength and water. If the soil is just a shallow layer above hardpan or bedrock, the roots will be unable to support the growth above ground for long.

While you project reaches to the sky, you can’t afford to neglect the foundations. You need the continued support of the sponsor, and a growing list of advocates to help support the project and strengthen its foundations, working within the culture as you prepare to weather the tougher times ahead.

Too dry, too wet, too soon, too late
Farming is far from a placid, pastoral occupation; it is fraught with risk, subject to environmental extremes and final delivery is dependent on optimal conditions and timing, many aspects of which are beyond the farmer’s control. Floods, scorching droughts, crops flattened by hail or heavy rains before they can bring in the harvest – it’s a wonder they keep at it, year after year.

Sound familiar? Perhaps farmers were the original project managers after all.

Harvest
A shovel, seed, water, dirt and sunlight by themselves won’t produce the best crops. You need well-conditioned soil, a timely spot of fertiliser and a diligent farmer keeping an eye on everything, pulling out weeds from time to time.

Projects are hard work, but with good foundations, support from a strong project sponsor, a host of advocates embedded in the business culture and a practical change management plan, your project can indeed survive your culture and even thrive – all while avoiding being mistaken for a weed.

And who knows? Overalls and gumboots might even look good with a tie…

ABOUT GARY NELSON//

Gary Nelson is a Project Manager, father of three boys and author of five project management books. He has worked on numerous projects in the private and public sectors over the past 27 years. His international experience includes projects in New Zealand, Taiwan, Hong Kong, the US and Canada. His blog, Gazza’s Corner, features a range of project management articles.

Whenever obstacles were put in the way, there always seemed to be a way to work around them and get things done, with (or without) number 8 wire – but no more.

But now, the pendulum has come full swing, and Risk Management has taken over nearly every facet of our lives at home, school, work and on our projects. However, paying too much attention to risk is not necessarily a good thing.

When I first arrived in NZ from Canada back in the early 1990’s, I was struck by the endless optimism of the people I worked with here. We were delivering a project that spanned multiple years and the full length and breadth of New Zealand, with a dedicated team behind it. I don’t recall anyone worrying about what might or might not happen. I rarely heard ‘risk’ mentioned in the office, if at all.

We had the plan and the schedule, we got to work, and when things went off track, we recovered, adjusted and kept moving forward. If there was a glitch in the system, the local system administrator would grin, say “kick it in the guts, she’ll be right” and reboot the server.

After the project finished, I went home to Canada with my Kiwi wife and we raised three young boys. I also brought home with me some of that boundless Kiwi optimism, which served me well on projects for many years. Even though Risk Management was becoming more common on projects at that time, it was at first used sparingly – and was seldom permitted to take over a project. It was a source of awareness, guidance and advice that assisted planning, certainly – but that was about it.

Over the years, Risk Management crept into many other areas of life: as children were no longer allowed to climb trees or scrape knees and flying foxes and climbing nets were removed from playgrounds. When I grew up, you always knew several kids who broke an arm or leg over the summer, and proudly sported their cast at school. Today, a child breaking an arm or leg is considered a drastic event, requiring someone to be ‘at fault’, endless paperwork, and a new risk management plan be put in place wherever it occurred.

When we moved back here in 2008, I was shocked to find that New Zealand was even more advanced than Canada in the area of Risk Management – with crippling effect. “She’ll be right” is but a distant memory, and it seems no project is allowed to start without a rigorous Risk Management plan signed off six ways. Sometimes it feels like more time is spent discussing how things could go wrong, than in planning how things should go right.

While a certain amount of Risk Management certainly makes sense – especially in Health & Safety – I would argue that having too much of it is killing our projects. Overly focusing on negative possibilities saps the energy and enthusiasm from your team, for who could possibly be excited about starting a project that has such a long list of potential problems? If you spend more time thinking positively about your goal, you are far more likely to achieve it.

We need a more balanced approach to risk, and to revive that Kiwi optimism, because we learn and grow when things don’t quite work out as planned.

We also need more kids climbing trees and scraping knees.

ABOUT GARY NELSON//

Gary Nelson is a Project Manager, father of three boys and author of four project management books. He has developed several methodologies and worked on numerous projects in the private and public sectors over the past 26 years. His international experience includes projects in New Zealand, Taiwan, Hong Kong, the US and Canada.

It is a tragic statistic – according to the most recent KPMG Project Management Survey (July 2013), only 33 percent of projects in New Zealand in 2012 were delivered on budget, 29 percent were delivered on time, and 35 percent produced the stated deliverables.

With numbers like that, it is a wonder that any projects are started at all – we would be better off crawling into a cave and rolling a rock across the door.

Declaring a project a ‘failure’ is a difficult thing to face, especially when we put in the long hours, lost weekends and all of the blood, sweat and tears needed to bring our projects to completion.

But what is ‘failure’, really?

For the bean counters, it is easy to declare a project a failure within the rigid confines of ‘what was planned?’ versus ‘what was delivered?’, closely examining every measure. On time? On budget? Delivered to scope?

Any slight variation can cross your project over to the dark side. It hardly seems fair.

However, experience tells us it is never so simple. All projects are new endeavours, where the unexpected is the norm, and conditions can – and do – change. If you always knew the exact outcome, you would be on an assembly line.

On a project, all that can be done is to set eyes on the target and figure out the best way to get there – using appropriate methodologies, best practices, expert input and a highly skilled team.

Even your best estimates will never be perfect, but honest estimates always help.

When things change and impact the timeline, budget, or scope – a change request is used to handle the variation. That means things are all good, now, right? I’s dotted, T’s crossed, the executive has approved it, and the team can just get on with the project.

Except, of course, that the project is already deemed and labeled a ‘failure’ in the eyes of some. More money was spent, more time taken, or the deliverables changed.

But is that really fair?

Certainly, there are some projects that are real failures – over budget, behind schedule, and which don’t deliver what was promised. Worse, the project deliverables may never be used to their full potential because they were not fit-for-purpose. Or perhaps the project was abandoned and no benefits were realised.

Now, that is what real failure looks like.

Arguably, a more realistic (and frankly, less depressing) method for determining project success versus failure, is evaluating stakeholder happiness. No, I am not suggesting cracking jokes to lift boardroom mood. What I am talking about is satisfaction with the project outcome; that the deliverables fit the need, are appreciated and will be well-used, even if it took a little longer or cost a little more. In other words, it was worth it, and provided acceptable value relative to the investment.

The best way to help ensure a successful project is to have open communication and active engagement with all stakeholders throughout the project, from requirements to the final deliverables. With that engagement, there is boosted confidence that what is planned for delivery will meet the needs of stakeholders upon completion.

When stakeholders embrace project outcomes and use them to better their services, help their customers and get benefits they wouldn’t otherwise have enjoyed, that is success.

They might even grin from ear to ear – and THAT is why we still do projects.

ABOUT GARY NELSON//

Gary Nelson is a Project Manager, father of three boys and author of four project management books. He has developed several methodologies and worked on numerous projects in the private and public sectors over the past 26 years. His international experience includes projects in New Zealand, Taiwan, Hong Kong, the US and Canada.

With shrinking budgets and project failure rates as high as ever, it is increasingly important to get your projects done right the first time. Using project management methodologies, hiring experienced project managers and having a clear set of requirements are all steps in the right direction. But no matter how hard you try, if you fail to work with honest estimates, you can be destined for project failure before you even start.

Estimates are how we try to deal with the unknown, and wrap our heads around various business cases as they are presented for approval. The more experienced your staff are in a particular area, the closer the estimates are likely to be to reality. However, if your staff are inexperienced or if they take a step into the unknown, the level of confidence you can have in their estimates will be low – and the tendency to under-estimate is the norm.

Usually if we have a low-confidence estimate, we try to compensate by adding to it to reduce or schedule risk. Again, this is a reasonable, common approach. And of course it is the nature of estimates to be off the mark at times. The real problem arises when dishonest estimates are provided.

These dishonest estimates can either be deliberate or unintentional. While both types of estimates are signs of bigger problems and can adversely affect your project outcomes, they have very different causes.

Unintentional estimate dishonesty
How do unintentionally dishonest estimates occur? A project team may present a realistic budget based on detailed analysis and estimations based on core requirements. The project may be more complex than originally anticipated, or there may be high levels of uncertainty. Therefore it is entirely appropriate to increase estimates to try and ensure a positive project outcome.

However, the team may have failed to adequately communicate this complexity to the project board, and when presented with the (much larger than anticipated) estimated project budget or timeframe, there may be a tendency to try to trim it back to a more ‘reasonable’ size. This trimming is sometimes imposed on the project team, with little discussion.

This trimmed estimate is unintentionally dishonest because, if it is accepted without robust discussion or a reduction in scope, the project team is put in a situation where there is now an almost guaranteed low likelihood of success. The team is aware of it, but proceeds anyway. Unintentionally dishonest estimates can generally be avoided through improved communication.

Intentional estimate dishonesty
Intentionally dishonest estimates are another story altogether. A culture of pad-and-trim is an altogether too common problem, where departments and projects intentionally pad all of their estimates, because they know that management always trims them back anyway. This approach is obviously dishonest, but in the company culture it just may be how things work. The problem is this: How much did the project team pad? Twenty percent? Fifty? A hundred percent? More? How much will management trim in response? When both sides are not playing by the same rules, there is a tendency towards the ridiculous, where estimates become completely meaningless.

There is an intrinsic lack of trust in this scenario – and, frankly, any project in which people engage in this approach will be in trouble. They will either be chronically under-funded, or over-funded and wasting company resources.

Intentionally dishonest estimates are much harder to fix, and require sweeping changes to develop significant levels of trust throughout the organisation.

ABOUT GARY NELSON//

Gary Nelson is a project manager and author of three project management books. He has codeveloped several project methodologies over the past 25 years, and his international experience includes numerous projects in New Zealand, Taiwan, Hong Kong, the US and Canada.

Whatever business you are in, you will find projects. They are the way that things get done, the way to introduce change, make new things or make things better – but what is the best approach to getting a successful project outcome?

‘Winging it’ has a tendency to produce variable results. Alternatively, you can use a project methodology – a defined set of methods, principles and rules for doing something in a consistent fashion. One good thing about using established methodologies is that someone else has already done a lot of the hard work. The down side is that there are a lot of methodologies out there, with names of varying levels helpfulness like Method123, Scrum, TenStep, UPMM, Prism, PRINCE2, Lean and Waterfall. Some are simple to use, while others can be extremely complicated and require huge amounts of effort. And following a project methodology does not mean that a project’s success is confidently assured, although it can significantly improve the odds.

If you are considering using a new methodology, there is a lot of information available that describes the pros and cons of each. With a bit of reading you can generally choose one that looks promising, but it is wise to seek advice on what methodologies are best suited to your industry or situation. You don’t need to hire another consultant to do this, just talk to other companies in your sector that have been using the methodology for more than a year – particularly those that have similar challenges to yours. Find out what project methodologies they use, what worked, what didn’t and how they adapted them to work for their business. You might also like to find out if the methodology needed extra staff to support it and what added the most value for them.

While a project methodology can help move a project forward, I have seen too many people get lost in the methodology itself and lose sight of their project’s objectives. When you adopt a project methodology, take it with a grain of salt. My advice is to introduce it slowly, learn from it, and gradually adapt it so that it works for your business. (Obviously, the shorter the project the less documentation and structure you need, but you can still pace the project for learning.)

You may not need to use all of the structure or documents the methodology describes, and most methodologies actually advise users to tailor them to their specific situation. If a particular document adds no value, then it’s not a sin to drop it. When all is said and done, it is not the methodology that is important, but the project results and a well-adapted methodology should be an aid to producing your desired results.

Another, more advanced, approach is to develop your own custom methodology that is specifically tailored to your business needs, using a framework like the PMI PMBOK Guide. These custom project methodologies typically serve their purpose very well and allow users to adjust and improve them as time goes on, but are only really worth the investment for large projects or when your company has lots of projects in its sights.

All in all, a project methodology is only a guide and should be treated with a critical eye. Throw out things that are not adding value, tailor elements to suit your environment, and keep an eye on your own project’s goals and you should find yourself with the perfect balance between methodology and practical application.

ABOUT GARY NELSON//
Gary Nelson, PMP, is a project manager and author of three project management books. He has co-developed several project methodologies over the past 25 years, and his international experience includes numerous projects in New Zealand, Taiwan, Hong Kong, the US and Canada.