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

By Gary Nelson, PMP

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

Originally posted on Gazza's Corner by Gary Nelson, PMP Friday, 22 June 2012. Reposted with permission. All rights reserved. Click here to see the original post.

Gary Nelson is an independent IT consultant and Project Manager, and is the current Director of Communications for PMINZ.

Project success and the role of good estimates

By Peter Young, PMP
 
As project managers, we crave the same thing – we want our project to be seen as a “success”, by the sponsor, business owner, governance, the team, end-users, ... everyone.

Successful projects deliver benefits, within constraints including scope, time and cost. To be seen as a success, a project needs to start out with good estimates of the time required to deliver the scope, and the cost of that time.

A key finding of KPMG’s NZ Project Management Survey in 2010[1], was that projects undertaken by New Zealand companies often perform poorly in at least one of the following areas – lack of timely delivery, cost over-runs, or inability to achieve the stated deliverables.

The survey found that only a third (36%) of NZ organisations reported consistent on-time delivery of projects, and only half (48%) reported projects being consistently delivered to budget. Internationally the Standish Group found only a third (32%) of all projects were delivered on time, on budget, with required features and functions. NZ project success rates are not unlike elsewhere.

As Project Managers, we are not enjoying “success” as often as we would like. At least some of the reasons for this can be traced back to how we go about preparing our estimates of time and cost to complete the project.

When looking back on a successful project, the following features will often be found to be true:

• During planning, the scope was broken down into detailed requirements that were measurable (testable). This ensures everything gets estimated, and the estimators are clear on what will be an acceptable deliverable.
• Estimation time was adequately budgeted, and a sound process used. It takes time, and a good process, to do a good job of estimation.
• Estimates were provided by the people who did the work. This ensures estimates reflect the work rate of the people involved, and helps to get their buy-in.
• Estimators understood the work and were able to estimate it accurately. Possibly the most challenging aspect of estimation. Get data on similar projects, to enable comparison. It also helps to break the work down into less complex tasks that can be more readily estimated. If in doubt, get advice from someone with more expertise, either in estimation techniques, the work being estimated, or both.
• Actual delivery was regularly monitored against the project baseline, to validate that the work accomplished matched the plan. Where there are variances, re-forecast completion time and costs. This enables you to signal early if the project is likely to run ahead or behind on schedule or budget, and creates the opportunity for the project schedule and budget to be adjusted (using appropriate change control).
• Scope variations were quickly identified and managed. Volumes can be written on this topic, and experienced project managers know that scope creep will torpedo the success of a project. The mitigation for this involves good communications within the project team and with stakeholders, an effective change control process that enables request for changes to baselines to be identified, assessed, estimated, approved or declined, documented, and communicated to all those that need to know.
• Risks to the project were identified and managed effectively. Risks and issues need to be estimated, either quantified as time and cost, or at least identified qualitatively in a risk and issues register, enabling allowance to be made in project contingency estimates. Under-estimating risks will lead to insufficient contingency time and costs, which in turn can lead to under-estimation of schedule and budget for the project.

This is not an exhaustive list, you may have tips and techniques of your own that contribute to project success. Consider sharing the benefit of your experience with the wider project management community. See below for details on how to submit an article to PMINZ eNews.

Good luck with your project estimates, may all your projects be seen as successes.

[1] For the full report, see www.kpmg.com/NZ/en/IssuesAndInsights/ArticlesPublications/Documents/Project-Management-Survey-report.pdf

Peter Young has managed business focused IT projects in the Wellington government sector over the past 5 years, and prior to that 25 years in international and local roles in the oil industry. He has held several volunteer roles with PMINZ and is the current Central Branch Chair. All rights reserved.

A Leader Without Followers is Just a Person Going For a Walk

By Allan Old, PMP

So how do you get others to walk with you ?

You have to know where you are going and know that you can’t get there by yourself.

You have to convince others that the goal is worthy of obtaining and that you need them.

This has to be done with integrity and be believable.

Share the vision
What and Why. The what can be attractive, but the why is more important.

Get a team together and determine the basic principles that the team will operate under. This aligns the values of the team and the individuals with the why of the undertaking. Get the team to determine the how.

You may think you know the answer but by asking open ended questions team members will be able to provide input and then the resulting plans will a shared outcome. The quality of your questions will determine the quality of the answers. Become a better questioner.

Leaders manage the task and the sequence, provide the support and ask the people for outcomes. When asked to make decision, unless the consequences of a delay are serious, a leader will ask a question to maiximise the learning opportunity.

Think about those who you thought were good leaders. Did they tell you what to do or ask you?

Allan Old is a Project Manager at Alcatel-Lucent with over 20 years experience in change leadership and project management.

Authentic Leadership in Project Management

By Sean Whitaker, PMP

There are many aspects of project management that contribute to project success. There are the technical skills learned and the experience gained in applying them. There are also the soft skills such as communication and influencing that a project manager must possess. Perhaps most important amongst all these skills is the ability to lead and demonstrate leadership, particularly authentic leadership. A good project manager manages a project; a great project manager leads a project.

Leadership is the purposeful, influencing of followers. Without any of the three key elements is simply isn’t leadership. Without purpose, it is someone we may wish to follow who doesn’t want to lead. Influencing acknowledges that the leader has a vision and influences followers to go in a particular direction. Followers are the most important part of the equation though, for without followers there are no leaders. Great leaders respect their followers and great followers respect their leaders – it’s a mutual relationship. Leadership is a conscious deliberate decision. It is an acknowledgment there is a relationship between leader and follower, and each needs the other to exist. It is a commitment by those who choose to lead of continual personal and professional development. It is a commitment by those who choose to follow of support and feedback.

Leadership requires many different competencies to be displayed at different times as it is highly situational. The competencies you must display during times of high stress and challenge will be different from the competencies you must display during settled and stable times. However, the one core constant aspect of leadership is authenticity. Being authentic means having integrity and not pretending to be something you aren’t. People will always know when you are not being authentic. Being authentic means having a set of values and living them. Don’t be the ‘do as I say, not as I do’ type of leader. Being authentic means having a genuine interest in people and especially your followers. Begin authentic means having a balanced assessment of your own strengths and weaknesses.

It has been proven that good leadership enhances the chances of project success and the absence of leadership negatively affects the chances of project success. So if you want to increase the chances of project success practice your leadership skills and recognise that the best sort of leadership is authentic leadership so be true to yourself. Be true timber, not a thin veneer. 

Sean Whitaker is the current President of PMI New Zealand and author of The Practically Perfect Project Manager. Sean is also the co-owner of Falcon Training and spends his days teaching, speaking or writing about project management.

Leadership: Ten Attributes of an Effective Leader

By Gary Nelson, PMP

[Also available as a Podcast]

Effective Leadership

No, it is not a myth. Many of us have actually seen this phenomenon, or even been lucky enough to work with an Effective Leader. If you were really lucky, they were also your manager/ team leader/ project manager etc.

Ok, to be fair, Effective Leadership is not quite that rare - but uncommon enough that people definitely appreciate it when they see it - and they wished they had it too.

My experience with an Effective Leader

1989 - Back at the beginning of my first career, straight out of University, I was quite fortunate to be hired by an Effective Leader. Of course, I did not know that at the time, but as time went on this became more and more apparent as teams came and went - and his stayed together. 

We identified with him, the team was loyal to him, even through a multi-year dissolution of the company into fragmented parts - in part, because he was also loyal to us. In the final stages of the corporate sell-off, while other departments in our part of the business saw an attrition rate of 70-90% over a 6 month period, his department lost only 2 people in the same period of time. And those only did so after long soul searching on career direction.

Over a period of 11 years, his team stayed together, until he recognized a strange truth - in order for his team to grow further on their personal development paths, he had to leave the company.

In our case, we not only had an Effective Leader, but an exceptional one.

So what makes an Effective Leader? And does that person need to be "the boss"?

Ten Attributes of an Effective Leader

1. Ethics

An Effective Leader has a firm ethical compass. They stick to what they know is right, even in the tough times, and do not easily bow to social pressure or fads. They also make sure that their team embodies the same ethics - honesty, looking out for the customer, doing the right things - right, etc. And not a "closet ethic" - it shows in how they conduct themselves every day.

2. People Skills

An Effective Leader has good people skills, and can communicate effectively with their peers and their team, as well as up and down the corporate ladder. They don't have to be a gracious public speaker to hundreds or thousands, but they do communicate well within their sphere of influence. And Exceptional Leaders develop a significant sphere of influence.

3. Not the Boss

In those 11 years, except for a few periods while on projects with a different department, I did not have a Boss. I had a Manager, a Coach, and a Leader - not a "Boss". An effective leader works with their team, encourages and supports them. Sure, there are plenty of times the leader needs to have things done a certain way, in a certain time - but the difference lies in how they communicate it. A Boss demands the work be done - a Leader requests it and expects it do be done properly - and those working for them are dedicated to doing just that.

4. Praise in Public - Criticize in Private

We have all heard this mantra - and it certainly makes a difference not being "dressed down" in public. However, an Effective Leader takes this one step further - when discussing issues in private, the Effective Leader rarely brow-beats their team member - even if they want to. They address the issues, the behaviour - whatever was at fault, but in a way that does not rip the team apart. If anything, their expression of caring for the team member while firmly addressing the issues at fault further strengthens the team and engenders loyalty and respect. Yes - you will be held accountable, Yes - you are expected to do things right/on time/etc. No - your Leader is not a push-over, and you cannot "get away" with poor performance or behaviour. But you leave the conversation wanting to improve/fix it - you want to live up to their higher expectations of you.

5. Formal vs Informal Authority

An Effective Leader knows how to get the job done - and how to use their formal authority as well as forms of informal authority (primarily influence). As we know, formal authority is bestowed with a title/job description, and not always respected fully if the person does not behave in accordance to the expectations of the role. You may "have to" do what is asked - that is more "Boss" talking. However, an Influencer gets things done by those around them by earned influence and respect - and people wanting to help. Exceedingly happy to help, even - because they know they can rely on the Effective Leader to help when they need it. A formal title may change - but influence tends not to fade that easily.

6. Loyalty

An Effective Leader both demonstrates and earns loyalty - through consistent interactions with their team members, standing up for them, and expecting the best from them. They are great people to work for (and with), but they are not just an easy-going smile-a-lot, they are firm when needed too. They will stand up for you with the higher-ups and with other departments, but they also expect you to live up to their expectations as well.

7. Consistency

An Effective Leader does not change their stripes according to the day - you can rely on them to be consistent in behaviour. Even when they have a bad day (and we all do), they do not completely change direction, and do not lash out at the team when frustrated. You know what to expect in your dealings with them - on good and bad days too.

8. Encouragement

Effective Leaders help to grow their team - collectively and individually. They support team members trying new things, advancing themselves by learning new skills - and providing opportunites to practice their new skills in the workplace. And it's OK to fail - if you are learning something new, you willl not get it right the first time. An Effective Leader understands this, and helps you to progress to the next level, without knocking you down a peg for failing while trying.

9. Not the Detail Expert

Effective Leaders are not the experts in what you do at the detail level. Maybe they used to know it once, but that is no longer their role - they know their value lies in orchestrating the team of experts to perform at their peak, and deliver the goods - on time, with high quality of results, etc. They become experts in working with people instead.

10. Caring

Finally, an Effective Leader cares. About the team, about the company,  about the customer, about the result - and about You. You can see this whenever you work with a team led by an Effective Leader, there is a whole different nurturing atmosphere. People want to be there, and are happy to do whatever it takes to succeed - because they are making a difference and know they are appreciated.

Summary

Nobody is perfect, even Effective Leaders. However they are consistent in what they do, and they do it well, which you can see by looking at the people that surround them. You might also say there are more attributes of Effective Leaders, and I would agree. If pressed, I could also boil it down to two main words - Caring and Consistency. But in truth, there is really so much more to it as you see above. 

Can we all learn to be Effective Leaders? Certainly! Few are born as Effective Leaders, those who have a high natural aptitude for it. Most Effective Leaders start out as good observers of people, and can learn the extra skills along the way. And having a good role model/mentor and exposure to Effective Leaders certainly helps too.

I have had the good fortune to work with (and for) an Effective Leader for a good portion of my career, and when I am uncertain of what to do in some leadership situations, I think back and ask myself "what would he do?". 

Am I an Effective Leader? Honestly, I can say not yet - though I am on the path and still striving to be closer - still wanting to live up to the expectations planted over two decades ago.

To my Mentor, Coach, Manager and Friend (you know who you are) - thanks for being a great example. Your infuence continues.

Originally posted on Gazza's Corner by Gary Nelson, PMP Wed, 24 March 2012. Reposted with permission. All rights reserved. Click here to see the original post.
Gary Nelson is the current Director of Communications for PMINZ, and is an independent IT consultant who has worked in the Telecom and Student Information System sectors since 1989.

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

By Gary Nelson, PMP

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 likelikood 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 spent 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. Specifially, 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 LandCruiser 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

Originally posted on Gazza's Corner by Gary Nelson, PMP Sunday, 17 June 2012. Reposted with permission. All rights reserved. Click here to see the original post.
Gary Nelson is the current Director of Communications for PMINZ,

Risk Mitigation Through Contracts

By Lars Theil-Lardon (MBA)

In my years as project manager, one thing my clients have valued most is the security of their funds or at least the knowledge of the last final figure.

At university they teach us that through planning 70% of the total expenditure of a project can be predetermined and secured. Life teaches us that clients usually do not want to go the extra mile in the planning process either due to time constrains or overconfidence.

Under these circumstances risk management helps to determine potential risks, which deviate from the desired project goal, and eliminate, isolate or minimize them. In the current market, dealing with risks and their potential influences can’t make up for inefficient planning.

In my personal opinion risks are best managed, some even avoided, through a solid written contract. However, this can only be achieved if the planning phase has been correctly and robustly executed. I have been in the construction sector for the last 6 years and I can recall that the most project issues came through wrong client expectations and sloppy written contracts. Many of my fellow engineers and project managers dealing with Local Government Agencies are using NZS3910 as their contract construct, but forgetting to personalise the contract with the particular project they dealing with. Sometimes recommendations made by the Engineers or Project Managers are rejected by the Clients as they are different to their standard contract conditions.

Now most of the readers will ask themselves, ‘why is this guy talking about contracts and risks avoidance in the same moment?’ The answer is easy. With a good and solid contract the client can avoid additional risks and with a sloppy written contract they will create additional risks. For example, if you predetermine your design in detail, you can anchor all the items in the contract document. As a client you will rely on the knowledge and experience of your consultants to get an understanding of the construction period. Even if the suggested timeframe is longer than your anticipated plans allowed for, try not to restrict the time by specifying the contract period shorter than it actually takes. Most contractors will still sign contracts with overly short contract periods, but they will work on potential extension of time from the early days. One piece of major advice is that a client shouldn’t change any plans or objectives after the contract is signed. A move like this will expose the client to a risk that the price for the variation is no longer the lowest market price and an extension to the contract period will be added.

Another catastrophic risk which can be eliminated with a contract is the reserves for any damages. Every construction contract has retentions placed on the suppliers. The maximum should be within 5% to 10% of the construction sum. This money can be used as funding source for any claimed damages after the project is practically complete and payment has occurred. I remember one of my contracts, where a maximum retention sum of $100K (equal to 1%) was specified. Three payments before the contract finished, potential applied damages were identified as being in the order of $300K to $500K. As you can imagine, the client got very nervous due to the fact that he was exposed to the risk of having to claim the damages from the contractor as invoices. This situation is not a single case - rather a regular thing.

A last but major risk is ambiguity of the contract. Some contracts are rushed and therefore mistakes, minor as well as major ones, slip into the contract. These ambiguities are risks which can cause financial implications to the client and frustrations on all sides of the contract. As a guideline to good management practice, all contract documents should be proof read at least 3 times preferably by 3 different people. At best one of these people should have had no involvement in the design process at all. With the increase in complexity and value the number should be increased too.

In my current project a lot of frustration between the contractor, client and consultant could have been avoided, if the document would have been closer examined before it was released for tender.

But every contract has its limitations and some unforeseen issues, such as unexpected ground conditions, can’t be eliminated. For these events and many others like delivery issues, theft, vandalism and so on, a well prepared risk management plan will govern the way through the risk world.

Lars Thiel-Lardon (MBA)

Professional Management Services 2009 Ltd

Lars studied at the University of Rostock and graduated in 2004 with a MBA. In 2005 he immigrated to New Zealand and works since in the construction sector.

Lars is specialised in civil and building construction projects and managed a number of construction projects in New Zealand. For the last 15 months he is involved with the Morrinsville Wastewater Plant Upgrade on behalf of Matamata Piako District Council.

Lars is also the Bay of Plenty Sub-Branch Coordinator.