The search for Professional Maturity

Also known as the x-factor come hiring, performance evaluation, and pretty much everything that requires an assessment of a resource or potential resource.

Professional Maturity is the attribute of a resource to handle various types of business and professional situations in a virtuous, dignified, and responsible manner. Although I think this is just a very broad stroked definition - it's definitely more than this. It manifests itself clearly in situations like a customer is being difficult, or your management requires you to do something above and beyond your workload, or even being able to handle unfortunate circumstances. Professional Maturity brings out the best in a person during clutch moments.

Management loves people who are Professionally Mature. Then again, where are these people and how to I get them? How do I recognize them? The unfortunate part is that it is not easy to spot one since they only shine when there are extraneous situations. I'd like to help out in this search by pointing out some key concepts on what Professional Maturity is and what it is not.

• Professional Maturity is not relative to age. - Not because you are older does it mean you are more professionally mature. Of course there is a tendency for older people to be more professional mature than younger people due to the amount of time they were exposed to the corporate world; but that should not be taken as such. Actually, the best people to have are those that are professionally mature but are quite young. You get more mileage.
• Professional Maturity is not relative to seniority - Not because you've been in the organization longer does it mean that you are more mature. It just means you've been there longer and probably have a better retirement package.
• Professional Maturity is not relative to position. - Not because you are the big boss means that you are Professionally Mature. However, I do want to note that most of the people that do get promoted are those that exhibit professional maturity. The only sad part is that not all are.
• Professional Maturity is about exhibiting grace under pressure. - Instances like having to meet super tight deadlines, being reprimanded, or being handed down difficult situations, and not being dazed or rattled are signs that a person is professionally mature.
• Professional Maturity is being able to take the good with the bad. - Because you know that it won't always be sunny skies and clear weather. A person that is professionally mature is cognizant of this and will not be shaken when bad news comes in. He knows that the world is not perfect and will adjust when needed.
• Professional Maturity is being able to make decisions in the best interest of the organization. - This means being able to make the tough calls - like letting people go or even accepting that you have to leave the organization. He is a person that can the organization can lean and count on.
• Professional Maturity is being responsible and accountable for his decisions and that of his subordinates - Not only does he make tough calls, he also stands by them. A professionally mature person will accept the repercussions of his decisions and that of his team.
• and a lot more...

It may seem that Professional Maturity is a mixture of various attributes of a person, and that it because it is. Its a mixture of 11 (or more) secret herbs and spices as the colonel would say. It is my hope that Project Managers look for these in their resources, as these will definitely improve their chances of having more successful projects. Yes, its not easy to find them - and that is why they are very valuable to have.

The Three C's of Project Management

You probably have not heard of this anywhere...and this is because I made it up myself. Nonetheless, it is something I have been quite preachy about my team over the last couple of months. This is what I call as the three C's of Project Management. Read On:

Communicate Early - A Project Manager must make all attempts to be the first to relay critical information to the necessary parties. Being the person expected by everyone (especially management) to be "on top of everything", it is highly important the the PM be the first to know what is happening within the project. He should be the first to cascade issues up to higher management. This is especially true if there are issues that are beyond his control.

Communicating early also provides some important advantages in the whole area of communication.

1. By communicating early, your statement is taken as truth. Every other statement made on the same topic is validated against what you have said. There is already a certain level of acceptance made on your statement, as opposed to people who reported after you - who end up being defensive on whatever it is you have already mentioned.
2. By communicating early, you can spin your statement in the manner you desire. You can frame your statement in the vantage point that is most favorable to you or your team. You don't end up being defensive and trying to explain yourself or preparing for a rebuttal.
3. By communicating early, you exude proactiveness to your management and subordinates. You look like you are doing something important and useful which is obviously what management expects.

Communicate Often - A Project Manager needs to be able to present a certain level of predictiveness within his project. One way of doing this is by communicating at regular and predictable time frames. The frequency of this reporting also has to be taken into consideration. One cannot have very long gaps between reporting. A good number would be two weeks though it can always change from weekly to monthly. When the gap is too long, information tends to be stale and loses value (see next C). When in doubt, its better to communicate more often than fewer.

There are times that it may seem that your communication is not being well received by your stakeholders. It may seem that it is not being read. Nonetheless, it is still important that communication still persist amidst the lack of interest. When the time comes, that status report will actually be of value especially when things get sticky.

Note however that if status reports and other communication methods are not being received well... there is probably an issue with the last C which is...

Communicate Value - Value connotes importance to the recipient of the information. You need to be able to communicate what the recipient of the information needs to know. For most status reporting, what is important to the reader is the status of schedule, budget, scope, and quality. In order further understand how to communicate value, follow these simple steps:

1. Who will receive my message/communication?
2. What would that person most likely ask me about the project?
3. What is the message that I want to say?
4. If I said the message in the manner that I just did... would the recipient understand it?

****
Communication is approximately 90% of what a Project Manager does on a daily basis. It is therefore very important that a Project Manager achieve a high level of proficiency in this area to be considered effective in his duties.

And so there you have it, the three C's of Project Management.

Spread the word.

PM Toolkit - War Rooms

Tool: War Rooms
Type: Technique

Do we really have to be that militaristic?
Personally, I don't like the term... but then again... its what most people call it so I just let it be.

The concept of war rooms is pretty simple - get everyone involved in the project in one room in order that they may work in the most optimal and efficient way possible. The thing is, with the advent of (not so) new technology and virtual teams, the concept of war rooms is all but gone. The danger here is that management and project management tend to think that it is just as efficient to work virtually than it is to work side-by-side. This obviously is not the case. Distance creates noise and disruption in communications. A video conference can never fully replace a face-to-face meeting. Emails and Virtual spaces can only go so far.

Having a war room for your projects can give you the following advantages:

• Instantaneous response with limited noise. - you can get feedback immediately and correctly. the possibility of things being lost in translation are lessened.
• Improved sense of belonging - you can really feel that you are part of a team - not just via email. There are real people beside you that can encourage and motivate you.
• Sense of unity and urgency - when the PM says its urgent, everybody will pretty much know how urgent the work really is.
• Better project monitoring - you'll know when its done - done. 
• Better issue management - issues can be resolved faster since everybody is there.

As you can see, having your own war room is and will always be the best case scenario. Project teams should always strive to have one whenever possible. Only when certain constraints exists do we opt to do otherwise. Nonetheless, we should always strive to reproduce the war room - even virtually.

Hence in most cases where a war room is not feasible and you have a geographically dispersed team, here are some very useful tips:

• Have a regular meeting with a pre-defined agenda. If you can all meet up at certain dates - do so. If not, set-up calls (preferably video). IM tools such as Skype can reduce costs though in cases like these a good and reliable internet connection is important.
• Agenda for such meetings should contain the following:
• Updates on the planned activities
• Reasons for planned activities that were not performed
• Unplanned activities that were performed
• Any decisions that need to be made by the project team
• Updates on Issues and Risks
• Action items / Planned activities
• Regular meetings should also have light moments. These can be a part of the agenda were people are praised for their work or commended for something good. Just like in a regular face-to-face meeting, it need not be boring and mundane. We are all people and we need to laugh sometimes. :)
• As with any meeting, there should be meeting minutes.
• Ensure that there is a central repository for documents and information, and that everyone has access to it. This way project team members can pick-up files and documents in just one place. There should be limited occurrences of "emailing the file" to the project team members but rather just referencing where it is located in the repository. This ensures as well that everyone has access to the latest version of the file and that there is less dependency on other people to get information.
• There are several collaboration software out there, some even free like Google Drive that can be synced up with Google+ and Gmail.

By keeping these things in mind, communication within the project will definitely improve, and in-turn help the project succeed.

PM Toolkit - Risk Registers

Tool: Risk Registers
Type: Spreadsheet

Everybody knows about it. No one really knows how to use it.

Common mistakes I've seen when people use a Risk Register.

• People often put down a list of risks in the Statement of Work, Proposal, Initial Project Plan and.. and... and... that's it. They forget all about it.
• People define risks in the vaguest most obscure manner possible. Some folks (no, not you) state risks such as "Fire"... "Earthquake"... "Programmer Problem"..."No support"... etc
• Mitigation is the ONLY way of managing a risk. Unfortunately, mitigation is all the way up there in the top ten lists of useless business jargon such as Best Practice, Right-sizing, and Can-do.

Risk registers are an important tool that a Project Manager can use to ensure that projects are delivered as close to target as possible. This is done by ensuring that project risks are managed properly and effectively. But how does one actually manage project risks using a Risk Register?

 A Risk Register is simply a spreadsheet that lists down all the project risks as well as tracks the progress of the responses to the said risk. The important things to see in a Risk Register are:

• Risk ID
• Risk Description
• Probability
• Impact
• Rating
• Response
• Response Status

A Risk ID is simply an identification number of the risk for reference purposes. As with anything that gets listed, it needs to be numbered.

A Risk Description describes the Risk. The proper way of describing risks is to state it in a form of a probability such as "Building might collapse" or "testing might not complete on time". Do not just simply state an object or predicament - state the activity involved that might occur. Describing the risk in the said manner is not only for conventions' sake, but rather it helps in formulating the proper response since the risk is viewed from a very precise probability.

Probability is simply a number. Depending on the organizations' preference, it can be 1-100, 1-10, or 1-3, where the highest number signifies the most probability. I normally don't advise using 1-100 unless you can actually determine a risks probability. Otherwise, you are arbitrarily creating complexity.

Impact is also a number (similar to probability) depicting the level of severity of a risk in the event that it occurs. The highest number signifies the highest, or most severe impact.

Rating is the product of Impact and Probability. The objective of this column is for us to have an idea on what specific risks we'd like to prioritize on. The PM needs to define the threshold by which risks are to be managed and what risks should be accepted.

A Risk Response basically defines how the risk is to be managed. There are many ways to respond to a risk. These include:

• Mitigating Probability - which is looking for ways to lessen the probability that a risk will occur
• Mitigating Impact - which is looking for ways to lessen the impact of the risk when it occurs
• Avoidance - which is performing activities wherein the source of the risk is avoided altogether. To illustrate bluntly, if you would like to avoid the risk of not getting wet if it rains going out of the office - you should not go out at all. This avoids the said risk altogether.
• Transference - which is transferring the risk to another person or entity. If I want to transfer the risk of getting wet while going out if it rains, then I will ask someone else to go out for me. The risk is still there... but I do not carry the said risk anymore.
• Acceptance - which is basically accepting the impact of the risk. You typically accept risks that are either too low probability or low impact.

Response Status - which describes the status of the risk response activities and what is happening to it.

Moreover, reviewing the Risk Register should happen at a regular basis. A good practice would be to include reviewing the Risk Register as part of the agenda during project team meetings. Everyone in the project team should be encouraged to read and review the Risk Register as they may be able to contribute to the said document. Also, the more that people are actively aware of what the risks are, the lesser that chances of people actually contributing to the possibility of the risk from occurring.

PM Toolkit - MBWA

Tool: Management by Walking Around
Type: Technique
One time, a PM asked me what is a typical day in the life of me as a PM.It made me come to think of how I actually manage projects on a daily basis. The short answer is I walk around at the start of the day, while my laptop is just booting up. Just like a doctor doing the rounds, I walk around to each member of the team, asking them a few simple questions:

• How's your tasks?
• Will it be completed as scheduled?
• Any issues/concerns preventing you from completing your job?
• What activities do you need to do next?

These are but sample questions that I ask when I do my rounds. These are not project meetings nor will this be a substitute for project meetings but rather a way for me, as a PM for multiple projects, to get my head around all the things that are happening to the projects. Based on the rounds that I do, I connect people that need to connect together - faster than doing it by themselves (since people tend to forget these kinds of stuff). Doing MBWA will also give me an idea on who is lagging behind and who is ahead of schedule.

I don't ask to many questions, nor do I want to do so, because I can only remember so much information. What MBWA does is basically let everybody tune-in to what needs to be done for the day. It's like your daily cup of coffee to start everything right. By tuning in to what everybody should be doing, everybody also becomes aware of what they should be doing and keeps themselves on their toes with their deliverables.

Lastly, there is a simple set of questions that I use specifically when I am updating ms project in order to correctly determine earned value metrics. I don't do this often, only when i am updating the plan. These are as follows:

• How many hours (days) have you consumed on your tasks?
• How many more hours (days) do you need to finish your current tasks?
• When will you finish your current task?

Note that I never ask for the percent completion, primarily because percent completion tends to be misleading and tends to get stuck at 95% for some strange reason. Answering the 3 questions above help me in understanding Actual Cost/Work, Remaining Cost/Work, and End Date. With these figures, I can actually determine the EV of the project by comparing them with the baseline plan (assuming of course that the plan was actually baselined).