Pennies in Actions

During this time of celebration, I believe it is a good practice to give back, pay it forward, or do something you might consider being generous. So in that spirit I am supporting a nonprofit charity that is raising money for a very important cause. Some of you may know that my wife Marie recently had breast cancer surgery at the Hospital of the University of Pennsylvannia. However, prior to the surgery, Marie received a series of vaccine injections as part of a new treatment for her early breast cancer (stage 0 cancer, also known as ductal carcinoma in situ or DCIS). It is a promising treatment that not only treats the cancer, but helps reduce the risk of recurrence. The doctor conducting the clinical trial of this new treatment, Dr. Czerniecki, is being funded in part by a nonprofit called Pennies in Action and I have made it part of my blog.

Pennies in Action was started by one of Dr. Czerniecki's patients. On the Pennies in Action website, you can find out more about the charity and the vaccine research it is supporting. I ask you to be generous in your thoughts and with your funds. I thank you in advance for your support and your generosity. May you and yours have a great holiday season.

Benny A. Recine, MBA, PMP, PMOC, CAMS

How to overcome communication difficulties when the culture is bad

A colleague commented on my last blog on communication difficulties:

“ I have noticed that while it is indeed a disruptive member at times, more often it’s the culture of questioning the scope, effort, time, etc - well after the project has been started. If possible, perhaps a future blog could be how a Project Manager (PM) can effect/change the culture of an organization, especially when resources are shared and rotate from project to project.”

Unfortunately, my colleague brings up an important point. As much as I believe the disruptive team member is a problem a PM may face, the PM’s biggest communication issue may come from the organization itself, especially when resources are not only shared, but scarce. And let’s admit now that there are organizations that have a culture where individuals question every initiative that may add to their daily work, and some organizations have negative individuals in them. This is an unfortunate reality that some PMs must face. I am not sure a PM can change a difficult organizational culture, but the question is, how does a PM go forward with their initiative in this environment?

First an admission, then…

So, the first thing to do when there is a problem is to admit there is a problem. Some say that admission is 50% of getting to the solution, and I agree that this is true. If a PM is in a bad place because every initiative is questioned, even if the scope has been agreed on or after the project has started, then the PM must come to terms that this is a risk that must be faced. That does not mean the PM is powerless or even at a disadvantage. As I have stated in previous blogs, the PM must communicate the value of the project, particularly if the project is a strategic initiative.

The PM must also have the proper project documents with him/her at all times. This includes the scope statement, the statement of work, and management signoff on all of them. I was asked recently,  ”How you deal with team members who don’t agree with the project scope?” Well, at the kickoff meeting, I go over the statement of work and the approved scope statement and ask the obvious question, “Are there any questions about the scope of the project?” This does not eliminate ALL of the issues that a negative culture can bring to a project, but it sure helps to disarm the negative person at least in the beginning.

Stay true

This statement means to keep straight, or in PM terminology, keep to the project plan. We all know that change is inevitable in a project. This may open an opportunity for that negative member to question that if there is change, is the scope of the project correct? Remember that a change in scope does NOT mean the original scope was incorrect. It does mean the original scope was incomplete and must be adjusted. That must be the message a PM provides to the project team. Once a deliverable is identified as missing from the project, a PM must communicate the message of adding to the success of the project, or more importantly, adding to the value of a project. This can deflect some of the negative responses to change or even the implementation of the project.

And, if that doesn’t work

Even the best defense of a strategic project can still be met with questioning or negative comments. This may be the reality of the organization, in which case a PM must look him or herself in the mirror and ask a question: “Is this something I must adjust to?” Reality and life are hard teachers. Nothing can teach you a harder and tougher lesson than life. The question isn’t if life is a tough teacher, the question is, are you a good student? Sometimes, the PM (or anyone) must look deep within themselves and ask if there is something they can do about the organization. If the answer is no, then other questions must also be answered. That may be a whole new topic and blog.

These steps may not help change the culture in the organization, but it will help the PM in working 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.

How to Overcome Communication Difficulties

You are the Project Manager (PM) on a critical project and one of the first things you have done is introduce yourself to the project sponsor. You have put together the communication list and the communication plan. You had the project kickoff meeting in which you discussed the project scope and the mission of the project.  The project has begun and is in the planning stages.

As soon as the project planning begins, one or two members of the team begin to ask questions that you believe were answered during the kickoff meeting. One person begins to question the scope of the project and the mission derived from the scope. This is where the PM has to spend valuable time, once again, to discuss the scope and the mission. This interruption to the normal flow of the project happens often in your projects. Is it the way you communicate? Are you too quick and skip the details that some members consider important?

Now, before you lose all confidence in yourself, you have to review your communication skills. If you find that you do have to improve your communication skills, I suggest Toastmasters International as an excellent non-profit organization that I have been involved with for almost 20 years.

However, it may be that some members of your team are habitually disruptive and argumentative by nature. You may have users that are part of the project team that were not part of scoping the project and do not feel that they are not part of the team nor that the project is a positive effect on their daily work. What can you do as PM when faced with these problems?

Dealing with the Disruptive Team Member

Every PM or line manager has had to deal with a disruptive employee. A line manager has Human Resource tools at their discretion to deal directly with a disruptive employee. A PM does not have the same tools that a line manager has, but must deal directly with the disruptive team member. For a PM, this is a tightrope that must be walked very carefully. Here are some steps that a PM can take:

·         Speak directly to the disruptive member.  Confrontation is not something that most people look forward to. However, we have all had a run-in with the individual who seems to argue for argument’s sake. A PM must confront this person before other members begin to become disillusioned with the PM leading the project. Appeal to the member’s sense of team unity and mission objectives.

Do not reject this suggestion out of hand. If the PM has conducted the kickoff properly, the PM should discuss the benefits of the project, the uniqueness of being selected for the team, and the need for unity and team work. These points should be important factors to the member. Being part of this project can benefit the member’s career. These should be the topics that the PM should bring up and hopefully influence the member to rethink their approach to the project and to other team members. 

·         Speak to the disruptive member’s manager. This has to be done gingerly as not to make the manager feel you are overstepping your bounds. First, you must inform your manager of your decision to meet with this manager about a problem employee. Next, you must ensure that you are prepared with details regarding your attempts to give the disruptive member every opportunity to change their disruptive ways and what your expectations are from the meeting with the members’ manager. If the member is still needed on the project, the objective is to convince the manager that he/she speak to the member to consider a different approach to the project. If the member’s actions are considered more disruptive than the member’s contributions are needed, then the PM must request that the manager remove the member from the team. 

 

·         Demand that the member leave the project team. The last step is to remove the disruptive member from the project. Removing a resource is the last thing a PM wants to do, considering how difficult it is to replace a resource. However, it all the steps you have taken have not worked, the PM does not have a choice. Throughout this process, the PM must be taking notes and make sure that all interactions are documented for any HR needs.

In all of this, the PM must keep his/her composure to ensure that he/she is viewed as the manager who wants to keep the project moving forward. The risk is that the resource may make this personal. The PM must keep above this type of discussion. In the end, the project will fare better without this resource. The PM must keep the good of the project and the rest of the project team in mind to ensure success.

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 Difficulties for a PM in delivering bad news

No one likes to deliver bad news, but it is a reality of the project manager’s (PM’s) professional life. In a project going along very well, the first issue may be the worst to accept. In a project that has gone yellow or possibly red by missing project deliverables, this can add more angst to what already exists in the project. In an already red project, more bad news brings morale down even further such that no one on the team believes the project will ever meet its objectives.

If this sounds familiar, then join the club of PMs in a bad project. There is a proper way to deliver news no one on the team wants to hear, however bad it may be. Unfortunately, it is easier to take the low-road and join in the chorus of the “we will never end this project” naysayers. As the PM, you must stay above the fray and have a clear vision of the next steps and the end or even the closing of the project.

Be honest and transparent

The first mistake most PMs make is to sugar-coat the problem(s) and issue(s) of the project. The other project resources will see right through your attempt to downplay the problems of the project. I cannot stress enough that the PM can be empathetic, but must have a vision and road map to complete the project.  Even if the PM doesn’t have a clear vision, the next task is to bring the project team into the solution process by asking them to draw up the project road map based on the issue(s). If the members of the team feel that they can contribute to the solution, they may come up with the best way to get the project out of the red. However, be clear and honest about the project’s issues and the roadblocks ahead. If the project team understands the gravity of the problems, then they can address their solutions properly.

The PM must also be honest to the client and senior management, especially to the client and project sponsor. They must be on-board with your road map to resolve the issue(s). The job of the PM here is to get the client and project sponsor on-board with the plan to resolve the issue(s) and complete the tasks and project. Without their support, the PM will be fighting windmills and will not be successful. He must also get buy-in from senior management of his organization. That should be an easier task than convincing the client or project sponsor. However senior management, along with sales, must be aware of the plan and the risks.

Be direct and realistic

It was Yoda who said “do or do not, there is not try.”  In this case, that must be the PM’s motto. If in fact the project team believes there is a “silver bullet” for the issue(s), the PM must be able to bring them back on task if the resolution, however good it may sound, is not realistic. The PM must be tactful, but direct and realistic. What does the schedule allow? What are the expectations of the client and project sponsor? Are the team members willing to risk the complete failure of the project? What are the benefits, if any? These questions must be asked, discussed, and answered. Here is where the PM must take copious notes. The PM must be able to refer to these notes and logs of the events. They will be the PM’s best friend later when questions arise.

Be very clear

This is not the time for the PM to become verbose or too descriptive. The PM must be clear, or as we say, use “go or do not go” type of answers. There must be no confusion whatsoever. Speak up (don’t yell), and make sure the project team understands what you are saying. Bad news is tough enough to deliver, but to be misunderstood in delivering the news makes a bad situation much worse.

It goes without saying that no one enjoys delivering bad news. It does come with the management terrain. Do not forget that, as a PM, you are the manager of the project. The PM only has some of the privileges of management, but all of the accountability. You either have the wherewithal to conduct the management of the project or you do not and part of the job is delivering bad news.  

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.

Who is on the project team – A response

A colleague responded to my last blog with the following remarks:

I would imagine, as a customer always wanting the "best" resources, that internal (at the PSO) collisions for top talent are a frequent occurrence.  How is that typically handled?

 

In a PMO

A Project Management Office (PMO) should be structured in such a way that the next available resources that have the necessary technical abilities will be chosen for the project. This does not mean that a project sponsor or end-user cannot request a specific project resource(s) for their project. This does happen, but depending on the strength of the management of the PMO, this request may be denied. As much as this is a compliment to the specific resource(s), it diminishes the charter of the PMO. It must be explained that the reason why a PMO is there in the first place is to staff the approved and funded projects for the organization with the available resources that have the technical ability necessary to complete the project.

In a PSO

So, as my colleague asked, how often does a request for a specific resource(s) happen and how is it handled? In a Professional Service Organization (PSO), the first thing we must admit is that this “problem” exists. First, a PSO has a good problem when the client employing their services requests a specific resource or resources, and this happens more often than we like to admit. This means not only that the resources are doing their job very well, but also that clients recognize this.

Now, after all the accolades, we must resolve this conflict. There are multiple ways to handle this; let’s go over a few:

·         Can the PSO start a project if another project is on hold?

If the project that the requested resource is currently on is in holding pattern for whatever reason, that presents an opportunity for that resource to begin the project of the newly requesting client. Now, the project manager (PM) has a balancing act to perform. The PM must be able to convince the current client that nothing will slip if the resource goes off project and then comes back. The proof is the execution of that promise.

·         Can the current project share resources with a new one starting up?

Depending on the type of project, sharing resources must be an option to be discussed. If the current project cannot support full-time resources, then it is obvious that the requested resource can, and most times will be used as a shared resource. This is what happens most times anyway and must be shared with the current client as soon as the project begins. In other words, the PM must be transparent about the project’s resources. If this is a surprise to the current client, then the PM must set their expectations straight. 

·         Can you switch resources on the current project?

This depends on the depth of the PSO’s bench. If the current project has just started or is about to close, then the requested resource can often be pulled from the current project and sent to the new or requesting client. Once again, the PM must be transparent and explain this switch with the management of the client that has the current project and with the project team. This is the least desirable choice because it may leave a bad taste in the mouth of the current project. However, this becomes a choice if there are no other options and the requesting client has an immediate need.

There is one other option that I haven’t mentioned and that is to say no to the requesting client. Now if the requesting client is insistent about the requested resource(s), then the start of their project may be delayed until the resource is available.

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.

Who Is On the Project Team?

Resource management is a crucial part of any project. A project manager (PM) must have the necessary people with the necessary experience to complete the project. What a PM needs just as much is the tools (i.e., SharePoint, MS Project), an accessible senior management team, an informed sales team, and just as important, a project team with the right attitude.  In this blog, I will discuss the importance of resource management and the PM’s juggling of those resources, senior management’s response to critical issues, and the team attitude.

The PM’s Resource Management Juggling Act

Whenever a PM begins a project, that PM has to assemble a team to plan and execute the project. In a Professional Service Organization (PSO), the PM must be ready to have a team as soon as the statement of work (SOW) is signed, sometimes having the team begin work the next day. This means the PM in a PSO has to begin putting the team together as soon as the client is close to signing the SOW. In a PSO, the PM must be an exceptional time manager in the sense that the PM may have to juggle resources between projects.  The PM must be careful not to jeopardize the progression of one project just to begin another. Conversely, the PM must be careful not to jeopardize the beginning of another project just to advance the established project. What can help here are virtual workers. More and more clients are accepting the new reality of having virtual resources work on projects executed by vendors. This is an advantage that the PM must utilize, but tactfully so as not to give either client any cause for concern.

This juggling act comes with multiple risks that must be acknowledged and controlled by the PM. The PM must be in constant communication with the members of all teams. This should be the least of the PM’s risks. As a PM juggling more than ten projects at any given time, I have been contacted for almost every single type of issue, sometimes for very small matters. However, if a PM wants to have the finger on the pulse, sometimes the PM must be informed of the smallest of issues to resolve.

Senior Management Response

The PM must discern which issue is minor and which is a major issue. Hopefully there are fewer major issues, but we know that is not a reality. In a PSO, clients believe almost all issues are major. As a PM, we must set expectation levels regarding project deliveries and project issues. The PM must keep the salesperson informed in case that salesperson drops in to visit the client at an inopportune time. The PM does not want to “blind-side” the salesperson. Also, PMs must discern which issue must be brought to senior management’s attention. Project show-stoppers must be raised immediately to inform senior management of a possible angry call from the client. So as not to be labeled as the boy or girl who cried wolf, the PM cannot bring every single issue to senior management’s attention.  A properly kept issues list identifies issues as show-stoppers, or as critical, high, medium, or low issues. This gives senior management the information it needs to address the client in future endeavors and to help the PM if necessary. 

Which Resources to Choose

The PM has to select from a resource pool to fill various project roles. Whether the role is a business analyst, a subject matter expert, or a developer, the PM must be able to get the right mix for the project. I am convinced that most resources have the tools necessary to fulfill a project role. The PM becomes a juggler in selecting individuals with the right attitudes to complete the project.  There was an author who wrote that “attitude is everything.” Although attitude may not be everything in an IT culture, it represents 80% of the need in picking the right resource. That may seem like a high percentage for an attitude, but a bad attitude is poison for a project team.

Availability is the next selection criteria. You may want a specific resource for a specific role, but if that resource is not available for your project, then you better have a second resource in mind. In a PMO or PSO, resources are stretched thin, even in good economic times. I do not know of many organizations that have a deep “bench” of resource that are sitting around waiting for their next assignment.

Having a resource that has worked with a client before and is familiar with the clients’ personnel is a nice-to-have. This is not always available, but can add value and continuity for your client.

The last criterion is ensuring the resource has the tools to complete his or her tasks. Although I have left this for last, it is critical that the client view you and your team as the experts in your respective fields. Delivering quality project deliverables and quality personnel to the project is crucial for the successful completion of your project. 

Selecting the right resources can result in a successful outcome for a project. This is as important as delivering a SOW that properly defines a 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 Value of a Delivered Project

Recently, someone told me that a project must have value, or as I interpreted it, value that is understood and communicated to management.  In saying that, I can also say that what is missing in many projects is the understood and communicated value of a project.  The Project Manager (PM) MUST communicate the value of the project to the team. If this does not occur, then the direction of the project team will be all over the place, unfocused, and unmotivated.

What is “Value?”

I could be smart and say that value is in the eyes of the beholder. The question really is: What is the strategic value of the project? If the project team cannot understand this or communicate it as well as the PM, there is trouble on that team and the delivery of the project may be in jeopardy. It is critical that the value of the project comes from a strategic vision and that vision must be delivered by the project team. If that occurs, no matter how “small” the project may be the value of the project and the team delivering the project will be appreciated by the organization’s strategic team.

Value is determined not only by the project team, but most importantly, senior management. The PM’s job, as well as that of the project team, is to deliver what is expected. No less and no more (ie, no scope creep). Remember this statement, “no surprises.” If the project team delivers exactly what is expected, then the value of the project is delivered.

Communicate the success

Now, just because the project team delivered the strategic project on time, within budget, and within scope, it does not mean that senior management will notice or even say thank you. In my past blog posts, I have stated that the PM must communicate with all parties: the project team, the sponsor, and senior management. In the past, most would suggest that this would ensure that all news, especially bad news, is known and not a surprise. Well, this holds true for the good news of a delivered strategic project, especially the value of it. The PM must be the key person in delivering this message of success.

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.

Fostering Partnerships in PSOs – A Response

I received the following response from a colleague to my blog, “Fostering partnerships in PSOs”:

“Asking Sales to meet with a Project Management Office (PMO) when they are 85% sure of a sale - is a little "out of bounds" in my opinion.  The PMO should focus on delivering valuable tools/services - to meet the business needs. If Sales (or any other organization) brings forth an idea, I don’t think it should be stipulated on a percentage of opportunity.  I am also not saying a PMO should be an order taker (as you note in this and earlier posts it’s a team effort), but at some point the decision/budget/authority to move forward with an initiative to improve the organization - must come from Sales (or other internal org) responsible for growing the top line or improving the bottom line.”

Agreement on a Partnership, or Failure

Let me begin by saying that I did speak to my colleague who commented on my blog. First, I agree that the PMO in a Professional Services Organization (PSO) should not be the final decision maker whether a project begins or not. However, a certain mark must be agreed upon and met between Sales and the PSO to begin to be involved in the initiation phase of a project. Otherwise, the only things that will be fostered are bad will and failure. The PSO must realize that a qualified sale, especially one that increases revenues and may add to the bottom line of the PSO itself, must be planned. Sales must realize that the PSO should become involved when the customer has come as close to being a viable project as possible. If the PSO comes to every sales call, the PSO cannot meet its revenue budget that it will be held accountable to.

In the discussion I had with the commenter, I gave an example of an experience I had in a PSO. The salesperson came to the PSO saying that there was a potential client that wanted to have a meeting with us regarding a “very hot” sale. I went to the meeting anticipating a planning session; what I experienced was a meeting where the “very hot” sale was a request for my project plan (which I did not provide).  So, what is needed is an agreed upon measurement between the two organizations that must be met by both organizations before proceeding.

What We Agreed On

When my colleague and I discussed my article further, my colleague mentioned that what is needed by the Project Manager (PM) is “gravitas.” I stated that the PM must not only be able to communicate, but must not shy away from confrontation or delivering bad news as soon as either presents itself. The PM must communicate not only to Sales or Senior Management, but also to the project sponsor, client, users, and especially the project team.  Take it from a PM that has failed in the past: a PM must be able to communicate and confront. By the way, when I say confront I don’t mean in a physical or menacing way. Even the Project Management Body of Knowledge (PMBOK) states that the best way to meet an issue is to confront it straight on.

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.

Fostering Partnerships in PSOs

In any Professional Services Organization (PSO), you want a clear communication channel between Sales and Project Management. As a matter of fact, you want to ensure that your Project Management Office (PMO) or delivery organization has a team mentality. In the scenario I am mentioning, the PMO or delivery organization supports Sales. This type of team mentality must start with Sales understanding what can be supported and what cannot. This is very similar to writing a Statement of Work (SOW) in which you begin with the scope statement and define what it in scope and most importantly, what is not in scope. How is this done and how does a PMO or delivery organization ensure that Sales is not “shooting from the hip” when in front of the customer?

How does Sales know?

It is the responsibility of both Sales and PMO/delivery organization management to meet and begin the educational discussions. Yes, I said both management teams must educate each other. What Sales management must educate the PMO/delivery organization management team on is what Sales is hearing from the customer base. What does the customer base want? What is important to them? What the PMO/delivery organization management must educate the sales management team on is what they can deliver based on the current schedule, and most importantly, how does the PMO/delivery organization fill the customer base’s needs? Let’s assume that the question is not whether the PMO/delivery organization can deliver what the customers are requesting. The most likely discussion should be the challenges in scheduling projects.

What to discuss at management level meetings

There must be some ground rules:

First, Sales will bring only those qualified sales that are at least 80% to 85% certain.  The delivery organization/PMO does not have the time to discuss anything below that certainty level.

Second, the delivery organization/PMO cannot shy away from being creative with regards to scheduling. In other words, the delivery/PMO can schedule multiple project kickoffs during subsequent weeks.  Not all projects will have five straight days of project work for the project team. Most likely, there will be more than one project team, and more than likely, more than one Project Manager (PM).

Third and lastly, both teams must be open to change regarding which projects are worked on and which must be delayed, the delay in the delivery of a piece of software, or even a change in project resources. What I have found in PSOs is to expect just about anything. Especially when you have a short resource bench, you may have to be creative in plugging holes for resources and schedules.

Sharing responsibility for project deliveries

Yes, even Sales have some responsibility for the delivery of the project by helping set expectations and being the communication conduit to the client. The PM has the overall responsibility of project delivery for the PSO. The PM must communicate to both his or her PSO and the client using the reports I’ve discussed in earlier blogs. These include the status report, the issues and risks report, and any change management reports. However, the PM must communicate the issues to the PMO and the salesperson as soon as a critical issue becomes evident.  Sales must be informed because the first complaint telephone call from the client will most likely be made to Sales, then to PMO management. How to confront this critical issue is a discussion between the PM, the PMO, and Sales. Depending on the critical issue, development may also need to be involved. How to deliver the next steps to the client must be agreed upon by all parties.

If you would like to comment about this blog, please do so by responding in an email at Benny A. Recine, or if you would like to publicly comment in this blog. I will respond as soon as I can and you may inspire a blog article. I look forward to your comments.

Dealing with Conflicting Priorities

I received an interesting inquiry regarding my last blob, “Conflicts in a Professional Services Organization,” that made this statement:

”With more and more matrixed projects (sales, operations, etc); the conflict could come from competing priorities and/or schedules on the "customer" side.   That is, one customer may deviate from plan and ask for an additional enhancement (or requirement) that could add "xxx revenue" to the organization.  Yet, delay in delivering that item could lose xxx in savings to the operations team”.

Project Managers (PM) know this all too well, whether we are in a traditional Project Management Office (PMO) or in a Professional Service Organization (PSO). This statement captures scope creep and the traps that come along with it very well. The additional enhancement is something that was missed in the initial stage of the project, but is necessary for the successful completion of the project. So, what is a PM to do?

First, do no harm

So, the PM is happily reporting that the project is green and progressing along very well. Then, the project sponsor, or the client, along with the users or the customers, alerts the PM that there is one missing deliverable. Calmly, the PM collects the information and realizes that the additional deliverable will make the project late and over budget, not to mention that this request is out of scope. So, the first priority for the PM is to ensure the success that has been accomplished during a project is not jeopardized by this additional deliverable. So the first thing the PM should say is the following:

“I understand that this additional deliverable brings with it sizeable advantages for the product. I also acknowledge the work of the project team for delivering a project that is meeting scope, time, and cost so far. I believe I have all of the objectives of this new deliverable and new scope for the project. What I will do is come up with a change request that will review the additional deliverable and the changes that this additional deliverable brings with it. I hope to have this change request delivered to you in XX days so that the project team can review and evaluate it”.

Let’s review what is stated in this message. First, the PM acknowledges the project team for delivering a project that is, so far, within budget, on time, and within scope. It is critical that everyone on the team understands this point. The PM is simply saying that gold-plating is not acceptable and that the current success of the project must not be jeopardized. The PM is also saying that, besides the additional scope, time, cost, and possibly additional resources may be added.

Now, this additional deliverable brings with it additional revenue for the client/customer and possibly additional revenue to the team delivering the project, the PSO. So the PM must keep this in mind when evaluating this additional scope. When evaluating this new scope/change, the PM must also take into account the additional value this new deliverable brings with it. Also, when evaluating this change, the PM may have to add additional resources, as the current project resources may not be able to deliver certain additional tasks that will be added to the project. Once the additional costs are tallied and the possible change in delivery date is determined, the PM must discuss this with his or her management first. The PM’s management must be convinced that this is the correct course of action, along with the change in scope, cost, time, and possibly resources. If the delivery date is not something that can be changed, then the need for additional resources is almost a certainty. If the change only moves the delivery date out a short period, for example a week, without adding resources, then the PM may be able to deliver a change request that may be acceptable to the project sponsor.

Integrity

It is imperative that the PM keeps composed and delivers the change with integrity and composure. The project sponsor needs to know that the PM is the leader as well as the manager of the project. This change is a challenge that the PM must meet and use his “capital” to keep the project sponsor as an ally. There is no greater responsibility for the PM than to keep his or her integrity, even in the face of a change that may be difficult.


If you would like to comment about this blog, please do so by responding in an email at Benny A. Recine, or if you would like to publicly comment in this blog. I will respond as soon as I can and you may inspire a blog article. I look forward to your comments.

Conflicts in a Professional Services Organization

Project Managers hate it, but…..

In any organization, you will have conflicts that are sometimes professional, and sometimes not so professional. Project Managers (PM) in Professional Services Organizations (PSOs) are no exception to this unfortunate reality. Whenever you have a close relationship and combination of Sales, Senior Management, and Project Teams, you may have more than a few instances of conflict. The question is, how can one reduce the number of conflicts?  The answer is by communication.

Communication to Reduce Conflict

There are a number of beneficial communication steps that can be taken to help reduce the number of conflicts between PMs and Sales and/or Senior Management. However, before I begin, I would like to mention a disclaimer. It could come to pass that none of the steps I am going to mention will work. However, if you institute these steps, you must devote 100% of effort to them or else they may fail. However, if you devote 100% of effort to these steps, not only could they succeed, but they could exceed your expectations.

Communication with Sales

First, the Sales and Project Teams must realize that they may be singing from different hymnals. Sales have quotas that must be met. Sales must meet their numbers, and they are incentivized by commissions and bonuses. Project teams are concerned with the triple constraint of their projects, which includes their budgets. 

The part of the project that Sales and Project Management meet is project initiation. If the Scope of the project has not been defined during project initiation, the Project Manager should be involved in developing that document. This will begin the transfer of the project from Sales to the Project Team.  In that meeting, all discussions Sales have had with the client’s project sponsor must be disclosed. What must be discussed in detail are the issues the client has discussed with Sales, which may be risks to the project. Also, the Project Manager wants to understand what was promised to the client. Now, I am not saying that Sales may sell a project that may be difficult to deliver within the triple constraint, but that the PM must understand what the deliverables are. The Statement of Work (SOW) must put the deliverables in writing and must specify what is in scope and especially, what is not in scope. 

This begins the “partnership” with Sales, but does not end the conflict. This does however, begin to alleviate it.

Communications with Senior Management

The conflict with Senior Management is usually with schedules, resources, and of course, project priorities. The most effective form of communication with Senior Management is the Status Report.  In this Report, the PM must show the conflicts that he or she is having with schedules, resources, or priorities in the form of a Red, Amber, or Green designation. Here is a caution for the Project Manager: Make sure that not only the project sponsor is aware of the conflicts in a project as soon as they occur, but most importantly, that the PMs direct Manager and Senior Management is aware of them. There is an old adage in project management that there are “no surprises.” What a Manager hates more than anything is to be “blind-sided.” The PM must keep his/her Manager in the loop as soon as a potential hot issue comes up. This is not an excuse to cry wolf. The PM must know the difference between a hot issue and just an issue, and these must be discerned in the Status Report.

Conflicts in schedules, resources, and priorities may come from Senior Management, with their ever changing priorities dictated by Executive Management. We all know that priorities change from the top and PMs must make the best of the cards that are dealt to them. However, PMs must be able to communicate the effects of these priority changes on their projects. The Status Report is the best method to do this.

In Summary

In all of communications, getting to the point is important, especially with the audience I am speaking of above, Sales and Senior Management. Details are also important in this area, but pick the audience for the details very carefully. Sales wants to ensure that the project stays on schedule and that there are a minimal number of issues. Senior Management is concerned with resources, specifically the effective and efficient use of them, and that all issues are being managed to the client’s expectations. All of this must be done effectively and succinctly.

In all, PMs must be effective communicators. If communications is an issue with you, speak to a mentor or check out a local Toastmasters International chapter. You do not want to fail for any reason, but you do not want to fail because you failed to communicate.

 If you would like to comment about this blog, please do so by responding in an email at Benny A. Recine, or if you would like to publicly comment in this blog. I will respond as soon as I can and you may inspire a blog article.

Project Vision: Getting Into Focus

One of the many comments I have received on my blogs was regarding vision, specifically the “blurriness” that a Project Manager (PM) must contend with when beginning or during a project. One of the things I have learned is that a project must be aligned in some way with the organization’s strategy. No matter how small the project is, it must tie back to the strategic vision of the organization. Now, in a Professional Service Organization (PSO), a project will most likely be revenue generating, implementing a product, or providing consultative services. So in that case, the vision can be explained in that the PSO is delivering a service to other organizations. However, in a Project Management Office (PMO) or an Information Technology (IT) group that has its own Project Management  group, the vision for a project has to be defined in a project for the PM and the project team. So let’s take them separately.

Project Vision in a PSO

As I stated in my opening paragraph, project vision in a PSO should be straightforward. The PM has to keep focus on the scope of the project using the scope statement and statement of work (SOW).  The major issue that confronts a PM and the project team is scope creep. This is especially hard in a consultative environment, considering the users or client in the project team would most likely want to stretch the funding of the project as far as it can go. This is only natural and should be expected by the PM of the project. What I have found effective is to review the SOW and the scope statement at project kickoff, reviewing what is in scope, and stating for the record that everything else is out of scope. During the project, with the Risk and Issues list and the Status Report as tools, the PM must keep the project schedule on track.

Project Vision in a PMO

In a PMO, one must ask:  does this project directly or indirectly tie into to the organization’s strategic vision? The PM and the PMO lead must ask this question before committing to take on a project. If the project does not, then the PM begins the project with the knowledge that this project is not a strategic one and the resources provided may reflect that knowledge. The PM must be responsible and provide a project schedule that reflects the importance of this project.

If the project is strategic, then the PM may be provided the resources that reflect the necessity of implementing this project and ensure that that scope creep (similar to a PSO project) does not rear its ugly head. However, it should be noted that there is a different dynamic with the project team from a PSO project. In a project run by a PSO, the PM should strive to make the client or users in the project team the champions of the project. In a PMO project, or a project that starts from the strategic management of the PM’s Organization, the PM should make the project sponsor the PM’s best friend. This person holds the purse strings and usually has some members of the project team reporting to them. Once a project begins to enter a yellow status, the project sponsor should be one of the first to be notified by the PM.

The scope statement and the SOW should also be used by the PM to ward off any scope creep that other project team members attempt to bring into the project.  These documents should be the PM’s most reliable asset. If the PM must re-emphasize the scope of the project to the project sponsor, there is no better tool than a signed SOW, especially if the SOW has been signed by the project sponsor. I find this is a task that a PM must do continuously in a PMO project.

Conclusion

The PM walks a tight-rope in keeping the vision of a project, whether it is a PSO or a PMO project. The scope statement and the SOW are the PM’s best tools to keep the vision of the project. Remember that the dynamics of the two projects may be different, particularly in the members who make up the project team. Reviewing the SOW at the project kickoff is a good tool and is strongly recommended.

If you would like to comment about this blog, please do so by responding in an email at Benny A. Recine, or if you would like to publicly comment in this blog. I will respond as soon as I can and you may inspire a blog article.

My next blog will be about conflicts in a PSO. Until then, be well.

The Tools of Communication – Part 4 – The Remaining Reports

The next several reports are not “critical” communication tools but are important. Since some of the documents that I discuss below may not be used in a project, I thought it best if I included them in one article.

Meeting Minutes

This report seems to be the most controversial of all the reports involved in a project. The controversy revolves around who will take the minutes. Until recently, I have advocated that the Project Manager (PM) or the Business Analyst (BA) of the project team take the minutes. With my recent association with Professional Service Organizations (PSO) and Project Management Offices (PMO), I have come to the conclusion that the most important document from the team is the Risk and Issues List. If the team is focusing on the meeting minutes, then the project member taking the minutes most likely may not participate in the meeting. Since there are multiple formats of the meeting minutes, I will not comment on the actual document. I will however suggest that if the Risk and Issues List is properly documented, then the “minutes” can be taken from there. If the meeting minutes are taken, it is my opinion that the duties of the “scribe” should be shared by the project team so no one person will always be taking notes.

Project Risk Document

The Project Risk document should be developed as soon as the project is approved and given to the PM. This document is an identification and ranking of the risks. This document should include both qualitative and quantitative analysis and should rank the highest risk to the lowest. Also, this document should contain the possible resolution of the risk if it becomes a reality. This document should be started by the PM and then reviewed by the project team members to comment on and possibly come up with solutions. The high risk items in this document should be reviewed by the project team on a regular basis and risk items should be added to the document as appropriate.

Communication Plan and Contact List

What’s the difference between the communication plan and the contact list? The contact list is just a listing of individuals, their role in the project, and their contact information. However, a communication plan develops an approach to communication during the project. This is not just the number of status meetings the project should have, but also identifies who should be involved in the status meeting, who should receive the Status Report and Risk and Issues List and so on.  Also, and just as important, if there is a show-stopper issue, who do you call first?

The Project Schedule

The most misunderstood document of a project is the Project Schedule, which is sometimes called the project plan. The project plan includes all of the documents of the project, including the budget. The Project Schedule is the tasks and their duration, resources associated with the task, and if the task is on the critical path. This is the full-view of the project, from initiation to project closure. This is the document on which earned value calculations are done.

Vacation Schedule

Most PMs will enter the vacation schedule of the project team in the Project Schedule. This is a necessary document for the PM to have. However, a separate document that all project resources can access and update is also necessary. All project resources have to be aware of the vacation schedule of the team.

Where does all this documentation go?

In this era of emails and attachments, it is necessary that all documents go in a central repository. The tool to create this repository is up to the management of the PSO, PMO, and the organization.  This repository must allow access management to all project resources. There are several options to use, even an actual cabinet if the team is collocated. Whichever way is used by an organization, the method of filing must be consistent with every project.

In my next blog, I will discuss vision in a project. This was a request from one of the many emails I have received from my blog postings. Please keep them coming by sending them to Benny A. Recine.

The Tools of Communication - Part 3 - The Status Report

There is no other communication tool that management likes better than the Status Report. It is a two-page view of the status of the project. It is very clear and unambiguous in its communication; the project is green, yellow, or red. There is no confusion in that message. What is sometimes confusing is the explanation of a yellow or red status. Below, I will discuss how to make the Status Report the most understood report in a project.

 The Status Report

The Status Report, sometimes referred to as the “Red, Amber, or Green (RAG)” report, is the most common report on a project. In one or two pages (no more than two), this report should provide the project team and senior management the entire picture of where the project stands. However, its brevity is as important as the message that is conveyed. In addition, one of the most important rules in project management comes into play here: no surprises.

If the project is green, or on track, the message should be short and to the point, summarizing what will happen next and which risks will be closely watched in the upcoming period. This is the easiest communication a Project Manager (PM) has to deliver.

If the report is amber or yellow, then the report may be two pages. This report must elaborate why the project is yellow and what will be done to bring the project back into green status. This is where the PM should be specific on what is needed from senior management, the project sponsor and the PM’s Manager (the PM would have discussed this with them prior to the publishing of this report). Most likely, a change order will be needed. This must be presented to the Change Review Board, of which senior management would run or be a participant of.

If the report is red, the PM must communicate critical information to senior management and the project sponsor. The PM would have already warned the project sponsor, senior management, and of course his manager (the PMO and PMO Lead), but the report must detail:

·         The specific problem

·         The solution to the problem

·         How much this solution will cost in time, resources, and scope

After the problem is corrected, there should be a discussion regarding why this problem happened. Questions to ask include:

·         Was the problem flagged as yellow first?

·         If it was, why couldn’t it be resolved then?

·         If it wasn’t flagged as yellow, why did this problem “creep” up as red?

·         Who was responsible for this task(s) that became red?

·         Does this person (for example, an overwhelmed developer) need help, or did the customer miss deliverables they were responsible for?

The problem must be studied separate from the project work and be resolved. If the PM was “blind-sided” by this problem, then he or she must resolve the communication breakdown immediately.

Next

As I have mentioned in my last blog, I look forward to any and all feedback on this article. I ask you for feedback because in my next blog I discuss the remaining documents that are common during a project: meeting minutes, the project risk document, the communication and contact list, the project schedule, and the vacation schedule.

As we continue in these discussions, you can provide your opinion on the specific article or section within the article. I will respond to you via email Benny A. Recine and possibly consider it a topic for another blog.

The Tools of Communication – Part 2 (2)

The Risk and Issues List – Redux

I have received a number of comments on my blogs. One comment was about vision and how to instill it in the project team. I intend to address this topic in a future blog. I will also be writing about delivering bad news in a future blog.

 In my last blog, I discussed the Risk and Issues List as the best document to communicate items in the project to the project members and stakeholders. One of the comments I received was to expound my views on how to present the risks and issues. Basically, this person believes that communication is sometimes the great equalizer of the actual content and that management never likes surprises. I couldn’t agree more that management never likes surprises and that communication is not only the equalizer, but the main reason why projects fail. So the way a Project Manager (PM) communicates this document to management is critical.

Communicating the Risk and Issues List

The most common ways to communicate the Risk and Issues list are: 1) via email and 2) in the actual status meeting. The mistake PMs make is that these are the only two ways they communicate the Risk and Issues list.  Earlier I mentioned that management NEVER likes surprises. A common mistake that PMs make is that they believe that everyone reads their emails. If a PM must communicate bad news, especially an issue from the Risk and Issues List, the PM must first discuss the message with their management and then the project sponsor. These may be two different types of communication, so let’s take them one at a time.  

Delivering the Risk and Issues List to the PM’s Management

Let’s face it, the PM’s Management is more concerned about the status report and that it stays green or on course.  However, as I mentioned before, probably the more important document is the Risk and Issues List. The two documents should refer to each other and be presented as one: the status report as the summary document relating to the project and the Risk and Issues List regarding any risk or issue. If it’s a risk, the status report can refer to it by mentioning it when summarizing the phase the project is in (initial, project planning, execution, control, or close). If it’s an issue, then the issue on the Risk and Issues List must be well documented and self-explanatory. This makes it easier for management to understand and to react if the project sponsor calls on the PM’s Manager. This is the most important communication the PM has in a project: ensuring that his management is fully informed and armed with the correct message.

Delivering the Risk and Issues List to the Project Sponsor Prior to the Status Meeting

Prior to the project status meeting, the PM may want to have a separate meeting with the project sponsor if there is an issue that needs to be explained in detail. This isn’t always bad news, but if not treated and delivered properly by the PM, it can easily become bad news quickly. What I mean by this is that sometimes an email cannot communicate the issues properly and the project sponsor may not understand the communication from the PM. I strongly suggest that the PM speak to the sponsor one-on-one, preferably in person, or schedule a separate call with the sponsor prior to the status meeting.  With this communication, the PM can fully explain the issue or risk properly and not “blind side” the sponsor.

What the Risk and Issue List Can’t Communicate

The Risk and Issue List cannot communicate the status of the project, which is my next blog. I do expect more comments on this blog and as I have done in this blog, make your comments another blog topic. Thanks again to the person who made this comment on communicating the Risk and Issues List.  If you would prefer to email me instead of leaving a comment, please do so at Benny A. Recine.

The Tools of Communication – Part 2

The Risk and Issues List

It is well known that the SOW is the primary document for every project, especially in a PSO. It is the legal document that defines what is in, and most importantly, what is out of scope. However, a document that is just as important is the Risk and Issues List. I say that they are equal in weight of importance for two reasons: 1) The SOW states what is in and out of scope, and 2) The Risk and Issues List ensures that scope creep does not begin in the project. As a matter of fact, the PM should have the SOW when beginning a Risk and Issues list for definition’s sake.

Let’s quickly define a risk and an issue. A risk is a possible issue that MAY happen. An issue is a risk that HAS happened. The level of importance of each can be defined as critical, high, medium, or low. If an issue has a critical status, that issue must be resolved.

Now, some say there should be a Risk List and a separate Issues List. I do not have any argument with that except this one: Who is your audience? If your audience is management or your project sponsor, do you really want to inundate them with more reports to review? I believe that a Risk and Issues List that correctly combines them, documents each risk or issue appropriately, includes the name of the person who is responsible, and provides a date on that risk or issue, properly distinguishes the two separate items. You want to keep the report as “thin” as possible, with the correct amount of information needed by senior management. This is not easy, but it is very necessary.

So, what are the important ingredients in a Risk and issues list? Each item should have the following:

·         An item number

·         The current date of the update to that particular item

·         The level of importance – critical, high, medium, or low

·         The description of the issue/risk. This can be detailed or can have supporting 

      documentation attached to it

·         The person/group who reported the issue/risk

·         The person/group responsible for the resolution of the issue/risk

·         The current status of the issue/risk

·         The date the resolution is due for each issue

How do you communicate from the Risk and Issues List?

The Risk and Issues List can be used as the second tool during a project status meeting, after the status report. The PM can introduce the Risk and Issues List by first discussing each risk quickly based on the level assigned to the risk. Then the PM should discuss the issues. If there are more than three issues, the PM may take the majority of the meeting discussing these issues and how to resolve them. The steps involved are dependent on the level given to each issue. If they are critical, then the PM must get the PSO’s management involved. If they are not resolved, they can keep a project in red and delay its completion. If they are high, the issue may have a short term work-around until a solution is delivered. Low and medium issues are usually product deficiencies that the product management team of the PM’s Organization must address.

The Risk and Issues List must not be viewed as the document that brings the meeting to a halt. With the Status Report, it can be used to move the meeting along smoothly, as long as the risks and issues are defined and described well.

Next….

Our next report of communication is the Status Report. However, I do look forward to your comments on the Risk and Issues List.