How does a PM manage peers?

One topic that does not come up very often with PMs is how to manage one’s peers. Yes, we have discussions about managing the project team and managing one’s managers or “managing up.” You may ask, “Why should I be concerned with managing my peers? Don’t I have enough to do managing my project team?” Well, yes you do, but if you want to be an effective manager, you have to manage your peers. This brings me to my favorite PM, Bob.

Bob is on a team of PMs that implements software for a specific industry. Bob has been an implementation PM for most of his career and has capitalized on his successes and accumulated a good list of lessons learned from his few project failures. Bob understands how to manage his project team and is aware that he must also manage up. However, what he has learned lately is that he must also manage his peers. Not so much in the way that PMs think of management, but in the sense that he must keep himself informed of other PMs’ issues and problem projects. Why? Because Bob has learned that being successful may mean that you can “inherit” other PM’s failures and be unfortunate enough to be the “go-to PM” for the wrong reasons.

So how does Bob manage his peers?

Bob suggests a monthly lunch with the other PMs

Bob sees that some PMs on his team are not as successful with their projects. So Bob suggests a monthly lunch with his PM team to discuss current projects and issues. He suggests that the PMs do so without management in order to get everyone’s objective and unfiltered opinions without fear of reprimands. (We all know that some of us do not express the complete story of one’s project in a general PM meeting with management in attendance.)

What Bob is trying to do is get the unfiltered issues out in the open for all PMs to comment on. Bob sets some ground rules for the PMs. They are:

·        Confidentiality

·        No personal judgments

·        No back-stabbing.

Bob helps other PMs as best he can

Bob also knows that at times a personal touch is necessary when a PM is having issues with a particular project. If Bob’s schedule allows, he mentions to the PM that that he is available to provide one-on-one advice in confidence. Unless management has made the suggestion, Bob ensures that these personal discussions are kept private, as he does not want to be seen as the “snitch.” Nor does Bob want to be seen as the “shoulder to cry on” PM. He wants to be seen as the PM who can help, within limits of course, and as the PM that has staff management capabilities.

Bob ensures that management is aware of his efforts

With the exception of in-confidence discussions, Bob ensures that his management team knows that he is involved and is invested in the team’s’ success.  Bob is discrete but visible to his management team for a reason. Bob shows that he can be trusted by his fellow PMs and that he is a knowledgeable PM that everyone goes to for suggestions and help. This increases Bob’s worth as a reliable PM and a future manager of PMs. You see, Bob not only believes in the open door management style but also believes in the “open mind” management style. Bob has heard many times the old saying, “What good is an open door, if you have a closed mind.” Bob has been at the wrong end of an open door and closed mind philosophy and it is one of his lessons learned.

Bob also ensures that the other PMs know that their problem projects are still theirs. They must lead their project to success. Bob can make suggestions and in extreme cases even lend a helping hand. But the PM on the project bears the responsibility for their own team and issues.

Bob is successful in his organization because he understands the “rules of engagement” when it comes to managing his peers:

·        Suggest an informal PM meeting without management

·        Suggest an informal one-on-one meeting with PMs having issues

·        Ensure that management values his input with other PMs

Bob is looked on by his peers as a person who can be trusted as well as a resource for project management and Bob does not want to have “red” projects dropped into his lap because the current PM on the red project is not seen as the PM who can complete the project. 

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.

The pre-status meeting

I know a certain Project Manager (PM) I will refer to as “Bob.”

Bob knows as a PM, he must be prepared for each project meeting that includes the client, for that is the meeting where the client receives an update on how well or not so well the project is progressing.  However, Bob must make sure that the project team is on the same page in delivering the message to the client.  There must be news of progress or at least news that the client needs to hear and/or make a decision. So Bob decides to have a pre-status meeting with his team to ensure that the message delivered to the client is understood by the team first. So what should Bob do to prepare for the pre-status meeting?

Ensure that the pre-status meeting is on point and brief

Preparing for the pre-status meeting is almost as important as preparing for the client meeting, mainly because the project team members need updates from each other as much as they need to update the client.  First, Bob must ensure that this meeting is no longer than 30 to 45 minutes because the project team members must get back to delivering tasks for this project. So the first rule for both this meeting and the client meeting is to not make this a solution meeting but keep it as a status meeting. That does not mean that some decisions can’t be made. Once again, I cannot stress enough that the project status meeting stays just that, a status meeting. If the project team members begin addressing the issue with possible solutions, this may lead to disagreement and an uncomfortable feeling by the client.  However, most decisions will be about what to present to the client as the next steps if a risk has become an issue. The point here is to have the project team update Bob on their progress on their tasks and to present any new risks or to inform Bob of any issues that have arisen. If an issue has arisen, Bob will not wait until the status meeting to inform the client, as we do not like to present surprises, especially bad ones.

Ensure that all project team members understand the message to the client

Bob guides his project team so that everyone is on the same page, and when the status is delivered to the client, it is one unified message. What the client does not want to see is disparity and disruption among project team members, which diminishes the client’s comfort level and trust in Bob and the project team. Even if Bob has to deliver bad news before or during the client meeting, the whole team is made aware of the message and the solution to the issue or a path to a solution. You see, even if there is bad news, the client wants to hear that the issue is being tended to by the entire team and that they are of the same mind. When this happens, the client may not like that a new issue has arisen, but has the comfort level that it is being addressed by Bob and the project team.

Ensure that the project status meeting

Unless an unexpected surprise pops up just before the client status meeting, the status meeting should have an agenda, a status report, a review of issues and if there is a new issue, what has been found and the next steps. Bob must be in control of this meeting or he will lose the client’s confidence. That is not what Bob’s management wants to see or hear from the client. Bob’s leadership qualities must be used in full-effect as to convey control and a smooth process.

As I stated earlier, there may be a surprise just before the status meeting, but since Bob has the control the client wants to see, those surprises are few and quickly fixed. Having the client’s best interest in mind is what the client wants to see, and the client wants to see that the project is under control. Bob ensures this with a pre-status meeting with his project team. 

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.

The Change Order

One of the most misunderstood documents is the change order. Basically, the change order is the admission that something on the project must change. Whether it is the schedule, the resource(s), or the budget, the change order is sometimes looked upon as an admission of failure. I strongly disagree with the failure mantra that so many managers have, falsely believing that a change order means that something went wrong with the project. Here is where the project manager (PM) must be at his/her best in communicating the reason for the change order. This is where the PM should have communicated to management BEFORE the actual change order is placed in front of management and definitely BEFORE the change order is placed in front of the customer.

So what are the reasons for the change order and what is the best way to communicate the need for one?

Change in schedule

A change in schedule is the most common change during a project and is the easiest to communicate, as long as it is communicated early. When a PM, along with the project team, comes to the realization that a change is needed in the schedule, the PM must begin communicating this need. There are multiple reasons for a change in schedule, with the main ones being:

-  A deliverable will be late because of unforeseen reasons.

-  The client has requested a change in schedule. 

-  A project member has been taken off the project.

-  There has been a change in the budget.

-  The scope of work for the project has not been scoped properly.

Of these, the last one is particularly important: the scope of work has not been scoped properly. In this case a PM must be quickly aware of this and begin communicating this as soon as possible.

Change in resource

A change in resources is not always the main reason for a change order, but I see it happening more frequently. If the change in resource is aninfrastructure change, this is easy to communicate. Basically, the initial scope did not include an infrastructure need that may have been excluded or more possibly, may be delivered later than expected. However, if a human resource is the reason for a change, the PM may have a more difficult communication to management and the client. If the resource is changing early in the timeline of the project, the communication is fairly easy. However, what I see happening more often, especially in Professional Service Organizations (PSO), is that resources are being moved more frequently and usually later in the project. This is harder for the PM to communicate and the PM should be enlisting the support of senior management before informing the client. But even if the PM gets the support of senior management before communicating to the client, this doesn’t necessarily mean that communication will be easier, but at least senior management will be prepared when the client contacts them.

                                                    Change in budget

A change in budget is a frequent reason for a change in a project and can be driven by change in schedule and/or resources. This is the hardest communication that a PM must deliver to both management and to the client. Basically, this states that whoever scoped the project did not take something into consideration. That someone is usually senior management, and this usually occurs because a PM is not brought into the initiation phase early enough to make an impact in the scoping of a project.

However, communicating a change in budget early is vital, and the earlier the better. Any delay can lead to multiple issues for the PM and the project team. First, the PM must enlist support of senior management. But before the PM does that, the PM must ensure that the reasons for a change in budget are well documented. The PM must provide the evidence or the communication will not be received well. Second, the PM must provide senior management the communication before delivering the message to the client. This gives senior management a heads-up and an insight to what objections the client may have. Lastly, this proves that the PM is in control of the process of change for the project. The PM must communicate this change effectively and with evidence for the need for change.

A change order is not a failure of the project, but it can lead to a failure to communicate. The PM must be seen as a leader and the manager of the project. The PM must have the correct information and the right attitude to face senior management and the client for a change order. Most importantly, the PM must deliver this change order so as to meet the project objectives. 

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.

Why and how should a PM become “irreplaceable?”

In these times when everyone is worried about their jobs and their futures, one question I hear from project managers (PMs) is how they can make themselves more valuable for their organization. Some have told me that they are extremely uncomfortable with the lack of control of their destiny. This is the most troubling comment I have received.

I understand the feeling of having no control. However, there are steps a PM can take to become more visible to the right managers. Here are some tips that have helped me in the past.

 Take on the problem projects

If you feel that you are not taken seriously, or that it is a challenge to convince management that you can take on the problem projects and deliver them successfully, then take on the problem projects. I am not suggesting that you take on ALL of them, but pick one or two if the projects are reasonable in size. You will have to do some investigation at first, especially if the project has already begun the execution phase, because it may be too late to volunteer to run that one. However, if you find a project that is still in or has just completed the initiation phase and you know it will be challenging to manage, volunteer to be the PM. In other words, step up and deliverand do so with confidence.

That means you have to do your homework before you volunteer. Ask internally why this specific project is considered challenging. You want to make sure that the project has been estimated properly and that you are not getting into a hornets’ nest. You want to especially ensure that you will have access to management and that you have the proper resources to successfully run the project.

Become vocal

With access to management, you need to do your due diligence regarding what this project needs to be successful. Whether it is a specific resource, additional funds, or a stakeholder analysis. Get management involved early and get their buy in. You see, when I say becoming vocal, what I mean is to become the leader that management needs to complete this project successfully.You must also get the project sponsor involved early and make sure that that specific stakeholder is on your side and believes that you are the PM to run the project to its successful end.

Become instructional

Here is the important part of this discussion. If you are the leader, as you should be viewed, you must also be the instructor. You must be ahead of everyone regarding the project and you must outline the steps the team needs to take deliver the tasks they are responsible for. Your team members for this project expect you to manage and lead, but you must also bring the extra benefit of being instructional. This doesn’t refer to the product you are delivering, but rather offering advice to other project members as to how to handle the client as well as how to manage the project sponsor and the demands coming from that stakeholder. 

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.

Confronting changing technologies in a PM’s career.

I know a certain Project Manager (PM) who we’ll refer to as “Bob.” 

Bob is an Information Technology (IT) PM and has seen a myriad of new technologies, many of which that he ended up implementing. Also, he has been involved in several organizations that have sold services related to new technologies. You can say that Bob has stayed ahead of the curve, or at least kept up with changing technologies. What has Bob done that is different from his colleagues in the PM community? When you think about it, Bob has not done anything special or outstanding in terms of the actual technology, but has done 3 specific things that have kept him current.

Listen to the noise

Bob is an active PM and is PMP certified. He reads PMI periodicals and attends some of his local chapters meetings. Bob also speaks to others outside of the PM circle that may have insight into evolving technologies. What Bob does not do is wait so long that he is not aware of new technologies and how they will affect his organization, and more specifically, what type of project he may have to implement. We hear the new term “disruptive” technology. This basically means that the new technology is different from the current technology Bob’s organization may be using. It also means that business operations may change with the implementation of this new technology. Bob makes sure he keeps current by paying attention to periodicals that keep current with technologies. Bob also speaks to the management team in his organization to listen to their input on the new technology. By taking these steps, Bob can prepare himself if the new technology is a new project for implementation in his organization.

Speak to the “experts” in the new technology

Bob also goes to events and speaks to the new “experts” in the new technology. You may want to call them “guru’s” or subject matter experts (SMEs). No matter what the title, they may have valuable information on how the technology affects organizations, especially Bob’s. You see, Bob can now visualize how this technology will be used in his organization, which also means he can visualize how this technology should be implemented in his organization. After Bob speaks to the management team in his organization and hears some interest in this new technology, Bob can now address that specific manager with valuable information on how the technology affects operations, financials, and even HR. Bob now becomes the “expert” in his organization and will be called upon to implement the new technology in his organization.

Be an active participant

Even though Bob has not implemented or worked with this new technology, he can become part of the conversation on the new technology and its effects, both positive and negative, on organizations. He can blog about this new organization and can even volunteer on a study group that is conducting research on this technology publishing a white paper on it.

All of this effort isn’t only to boost Bob’s career. That is a side benefit. The main reason why Bob does this is so he is not blind-sided when this new technology is now a new project in his organization and he is told that this is his new project. Otherwise, Bob would have to catch up on the new technology, and may not be in a position of strength as the PM on the project.

All in all, Bob ensures that he is a sought-after PM on new technology projects because he makes an effort to keep current on new technologies.

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.

How does a PM react to changing resources in a PSO?

In a Professional Services Organization (PSO), resources aren’t just hard to attain— sometimes they are hard to retain. The reason that pops into everyone’s head is that are source may leave the company. However, in PSOs, sometimes are source is needed on a new project, and as a Project Manager (PM) you may not have the power to hold onto to that resource for your project. So, how does a PM react, or the better question is, how does a PM negotiate with management to leave are source on his or her project? Here are some scenarios that may be familiar to you.

Don’t panic and have logical reasons to keep the resource

As soon as you start your project, your resources become familiar with the project and the client. Take notes on successes that the resource has provided to the client. These will be excellent examples of why this resource is part of the success of your project. Also, if the resource has been with the project since the kickoff, that resource knows where everything is, and not just files. They have become familiar with the client’s structure and sometimes know the client better than the client knows themselves. Also make note of the fact that this resource has been your go-to resource for the duration of the project, and give specific reasons why.

The resource has a valued skill needed for your specific project

Skills are especially valuable if are source is a technical one. If the project requires a resource to have experience with Java, for example, and that project cannot be successful without that resource on the project from the beginning to the end, is a valuable reason for keeping the resource on the project. If the resource has worked with the client before and the client specifically asks for that resource, it is because the resource has knowledge of the client’s structure, particularly the client’s management structure. With this experience, there is some leverage you should be using.

Use the client card, but not often

If the client has used your organization’s services in the past and has had a revolving door of resources, the client may react negatively to changing a resource mid-project. This is a very tricky reason and you cannot use it often. One of the reasons a PSO is in existence is to bring in revenue for services. If a resource is used for the beginning of any project, your management may expect you to expect short services for any resource. This is a hard pill to swallow, but in my experiences with PSOs, this is usually the case.

In the end, it is how you react to the inevitable possibility of changing resources. Your management will judge you the PM on how you react to their decision and how you explain this to the client and manage their reaction. Saying that this is part of a PM’s job does not make this reality easier. Being prepared for it will.

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.

In a project team, who is the “Number One?”

“Number one” is a reference to Star Trek Next Generation’s Captain Jean-Luc Picard’s name for Commander Will Riker. Riker was always Captain Picard’s “Number one” when he needed to get something done. So, in a project, whom does the Project Manager (PM) rely on as their “Number one” to interface with the client when he or she is not available? Is it the Business Analyst (BA), or is it the Technical Analyst (TA) or the Systems Engineer (SE)?

I will use my fall back answer that you, the reader, should be used to by now: It all depends. It depends not only on the type of project the PM is managing, but also the fit of the individual being considered.

Is the project a “technical” project?

What do I mean by a technical project? A technical project is an upgrade of an existing product that is for technical reasons and does not enhance the product. For example, most of us know that Microsoft is discontinuing support for Internet Explorer versions older than version 11. If a product has to be upgraded so the user interface (UI) can be compatible with IE 11 but does not change the UI, then this is a purely technical project. If that is the case, the technical resource, be it the TA or SE, would be my first consideration. Why? Because most likely the client project team would be staffed mainly with technical resources. If the PM has to take some time away from the project, the client will most likely interact with the technical resource on the project and that resource can update the PM when he/she returns. There may be a business user on the client team, but I have found that when the project is technical in nature, that business user usually interacts most with the client technical team.

Is the project a “product” project?

Product projects are most often a pure implementation or a product upgrade. In this case, the main resources on the client project team will be business users. Yes, there will be technical resources, but they will not be the main resource. In this case, when the PM is unavailable, the most likely Number one would be the BA. The BA should be establishing a relationship with the business users from the beginning of the project, so being the Number one will not be a stretch for the BA, or for the client for that matter. Particularly in the beginning of the project, after the PM establishes the project protocols (contact list, status report, etc); the BA should be the main focus. He or she should be the most familiar with the product and the phases of the project and what needs to be accomplished with the PM away. The BA can also bring a more “personal” touch to the status meeting or any interaction with the client.

Which person is the best fit?

Regardless of the type of project, the fit of the individual is more important than the role they play. Even in a purely technical project, a BA may be involved on your project team. If that person has the technical where-with-all and can easily interact with technical resources on the client team, then the BA may be the logical choice for Number one. Conversely, if the PM is going to be away at the inception of the product project and must interact mostly with the technical resources from the client team, then maybe the technical resource would be better suited to lead the project in his or her absence.

However, this leads to a decision the PM must make regarding fit. If the PM is more comfortable with the BA being the Number one in the PM’s absence, then the PM must go with their gut and choose the BA. Also, if the BA is more comfortable with the technical resource because of the relationship with the client, the PM should choose the technical resource on his team. In either case, the PM should know that he/she is not indispensable and must pick a member on the project team to lead the project in their absence. This choice becomes easier once the PM, like Captain Picard, provides guidance to the BA or technical resource on their team on how the PM wants the interaction to occur and who best to fit the role of Number one.

I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine. You may inspire a blog article. I look forward to your comments.