Risk in Project Management

I want to talk about risk in IT projects.
I don't feel we do a good enough job assessing risk and constantly staying on top of it.

Why?
IT Project Managers are under enormous pressure to deliver so looking only at the sunny day scenarios gives them a sense of optimism. Dates are then promised based on this scenario and everything is done to make that date. Risks are ignored, hoping they'll go away. Turning a blind eye is easier and then throwing your hands in the air is the final resort when the realization hits that there's no way you're going to make that date.

The nature of risk is that it's neither good nor bad. It just is. And it always exists. Hence it needs to be managed. Ignoring risk imperils projects, plain & simple. Another aspect of risk and more important, is that it constantly changes. Staffing changes can occur -> Risk occurs. A project can move from the requirements stage to the design change -> Risk occurs. In fact, every single day a new risk can reveal itself. Therefore, it is important to be constantly assessing for risk.

In simple terms, managing risk basically means staying on top of your project. You just can't do all your planning, baselining, draw your Gantt charts and say "GO!". After you put the ball in motion you have to watch where it goes constantly and re-adjust yourself, and your team (Tennis analogy anyone?)

So the first piece is to constantly monitor risk. That part requires vigilance for the duration of the project. You can do this via using checklists, talking to people, going to training, asking questions, etc. The 2nd and most often-neglected piece is to mitigate the risk. Identifying risks is not enough. Sometimes a risk makes itself apparent to you and everyone else and if it actually does occur, people tend to throw their hands in the air and complain and the project fails to move forward until it gets escalated. Someone from high on up chimes in and then the project starts to move again.
This is bad. Your boss or boss's boss shouldn't be managing your project.

The key is to assess the risk earlier and have a mitigating plan in place to deal with the risk. That way, if the risk actually does occur, you can follow the plan. Remember: to fail to plan is to plan to fail.
I find that there's not a lot of mitigation planning going on. Risks are usually left unattended. I've done this personally. I hadn't even realized I was doing this until some recent experiences have burned me.
Mitigation of risks is an extra step after identifying the risk and requires further research and thought. You need to reach out to others for help to see what can be done, who can act as backup, etc. It all seems like extra work beyond the actual work needed to get the project done. Perhaps this is why it is neglected. But it is absolutely crucial to do.

Overworked and juggling too many projects? That is a risk. Some projects need a dedicated Project Manager to see them through. Identify that as a risk and tell your boss or PMO. If they are made aware of it, they can remedy it.

More later...

A quote on leadership

I love this quote on leadership by Lao Tzu, the founder of Taoism:

A leader is best when people barely know he exists, not so good when people obey and acclaim him, worse when they despise him....But of a good leader who talks little when his work is done, his aim fulfilled, they will say, "We did it ourselves."

 

Plugging In

What I mean by 'plugging in' is the ability to deliver needed capabilities as a project evolves over time.
For instance, I was assigned as a QA resource on a project which is what the manager on the project felt he needed. It soon turned out that what was really needed was an env manager to sort out issues currently experienced in UAT by outside users. So I straightened that out. Then I started sending out emails about the resolution of those issues daily. Then we got out of firefighting mode.

We've been able to move forward but now other issues have cropped up: we decreased the scope of our release but the other groups weren't notified so a change in the strategy was needed. I made sure this happened.

So now I'm communicating daily with all stakeholders about the status of the project. Sounds like what a PM does eh?

In addition, as those things get sorted out, I am actually doing some QA on the side and noticing things that are off-kilter. I'm communicating these to the dev team for fixes.

So what I am trying to communicate here is 'plugging in': the ability to fill in gaps as they arise. So I'm doing PM & QA/UAT and Env mgmt. The project takes a life of its own and as usual, we are short on resources. I can scream that I was only assigned to do QA and that I shouldn't be doing anything else, but I choose to engage on all levels and move the project along by seeing what needs to be done and doing it.

What it really takes to make it as a PM or BA in this industry is to be a generalist with a passion for learning. To speak with colleagues on the phone an ocean away whom I'll most likely never meet and to understand their pain from their point of view (netmeeting, webex anyone?) and then to demonstrate that pain to an SME who knows how to fix it. This is how I plug in. The SME may not be able to talk directly to the user because of time-zone issues or an inability to properly communicate, etc so I fill that gap.

It's taking care of the simple things: building the small bridges that most people overlook. I like to say that 'adding value' to something doesn't necessarily have to be a big-bang type of thing. You just see what needs to be done and do it. You see where things are being dropped and pick them up. Not rocket science, but it makes all the difference.

Eventually, people will think of you as a go-to person, someone who doesn't drop the ball, who gets things done. And nothing is better than that if you're worried about job security!

The giving of thanks

We recently had a change in management in our group and we have a new head boss. He's already been here a few weeks & is based in London. He came to NY recently and I met him as he did his rounds. That same day, this project I was put on in the last 2 weeks got escalated to him because the stakeholders weren't seeing any progress. This is the highest priority project we have right now and is already late. I got put on the project because I have an excellent track record in QA (which is *yet* another hat I've been wearing in the last year! More on that some other time).

Long story short, the same day I met him, he must have come to my cube about 5 or 6 times to get status updates! There was a quirk in the system that wasn't allowing proper comparison of BEFORE and AFTER files, so the users couldn't compare accurately.

In order to debug this thing, I pulled in resources from North Carolina, India (I called the guy at 6 AM and had him on the phone until 12pm which is 11pm his time), Houston and NY all to figure out this quirk. It was intense and I put in a lot of hours. We never figured out why it was failing but we instead devised another test procedure that was acceptable to the stakeholders.

I've also been placed in charge of all status updates to the stakeholders, so I sent out regular communications to them giving the latest status. I made sure these emails were clear, and detailed who was responsible for what. We steadily made progress and have nearly cleared the entire list of issues.

My boss sent me a note of thanks after each one with things like:

• "Excellent work"
• "Awesome work. Push this one over the line"
• "You have taken ownership and this is exactly what I expect of people to do."
  

Can you believe the impact of one line like that ? It's indescribably awesome! These are emails I will stow away in my personal folder that I can come back to if I want a lift or to show off (I sent one to my Dad!).

Lessons Learned:

• Why be stingy about thanks? Some people don't have it in their nature to be effusive but that's not what's even required. A simple note of recognition can go a long way.
• Engagement, engagement, engagement! This guy was after me for updates and sending out emails to the stakeholders keeping them informed. He knew that the reason stakeholders escalated to him in the first place is that they were in the dark about the project and they felt nothing was being done. The first thing he stressed to me was to keep them engaged, and that is what I started to do. The cool thing is that he did it by his own example: he engaged me! He's the one that kept coming by, called me and IM'd me. So I became that way! Modeling the behaviors you want to see in others...how novel!
• Test the heck out of something. and test it smartly and efficiently. My belief is to test the software so well that you should be aware of any issues before you go into production. And then either resolve those issues or have workarounds. You don't want to go into production and then wind up seeing a problem you've never seen before. Preparation is key. Granted, there are times when something unexpected will happen and we have to deal with it on the fly. But this is rare and my preference is not to deal with the rare. Why spend a dollar on a 10 cent problem?
  
• Ideally, there shouldn't be any need for 'heroes': You know that special go-to person on your team who knows the system inside out and can solve your problems in a pinch. Things should never get that bad. I should have all issues worked out before I go to production and whatever issues there are should be transitioned to the support team so they know how to deal with it. I prefer saying instead that "everyone can be a hero!" and everyone can be if they all perform their roles to the utmost, don't drop things and take an active interest.