More on Risk Management...

... 17 months and 2 companies later

According to the Project Management Body of Knowledge, there are 6 processes to Risk Management namely:

• Risk Management Planning
• Risk Identification
• Qualitative Risk Analysis
• Quantitative Risk Analysis
• Risk Response Planning
• Risk Monitoring and Control

However, before we all get ahead of ourselves, let's first try to identify the meaning of a Risk.

Risk - An uncertain event or condition that, if it occurs, has a positive or a negative effect on at least one project objective, such as time, cost, scope, or quality. From this statement, we can see two characteristics of a Risk.

The first is that there is a certain level of uncertainty or probability. A risk could or could not happen. If it is something that is already there, then it is not a risk. More likely, it is an issue. To say that the rain is a risk, is wrong. To say that it might rain, is right.

The second characteristic is that it has an impact. All risks have an effect on the projects, whether positive or negative. Each risk could actually have more than one impact. This is why Project Managers need to manage risks - because of the impact it could bring to the project.

Risk Management Planning - As with every other PM activity. The first step is always to plan. But what do you plan about? Here's a couple of stuff:

- Methodology
- Roles and Responsibilities
- Budgeting
- Timing
- Risk Categories
- Probability and Impact Matrix
- Stakeholder Tolerances
- Reporting formats
- Tracking

Depending on the size of the project, not all of these items are throroughly put in a plan. However, it would be good practice to include and/or reference all of these in your plan. Take for example methodology. Some companies already have standard risk management methodologies in place. In doing your own risk management plan for your project, you would just need to reference the company risk managment methodology - not create your own. Just make sure that everyone involved in risk management actually know all about this methodology you are referencing. =)

More inputs next time...

Risk Management for those who think they know what they're doing

[reposted from my yahoo 360 site 5/29/06]

Yes, it hurts.

Risk Management has got to be the most misused, mishandled, and misguided activity done by Project Managers. A lot of it has probably got to do with the fact that although risk management is often deemed important, the positive outcome of proper risk management has never really been appreciated. On the other hand, poor risk management results in disastrous, fire-fighting mode, call in the big guns, why didn't you anticipate that, type of remarks from Management. Often, everything is just hindsight. A reactive rather than pro-active approach.

A good doctor is one who can cure his patients. The best doctor is one who can keep them from getting sick.

The same is true with doing risk management.

Some common pitfalls on Risk Management include:

• No continuous monitoring and identification of Risks. A risk can pop-out anytime during the project. Sometimes, it can even come out because of responding to other risks. A major pitfall for Project Managers is that after identifying the risk, they just let it stay there and not do anything about it. The question a PM should ask to himself is that "What have I done about this risk?"
• Knowing that any change involves Risk. Every single change in the project (which always happens) involve some form of risk. In light of change management, risks should always be considered as a factor for approving changes in the project. There are (a lot of) times that Project Managers do not realize that changes involve risks as well.
  Realizing that risks grow into issues. This is what the Project Managers are supposed to avoid and is the very purpose of doing risk management. In some instances however, risks are accepted in the project and thus are non-issues.
• Planning for Risks. One way of pro-actively addressing risks in a project is by planning for it. A Project Manager cannot blindly say that "my project does not have risks since it is very small." I have seen projects that - specifically because they were very small- were oftentimes overlooked for risks. The sad part about that was that these projects at times cause the biggest problems since no amount of risk managment was done on it and results were catastrophic.
• Knowing that the hardest part of Risk Management is identifying the risk. Oh yeah, baby - this is the truth - and I really saved it for last. Qualifying-Quantifying risks are easy; and so are creating responses from them. The hardest part of risk management involve knowing what are all the risks to the project. For Project Managers to do that, they have to:
• Know what a Risk really is
• Look at projects from all - and I mean ALL angles - in order to find them
  

These are but a few pitfalls of Project Managers when it comes to Risk Management. There really are a lot more - but these are the ones I encounter the most with Project Managers who think they know what they're doing. I'm not being brash - it's just that some people need to realize that Risk Management is not just some buzz word they can throw around thinking that its an inherent thing to do in Project Management.

But how do you do proper Risk Management?... I'll put that one up on my next post.

Process for Process sake is stupid

[reposted from my yahoo 360 blog 2/23/06]

Easier done that thought about.

Sometimes, I just think its part of "Corporate Culture". Sometimes, I think people just don't use their brains that much. The problem with most organizations is that they have a tendency of doing things just because "It's always been done that way!". That has got to be the lamest, most unimaginative, and downright pathetic thing I have ever heard.

Process Management, or what is more used nowadays as "Process Improvement" techniques, actually stem out from the need to "optimize" work and introduce more "effecient" ways of doing things. Methodologies such as CMM and CMMI aim to attain levels of "Maturity" and espouse "Continuous Process Improvement". Others like ISO and Six Sigma aim to improve the "Quality" of the organization and its products.

In all honesty, these things are good. I am not bashing at process methodologies nor am I singling out any of them. In fact, I am a firm believer of processes in the workplace. However, we must always be reminded that these processes are TOOLS used by the organization to achieve more tangible benefits. These activities should always contribute to the bottomline of the organization... otherwise it's not worth doing.

"But all we need is to strictly enforce the process and everything will be ok."

Wrong. Dead Wrong.

If people hesitate doing the process. There is something wrong with it. Process owners need to understand why this is happening. You can never say that there is lack of support or it's taking some time for people to accept the new process. This is simply a telltale sign that the benefits of doing the process is not that acceptable.

Process of the People, for the People, and by the People.

Over the years that I worked with certain processes such as CMM, CMMI, UML/RUP, and the ever notorious SDLC, there are a couple of key learnings that I discovered. This may not be all of it, but it's what struck me the most.

• The Process must be in line with the organizations' objectives. For companies, it's their mission and vision. This answers the question "Why am I doing this?".
• The Process (or part of it) must directly benefit the person doing that part of the process. You can never enforce a process that is only beneficial to only a portion of the organization that does the process. This is simply saying, "What do I get out of this?".
• The Process must have tangible benefits to the organization. This is the realization that doing the process does actually contribute to the organizations' objective. This answers the question, "How do i know that it works?"

I placed an emphasis on the must because its a must. No kidding! It really is! (I could actually just live on the 2nd bullet but I don't want to be that greedy, haha!) As Project Managers, we must always consider these items whenever we implement certain processes in our Projects. Be sensitive on how your team's acceptance of the process you are implementing. Not because it work's for someone elses' project does it mean that it will work for yours. The important thing there is that everybody knows why they're doing the process, what they'll be getting out of it, and how they will know that its' working.

PLINC: General Management skills for the Project Manager

[reposted from my old yahoo 360 12/14/05]

Trust me, this stuff works!

The discipline of project management is essentially a specialized form of General Management. with this in mind, I believe that it can be said that to be a project manager, you have to have some skills that are present in General Managers. But exactly what GM skills are needed? Read on to see what should be taken from the General Managers aresenal of skills.

Problem Solving. Essential to any project manager is the ability to solve problems effectively and efficiently. This is actually easier said that done, especially in the Project Management world since there is a lot more problems to be encountered per day on a project than managing the daily operations of a business or operations. Why? This is due to the fact that projects involve change, and that change involves risks, and that risks produce issues, and that issues are problems that need solving. If i were in the infantry, this would be my grenade.

Leadership. 'nuff said. The most basic of tools for Project Managers. This is your all-purpose standard army issued bayonet knife. Excellent for opening up a can (of whoopass), cutting thru (personal de)fences, and encouraging people to follow your lead.

Influencing Others. The ability to influence others is the most potent weapon of the Project Manager. Far harder to master than a Jedi Mind Trick, it is seen used only by the most experienced Project Managers. This is a mixture of charisma, diplomacy, and guile rolled into one. Perfect for tight deadlines and uncooperative functional departments. This is a special weapon only used by specialists in the army.
Don't think that influencing others is a bad trait. This is perfectly ok - as long as you're not bribing or getting into conflicts of interest.

Negotiation. Almost every activity in Project Management involves some form of negotiation. From stakeholders to vendors, Project Managers negotiate for time, resources, costs, and deliverables. The better you are at negotitating, the more capable the project manager will be in turning the project into a success. This is the AK-47 of project managers.

Communication. What's a project manager worth if he cannot communicate? Each Project Manager is expected to have a communication skill level particularly higher than the average techie guy. As Project Manager, you are the heart of all the communications that revolve within the project. This is your basic side-arm. You simply cannot be called a Project Manager if you cannot communicate. To see if you at least have the communication skills... ask yourself this question - Was there ever a time in my project that something happened that you were not informed about? An added feature or a forgotten requirement? If the answer is yes - then you have a problem.
---------------------------------------
Well, there's actually more to this than what i stated above. Then again, just focus on the PLINC and you've got a good majority of things covered.

A kick-off is not a project milestone

[reposted from my yahoo 360 blog 12/6/05]

There are a lot of misconceptions in Project Management. Here's a short list of some of them:

• A kick-off is not a project milestone. Milestones do not have durations in them. Just like milestones in the real sense, they are merely markers of what you've done so far. This is why when you put in zero duration in MS Project, it automatically treats it as a milestone. (Btw, "Project Kick-Off done" is a milestone).
• The MPP file is not the Project Plan. More often than not, PM's tend to refer to their MS Project file as the "Project Plan". Although it does contain a lot of information, it is only at best - A Project Schedule tool. A Project Plan in the real sense is a document that contains all the information regarding how to perform the project. It contains the scope of the project, the schedule of the project, the cost of the project, and other subsidiary items such as the communications plan, risk management plan, quality management plan, et al.
• The Gantt Chart is not the WBS. Although there are similarities between the two. The WBS is more important and should be the basis of what needs to be done in the project. Note that a WBS does not have a schedule in place but is rather similar to an Organizational Chart of what needs to be done in the project. Btw, the Gantt Chart in MS Project is not a Gantt Chart in the real sense as well.
• The Project Plan is bound to change. Don't let anyone fool you otherwise. Unless the Project would take a day to complete, something is bound to happen. This doesn't necessarily mean that the PM did a bad job in doing the plan, it only means that the project is progressing.
• There's a lot of value in the Project Charter. People often just rush into projects and often think about why they're doing it as hindsight. That is Very Bad! Sooner or later (or sooner than you think), you realize that management does not give a hoot as to why you are doing that project, or that other functional departments don't support your project. Even worse, mid-way in the project the budget gets cut! All these could have been more manageable if there was a Project Charter in place. For one thing, Project Charters give the PM the authority to start a project since charters are initiated by Senior Management. It is THE document that says "Hey, I can use XX resources because this charter says so!"

So there. I've put in a few stuff off-the-bat regarding common misconceptions in Project Management. I'll be posting some more as soon as I finish my Initiation Review (aka "Rites of Passage") with our CIO.

The Art and Science of Project Management

[reposted from my yahoo 360 blog 12/6/05]

More often than not, people consider Project Management as either one or the other. The truth is, Project Management is a combination of both. The tendency for you to sway on one side defines how you approach Project Management.

From an Artistic perspective, Project Management involves the ability to deal with people, influencing them, and negotiating with stakeholders. It also involves the uncanny ability to determine when risks are worth taking. Your "gut" feel and intuition are artforms in themselves... and that these cannot be contained by logic and reasoning.

From a Scientific perspective, Project Management deals with Earned Value Management, Critical Path Management, Quantitative Risks Analysis, and other PM work that deal with numbers and statistics.

What's the best mix, you may ask? Actually, it would be dependent on the needs of the situation. (Knowing the proper ratio in itself is an artistic attribute.) But then one thing's for sure... you have to have both to be a good Project Manager.

I intended to put up this blog in order for me to share what i've learned as a Project Manager - from both the artistic side as well as the scientific side. I believe that by helping promote the Project Management discipline - i can help raise the bar of Project success - not only in my Projects, but of others as well. A lot of times, failure is brought about by lack of knowledge. As as my favorite cartoon movie would say, "Knowing is half the battle!"

Yo Joe(y)!