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
Saturday, December 29, 2012
Friday, December 7, 2012
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.
Friday, November 23, 2012
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.
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.
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.
Friday, November 9, 2012
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.
Saturday, October 27, 2012
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.
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.
Saturday, September 29, 2012
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.
Sunday, September 16, 2012
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.
Saturday, September 8, 2012
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.
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.
Saturday, August 25, 2012
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.
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.
Sunday, August 12, 2012
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.
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.
Saturday, July 28, 2012
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.
Sunday, July 15, 2012
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.
Saturday, July 7, 2012
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.
Sunday, July 1, 2012
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.
Saturday, June 23, 2012
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.
Subscribe to:
Posts (Atom)