Green project management

Sustainable green and healthy earth concept

One of the things which I have noticed since living in Japan over the last 3 months is how much plastic there is. Everything seems to come wrapped in the stuff, even if it already comes with a more than adequate natural packaging – bananas for example. At the supermarket, a piece of fish wrapped in plastic is given its own plastic bag at the checkout and then another plastic bag for all of the groceries. Three layers of plastic then for good measure.

All this plastic got me thinking about green project management and whether environmental concerns can be better integrated into mainstream project management. Although to give them credit, the local government here does take recycling waste very seriously. There are bins everywhere – one for plastic, one for paper, one for tin cans, another for glass, and one for the stuff which cannot be recycled. But aren’t we doing things the wrong way round? Rather than producing a whole lot of plastic and then collecting and recycling it, wouldn’t it be better if we didn’t produce as much in the first place?

After thinking this through, I think it’s time to add another aspect to a project’s performance – sustainability and the project’s contribution to it. If we can set targets for sustainability on our projects, we can work towards a more secure future on this planet for our children. For example, when you procure resources on your project, do know if they come from a sustainable source? The paper which you use in your office – does it come from a managed plantation, or from trees felled in a tropical rainforest?

Hang on a minute I hear you say. The shareholders and executives in my company only care about the bottom line and therefore it’s my duty to buy resources in an efficient way. If buying resources from sustainable sources costs more, then it’s not going to happen. This is certainly true. In a commercial organization, the project needs to show a return on investment, but in non-commercial projects this isn’t necessarily the case.

It’s also true that we have probably always sourced things based upon cost, so doing things which are more costly just isn’t going to happen. I think this is where education plays a part.

Project Managers who are concerned about sustainability can now gain knowledge and accreditation in green project management. A quick Google of sustainable project management also revealed this book which looks like a really interesting read. It’s on my list of books to read in the coming months.

By Project Managers gaining more knowledge of sustainability in relation to project management, they can begin to educate corporate executives why setting sustainability targets on projects can only be a good thing.

The Pareto Thing

Pareto principle illustration

The past few weeks have been quite busy helping a client prepare for an arbitration between a project contractor and the management of a troubled project. An arbitration is less severe than a lawsuit, in that the parties in disagreement choose an ‘arbitrator’ who is well qualified in the industry, to decide who is right about which claim. They then agree to abide by that decision. Much cheaper than a lawsuit, apparently.

We are reviewing the contract, deliverables, deadlines etc. on a given section of the work, when I notice the monetary amount in that section does not seem very large. Diplomatically, I suggest we do a “Pareto Analysis”, and prioritize the preparation of the larger items.

Pareto Analysis (also known as “the 80/20 rule”), refers to the analysis of the Italian economist Vilfredo Pareto, where he observed that 80% of land in Italy was owned by 20% of the population. More recently, it has been applied to many more uses: what 20% of the effort would contribute to 80% of the improvement; which 20% of customers bring 80% of your business.

“Oh yes” said my customer, “let’s do the Pareto thing”. So instead of a small work item, we analyze and document an item which -by itself- is more than half of the total amount in dispute.

Pareto analysis is one of the first tools the project manager should reach for, suggesting to us which 20% (ie, small amount) , if addressed, would bring us the 80% benefit (ie, large amount). It can help us prioritize change requests. It can help us organize the resolution of problem log items. If funding has shrunk, it suggests which work to keep in scope; which to de-scope.

Even in Agile Scrums, Pareto Analysis can bring clarity to the product owner about which high priority work to deploy in the next Sprint. It can be applied to large items -such as which budgets to analyze first- and to small items -which phone calls to return first-. So do use it extensively.

As to my customer’s arbitration: they lost 2 items and the contractor won 2 items. The contractor’s items were about 25% of the amount in dispute, my customer’s items were 75% of the amount. The contractor just did not present a very compelling argument. He must have run out of time. For my customer, the Pareto thing paid off handsomely.

My own moving country project

Business project concepts spread throughout desk

I’m a lucky guy. I’ve had the fortune to be able to move half way around the world, start up in a completely alien country, and manage to keep the stress levels under control – for much of the time anyway.

I’m writing this post from Tokyo, a city I have visited many times previously – both for work and for leisure. It’s been rather cold since arriving, but nothing which a boy from the north of England cannot endure.

So, what’s this got to do with project management? Well, quite a bit actually, if we consider the move (which I made with my wife who is Japanese) as a project.

Planning

Like all projects it required a plan. We (I should say my wife) made a very detailed plan, which started months in advance, and got more detailed the nearer to got to the moving date. There were several milestones along the way – putting our house on the rental market for example.

Changes

Things changed unexpectedly which meant that we had to take some decisions and re-plan accordingly – for example when the nice tenants we had found for our house wanted to move in 3 weeks earlier than we wanted.

Risks

There were risks to be considered – for example, what if our 2 lovely Chihuahuas weren’t allowed on the plane, or worse, were refused entry when we faced quarantine at Tokyo’s airport? Governments tend to like paperwork at the best of times, but I was totally unprepared for the amount of paperwork demanded by these two rabies-free island nations.

Execution

So, the plan evolved – injections, visas, tickets, moving, packing, selling the car – each one ticked off as they got completed, each one getting us closer to the final day.

My wife did an astonishingly good job of planning everything – even down to having futons and duvets, cutlery and crockery delivered within 2 hours of our moving into the Tokyo house the day after we arrived. Two hours later, the fibre-optic cable was installed for our internet connection. My wife has never been on a project management training course, but for her, the planning of all the different steps involved follows a certain inherent logic, just like it would on any other project.

48 hours prior to departure we had to have various paperwork completed by our vets in the UK. The day before flying this had been faxed off to the Japanese quarantine people who had promised to check it before we arrived.

Murphy’s Law (if something can go wrong it will)

On the morning of our departure their reply landed in our inbox. “Don’t forget to bring the original rabies antibody test certificates with you – otherwise your pets may be refused entry and may be sent back to their country of origin”. We looked at each other in horror. Of all the things which we had thought about and had planned for, we realized this was the one thing which we had overlooked. In fact we didn’t have the originals – they were at the vets in London.

We immediately phoned the vets. Luckily they still had them and we could pick them up on our way to the airport. So, we made a 2 hour detour to get the certificates, but this was well within the slack which we had allowed in the plan to get to the airport.

So, we arrived at the airport, after driving through yet another of the UK’s winter storms and went to check-in. The attendant took one look at the dogs in their crates and said we couldn’t take them. We couldn’t believe it. We had double-checked when we booked the flight that the pets could be carried in the cabin. We argued and when he realized that they were bound for the cabin we were OK to check-in with both dogs.

One huge sigh of relief and a walk through security later, we were able to board. Eleven hours on a flight with no toilet or food or water is not much fun for a small dog. Yet despite a few passengers being startled by the occasional bark, their first flight was thankfully pretty good.

Lessons

So, what lessons can we take away from this? Well, for one, plan your project. Had we not planned in detail, there would have been a lot more surprises along the way.

Make sure you analyse all risks beforehand and ensure you have a plan to deal with them. We had tried to reduce most risks, for example by researching in detail the requirements of the Japanese quarantine and the UK pet export regulations. But there was always the chance that we might be refused entry.

Lastly, be prepared to change your plan, when things come up unexpectedly.

I’m sure that you have had similar experiences when managing projects not just at work, but in your personal life too. Did an awareness of project management methods help you as much as it helped me?

Cultures In The Project

Group of multiracial individuals holding a sign with the word multicultural

In this ever shrinking business world, it is not uncommon to deploy a project with colleagues from different countries, with cultures different from our own. We can even implement a project in our own country and easily have stakeholders, say, from India, China, Mexico, Canada. Each one will bring different points of view, dependent on their upbringing and experiences (read ‘culture’). So it is a great business advantage to have project managers who are able to navigate these different cultures, and not end up in the difficulties Mrs. Muddle finds herself in.

Mrs. Muddle is a very capable technical project manager from Ohio, where she still lives. She has a science degree from a major US university and, because all her projects finish on time and on-budget, Management has chosen her to lead the expansion of key manufacturing equipment in their US and in their Asian (South Korea and Vietnam) locations.

After a kick-off meeting in person and a scope definition workshop, Mrs Muddle wanted to publish some ground rules for the ongoing status meetings. She had noticed that the Asian project managers −Mr. Moon-ki from South Korea and Mr. Chuyen from Vietnam− brought to the meetings no less than half a dozen colleagues. She therefore issued the rule that, henceforth, only the project managers should attend the status meetings.

Her edict was met with shock and discomfort in the Asian teams. Mr. Moon-ki informed Mrs. Muddle that he absolutely did not have the delegation from his management team to commit the company to any decision whatsoever. Mr. Chuyen made very clear that since the project required tasks from finance, engineering, IT and other disciplines, he could not agree to anything on their behalf. Mrs. Muddle tried to make her colleagues see reason, indicating that it was more efficient to deal with just one person than casts of thousands. She was confused as to why such a reasonable rule would make her colleagues angry.

What she failed to recognize is that South Korean and Vietnamese cultures are highly collectivistic, and that these gentlemen were unwilling to make any moves that would upset the peace of “the group”. In some societies, like the USA and Canada, being “individualistic” is a desirable trait. But in many parts of the world, the interests of “the group” do take precedence over the needs of “the individual”. Mrs. Muddle was astonished when her manager called her. Seems like they needed to schedule an apology meeting with the Asian subsidiaries…

Where Can a Project Manager Go From Here?

Smiling corporate workers standing beside a window

As inevitably happens at the beginning of a new year, with all the thoughts about resolutions, a few colleagues and acquaintances have been examining their jobs and careers.

Some are considering entirely new fields, like the lady who is considering leaving her IT job to open a hip Bakery because bread has always been her passion. Or the chap who is thinking about turning his corporate strategy expertise into strategy for a non-profit organization. While I was considering these various cases, along came a friend with her own dilemma. Let’s call her ‘Maria’.

Maria is the office manager for a small business and, as is often the case with small businesses, did so much more than just managing the office. She fixed problems with unhappy customers. She coordinated travel schedules. She orchestrated salesmen’s (and equipment) participation in trade shows. She even oversaw the installation of their first automated payroll system.

A few weeks ago Maria mentioned that there was an opening for ‘Event Planning Coordinator’ which she considered her dream job. Lots of travel and interesting events of all kinds. No way would they consider an Office Manager for that position, she thought.

I told her in truth she was not an Office Manager, but a Project Manager. And events were just a different flavor of project: They had a distinct beginning and an end; they required her to stick to a budget; they meant coordination of resources; often they needed change management.

Maria saw the parallels too, and filled her job application describing her projects as events. She was complimented for being such a well-rounded candidate (after coordinating a payroll migration, a trade show in Las Vegas should be easy!) and got the job.

So really, Project Managers can be successful in any field that requires the deployment of limited resources for a specific end, with a prescribed amount of time and money. Including not-so-obvious fields such as Cruise Director, Wedding Planner and Disaster Relief Coordinator. Now, I wonder if I can come up with parallels between managing projects and a Bakery…

Good, cheap and fast! You’ve got to be joking!

Man in black suit jacket making a thumbs up

You’ve heard of the old proverb: “if it’s too good to be true then it probably is”. In other words be suspicious of people offering you high returns for little investment.

Whilst that might apply to everyday situations such as when that door to door salesman comes knocking and offers you a free holiday in return for one of his garden sheds, what’s this got to do with project management?

Well, quite a lot actually. If you’ve ever been involved in those pre-project discussions with your sales team who have just offered a product to a client which hasn’t yet been designed, then you will know what I’m talking about.

The problem is essentially that you cannot deliver something well (i.e. high quality), both cheaply and quickly. Anyone who promises all three things is either deluding themself (and possibly trying to delude you too), or simply doesn’t understand project management.

Let’s think of a simple project – having a new house built for example. Could this be built cheaply? Sure it could, if you could source the materials second-hand perhaps or maybe retrieve them from a demolition site. You could even try designing and building it yourself to save on labour costs.

Could it be built to a high standard? Of course! You could build it with all the latest bells and whistles, providing you can source the components and there are people competent enough to install them. But delivering to a high standard however doesn’t come cheap. If you really need to keep costs down, you are going to have to cut out all the nice things about the house – the en-suite bathroom, the fitted kitchen etc. And whilst you’re at it, why not just have a single room? That would be much cheaper than that 4 bed house you were dreaming about.

Could it be built quickly? Generally speaking, the smaller the house, the quicker it could be built. But if you really don’t want to compromise on the size, you might be able to build it quickly using pre-fabricated panels built in a factory, but these things don’t come cheap either. You could also have a team of hundreds but it’s always going to take a certain time to complete and just having more people might actually slow things down if they’re getting in each others’ way. Just instructing the trades people to work twice as quick is no good either because they’ll just make lots of mistakes, and the result will be shoddy. A leaky roof or dodgy electrics is not my idea of a high quality build.

So, you can see the problem here. Trying to deliver a high quality product both quickly and cheaply is simply not feasible. Project managers have grappled with this conundrum for years and have created an abstraction to help them understand it. It’s what’s become known as the project triangle.

The three 3 sides of the triangle are scope, cost and time. Every project will have one side (or sometimes 2) which is fixed. For example, the London 2012 Olympic projects had the time side fixed. The side(s) which is fixed cannot be changed no matter what happens. The other sides however have flexibility. For example if you are in danger of delivering late, then a common remedy to get the project back on schedule is to add more staff to the project which of course, will increase the cost side.

So what lessons do we take away here? Well, firstly, ensure there is agreement with your stakeholders about which side of the triangle is fixed. That will help you to understand the areas where there is room to manoeuvre. Secondly, manage their expectations throughout, so that you never over-promise what you are going to deliver. It’s always best to under-promise and then over-deliver at the end. Thirdly, educate your sales staff so that they understand that you can only ever deliver two of the following – good, cheap, fast – from your project.

If you are able to achieve this, then your project has a much better chance of meeting your clients’ needs and should ensure a much less stressful project for all.

What do you think? Do you think it’s possible to deliver all three things on a project?

‘Agile’ or ‘Waterfall’ ?

agile methodology

A few days ago, before the start of a meeting, a couple of developers where discussing ‘Agile’ project management versus the more traditional ‘Waterfall’ project planning.

A ‘Waterfall’ approach, you may recall, is the type of project that flows sequentially from stage to stage, much like a waterfall. It came from, and was heavily influenced by, the Manufacturing industry. The names of the stages vary, but roughly include: Proof-of-concept -> Initiation -> Requirements -> Design -> Implementation -> Testing -> Go Live (& Turn over to Operations). Although it does allow for change requests, it is definitely quite structured in progressing from stage to stage.

The ‘Agile’ approach on the other hand, came into being for software development, which often is non-linear, reactive, and has as an objective to deploy useful items very quickly. In an Agile project, the “product owner” decides which are the highest priority items to be included in the next iteration. The entire big picture, or thorough system requirements, may not be fully known . What is known, is that these high-priority features must be developed now. So the team delivers these items, hopefully with great quality control, and the next iteration is prepared after that.

‘Waterfall man’ was extolling the virtues of arriving at consensus on project scope from the beginning; agreeing timeline and costs; carefully tracking progress, then introducing change requests whose merit had been approved by all. ‘Agile man’, on the other hand, was calling him a dreamer, saying that such a staid and rigid approach was completely last century. That 21st Century projects need to deliver much more quickly than stodgy Waterfall projects could ever manage to.

I’ll have to say that both of these guys were making really valid points. If I am able, as a project manager, to lead stakeholders to consensus on features, priorities, total cost, total timeline, etc, doesn’t that yield a better price/performance project than deploying it ‘piecemeal’? If I have a good, decisive Executive Sponsor, who is able to map the project’s scope to company strategy, won’t that lead me to a successful and relevant implementation?

On the other hand, if my project deploys features before my competition does, and I get more customers as a result of small but important changes, doesn’t that trump the time required for sequential project planning?

Surely there is room for both methods then. If I can lead stakeholders to agree on crisp, prioritized scope items I should use the orderly “Waterfall”; I should deploy a project with the most requirements for the least effort. But if all we know is that there are critical features that must be deployed in the next 3 weeks −or something terrible will happen− then I should organize an Agile “Scrum”. It might be another case of that old saying: the right tool for the right job

Are issues risks?

We all know the difference between an issue and a risk, right? Well, if we’re not clear, let me explain.

Think of an issue is an event which wasn’t planned to occur on your project but it has occurred and now requires management action. One of your project team quitting mid project; your sales director requesting a change to the requirements; a bug in the software which preventing a database being updated correctly are all examples of issues. Each one will need to be resolved one way or another by someone with authority.

When deciding what do to about an issue, it’s important to weigh up the pros and cons of taking a particular action i.e. what will be the benefits versus the costs of taking the action?

A risk on the other hand is an event which hasn’t yet happened. It might happen at some point in the future, or it may not. Risks therefore are about uncertainty. Perhaps there is a risk of your supplier going bankrupt, a risk of your business critical system software not working properly, a risk of you crashing your car on your way home from work.

If the risk event does eventually happen however it will have an impact on the project, usually in terms of cost, time and benefits, but maybe also on scope, quality and other risks. It’s therefore important to try to qualify these impacts before they occur. If your supplier does indeed go bankrupt during your project, you will need to find an alternative supplier which will likely incur additional costs and might well delay the project.

Precisely because risks are uncertain, it’s important to estimate the likelihood of the event to occur i.e. that your supplier will go bankrupt? You will need to make an assessment based upon your understanding of the situation.

Depending upon the likelihood of the event occurring and the impact if it does occur, you can then plan one or more mitigating actions in response. Whichever actions you plan however, must be in proportion to the level of risk. In other words, for risks which have a low impact and medium or low likelihood, you might decide to accept them i.e. do nothing about them.

For risks which have a high impact (let’s say on costs), and medium or high likelihood, you might decide it’s worth spending a reasonable sum to reduce the chances of the risk occurring. If by selecting the cheapest supplier, you run the risk of them going bankrupt, you might decide to choose another (and potentially more expensive) supplier if you consider there is less chance of them going bankrupt.

So can a risk become an issue? Absolutely. Let’s say your supplier did indeed go bankrupt during your project. At that point there is no uncertainty any more. The fact now is that the uncertain event (the risk) has occurred. We didn’t plan for the supplier to go bankrupt but we now need to do something about it. It has now become an issue and a suitable decision will need to be taken by someone with authority.

As you can see, risks can become issues, but they can stay as risks forever if they never actually occur.

Brainstorming risks early on your project, putting in place mitigating actions and tracking these consistently throughout the project are all part and parcel of being a project manager. Keeping track of issues and taking sensible decisions accordingly are also part of the day to day work of the project manager.

What were some of the biggest risks which you had to deal with on your projects? Looking back, could you have dealt with them any better? I’d be happy to hear your stories.

Can You Exit Stage Left?

One of our recent projects involved work to be done on a short, 3-month deadline. According to the project leadership, everything which denoted good project management practices had been performed.

The work was scoped, fine-tuned, and broken down into work packages. The work packages were then assigned resources and budget. Budgets and timeframes were confirmed with the actual performers of the work. Inspections and progress tracking were built into the schedule. Planning went on and on. By all counts, the project should have gone smoothly.

In hindsight, the first sign of trouble should have been the payments. The contractor performing the critical “Stage 1” in month 1, had agreed and signed a contract for milestone payment. Yet he approached management every week with reasons why he needed an advance, or needed management to cover certain expenses. As a sign of goodwill, and given the tight deadlines, management approved the payments. They figured these interim amounts would just be subtracted from the final milestone payment, so all would be well.

Soon, it was quite impossible to correlate invoices with actual progress achieved on the different work items. At the 1-month milestone review, the contractor said items were 90% complete, whereas the customer’s tester rated the progress as much lower.

Management became hugely concerned. Not only was the critical first stage not been finished in month 1, there was no agreement on how much work was actually completed. They decided it was best to pay the contractor for work performed and go with another, more experienced contractor for the remainder of Stage 1. So Management went back to the contract, to see what clause to invoke to terminate this sub-standard contractor.

To their great consternation, the agreement only included termination for breaching the contract, not “termination for convenience”. Otherwise, there was a clause for dispute resolution, which included an outside mediation group. A great battle ensued, where the contractor did not accept they were in breach of the contract. Their position was that they had had a few delays, but would remediate all incomplete items. If not allowed, they would sue Management for the entire value of the contract. The Management team found this stance unacceptable, and hired another contractor to finish Stage 1, since they had time pressures.

To this day, that contractor and that management team are mired in submitting paperwork to the dispute resolution mediators. The contractor claims he is owed the entire value of the contract. The management maintains that those interim payments made to the contractor are equivalent to the incomplete work in Stage 1, and not another cent will be forthcoming. So the inspections, submissions, and document reviews continue with the dispute resolution group.

In summary, include in your contractor agreements a clause on “termination for convenience”, whereby you can pay them for work performed up to a certain point, and then part ways without further explanation. A point may come in the project where you have to be able to -as they say in the performing arts- exit stage left ….

The trouble with sponsors…

Is that often they aren’t too familiar with their responsibilities on projects.

That’s a rather sweeping statement you’re thinking and you’d be right. In my experience, senior executives who have committed to funding the project often don’t have the inclination or the time to learn more about project management. And that’s leaving aside the fact that they are often too busy managing the business anyway to devote much time to your project.

These factors combined often means that the project manager is left without the direction expected from the sponsor.

I remember a conversation with a senior project manager at a UK government department. He was complaining that as soon as parliament closed down for the summer the sponsor jetted off to his villa in Tuscany for 4 months. Not only that, but he refused to leave any contact phone number or contact details with the project manager. So, when issues came up during this period, the project manager was either left waiting for several months, or was forced into taking a decision beyond his authority.

Lack of sponsorship was identified by the Standish Group in their Chaos Report as one of the most important reasons why projects fail. Of course, there are always some projects with active, committed executive sponsors who know that their role is to direct the project and to take the big decisions whilst delegating day to day to the project manager. These projects stand a much higher chance of being successful compared to those with non-committal or absent sponsors.

So what can you do as a project manager to try to avoid this scenario? Well, the truth is, there is no silver bullet.

You could identify the sponsor’s potential lack of involvement as a risk early on and use this as an opportunity to discuss with the sponsor the expected level of involvement. Crucially, it will be about agreeing when key decisions need to be taken by the sponsor and trying to ensure their availability at these times.

You could try to educate them about their responsibilities on the project, but don’t expect that they will want to sit through a training course however.

More fundamentally, if you find your sponsor going AWOL shortly after committing the project budget, then this is a sure sign that your project is on the road to failure.