Search This Blog

Saturday, June 30, 2012

Other People's Money: Managing Project Budgets Effectively

[Also available as a podcast]

Other People's Money. 

(Image source: Wikipedia)
When you mention these words, some people might think of stock markets, mutual funds, and the 1991 movie by the same name starring Danny DeVito, in which he played a ruthless corporate raider, leading hostile takeovers of other companies using everyone's money but his own. You might then think about recent history and failed banks, brokerage firms and the millions of affected people when their retirement investments shrank or fell to near zero and countless people lost their homes.

Scary, scary stuff.

Well, let's step back from the big scary picture out there. Back to the reality of your project, where you are "in charge". All of that scary stuff does not really apply to you, does it?

Well, unless you have zero control over your project (and you are just watching from the sidelines and not doing your job), it does apply to you. Unless you are Richard Branson or Bill Gates, you are probably not bankrolling this project from your own pocket.

Your entire project is funded by Other People's Money. This may be customer money, corporate internal project money, or the collected money from the bake sale last month.

The Bad News? You are the steward and caretaker of Other People's Money, entrusted to deliver the project outcomes successfully - within scope, on time, and of course - on or under budget.

The Good News? You are the steward and caretaker of Other People's Money, entrusted to deliver the project outcomes successfully - within scope, on time, and of course - on or under budget.

The Good News and the Bad News

How can this be both good and bad news? Well, if things go sour and you did not manage scope, effort and budget effectively - there will be wastage and you will likely run out of money before the project is finished. You are accountable, it will be "your fault".

The good news is that unless you are hamstrung in managing your projects by sneak-around requests to the CEO that end up blowing out scope (but with no increase in budget), you are in charge. And even in that scenario, if you manage it effectively and are able to handle the change requests for increased budget, you are still "in control".

Well at least the common perception is that you are in control - you have the authority to manage the resources and activities on your project. And often, that is all you really need - formal or informal authority discussions aside.

You might have full disclosure of the internal cost and external billing rates for every one of your team members, or you may only know the overall billing rate to the client. Or if this is an internal project, you may only know the hours budgeted and not hourly rates.

But you can still work with the information you have.

Creating the Budget: Estimating

Depending when you got involved with the project, you may have been involved with the estimating & budgeting process, or the overall budget may just be handed over to you. But if you are helping to define the project budget, read on:

There are many models for estimating in different industries, so I won't go over any detailed specifics of what the best estimate is for service X in scenario Y. These are things that will have many contributing factors based on your industry, the environment, delivery schedule and so on.

But in general - you should plan for a few surprises. Build in a "buffer" or a reserve, that can only be tapped if needed. In some industries, a 10% buffer is recommended. In a low-risk project environment, 5% may be enough. But if there is a high level of risk and uncertainty, you may want a reserve buffer as high as 30% or more of what your overall estimate is "to get the job done".

Note that the Project Manager may also build in a (much) smaller buffer for resource flexibility - perhaps earmark an additional resource that might be needed for a portion of the project, for example.

There are different methods on how you can do this. You may build it into the overall budget itself, or you can work with the client to have them secure separate funding in that amount, that can only be drawn against by formal request of the Change Control Board.

There are pros and cons to both approaches; if it is within the actual budgeted PO for you to manage, you have more flexibility in managing and juggling funds within the project, without a lot of red tape. Of course, then you have to also make sure that you track very carefully and don't "touch" those funds without joint agreement with the customer. From the customer's perspective, if all of the funds, including the buffer, are "accessible" and under the same PO, then they might realistically feel that the money will be spent - and that someone will find a reason to spend it.

If, on the other hand, it is really "emergency money" and the customer retains it in their coffers, doling out small PO's for clusters of change requests, they may feel more secure that any un-spent money can be saved for a rainy day and other projects after this one. This will add more overhead to the process, but it is an equally justifiable approach.

It is a matter of trust, on both sides as to who "holds the buffer", or at least, the potential to get at it most easily. 

You need to look at it from both levels - the PM needs a bit of flexibility in juggling hours and adapting to events without appealing to the Change Control Board, but the really big stuff should go through the CCB.

On one of my projects, I included a few extra weeks of training that were likely to be needed but might not, depending how things went - so those training days served as a small internal pool of hours that we were able to use for other things near the end of the project when it turned out the training was not needed.

Managing the Budget

Well, now you have your budget. Your overall pool of hours, resources, equipment costs, all to be managed. The budget may be based on a detailed project plan, but more likely it will be based on an RFP response which used high level estimates of what type of work needs to be done. You then need to flesh out your Project Plan - and Resource Plan - based on what actually needs to be done and when, under your ceiling of hours.

This will involve a lot of juggling on your part, working with your team leads to make sure that you have enough, but not too many resources on any particular set of tasks at any point in the project. If it sounds like a lot of work, it is - but quite essential. This is why you are the Project Manager, after all.

Of course, things are constantly changing - and the larger your project (and budget), the more things there are going on, and the greater likelihood of surprises. So you need to keep on top of the budget, the resource plan and what is coming up next. There may be delays which mean that you don't need resource X on the project until June 20 instead of May 30, so you had better make those changes quickly or you will end up burning hours while they cool their heels waiting for work to do.

You should be reviewing your budget and resource planning regularly - at least monthly, but also be aware of what is going on day-to-day in your project. Something might come up in the status meeting or be brought to your attention that requires an immediate adjustment to plan (and resources or equipment) that cannot wait for the monthly budget review. You may need to add or trim hours on an ongoing basis.

Ah, the life of the Project Manager!

Budget vs Actuals vs Forecast

On one of my projects, there were seven different resource cost and billing rates for the different types of resources utilized on the project (people, not equipment). One of the challenges I faced early on in the project was trying to get a good handle of where we actually were in terms of tracking to budget, in the midst of a lot of changes.

Of course, we had the invoice history and the details from Finance - monthly, but that was not quite enough for managing a fast-paced project. Also, with the variable billing rates of the different resources we had on-and-off-site (with different rates for on and off-site, so 14 billing rates), we had to be able to forecast in great detail, while also reconciling the actuals for auditing purposes.

Note: since that project, the company decided to go to a universal billing rate, regardless of the skill level. The only variations now are on-and-offsite rates. Almost too simple!

Previously on other projects, the PMs were tracking actual $ and forecasting hours - but this left a lot of room for error due to the multiple billing rate model. Then there were the inevitable credits issued to the customer that had to be accounted for too.

So I combined the actuals and forecasting data into one complex spreadsheet, where we reviewed the actuals and managed the forecast with the client on a monthly basis, and during the meeting we were able to immediately view the net$ impact of tweaking the different classes of resource assignments, down to the penny. As actuals came in, these replaced the forecast amounts, and we could also see the variance of the actuals vs forecast by resource and month, all in one place. We were then able to easily adjust going forward, where last month was 6 days under-spent on resource X but two days over on resource Y, and so on.

This gave the customer a great deal of confidence in the overall management of the project, and also gave them input to the resource adjustments for the upcoming months. As this was a 3-year, $5M project, having forecasting capability to that level of detail was extremely helpful, and the monthly budget meetings proved sufficient to avoid any real surprises.

And in the end - we delivered the project successfully, and under budget.

Managing Expenses: I've Got A Coupon For That!


On most projects, the expenses were relatively predictable. Airfare, Hotel, Car, Meals (no alcohol). We carpooled based on the number of resources in town at any point in time, stayed at the project hotel, and the airfares were pretty predictable. Meals were capped at $45USD per day, total.

From a budgeting/forecasting perspective, there was not a huge degree of variance.

Except for one person who I met on that project, and have worked with closely for many years since (and is also a good friend).

He was not wasteful, far from it. He does not drink (well, water and soft drinks, yes). And with a limit of $45/day, you could not really go too far astray - any excess was from your own pocket. He was also extremely generous to a fault, bringing in chocolate to the office on a regular basis.

But only when it was on sale or he had a coupon.

Yes, he was generous - but extremely frugal with his money, and especially Other People's Money. Even though we were on expenses, he took it as a personal challenge to save the project money. Not just him, but the group of us!

He scoured the papers for coupons, bought the Entertainment Coupon Book, and when he ate out, it was almost always a place he had a coupon for. And he never ate alone. He was great company to be with, but the other reason was that most of the coupons were 2-for-1. Of course, he also shared the coupons with us in case we were not dining with him that day.

He came into the office one morning beaming from ear to ear.  He had just bought a pen from CVS the day before. He had a CVS cash-back voucher, a coupon and a rebate for the pen that he could use together. Including the price of the envelope and the stamp for sending in the rebate, they were paying him $0.55 to take that $3.50 pen home. Now that is effective fiscal management!

When we had completed the main project deliverables and I returned to the head office (still doing some remote PM for the customer), we were able to keep him on-site for a good portion of the following year, based on the budgeted funds that were left over. We joked with him that his Coupon-clipping had "saved him into a year's employment". A bit of an exaggeration, but not much. He definitely contributed to the overall project ethos of "eat well but save money" that did end up saving us a lot of money for the project - and it was fun, too.

Summary

Fiscal accountability is what it is all about - being a conscientous steward of Other People's Money on your project. I am not saying there will not be some wastage, there always is some time or material that is not used quite as effectively as it could be. But if you keep in mind that the funds from your project are the result of someone else's hard-saved or hard-earned efforts, you will be able to keep the big picture in your head a bit more clearly.

It is not about spending the entire budget, reaching your corporate fiscal targets this quarter, or looking at it as a steady paycheck for a period of time. It is about doing things right - to the best of your ability, and respecting the investment they have in you - to invest their money wisely in the delivery of the project.

Good luck with your projects, manage those project budgets wisely, and when you next eat out, there might just be a coupon for that!

And as for me? I am going out to have a coffee with my wife (2-for-1 card).


Cheers!



Wednesday, June 27, 2012

Implementing Organizational Change? Learn How to Grow a Desert

[Also available as a podcast] [YouTube webinar]

All projects are change projects. That is the nature of projects – to create something new, to improve processes or to introduce something new into the business – and all of this requires people to adapt to the change. To better learn how to approach change - especially organizational change, we need to take a trip to a place that seems timeless, but is constantly changing.


White Sands, New Mexico - home to the largest gypsum dune field in the world, covering 275 square miles (712 sq km).



The glistening dunes of the White Sands desert are one of the wonders of the world, rising from the Tularosa basin on the eastern edge of the San Andres mountain range. Every year they slowly advance eastward across the Tularosa basin towards Alamogordo.

Gypsum sand is not a "normal" sand. Usually a desert like this would not even exist - gypsum is highly soluble and usually washes out of the hills and works its way down to the sea through streams and rivers.

In fact, the Tularosa basin used to be part of an inland sea, created by a massive rift when the continental plates pulled apart - but now it is a land-locked desert basin. It is part of the Chihuahuan Desert, seeing only a few inches of rain a year with no rivers to carry moisture (or gypsum) away.

The desert basin is also very flat - really flat, as only the bottom of an old sea or lake can be. When driving up to White Sands from El Paso, I literally drove in a straight line at 70mph/113kph (yes the speed limit) for an hour or more. And it felt like I was crawling.

The White Sands dune field is a good model for looking at Organizational change - progress can often be slow and steady, with occasional bursts of movement. From a distance, change may not even be apparent at all over short periods of time. And with the "wrong" environmental factors, progress can be literally washed away. But with persistence and the right change agents working together, you can move mountains.

Recipe for Change: Growing a Desert, Step-by-Step

Interestingly enough, you need the some of the same basic ingredients to grow a gypsum desert as you do to grow plants.
  • Minerals
  • Water
  • Sunlight
  • Air


When you want to grow a plant, you need the seed and (1) minerals [in soil], (2) water, (3) sunlight, (4) air, all in balance. Too much (or too little) of any one of these four, and your seedling will die.

In the case of growing a gypsum desert, you need (1) the mineral gypsum - from the surrounding mountain ranges, and (2) water, (3) sunlight and (4) air - specifically, wind. You need some energy, a push to get things moving. Too much (or too little) of any one of these four, and you will not have your gypsum desert.
  • Too little water, and the gypsum won't dissolve out of the mountains
  • Too much water, and the gypsum will stay in solution in the lake water
  • Too little sun, and you can't precipitate the salts out of the water (less evaporation)
  • Too little wind, and you have no crystal erosion or movement of sand
  • Too much wind - and it all blows away!
There is of course one major difference between a desert and an organization. You would never ask a grain of sand if it wanted to be part of a sand dune. It is just part of being a grain of sand to be part of a beach or a dune - it is in its nature. All it takes is a bit of wind or wave action, and it moves.

However, in an organization, you have people, not sand - and people can provide disproportionate levels of resistance to change relative to their "size". It is just part of being a person - it is in our nature to resist change.

When planning for and implementing organizational change, you need to start with these basic ingredients:

  • Vision of the future
  • Reason for the change (why "there" will be better than "here")
  • Change Agents (people who buy-in and help introduce the change)
  • Energy and determination to persevere

Moving the Mountain

People simply don’t like change. If things are going along “well enough”, people will generally not want to change – they will stick with their ingrained habits and procedures. And not only will they not want to change – they will, either actively or passively, resist it. They want to remain part of the mountain.

We need to help start them on the journey to change. And it won't be a smooth road either - there will be stops and starts along the way.

Just Add Water


Infrequent seasonal rains dissolve gypsum from the light stratus layers in the mountains, bringing it to the low point near Lake Lucero. 



In projects, you need to prepare for change by looking at the current state and the desired future state. You also need to look at the organizational culture to see what approaches may or may not work, and look at what has worked in the past.

Generally, a "hit them hard and fast" approach never turns out well in the long term. If things have been pretty stable for a long time, you need to take a softer approach to start - you need to assess the lay of the land carefully, test the waters, talk to people in the different areas where you are trying to effect the change.

You will likely only find a few people that welcome change with open arms – these are the early adopters, and they can prove to be your greatest advocates. Ideally, you will be able to identify and bring advocates on board from each of the to-be-affected areas of the organization.


Then, you begin to craft your message. Your Communication Plan is a key component of any change management strategy, and can literally be the make-or-break factor for your project change efforts. Take the time to invest effort in it, and invest your efforts wisely. The form and size of the communication plan and your change management team (including the advocates) will vary depending upon the scale and strategic importance of your project.

I would even suggest creating a storyboard - laying out the overall message for what we are changing, why the change is needed, and setup a progressive strategy for different levels of detail in the messages for the different audiences as you go forward.

You may not be permitted a lot of time to invest in your change management plan up front before you have to start communicating to the end users. However, it is important to layout the overall strategy, with plans to adapt when things don't quite turn out the way you hoped. Design the initial communications in detail - with the big picture sketched out, to be filled in as you go.

Once you have crafted your initial messages, use your advocates and the appropriate communication channels to spread the word, to soften up people's attitudes and begin to dissolve initial resistance, like gypsum in rain water.

Turning up the Heat

Once in the lake and alkali flats, sunlight begins to evaporate the gypsum-rich water, forming columns of the soft crystal Selenite.



 Ok, so you have things started - the initial messages are out and circulating with your end user "audience".

"That's interesting" they say.

You got them loosened up a bit, noses above the cubicle walls, but then they settle back and go back to doing things the way they always did.

Almost.  They are not exactly as they were before - you moved them a bit, but without any further actions from you, they will simply go back to their old ways - re-crystalizing where they now stand.

Believe it or not, this is not a bad thing - you have at least got them used to the idea of change. And it didn't hurt too bad yet, did it?

But this is not quite good enough yet - we need to put a bit more pressure on, turn the heat up, and put some more effort and energy into the process.

Shaken, Not Stirred


As the lake dries up further, wind and friction from other gypsum chunks break the crystal columns apart, bashing the pieces together over and over again until they break down to the size of a grain of sand.

For most people there has to be a compelling need in order to adopt change – and this can either be to improve from a very negative condition, or to adopt something new that will make things much easier for them. And even in these cases, they will not embrace change with open arms – there will still be doubts and uncertainty. (The devil you know vs the devil you don't)

We need to introduce a bit of discomfort. (Humanely, of course). Oh, and some Hope too.

We need to shake things up!

If we truly want the change to be effective, we need to have people wanting to change. We can't actually make them change. They have to do it themselves. And the only way to do this is to make the future state look and be much more appealing than the current state. (The "carrot".)

We need to crank up the communications and story-writing (truthfully of course), painting pictures of how things will be better with [the new system, product, process, whatever].

"That's nice," they say "but I like it the way it is now. Sounds ok, but I'm not changing."

We also need to carefully and selectively apply the "stick" to help move things in the right direction. You need to make it clear that it will be quite uncomfortable to remain "as is" - perhaps the system is being replaced and decommissioned, so the old one can't be used anymore. Or perhaps the job descriptions are changing and you need to "tool up" if you want to remain employed. There are less drastic scenarios in the middle ground as well - but the point is, you want them to move. If they are nice and cozy right where they are - most people will simply not adopt the change, and you will languish as your project sputters out and eventually fails.

Again - use your advocates at the grass roots to help manage the change and have their ears and eyes monitoring the mood and reaction with their peers; you need a feedback loop to the project team. However, the main push for this phase needs to have official, higher level support and enforcement.

Build Momentum


When the wind reaches approximately 20pmh/32kph, it is strong enough to blow the individual grains eastward into the dunes, one grain at a time.


Ok, now you have people starting to go your way - the masses are starting to move. Slowly at first, but the momentum starts to build.

Don't give up on your efforts now, though - you need to keep the communications and monitoring efforts going, to make sure that progress is being made. If you let it lapse, the wind will die down and you will stop making forward progress.

And don't forget to publicize any successes and milestone achievements along the way ("1,000th PC upgraded/user migrated, etc), as this will also help keep up the forward momentum.

Success promotes success!

Handling Resistance

Some resistance is inevitable, but unless it is a big enough obstacle, it should not impede the overall progress of your efforts - if you are prepared, that is!

Resistors - You can’t avoid them; there will always be at least one, so you had better be prepared. There are three types of resistance –passive, active, and subversive.

  • Passive Resistors: These are by nature the hardest to spot. They will quietly resist your efforts, but it is unlikely that they will spread the word very far. You need to remember they are there, but don’t need to put much effort into handling them for the most part. It is likely that they will gradually become “reluctant adopters” and then “users” as their peers gradually adopt around them.
  • Active Dissenters: These people can seem to be your biggest headache. They are generally quite outspoken, even more than the advocates. Their tirades can bring many of the “undecided” over to their side of non-adoption, so you can end up with a steep slope to climb. The trick is to identify them early – and bring them into the fold. (Keep your friends close and your enemies closer – Sun-tzu). Yes, bring them onto the Project Team. Not only that – give them a job to do, and listen to their input.

    Many dissenters are simply people seeking to have their opinion valued – and if you can manage to “convert them” to the project’s goals while also demonstrating that you value their opinion, you can end up with some of your most influential advocates. At worst, if you are keeping close tabs on them, as part of the team they are less likely to be destructive as it will reflect badly on them too.

    So they won’t join “the dark side” of the project team? Still keep a watchful eye on them, and try to involve them. Don’t give up – you may still be able to bring them in line with the project.
  • Subversives: These are the ones that smile to your face and talk behind your back (or stab you in the back). We had one of these on one of my projects – he had built a "side" system that was to be decommissioned, and simply did not want to let it go.

    Even though there was a company-wide edict from the CEO to adopt the new system and close down the “old” internal one, he went around behind and whispered into key ears, which ended up interfering with the adoption of the new system in multiple locations. Not completely, but there were complications that delayed buy-in. 

    Sometimes it’s simply down to
    who you know, not what you know. Be careful of the subversives! You may not be able to diffuse them, but you can’t ignore them either. You will need to figure out ways to counter their back-door rebellion – likely on an ongoing basis, unfortunately.
Don't make the mistake of ignoring your resistors - they can quite easily hamstring your project and bring things to a complete halt.

In the worst-case scenario, they can set you back quite a bit in both progress and credibility as they undermine what you are trying to achieve. In White Sands, the equivalent would be a heavy downpour dissolving large quantities of gypsum sand, erasing progress and shrinking the dunes.

The Tipping Point

The wind lifts and rolls the individual grains up the windward side of the dune, until they collect at the crest. The gypsum sand grains build up into a sharp edge or overhang until gravity pulls them down the leeward face, moving the dune slowly forward, inch by inch. (Sometimes a helping boot may give it a little nudge, moving the dune forward just that small fraction faster).

And there we have it - progress may have seemed slow, always uphill - but eventually, we reach a critical mass on the path to change, and it eventually becomes self-sustaining; we have reached the point of collective buy-in.

Well, at least for the first key group of users, but the others are not far behind, and will be soon coming over the crest, a group at a time.

Again - don't stop your change management and communication efforts just yet - you still need to keep the message going, and advertise success stories.

But at this stage - you are not having to work quite as hard. The masses are moving together, following the advocates and their "peer leaders". All you need from the project team is the occasional "nudge of a boot" on the crest if gravity "seems a little slow taking over", and regular monitoring to make sure that things remain on track.



And then, suddenly we are there! It may have been a long process and a lot of effort, but you have grown your own desert. Well, implemented the organizational change you needed for your project, anyway.


 Congratulations!

Summary


Growing a desert has many parallels with driving cultural or organizational change on your projects. In fact, when trying to implement organizational change, you might feel like you are stranded out alone in the desert all by yourself.

But with the right conditions, the right ingredients, and energy/effort applied in the right places at the right points, you can literally move mountains.

And on a side note -  when you look really close, the desert is not a barren place at all. It is full of life - and hope.



Good luck with your projects and implementing change!

Friday, June 22, 2012

Developing Exceptional Requirements: Lessons Learned from Ice Cream and the Spice Girls

[Also available as a podcast]

One of the things I looked forward to most on my business trips from Canada to New Zealand was a little town called Pokeno, south of Auckland on the edge of the Bombay hills.

Pokeno is famous for two things: Bacon and Ice Cream, most definitely not in that order. Pokeno used to be right on SH1, and everyone travelling to or from Auckland and the Waikato went through it - right beside the butcher and two of the busiest ice cream stores you have ever seen, summer or winter. And even though these ice cream shops are literally side by side, neither of them suffers in the least. Today, even though the SH1 is a newer road bypassing Pokeno, it is still as busy as ever, with people making sure to take the off-ramp into the little town.

There is nothing special about the ice cream itself - you get the same brands in the grocery store. Nothing special about the service either - and you only get the one tiny napkin wrapped around the cone, and no spares on the counter.

What made Pokeno famous - and still does today - is that they have the cheapest, largest scoops in the country. And 42 flavours to choose from! Not only that - you can have up to 11 scoops at once (on one double cone base) - for only $8. I am not kidding. It would be literally about a foot high at least, above the cone. I haven't tried it myself, as 2 scoops is plenty for me, but you can be sure my kids have been sizing it up as a worthy challenge.


These are by no means tiny scoops either - in Canada and the US you generally get a modest scoop most places you go, except perhaps the "premium" shops, with premium prices. Here you get good, honest scoops, twice as wide as the cone itself - for once, actually bigger than the pictures suggest.

I am getting hungry just writing about it!

Anyway, this article is about writing Excellent Requirements - and yes, it does relate to the Ice Cream. One of the challenges in Pokeno is there is a lot of choice - 42 flavours, 11 configurations (1 to 11 scoops at once). That is a lot to wrap your head around, and don't forget the Sundaes.

We have similar issues with eliciting and documenting requirements on projects - we need to get down to the details of what is exactly needed by the customer. When everything is shiny and new, sometimes customers simply want it all...and sometimes they kind of know what they want but can't commit to a specific choice and option.

Chocolate, Dutch Chocolate, Dark Chocolate or Triple Chocolate Chip?

Cookies and Cream, Gold Rush, Peppermint or Goodie Goodie?

Wait, let me look at the other 34 flavours first...

And which one goes best next to Liquorice?

It is so hard to choose...we need some help!

What we need is...a good Requirements Definition Process.

Tell Me What You Want, What You Really, Really Want

I have to admit, The Spice Girls nailed the key elements of a very successful Requirements methodology with their lyrics "Tell me what you want, what you really, really want". 

Well, maybe not the whole song - perhaps just the chorus.

But it is definitely about Requirements - and we do have some lessons to learn from them.

Project scope, RFP, user needs, specifications... these all are variations of customer requirements. We definitely need them, so that we know what we are supposed to deliver. But when do we know we have enough requirements? How do we determine that there is sufficient level of detail before the requirements get signed off?


We need  to get into the details - and in the most effective, efficient way possible.

A successful Requirements gathering methodology involves three main steps, that progress from higher to lower levels of detail.

Tell Me ...



Generally it is sufficient to kickoff off your project with very high level requirements, so that everyone has a common "big picture" understanding of what it is we are trying to achieve. However, once you actually start the work of the project, these requirements must be refined into finer and finer levels of detail.

I want Ice Cream! Lots of Ice Cream!

Part of the project planning should include tasks and the associated investment of time and effort into the requirements refinement so that the project deliverables can actually be designed, developed and delivered. Not only that, but the delivered items should match the business need. So hopefully we can collectively nail down the requirements clearly enough with the customer that when we do develop exactly to spec, it is exactly what they asked for - and is what they actually want.

You look at the board, the size combinations, and realize that you might not be able to eat 42 scoops at once. Maybe not even 11.

I need to think about this a bit...

...What You Want...



I think we have all had the experience of delivering something to a customer (hopefully on-time and budget) and having them say "yes, I know it is what I asked for and you delivered it to spec, but it's not what I wanted!"


So the solution is apparently simple then - just find out what they want, document it, and then deliver it!

Boy that Ice Cream looks good. I like this flavour, and this flavour and this flavour - and...oh wow! I haven't had that since I was a kid, better get that one too...


...And yet here is where we run into some major stumbling blocks that have to do with Communication and Expectations, seemingly no matter how hard we try. The key issues generally are:

1. They think you know what they want, in great detail... from the vague outlines in the Project Charter, RFP or High Level  Requirements. Oh, plus the word picture they gave you months ago while standing in line for coffee at Starbucks. You must understand what they need from that! They certainly described it to you well enough...right?

2. They think they know what they want... but sometimes they don't - at least, not in full. This happens more often than they will admit.

3. They don't know what they want. At least, not yet. This happens often - and especially when a customer is migrating to a new system. They know how the old system worked, they know what they could produce from it - and they don't yet have a full understanding of how the new system functions or what it can do.

4. We don't know what they want. It is generally safe (and wise) to approach the project with the attitude that you don't know exactly what the customer wants, at least, not in detail - so approach it with open eyes, ears and mind, asking questions.

5. We don't know what we don't know. It is inevitable that even with a rigorous requirements collection model, things will be missed. People may forget to bring them up until later, not on purpose of course, but because they forgot.....or sometimes, we just don't have enough information yet and it is truly an "aha" moment brought to the table later on.


Ok, so I think I can handle three scoops, or maybe just two. They look pretty big. 



Getting Down to Brass Tacks


We need to break the bonds of assumptions and pre-conceptions of "this is how we used to do it" and get down to what it is they want - in words that both the customer and you can uderstand - and hopefully agree on the same meanings for the same words.

Gather as much detail as you can at this stage - and WRITE IT DOWN!  If possible, collect samples, photos, screen shots, diagrams, anything that will help remove ambiguity from the requirements. A picture may be worth a thousand words, but a screen shot or report sample definitely does not cut it on its own - there is an iceberg worth of business logic detail hidden beneath that small sample.

So, we sit down with the customer, talk to a few people, write things down and thereby "document the requirements". Many people stop here, shake hands all around, get the specs signed off and get ready to start designing and building. Mission accomplished!

Well, not quite. In order to make sure we have covered the bases, we need to validate the assumptions around the requirements to make sure nothing was missed - before signoff.

We need to check and ensure that what they have asked for, and what they have documented as "what they want" is also what they need.

I have five favourite flavours, now I just need to choose which ones for today's masterpiece...
 

...What You Really, Really Want!



In my experience it is often the case that the users or persons responsible for writing the requirements (either with or without you) know what they want, but they don't always know what the end users need. But they think they do - and therefore, so do you.

"What's that?" you say. "Of course they know what they need. They are writing the requirements so what they write simply ARE the requirements. What they want is what they need."

Well yes...and sometimes no. As thousands upon thousands of Change Requests every year around the globe will attest.

Sometimes they have difficulty articulating their actual needs. Sometimes the language they use relates to how things were done in the past and do not translate well into the new environment. Sometimes the customer's language is not your language, (project or domain-speak) and there are misunderstandings. The words on the page may read exactly as the customer believes it should be - but the vendor interprets them differently. So a "read-back" review of the requirements with both parties is an excellent idea - it helps ensure that the words on the page are interpreted the same way.

And quite often, they simply forget to write things down because of the embedded culture...meaning "well, everybody knows about that part because it is just they way it is around here" ... and things get missed - especially if you as the vendor/contractor are not part of their culture.

In our Ice Cream example, everyone assumes that you actually want Ice Cream. Who doesn't? Well, if you are Lactose intolerant, you might buy some dairy-free sherbet, or just go next door and buy some Bacon. (The good news? Yes they have Sherbet too! No Gelato, sorry.)

The truth and your project salvation lies in the questions...lots of questions. And without those questions we are often lost in translation.

"What they want" is not the end game. "What they Really Really Want" when you dig deeper is more representative of what they actually need. Sometimes you may find that these indeed are one and the same thing - and the customer does have an excellent grasp on what they need, and articulate it well. And sometimes, that little bit of digging deeper will save  thousands of dollars or hours of rework (whether or not it is a paid change request, it is still better to be able to meet the need the first time).

"There is never time to do it right the first time, but there is always time to do it again." - Unknown

If you dig deeper and challenge the customer's initial presentation of the requirements, especially as they are translated into the new system, you have the opportunity to make sure that you have been thorough. However, you also have the opportunity and responsibility to identify better or more efficient ways of satisfying the need, while still staying in budget etc.
Which type of chocolate scoop do you want? Chocolate, Dutch Chocolate, Triple Chocolate Swirl?

If you can do this and do this well, you will also gain a reputation for someone (or a firm) who are good at getting to know what their customers need, and can deliver. Now, what customer would not jump at that? Word-of-mouth referral is a powerful tool.

"It takes less time to do a thing right, than it does to explain why you did it wrong."  ~Henry Wadsworth Longfellow

Sometimes those "missed requirements" are small omissions with small change requests, but sometimes they are big ones.

You can't un-scoop an Ice Cream if you changed your mind.

The Cost of Requirements Change


We have all heard about how the cost of change increases significantly the further you are along the path of delivery. If the unit of effort to make a change to the requirements is (1) at requirements stage to accommodate a change, then in design it increases to (2-5X), in development it jumps up (to say, 10-20X) and once delivered it increases again to (100X+). Or perhaps a different scale may apply in your business, but you get the idea.


With one of our recent clients, there was a piece of custom programming work that went through a formal requirements process, reviews, signoff, development, delivery, testing...it was on the verge of acceptance when one of the end users identified that they did not want whole numbers (Integers) on the report output, they were supposed to be decimal (xx.xx) numbers in a particular type of result.

 In most situations, this would be a relatively minor change. However, in this case, due to the complexity of the overall report code, and the specific and unique solution developed to accomplish what was required, this was not a simple change. In fact, in this case it was a HUGE architectural change that required a full redesign of the report and the coding logic.

The solution to satisfy the new requirements ended up being even more complex than the original.

This might be a 1 in 10,000 case, but in this specific scenario, if the original estimate was (X), the cost of the rework was actually (X*1.1), so the TOTAL cost of the custom report ended up being (X*2.1), or 210% of the original estimate.

When you change your mind about flavour after you have started eating or have finished the cone, you need to buy a whole new cone...you are not just asking for a few sprinkles on top.

An extreme case perhaps - but still true. Missing the fact that they needed the decimal places vs integers at the outset was an acknowledged requirements failure by the customer, but it was still a very expensive mistake.


So, Ask The Questions...

It is incumbent upon the project manager to ensure that all of the right questions get asked ... Lots and lots of them... And the earlier in the project the better.

How many scoops? (So they choose the right base)

It is through the interactive dialog that great requirements can be elicited and documented. The better you are at asking the questions and understanding the big picture and the detail level, the better your requirements will be. This has the benefits of:
- Better estimating process
- Better initial quality
- Less rework / waste
- Lower overall cost (time, effort, $)
- Delivering what the customer needs
- Better reputation for insight and delivery

Ice-Cream? Sherbet? Which flavours? ...And FYI the Bacon is next door.

...And Remember to Actually Read And Use the Requirements!

When you have the requirements, good ones or exceptional ones, you can still fall flat on your face. When you are executing (designing, developing, building), make sure to read, re-read and read the requirements again. And before you say you are ready to deliver to the customer, re-check the requirements to make sure you have done it right, to the specs.

And if you come across something that looks odd or not quite right, or incomplete - raise the red flag and ask questions. Clarify the requirements with the customer. There may be a question of interpretation , there may be a clarification needed, or there may actually be a Change Request needed, if the requirements don't accurately match the need based on current information. 

Remember, the cost of making the changes to your project deliverable get increasingly higher the longer you wait - so after you have re-read and you are still not sure - ask the questions as soon as possible - and if a Change Request is needed, better to catch that in Design than Development, better in Development than in Testing, and better in Testing than in Production.

Summary

"Good" requirements analysis and documentation is often not good enough. You need to go that extra step to validate that what they are asking for is actually what they need. So work closely with the customer, and follow the three-step process towards developing Excellent Requirements.

1. Tell Me
2. What You Want
3. What You Really, Really Want!

Don't stop at #2.Too many people do.

And once you have those artfully crafted Requirements, make sure to follow through with a flawless delivery - checking against the requirements, and also looking out for when "what they ask for" might not be "what they need".



Today, I am going to have two scoops, Dutch Chocolate and Orange Chocolate Chip. Next time, I may choose the Mint Chocolate Chip and Rocky Road. Now that I actually live in New Zealand, Pokeno is not that far away!

Decisions, decisions!

Good luck with your projects, and keep an eye on those Requirements!

Sunday, June 17, 2012

Everything I Need To Know About Risk Management I Learned From My Pocket Umbrella

[Also available as a podcast] [YouTube]

January 6, 1991: Standing on top of Ayers Rock (Uluru), Northern Territory, Australia. 
45C/113F and a cloudless, brilliant sunny sky. Humidity? near zero.




One of the driest, hottest places on earth.

So why am I carrying my pocket umbrella in my backpack?

And what does this have to do with Risk Management?

Interesting question!

To answer that we need to go back a few years earlier - and to a much wetter climate.

A Basic Lesson in Risk Management

Vancouver, BC, Canada - the "Wet Coast". 
Growing up in Vancouver you get used to rain. Lots of it - or at least long periods of drizzle especially in winter. (In Vancouver they can take a good NZ afternoon downpour and spread that out over three weeks of solid gray sky and liquid sunshine. One joke goes like this: "If you can see Mount Baker, it is going to rain. If you can't, it is already raining."  And another one - "They don't tan in Vancouver - they rust.")

Exaggerating a bit of course, but you get the idea. Wet. And not only that - you expect it, and plan for it.

Everyone has an umbrella (or three or four) and a rain jacket. One umbrella for the car, one for the office, one or two for home, and some spares for guests that might come by. Why? Well for the rain, of course - or at least the very high likelihood of rain, especially in the cooler months.

From the time I was in High School and taking the bus (or walking on a fine day), I carried a small umbrella in the bottom of my backpack.

It did not rain every day, of course - but I always carried the umbrella with me. It was perhaps my first practical exposure to Risk Management Planning. Knowing the region and the climate, there was a decent likelihood that on any given day I would need to keep my head - and especially my textbooks - dry from all that liquid sunshine. 

Remember the book "All I Really Need to Know I Learned in Kindergarten" by Robert Fulghum?  

My parallel to this might be called "Everything I Need To Know About Risk Management I Learned From My Pocket Umbrella."

Silliness, you say. How can you learn anything from an umbrella?

Essential Components of Risk

Risk - especially in the context of a project, is sometimes misunderstood, sometimes feared, and sometimes given no more than a sideways glance as everyone just wants to "get on with it" and start working on the project and produce the deliverables everyone is expecting. On the other end of the scale, Risk Management may become an all-consuming task that sucks the life out of your project as everyone is consumed by the worry of what might happen.

So what is a Risk - vs an Issue?

An Issue is a definite item that will pose some challenges or problems for your project. You are going to have to address it, or choose to ignore it - but it is not a "maybe" - the item is there, in your face- either right now, or at a known stage of your project.

Risk relates to an event that might happen at some time on your project. This Risk can be broken down into the following components:

- What may happen (the Risk Event)
- When is it likely to happen (timeframe: during a specific stage of the project, or at any time)
- What is the likelihood (probability) of it happening (High/Medium/Low)
- What is likely to be the outcome (the Impact) of the Risk Event should it occur (High/Medium/Low)
- What factors might precipitate or contribute to the event

These are just the basic concepts - in your Risk Management Planning you will indeed include all of the above, as well as what you might be able to do about it - to try to prevent it happening (Risk Avoidance/Pre-Event Risk Mitigation), or if it does happen, what you can do to lessen any negative impacts (Post-Event Risk Mitigation/Risk Response).

The trick with Risk Management is doing a thorough enough job to make sure that you are aware of what might happen to impact your project - and to have plans in place to monitor the potential risk conditions and respond in the event it occurs. You don't want to take the "hope and pray" approach, hoping risk will pass you by - but you don't want all of your resources tied up in an exhaustive Risk Management approach that takes on a life of its own and detracts from your project. 

You need to take a practical approach to Risk Management. Look at what is "out there", and do a realistic assessment of what may happen, probabilities and impacts, and then devise an action plan to respond to any events, and look at what practical preventative measures you can afford to take, without going overboard.

When you have your list of Risk Items, you need to categorize them as outlined above, and map them out. You can do a simple 2x2-square grid (High-Low) or 3x3 (High/Medium/Low) if it is helpful to your project, but in my experience, simpler is better. For now let's discuss a simple 2x2 model.

In this model, we want to pay particular attention (and concentrate most of our efforts) on the High Impact/High Probability quadrant items. These could be show-stoppers. Proactive risk mitigation actions might also be advisable for several of these items.

High Impact/Low Probability items need to be monitored and prepared for - but you should not spent a huge amount of effort on prevention - but do have a good post-event mitigation plan.

Low Impact/High Probability items need to noted - but you should not spend a huge amount of effort on prevention or the mitigation plan.

Low Impact/Low Probability items can in many cases be simply noted and little time should be spent on them. Don't lose them though - it might be that their profile will change if conditions on the project change.

Pre-and-Post Event Mitigation

When you develop your Risk Management Plan, you will likely come up with a "what to do IF it happens" set of plans (Post-Event Mitigation) - write them down, and keep them in a drawer somewhere, just in case you might need them later. Update them as necessary.

However, the proactive (Pre-Event Mitigation) side of Risk Management includes taking preventative measures on an active or semi-active basis.

For example, if there is a risk that you might be attacked while staying in a war-torn foreign country, it might be wise to actively station armed security outside your complex. (The best Pre-Event Risk Mitigation strategy is simply not to go there in the first place, but if you are already there...)

But in our example (fortunately) all we have to worry about is rain. Specifically, preventing it from soaking your bag or briefcase.

Preventative Risk Mitigation

 If we took a fully active approach, you might walk around all the time with an umbrella open over your head. Aside from the lack of Vitamin D from sunlight, you would look pretty silly after a while and people will begin to talk about your odd behaviour.

So a semi-active approach might be a bit better. In this scenario, we would be prepared for rain- or at least rain of an average volume. So let's just take an umbrella with us - all the time. (If you only take an umbrella when you know it will very very likely rain - i.e. the weatherman warned you it is going to rain, that is just being prudent. No bonus points for you!)

Which umbrella to choose? (aka Effort)

Those big golf umbrellas provide great coverage, but they are bulky - and just like the guy walking with the open umbrella on a sunny day, walking around with one of those all the time will get people talking. Not ideal. Plus you are quite likely to poke people with it on the bus.

I prefer a more pragmatic semi-active approach - be prepared, but not necessarily for a monsoon. Prepare for a typical or middle of the range event - in this case, a typical Vancouver rain. So I packed a pocket umbrella in my bag. (Not the tiny ones, the ones about 33cm/1 foot long when closed). Suitable for most conditions, but small enough and light enough to carry everywhere, and not be too visible. People will commend you when you bring it out in the rain, but not look at you oddly on sunny days, because they can't see it.

And most of the time - as a Pre-Event Risk Mitigation Plan it was sufficient. Until last year, that is...

Change the Environment, change the Risk

As with everything in your project, things change over time. And sometimes, your Risk profile can change. You need to be aware of the changing conditions and re-assess your risks based on new data. You just might need to update your mitigation planning (post-event and pre-event).

Sometimes what worked before simply won't be enough!

August 30, 2011, Annapolis, MD, USA. 7:45am - I am due to start the training class at 8:00am. I am waiting in my car, outside in the parking lot, along with dozens of other people in their cars. Waiting - because it is not raining. It is drowning outside. Heavy rain bombs hitting the window, and over 1.5cm/half an inch of water pooled everywhere in the flooded parking lot, deeper in many places.

I have my pocket umbrella. Wheelie computer bag is in the trunk. Waiting.

7:59am. Still pounding down outside. I am going to be late for class!

Risk assessment: I have my umbrella. If I grab the bag and pull it, running fast I might be ok. 30 seconds to the front door, give or take. How bad could it be?

8:00 Inside the foyer, absolutely soaked except my head.

8:01 In the classroom, opening my computer bag. Everything is wet.

8:02 My laptop will not turn on.

8:02:01 Risk Event: Computer will not turn on! !@#&*!&#*(&!@#(*&!@*(#& 
Oh dear... I definitely did not make the right call on this one!

8:04 Risk mitigation (post-event): USB thumb drive with the training materials I made as a backup copy seems to be dry. Let's give it a shot, or I will not be earning money today!

8:10 Class starts, up and running with a borrowed laptop and my USB stick - while I completely empty my bag and disassemble the components of my laptop to try to dry them out with the hot air from the LCD projector.

11:55am Wrapping up for lunch. Things seem dry- I reassemble the laptop and power it up. Crossing fingers! 

11:59 Laptop boots up normally. Lucky. Very lucky I don't have to go buy a new laptop.

Lesson #1: Sometimes having a backup to your backup plan is a good thing to have!

Lesson #2: Don't let the heat of the moment let you make bad judgement calls when you have a Risk mitigation plan in place that is likely inadequate. As it turns out, at 8:05am the rain stopped. Haste makes waste, all those sayings...very true. Patience is a virtue...

Lesson #3: Pre-Event Risk Mitigation Plan adjustment: Buy a plastic bag to line the inside of the laptop bag in case of heavy rain.

Back to the Australian Desert

Down from Ayers Rock (Uluru), back in the Land Cruiser and on the way back up to Alice Springs.

Still very hot, and dry. No cloud at all.

Feeling a little bit foolish about dragging that little pocket umbrella into the middle of the arid Australian desert. But then - I could not exactly leave it anywhere either - so here it is with me, in the bottom of my bag.

January 10, 1991: Took the train from Alice springs towards Canberra, stopped in Broken Hill NSW. 44C/111F. Dry. Hot. (Note: Home of Silverton Pub, the pub in the original Mad Max movie. If you go there, take "the challenge" and you will get a free beer. Really! I did.

January 11, 1991: Broken Hill, New South Wales, Australia. One of the few rainstorms per year hits the town, dumping several inches of rain in the afternoon.

** Guess who has an umbrella? ** :-)

Ironically, as there is so little rain, there are no storm drains in Broken Hill. They just have the street curbs, and some walkways the put out from the curb to the middle of the street so people can walk over the water until it flows back out into the desert. However as the rain was quite heavy, the little bridges only went halfway through the flowing water. 

So - umbrella held high and barefoot I went, walking down the street holding my shoes in my hand.

You can't plan for everything!

Summary

Risk Management is a matter of awareness and balance - and updating your Risk Profiles as time goes by - some risks disappear, new ones may be added, and some may change.

I have continued the habit of carrying a pocket umbrella in my bag - or, I did until my teenage son needed it more than me this year - now that it is his turn for taking the bus to High School. 

Time to buy another umbrella!

Good luck with your projects, and try to stay dry!





Saturday, June 2, 2012

Leadership: You Can't Get There From Here (or, How to get things done in spite of it all)

[Also available as a podcast]

Attitude, they say - is everything. Well, almost. 

Perspective is a pretty big player as well.

On a project early in my career, the system deployment involved a group of technicians racing around the country installing hardware in switching and transmission sites in cities as well as some pretty remote areas. One of the technicians made a wrong turn off the main highway on his way to the Picton ferry terminal to come back up to the North Island of New Zealand. Standing by the beautiful shoreline and trying to work out where he was on the map (no GPS back then), a friendly local offered him some assistance. 

"Where are you trying to get to?" the local asked. 

"The ferry terminal" my colleague replied.

"Ah, you can't get there from here." responded the local.

Sometimes, our projects are like that. You know what needs to be done, but you are not sure how to get there - and when you seek directions or guidance, you seem to hit a wall. People are not usually obstructing you on purpose - they might just not have a wide enough perspective to help you with the big picture.

The Cat Who Walked Through Walls 

As a youth, I was a voracious reader. One novel I read was "The Cat Who Walked Through Walls" by Robert A Heinlein (1985). I don't remember much of the rest of the book, but the title and subplot, which was about a minor character as it turned out, stuck with me quite vividly.

The plotline about the cat was simply this: Periodically throughout the story, it walked through walls (not through the doorway, but right through the solid walls). When one character remarked at this amazing ability they asked "How does the cat do that?" The memorable response? The second character shrugged indifferently and said "Because he does not know that he can't." I am paraphrasing slightly, but that was the gist of it.

Ignorance, as it turns out, is not only bliss - sometimes it is incredibly empowering.

I am not saying that you should be a fool, approaching a project with no knowledge about it whatsoever, that would be suicidal - I am saying that you need to be mindful of your preconceptions and be able to put them aside, in order to tackle the really tough stuff - especially in new areas, or in areas that other people found "just too difficult" and gave up.

There have been several times in my career that I have in some sense been that cat - doing what others "know" cannot be done, because I was not trapped with excess empirical knowledge of a new knowledge area, or sometimes I was just stubborn enough to figure out a way to get things done "in spite of it all". (Actually when I come to think about it - much of what I have accomplished as a Project Manager has been "in spite of it all".)

There are other names for this - "thinking outside the box", "Green Hat thinking" (Edward de Bono), but the principle is the same - coming into something fresh with no baggage, or stepping back from "what you know" to take a fresh look can yield some amazing results.

"Everything is possible ...the impossible just takes a little longer" - Dan Brown, Digital Fortress

A Fresh Start

At the start of my second career, I was hired to manage an onsite software deployment for a customer. I was new to the Student Information Systems area, coming from a Telecom background. I received the initial 2 week product training and then was shipped off to meet the customer. What I brought with me was my technical background and experience managing projects. Other than the blur of product training, I knew very little about this new area - other than I had myself, for my K-12 years, been a student in school like most other people. No great starting advantage there!

I called back to the head office to confirm the scope of my tasks, having gone over the migration checklist and the few generic planning documents. They seemed to be a bit vague on the "how" part, so I asked them to clarify exactly what it was I was supposed to do in making sure this implementation was successful. "Just make it work" was the response (I'm not kidding, that is what they said).

Talk about huge scope statements!

So, that is what I did. I reviewed everything I could get my hands on, talked to the services team and technical support on the "hows" of the migration process. The migration involved connecting individual schools into the new central system, and part of making that work required making sure that the schools were all configured similarly - at least at the level of all of the lookup lists. This involved a series of meetings, printing out information from a few sample schools, comparing them and coming up with a set of common "standard" values for each list. Once all of the schools had made the changes, they would send up the school databases to be "scrubbed in" (test integrated) to see if things looked good from a data quality perspective before going live. Inevitably, there were a few more cycles as discrepancies were found and reported back to the district for fixing.

Oh, did I mention I had no regular staff on my project team? Well, except for a couple trainers that came in for new product training for a week or two and a couple other short staff visits, it was a solo act. The customer was my de facto project team, with myself receiving limited remote support from HQ. (Limited not because they were not helpful, they were very accommodating - I just did not know enough to ask the right questions a lot of the time).

So, what did I do? They had 68 schools (a daunting number, as each school had to be physically visited multiple times as part of this 11 month project). I was also not terribly satisfied with the "limited sample" approach - with every school having been operating independently the prior 10 years, the sample approach was not, in my mind, nearly good enough. In order to "make it work" and work well, in my view, we had to compare all of them. Even more daunting.

So, being new and fresh (and naive), I asked if there were any tools, any at all - that would allow me to extract data from the proprietary DB structure. They gave me an extract tool, and after I promised to keep the actual tool safe and out of customer hands, I developed a set of custom tools and a process to compare and validate all of the school lookup lists at once, thus enabling consistent district-wide standardization and the most successful "scrub in" test integration that had ever been performed on the first pass.

To keep the story short - those tools and process, plus the 3 1/2 customer staff I had to work with, enabled us to accomplish more in a shorter time than anyone thought possible - which then gave us more time to work on a few other things to make the overall project more successful and improve end-user buy-in. 

But the key thing here is not about having some fancy set of tools, it is looking at the bigger picture and figuring out a way to get things done - when you don't know "what can't be done", or in spite of it. 

At the end of the project, someone on the project confided in me that at the outset, they thought that we would actually fail - that we would not complete the integration as there was no way to get the required amount of work done in time, with the few people we had at our disposal. And in the end, we had accomplished all of that - and much more, within the limited project budget for my time there. 

And all because we were not smart enough to know what could not be done - the team and I just did what needed to be done. I am so glad they had not shared that negative opinion early on - it would have most likely cast a shadow on the project and they may have been proven right, as a self-fulfilling prophecy.

Summary

If you have nay-sayers on your projects, don't pay them much attention or let them get under your skin - especially if you know you need to get things done "despite" what others say. Odds are, you will figure out a way to do it - either if you are persistent enough, or just plain not "smart" enough to know it can't be done. And look around for some more optimistic and creative people to help you get things done.

But back to my colleague, standing lost by the shoreline:

He did manage to backtrack to the main road and continue on down to the ferry terminal - just in time to board the last ferry of the day. But the tale he told helped remind me that people do not all have the same perspective - and often they are not even looking in the same direction!

Perspective affects everything we say and do. I am pretty sure the local probably meant something like "You can't get there from here, if you keep going that direction", but of course, that is not what was said. So communication is pretty important too - in both the things that are said, and remain un-said.

One final note on perspective:

Question: "What is the difference between an Optimist and a Pessimist?"
Answer: "The Optimist thinks this is the best of all possible worlds. The Pessimist is afraid the Optimist is right".

Perspective makes a difference.

Cheers, and good luck with your projects!