Risk Management: Are You Free?

Risk management is all about predicting the future, and we're really bad at predicting

It's a running joke with the secretary at my dentist's office: "Mr. Donath, can we see you at 8:00 am on Tuesday in 6 months?"  "Well, I'll have to check, not sure what I'm doing them."  "Oh, I know what you'll be doing, you'll be here!"  Usually when she asks this question the season will be the opposite of what it is now.  If it's summer, there will be 2 feet of snow on the ground then.  That's the trick right?  The context then will be totally different.  Heck, I could have a different job, could be living in a different, house,...  Hey, I could be dead!  Crazy?  It happens.  Predicting the future is tricky.  In the book, The Black Swan, Taleb cites an example where some government agency was predicting the price of a barrel of oil for 25 years.  If I'm not sure what I'm doing at 8:00 am on Tuesday 6 months from now, how is someone going to predict the price of oil 25 years from now?  Stop for a moment and catch the seriousness of this: here's a government agency with a bunch of very smart people who are paid to know oil and the US energy sector is watching these predictions closely (and there probably a whole chain of people watching the energy sector).  So what these guys say has a big impact.  They said that oil wouldn't go over $27 a barrel over that 25 year time period.  Wait for it.  The price went over $27 in the first 6 months.  We are really bad at predicting.

Which leads me to risk management.  I'm speaking of risk management on IT projects.  We're told to predict (1) the probability of occurring, (2) probability of impact, and (3) timeline for impact.  There are other things to capture, but let's start with that.  Let's just pick one, probability of occurrence.  In the oil example above, they gave the probability of occurrence of going over $27 / barrel in 25 years as low.  It turned out to be very (VERY) high.  We are really bad at predicting.  If we are, how do we perform risk management?  There's a lot to talk about here, but let's start with who should do the predicting.  Don't confuse this with who can identify a risk, anyone on a project can identify a risk.  We'll talk more about that in another posting, but let's talk about who should do the predicting.  Apgar's book, Risk Intelligence, has five criteria for assessing someone's ability to identify risk and the first is "How frequently do your experiences relate to the risk?"  Let's say the risk has to do with system performance on a cloud solution.  Do you have experience with cloud solutions?  Do you have experiences with performance problems?  Do you have experience with measuring performance in a cloud environment?  If your a project lead, then finding someone who scores higher on this assessment will be important.  If you have the experience, go for it.  If you have a general feeling about the technology, better find someone who has more experience.  Yes, experience can be hit by a black swan too, but it is a step in weeding out possible error and refining the risks.

Agile Development Myth

Another presentation on agile process, another set of misconceptions.  The agile process is not just for software development, although it works very well there.  You could plan a birthday party using agile development.  The agile process is a project management tool, not just a software development tool.  When we hear that agile development is just for software development, we need to look deeper.  Agile development focuses on the delivery of specific products in a 3-6 week period.  Software is a specific product.  Many times the system life cycle is so full of huge work products in the form of documents that no wonder someone thinks that it's just good for software.  If a system design is a huge document, then of course we can't come up with a copy in less than 6 weeks.  But if we see the work product a server design, a network design, etc, then these can become chunks that can be delivered in that timeframe.  Identifying the chunk of work is hard, but the reward in productivity can be worth it.

Another problem is that classic waterfall processes created a lot of work that wasn't really used.  Agile came along and said, 'lets focus on just what we need'.  So agile projects start popping up.  The folks who define the waterfall processes then say that they need to add stuff to the agile process - basically bogging down the agile process with everything that made the waterfall process ineffective.  Ugh.  But we do need to be careful: there are things that agile projects have overlooked in the name of getting systems out quickly that make the operations and maintenance of the system difficult.  So we can't just throw out the waterfall process.

Twitter and $25B

All I can say is: you've got to be kidding.  I like twitter.  I love twitter.  Twitter does some things very, very well.  But $25??  It's not a cure for cancer, doesn't reduce poverty, provide healthcare to poor, etc.  I think we're looking at another dot com bubble?

Assumptions

Anyone ever get mad at you because they had an assumption that they didn't communicate with you?  This is a problem in personal life as well as professional.  Never goes over very well.  This is why the use of Log Frames in projects can be very useful.  What are the assumptions that get us from the project inputs to the outputs?  What are those things outside your control that could impact your delivery?  Also, when creating a project schedule in MS Project, add assumptions to the Notes section of a task.  Always be aware of what your assumptions may be.  The odd thing is that when we have assumptions about someone else, we think that they're obvious - 'hey, don't you think it's reasonable...', 'isn't it obvious that you should have...'.  Funny how that works...

Book Review: Tribes, by Seth Godin

Just finished reading Seth Godin's book, Tribes.  Mr. Godin is a fantastic speaker and a wealth of ideas, so I was pretty eager to read this book.


First, what is a tribe?  "A tribe is a group of people connected to one another, connected to a leaders, and connected to an idea."


Pop Business Philosophy
I get tired of the 'break all the rules' business philosophy.  It's old.  It's not helpful.  I get what the author is saying - think critically about how things are being done, think outside the box, overcome fear of change.  The guys that say this usually knew what the rules are, knew which ones to keep and which ones to break.  We don't normally read books from the cemetery, right?  You aren't going to find the book 'I Broke All the Rule: How I Crashed and Burned'.  Ah, but these pop business philosophies would say, 'that's your fear talking.'  And you see where this conversation is going: no where useful.  Take the book, Great by Choice, now there's a book with practical guidance and insight.


Fear
The book spends a lot of time dealing and challenging our fear for starting something new.  It reassures that we can start - do something.  It makes the point that we don't need to climb Mt. Everest at the first go, but we do need to act.  This is a great reminder: start something, do something.


Religion
I was surprised by how many references to religion were in the book.  The problem is that the book doesn't define it's terms, casting a very wide net as to what it means by religion to include formalized religion as well as corporate culture.  This too isn't useful.  Some of the greatest 'rule breakers' in history were from religions.  Abraham leaves rich community and goes to no where.  Jesus turns the leaders of that day, both religious and secular, on their heads.  Ditto Paul.  Martin Luther tweets his 99 thesis on the church door and starts the reformation.  The puritans, a group of counter cultural young people hire a ship and start a different kind of community in a place no one knows anything about.  Now THAT's some serious rule breaking.  Each of these people or groups had a hugely profound impact for centuries.  Godin doesn't differentiate between effective and ineffective religion - just throws them all into the same box, but even religions differentiate in their own doctrines what constitutes good vs. bad religion.  I get it: any system of rules that people blindly follow is bad, but to use 'religion' that broadly isn't accurate, isn't helpful, and subtly fosters a new racism.


Service & Leadership
The book makes a really big deal out of leadership serving - that was very refreshing to hear.  The leader of a tribe needs to think about how to give to that tribe and how to let the tribe give to each other. Very powerful.  I'm going to be giving a lecture this summer and it got me thinking: how can I give to that group of students, other than just talking at them?  Something to think about.  Godin also makes a very strong case for you being a leader.  You don't need to be a national or international rock star, but you do count, you do have something to offer, so get off your butt and show some leadership!  He really makes the case that you can lead something.


Pg 103
This is probably the best, most detailed advice the book gives - get a copy of the book and copy that page!


Bottom line?  Not a great book, worth a quick read if you can get it for cheap.  Amazon has it used for under $4.  You should seriously consider the three points in the definition, and go show some leadership.

Sharepoint: My Site Profiles

When deploying sharepoint 2010, it's really important to review the profile attributes offered through My Sites especially if your organization has international users.  International privacy laws are different from those of the US.  For example, posting a picture of a team can violate UK laws, if the people in the photo haven't given permission to post that picture.  Heck, we post pictures of people all the time in Facebook in the US!  There are two options with My Sites, one is to preset profile attributes to privacy setting or simply to make My Sites inaccessible to international users.

Meetings: Background Noise

I just got off of a conference call where something was flapping and ticking in the background on someone’s phone – annoying.  Distracting. 

And distracting means ineffective.
Lots of meetings these days take place over the phone.  If you’re on one of these virtual meetings, watch your own background noise.  Dogs barking, fans blowing, wind coming in from the window over speaker phone, kids bursting in, keyboard clicking next to speaker, and on it goes.  Here’s what happens: we hear a strange noise on the conference call and our brains wonder what it is.  Our attention gets pulled off what’s going on.  Then you get annoyed, wondering if other people hear that noise.  Then finally someone says, “please put your phone on mute.”  By that time, the people in the meeting have lost focus – not in a big way, but enough.Solution?  Use a headset.  Also, if you’re not sure if your environment is quiet enough, do a test call with a friend.