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!

Gary Nelson, PMP
Gazza Consulting Services

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!

Gary Nelson, PMP
Gazza Consulting Services

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!

Gary Nelson, PMP
Gazza Consulting Services

Leadership: Working with Volunteers

[Also available as a Podcast]

Everybody knows you should "play nice" when you are working in an office together. If you don't get along, there is the polite smile, or taking another hallway when you see them coming. But you are all paid to work together to get things done, so unless you are ready to quit and work somewhere else, you do need to work things out so that the team somehow manages to function - or eventually one of you might find you are being shown the door.

A Different World - Volunteering

In the world of volunteering, this becomes a totally different situation. Nobody is paying you to be there. Sure the donuts and coffee might be ok, but the real reason that volunteers are there is because they want to be there - they want to contribute to some vision or goal and make a difference.

I have been volunteering in various roles and organizations as an adult since 1984 (and many years before as a youth), and in that time I have had to deal with the same personality types and problems that you find in any office. I am sure I have occasionally been a problem for somebody else too, as nobody is perfect. But I have worked through each of those challenges, and still continue to volunteer because I want to give something back. I guess like most people, I want to make a difference, not for financial gain, or fame or glory, but because I care about something and believe in it.

Why Volunteer?

Volunteering is important for many reasons. From Little League to Board Members of not-for-profit organizations, volunteers drive many of the important things that go on in our world. Without volunteers, the world would be a dull and listless place. People want to be able to give - without necessarily expecting a reward from someone else. So they volunteer their time, energy and skills to things they believe in.

According to the 2011 United Nations State of the World’s Volunteerism Report, “...volunteerism benefits both society at large and the individual volunteer by strengthening trust, solidarity and reciprocity among citizens, and by purposefully creating opportunities for participation.”

Looking at official statstics, in the USA,  2011 statistics show 26% of the population volunteered, with 64.3 million people volunteering at least once per year. In New Zealand, 2008 statistics show 32% of people spent time volunteering. In Australia, 2010 statistics reveal 36% percent, or 6.4 million people gave their time for volunteer causes. In Canada, the 2010 statistics showed almost 50% of the population spent time volunteering. Most developed countries reflect similar statistics to the above. That is a lot of time spent volunteering!

You will often find that people work to get paid - and they volunteer to get satisfaction, and that intangible but very important sense of well-being from making a difference. Some people volunteer and do get recognition - but for most that is secondary, and for some, even a bit embarrassing - because they know everyone else is working hard to make a difference and they don't feel they should be singled out.

The PMOIG Club

A friend of mine told me he was a member of the PMOIG club. "What is that?" I asked. He was a retired school administrator, who still consults and does the work he loves to do (but for this he does get paid). He said in the public sector, they count the years of service, and once you get close to retirement age, depending when you started, you may meet the requirements for a full-pension retirement with your last few year's top salary - before you are at "normal retirement age". In his case, he could have retired several years before age 65. Many people he worked with of similar age were in the same position. He told me they were all members of the PMOIG club. "P**s Me Off, I'm Gone." They could retire at any time on full benefits - they just stayed on because they still enjoyed doing what they were doing. 

And he remains a member of the PMOIG club today - but he continues to work with us and the customers because he loves doing it. Sure, it is hard work sometimes, but he enjoys the challenge, and knows he is making a difference. He has the best of both worlds - he does not need the money, as he has full pension - but he loves what he does. Kind of a "paid volunteer" in some respects.

The PMOIG principle most definitely applies to volunteers - essentially, everyone who volunteers is "pre-retired" - they don't actually have to be there. They are there because they want to, they enjoy it, they feel they are valued and are making a difference. Even the Soccer Mom who feels "she has to do it" because her son or daughter is playing is really volunteering because she cares - she could have said no. (Of course, then there may not have been a team, but you see the importance of having volunteers?)

Rules of Engagement for Volunteers

There are a few key things we need to keep in mind regarding volunteers:

- We need them! The world revolves around volunteer efforts.

- They don't have to be here.They want to be here. At least, unless you drive them away.

- They want to make a difference. This is why we volunteer.

- They need to be respected and valued. We all do!

- They need to be given something useful to do. Don't give them idle work.

- They are buying into the Vision. They will give heart and soul when they do.

Respect

Every volunteer needs to be treated with respect. Well, everyone should of course use the Golden Rule with everybody else, but for some reason a few people forget this with volunteers, and actually treat their volunteers like slaves. They may forget that although these people are not getting paid, they are providing a valuable service - because they want to, not because they have to.

There are no "unions" in volunteering, but if the "working conditions" become too unfavourable, they will vote with their feet on the way out the door. So be nice to your volunteers, remember they are people contributing their own invaluable time to your mission/initiative/organization/cause.

Making a Difference: Feeling Valued

Every volunteer joined your cause for one main reason: they wanted to make a difference. Give them the opportunity to do so. Find a task that will match their skills/talents and will challenge them - but not drown them. Give them opportunities to excel, and make sure they know how their contributions affect what you are doing. They may be "just photocopying and stapling" but it serves an important function. Everybody's role is important - from the bottom on up. But make sure that you make good choices in your assignments - check in with them to see how they are doing, and if they feel they are contributing and making a difference. If they don't feel it - they will probably quietly disappear.

Too Many Volunteers?

While many organizations struggle to get and maintain volunteers, sometimes you may actually be faced with having too many volunteers. Your media promotion may have exceeded your expectations in your call for volunteers.

What to do? Well - you might have a wonderful opportunity on your hands. You may be able to tackle a few projects that you could not do before, because you did not have enough people to help make it a reality. If that is the case, great! Make a plan to use the new volunteers mixed with current volunteers to get those things off the ground. You may be at the beginning of your best year ever!

But sometimes, you will have too many volunteers, and nothing for the "extras" to do at the moment. What do you then? There are a few options. 

- Do you need "backups" for certain roles? If so, then you can discuss this with the existing volunteer and the potential volunteer to see how that might work - they could shadow and provide support, and fill in when the main person is away. 

- Ask them if they would like to volunteer with another organization you know is short of people. Quite often volunteer circles interact/overlap - you will know something of what is going on with the other organizations and who may need help. The prospective volunteer may be delighted to help the other group - and the other group will be glad for the help (and your good-will referral). They may also be able to help you in kind one day.

- Thank them and let them know there are no current opportunities, but take their name for the future if they are OK with that. You might have something come up unexpectedly where you will need a replacement, or your cake sale was so successful that you now have funding to take on some new things. If you have a list of willing volunteers, you can then ring them up and see if they are still interested.

Expectations: The Volunteer Job Description

A job description for a volunteer? Come on - really?

Yes, I am being quite serious. Many people who get involved "as a volunteer" were sucked in, without proper disclosure of what was involved, or what was expected of them. These people will often feel resentful, and may choose not to volunteer (for anything) in the future, once this current activity is complete. Or they may not be doing the job you needed done...because you did not tell them what it was!

Frankly, that is straight manipulation - and does nobody any good. People have a right to know what is likely to be involved when they are asked if they would like to volunteer for something - or if they approach you wanting to volunteer, to know what your expectations of them might be. This can include the average number of hours per week, the types of activities and responsibilities, and who else they will be dealing with (other volunteers and whoever they might be serving). Again, it comes down to respect - be fair and open with what you expect from them.

The "Job Description" may be verbal or it may be written - but the more responsibility involved, the better it is to have it written down. In an ideal world, you would have a brief (or long) description of each role - so you know what you are looking for, and they know what they are getting into. Perhaps post it on your web page for each type of role you have. Be open about the roles and your needs.

It is also a good idea to ask why they want to volunteer. You might find that their goals and your goals might not actually align... In which case you might not actually want to "hire" the prospective volunteer. Who would have thought you might not want someone? But sometimes, it happens - and better to find out early than later on.

Leadership

Volunteers need leaders - and Leaders need volunteers. And you can be both at once. But remember the best role is the Servant Leader... You are not the boss of anybody. Things will work best when you realize that the role of the volunteer leader is to support the volunteers, coordinate things and make decisions so that the job can be accomplished. You might need to be the public face, but internally you are serving the volunteers by what you do, to help them help you, so together you can fulfill the purpose of the organization or club.

Tough Love

Sometimes, you may actually need to "fire" a volunteer. They may not be contributing, and may actually be detracting from the overall efforts. This is usually not because they want to sabotage anything - it is more likely they are "burned out" and need to change tasks or possibly take a break from volunteering for a while. Have a kind but candid conversation in private with them - discuss what they see happening with their volunteer role, if they feel they are still contributing, and feeling they are valued. Ask if they feel overwhelmed. Perhaps their circumstances have changed and they can give less time...but feel obligated to stick with what they said they would do. Remind them it is ok to say no to a task.

Perhaps there is another role that they can take on that will recharge their batteries. It is harder to get a new volunteer than to keep one, most times - so if they are still interested in being involved, something else to do might just be the thing to keep them engaged, happy and productive. And if they are truly, really burned out - "let them go", thanking them for their valued contributions but remind them they are welcome back later - when they feel up to it and have the time for it.

Burnout? - Share the Load

People do get burned out - especially in a volunteer setting. It is important to watch out for it and share the load - "by force" if necessary - so that one person is not taking on too much. They will eventually wear out and may get resentful, but they may not talk about it, suffering in silence. Help them by discussing their tasks and how they might see them being "done better" - nobody likes something being taken away from them, but if you can show them that they may be contributing more by focussing on one or two less things, the result will be better and they will feel less stressed - they may be more likely to accept someone else taking on the other roles. Besides, most people work and have family obligations too... So be sure to share the load around.

A role for everyone

When you do get volunteers, be creative. Someone may only be able to help an hour or two a month, while others can provide a few hours per week. Find something for them to do that fits their available time, and do not pressure them to commit to more. If they feel valued and can give more time, usually they will tell you-they will come to you asking if there is anything else they can help you with. And if they don't... Be thankful you have them doing what they can do. Every little bit helps.

But also be realistic... If there truly is no role to fit the few hours they can give, thank them for their offer and ask if it is ok to contact them later when something comes up that may fit.

Dealing with difficult people

Occasionally you will have difficult people to deal with. It is the nature of things that you will, at some point have to face up to someone you cannot get along with. When you do, you need to look closely at the source of the problem, and this will involve talking to them about it.

- are they used to leading, and don't like "being led"?

- perhaps they do not feel challenged?

- are they competent at what they have signed up to do?

- are their own goals still aligned with the shared vision?

If they are feeling under-utilized, give them something more, or something else to do. Perhaps they can manage a sub-team for you if they are used to leading, or would like to try it.

If they are just one of those "difficult people" but they have skills you desperately need, find a way to make it work. Give them something to work on that will challenge them, but maybe not so close to your own chain of command. Perhaps you can "transfer" them to work with someone else they may get along with better. Who knows? Your personalities might not just mesh.

But, if they seem to be consistently at logger heads, and particularly not in alignment with the vision, perhaps it is time for some "tough love" , thank them for their time and send them on their way. (Yes, you can "fire" volunteers). They may be more suited to a different type of organization.This might be the best for both in some cases.

Note: Volunteering is no place for an "empire builder". Servant leadership, remember?

Summary - The three R's

Working with volunteers can yield some of the most rewarding experiences of your life. You may have chances to do things and get experience in things you never would be able to with your "day job". But remember the three R's:

Respect - treat all of your volunteers with respect, and regularly thank them for their contributions.

Relationship - great things are accomplished by teams, and good relationships are at the core of every well-functioning team. Nurture those relationships!

Realistic expectations - people buy into vision. Be clear about the goals and how each person can contribute. Don't pull the wool over their eyes to try to suck them in...people soon wise up to that. Be truthful about what you need and what you expect from them, and they will often outperform your expectations because they have bought into the vision.

If you have never volunteered... give it a try! You will find you get as much or more from it as you give. You will also make new friends you would not otherwise have had.

If you do volunteer, and especially if you "manage" or lead volunteers, I hope you have found this useful and are able to apply the above principles in working with your volunteers.

Happy Volunteering!

Gary Nelson, PMP
Gazza Consulting Services