Wednesday, December 24, 2014

How Does the Cloud Change How a PM Runs a Project?


For Project Managers (PM), new technologies may present an issue regarding the phase structure of a project. What I mean is that when a new technology is rolled out, there seems to be a “buzz” as to how to handle the project using that new technology. The same is being said of Cloud Computing or projects that are related to cloud projects. What I am NOT saying is that cloud projects don’t have their own risks; they do. As a matter of fact, the risks can be substantial in that they can increase the costs in technology and human capital. However, does a cloud project bring about changes in the way a project is run? Should we have a new set of phases and tasks for cloud projects? Are the roots of a cloud project so intrinsically difficult that they demand a new set of project protocols?

Are there new phases?

No, there are no new phases in a cloud project. They remain: Initiation, Planning, Execution, Monitor and Control and Closing. There are new tasks and increased risks in a cloud project but they alone do not create a need to create new phases. However, in a cloud project, new tasks within the traditional phases are necessary. For example, in Initiation, due diligence regarding Software License Agreements (SLAs) is absolutely necessary. In Planning, there has to be a review of how the new environment is established and how the environment that is being replaced is going to be decommissioned. In Execution, attention must be paid to the types of risks that arise and how to resolve or mitigate them. Monitor and Control brings about a task that addresses the costs of implementing the cloud project and continuing the system being replaced. Lastly, in the Closing phase, ensuring that all tasks for decommissioning the system being replaced are completed is highly recommended.

Are there new risks?
Absolutely yes! I alluded to one in the previous paragraph regarding the risks of costs in decommissioning the system that is being replaced. Or should I say, delaying that task. You see, if the system being replaced is allowed to stay active beyond a reasonable and agreed upon time, the costs of the cloud project will balloon to an unsustainable amount where the cloud project will be considered a failure due to no fault of the cloud system. This is probably the greatest risk and the risk the PM must keep a close watch on.
Another risk would be the increase of costs that are associated with company resources requesting the new application before it’s deployed or after deployment, requesting the application for the sake of having it without a having a check point for approval of the application. This can be the highest risk and cost to the project or when the project becomes operational.
Should a PM handle a cloud project differently and how?
Every project brings with it risks that may de-rail the project and render it a failure, and this is no different for the cloud project. The difference is the magnitude of the risk(s). The PM MUST pay very close attention to the risks, and especially the risk controls, in a cloud project. This is not a “difference” in the way a PM runs a cloud project, but it is a heightened risk and concern regarding the success of a project. During planning, the PM MUST have agreement from the project members and especially the project sponsor regarding the risks and the decommissioning of the system being replaced. In this, the PM must be relentless and communicate effectively and efficiently throughout 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 28, 2014

Where does the PM fit “in the cloud?”



With the advent of cloud computing, Project Managers (PM) now have another technology they have to learn and become experts in at a quickened pace. At this time, PMs are not required to have the deep knowledge of the cloud regarding the intricacies of the business case for implementing a cloud application. However, it would benefit the PM to have some knowledge regarding the complexities of cloud computing, as that knowledge will give the PM an advantage regarding risk management. Implementation of cloud computing brings up a number of important questions. Where does the PM fit in an organization that will be deploying cloud applications? Does the PM treat the cloud project differently from other IT projects? Should the PM treat the stakeholders differently from other project stakeholders?
Where does the PM fit in an organization that will be going to the “cloud?”
Similar to any new project or type of technology, the PM should be knowledgeable about the product, the stakeholders, and especially the type of project the PM will be managing. In the case of cloud computing, the PM must also be knowledgeable about the additional risks unique to a cloud technology implementation. These include, but are not limited to:
  • Increased telecom costs
  • Increased resource costs
  • Increased validation costs
This does not mean that the risks associated with other projects are not valid in a cloud implementation. As a matter of fact, the risk of scope creep becomes an important area where a PM must be vigilant.
Does the PM treat the cloud project differently?
Absolutely not! A PM must approach a cloud project with the same project outlines that we have discussed previously. Yes, cloud computing is a relatively “new” type of implementation. However, the PM must keep in mind all of the PMI standards that are associated with a project implementation. And like other projects, the PM must keep in mind the turnover to operations or in IT terms, the production deployment. 
Should the PM treat the cloud project stakeholders differently?
In this case, I would say yes. The reason is that a cloud deployment may be very new to an organization. The stakeholders may be the same, but this type of implementation brings about a change from a Capex to Opex expenditure. This change is the most important differentiator of a cloud implementation. That means that the PM must keep a close eye on costs.
Overall however, a PM must still be concerned with the triple constraint; budget, schedule and resource. We also know that quality is a major concern for any project. In a cloud project, this is also true and possibly a fourth constraint as with a cloud project, the team is replacing an old technology that may be an old “standard” within the organization.
In conclusion, the PM has to work ensure that the level of work is at the same or better level of quality that the organization historically delivered in the past.
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, November 1, 2014

Where is the Project Management Profession Headed?


Where is the profession headed? Is Project Management going the way of CMMI and becoming less relevant? Are there versions of Project Management that will continue and others that will fade away? Which vein of Project Management should Project Managers (PM) focus on?  There are a number of PM gurus that have their own beliefs and suggestions for the future focus of our industry. However, isn’t the answer “it depends?” Unless you are a freelance PM, isn’t what you should focus on be dependent on your organization’s focus?


I hear, very often, that Project Management is going the way of an Agile process. My only caution is that this may become an excuse to have PMs become more ad hoc, or without process. I do like the Agile approach, I just caution senior management’s motivation. I also believe that a Project Management Office (PMO) approach is a valid and good process. As long as it is used as a carrot and not a management stick. We as PM must remember that we must complete a project and NOT a process.
So, my next questions and responses are what I believe the PM profession is headed.
Do I focus only on what my organization is focused on?
Yes, you have to fulfill your duties as an employee. But that doesn’t mean you can’t keep up to date on what is new and up and coming in Project Management. I posted a blog on 1/19/13 about an article I read in the previous November’s Information Week. The author discussed his findings that organizations he was following were closing up Project Management Offices (PMO) and the lines of business were having their PMs run Agile projects. I have been reading up on Agile Project Management and I believe that it has both its good points and points that I am not too comfortable with. As a member of a PMO and formerly a PMO in a Professional Services Office (PSO), I found my clients wanting documentation and the ever famous MS Project as deliverables on a weekly or every other week basis. Going to Agile may be an internal change, not a client-facing change.
Are there trends I should pay attention to?
As I mentioned above, the trends in Project Management seem to lean towards Agile. I read a book about 4 years ago titled, Reinventing Project Management, by Shenhar and Dvir and I attended a session where Mr. Shenhar presented the findings discussed in his book. He and Mr. Dvir argued that Project Management had to go through a change in the process of its foundation and think about the value of a project differently. I have stated in multiple blogs that a project must be linked to the organization's strategy and that has to be communicated to all.  Messrs. Shenhar and Dvir argue that a project should be broken up and developed differently. In other words, the initiation phase has to be its own project, as does the planning phase. This is because when a project is originally planned, things may change when it gets to the execution phase.
In bigger projects, I strongly agree with Messrs. Shennar and Dvir. In shorter projects, that should not be the case, especially if the project is less than 6 months' duration. However, my point is that we have to pay attention to these trends and see if they apply in the organization we currently work in. I do not mean to reject these new trends out of hand, as they bring a lot of value to our thinking process. However, in a strongly documented process, the PM must be careful not to be the one to upset the current process, but be the PM that suggests gradual changes. 
If I am not following the “new trend” am I going to be considered "old school?"
Why is old school considered so bad? Change is inevitable, but change sometimes comes slowly. This does not mean that the PM does not stay tuned to new theories. It does mean that the PM should be involved with his/her PMI chapter, even if it is once a year at a symposium. Attend the unusual sessions that introduce new theories. Study and write about them and keep informed of new processes. However, keep yourself grounded in the current process of your organization. This may sound like the “safe” way to keep informed of new theories. Maybe I am more grounded than other PMs, but I am also tuned into the new theories and new processes of what a PM should be studying. That may be the step necessary for all of us to take.
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 27, 2014

Why are you a Project Manager?


You may be asking why this wasn’t my first blog. I believe we had to establish a relationship before this question was asked. So, why are you a project manager (PM)? If the answer is, why not, then most likely you don’t understand the question. Allow me to elaborate; in this work world of ever changing direction, scope, and responsibilities, why would you want to put yourself right in the middle of chaos? I understand that the job market is very competitive and that even PM jobs are hard to find these days. However, many of us can work at another role, a business analyst for example, or a technician. So, why are you a PM?

Many of us like the challenging and exciting role
This is probably the most appropriate reason and I admit that this is the top reason for me. I like being a leader and I believe I am a good communicator, but the challenges and the excitement of being a PM are the most alluring for me. And like any other role, with challenges lurks the dark side of agendas. As PMs we are more vulnerable to those that don’t have our best interest at heart. As a matter of fact, sometimes there are individuals that just want to prove they are more valuable by finding fault in the PM and just about everyone else. To that end, I would encourage everyone to read Dr. Sutton’s book, “The No A**hole Rule.”  I also encourage you to read “What every body is saying” by Joe Navarro, a former FBI agent, regarding how to read body language.
Even with the criticism by individuals who revel in everybody’s failure, the excitement of being a PM can be exhilarating. I remember when I was the PM on a project that led my organization in placing our biggest client into production. The feeling was something I can’t explain in writing, but suffice it to say, it was exhilarating.
Some of us like to lead
Speaking of challenges, being a leader is one of the hardest things to accomplish. And it’s not about titles and organizational charts; it is about perception. You know when a leader walks into a room, Heads turn, people sit up, those who are speaking to others stop to listen. It’s not about power taken from interrupting someone that is speaking. A leader knows when to speak up, and most importantly, when to listen. Leaders put themselves in positions that some would consider precarious. Others would shy away from leadership positions because of the need to make decisions, and here’s the hard part, be judged on those decisions. You see, it is easier being a follower and criticizing a decision, especially when others are piling it on. Leaders are not afraid of asking for forgiveness later rather than waiting for permission. You may think I am speaking of a PM that has gone “rogue.” On the contrary, the PM is tasked to make decisions and will be judged on those decisions based on organizational policies and procedures. Sure, we all like to break the rules once in a while, as long as we can back those decisions with strong evidence that the rule was hindering progress on a project. I am not speaking of a Captain Kirk type of person, but rather a Captain Jean-Luc Picard who understands his or her underlying role and is not afraid of risks if the benefits outweigh the costs. 
Some of us are very good communicators
I have discussed communications before in previous blogs. I believe communication is the most difficult part of being a PM and is, I believe, the biggest reason for project failure. I believe the root of communication begins with clarity and value. The customer or client must understand the value of the project in clear, concise terms that they will understand. What PMs sometimes miss is that the client may not be well versed in PM speak. What the client wants to hear is that the status is green, or if yellow, how to mitigate the issues. Also, in clear terms, what are the tasks for the client. Don’t be fooled; the client has tasks, even if they are to approve a change or a document. If the client does not understand the value of the project or even the value of their decision input, then the project is doomed to fail.
In summary, I would like to know why you are a PM, now that you understand my reasons. I encourage your feedback not only to me, but to all who read this blog.
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, August 30, 2014

Communicating and Working the Plan


You have heard the comments from others, especially senior management. "Project management (PM) is simple blocking and tackling.” “All a PM has to do is work the plan.” Wow!! If it was that simple, the failure rate would not be over 80%, would it? What we PMs have to understand is that senior management sees PMs in the spectrum of their world. EVERYBODY reports to them. For a PM, the resources report to the project, not the PM. That is a major difference and one that has to be explained to senior management. However, I do believe that if a PM develops a plan that includes budget, scope, resource needs, and the risks, along with the schedule, then that should be part of the explanation. The major part of the explanation is communicating the plan to management and then working the plan.  

Communicating the plan, especially the risks 

The major communication device to the project sponsor and senior management is the status report. Basically, all of the completed tasks, the risks and issues, as well as the upcoming tasks must be communicated in two pages. Whether the status report is called the RAG (Red, Amber, and Green) report or the RYG (Red, Yellow, and Green) report, a picture of the project is worth a thousand words. The PM must remember the audience for this report. Yes, we like the project schedule, the budget, and especially the risks and issues lists. But the sponsor and senior management want one or, at the most, two reports. I strongly suggest that the two most important reports during the execution and monitoring phases of the project are the status report and the risk and issues list. These two reports are what the sponsor and senior management understand. The status report is direct and short. The initial portion of the status report should have a short status of the project, for example “the report is on schedule.”  

The risks and issues report is the report that the PM will be utilizing the most. This report is where the PM should spend most of the time explaining the issue(s) and the resolution of the issue(s) and the possible risks and how they will be mitigated. The PM must keep the sponsor and senior management keenly focused on the risks of the project so as to avoid surprises. I have written about the risk and issues list before on my blog on 6/23/12 http://blog.bennythepm.com/2012/06/tools-of-communication-part-2.html. What I have stated is still true today. It is the most important tool for the PM in explaining the risks to the team.  

What to do if a risk becomes an issue 

On the risks and issues list, there should be mitigation to a risk if the risk becomes an issue. During the building of the schedule by the team, the PM should have led the team to identify the risks and the probability that the risks would happen and what the impact would be. Along with that calculation there should be the resolution to the risk if it becomes an issue. That solution must be identified and communicated to the team, especially to the project sponsor, and the sponsor must have buy-in to that solution. 


I have discussed communication of the risks and issues list in a previous blog posted  




Failure is not an option

We have all heard that over 80% of projects “fail” to meet the project's original goal.  What PMs fail to do is effectively communicate the risks and then the solutions. PMs also fail to communicate the change request effectively. Once a solution is communicated to the sponsor, senior management, and the team, the PM must guide them through how the solutions may change the project’s end date and possibly add to the budget. Once the PM communicates the change to the team, the PM must document it in a change request and present it to the change review board (CRB) and senior management.  Once this is done, the project is no longer a “failure” or going RED. The project is re-scoped and re-balanced to include this necessary change with a change in the end date and resources. 
If the PM can communicate these necessary steps and options to the team, sponsor, and senior management, then the project will not fail.

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, August 2, 2014

Developing the Plan


During a discussion with a colleague, the topic of the project schedule vs. the project plan came up. The first thing I did was thank my colleague for correctly stating that the tool we Project Managers (PM) use--MS Project--is the schedule, NOT the plan. When I state this, I usually get a glazed look from folks who are not PMs or do not completely understand a PM's role in the overall project plan. So a discussion is necessary to answer the question, “What is a project plan?”  The first thing we must do as PMs is stop using the term “project plan” when we really mean the project schedule. Now, we can begin the discussion of what is in the project plan.
Which tools make up the plan?
The first tools the PM must receive are the Statement of Work (SOW), and included within it, the Scope Statement, or in other words, what the project is delivering. We are all familiar with the term, “What is in scope.” Well, the scope comes from the SOW. What I like to do is begin the kickoff meeting with the client by reviewing the SOW and highlighting what is in scope and most importantly, what is out of scope. The SOW that includes the scope statement is the PM's first and most likely most important tool. This is the compass that the PM must use to begin building the rest of the project.
The next tool is what we use to organize or fill the roles necessary to deliver the project. We sometimes call this the Human Resource (HR) Plan. But I like calling it the Resource Plan because we all know if this is an Information Technology (IT) project, the resources could be new hardware or software. This plan should highlight what talents and technology are needed for the project. It should also note if the resources are already “in-house” or if there is a need for a third-party consultant or a purchase of hardware and/or software. Once these resource needs are identified, then the PM can work with management to fill those needs.
The communication plan, which includes the contact list, can then be developed. Also, the PM must have at the ready tools that will become important during the project, such as the risks and issues list and the change request.
Once these tools are established, the PM can then meet with Human Resources to begin building the schedule. This is another common fallacy that must be dispelled: the schedule is not built by the PM alone. On the contrary, the schedule is built by the team. You see, it is the team that puts together the tasks of the project, links the resources to the respective tasks, and then places a schedule for that task, creating the whole MS Project schedule. When this schedule is put together, then reality sets in regarding delivering the project on-time, within scope, and within budget. It is at this time that the first change request may be written and submitted.


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.

Thursday, July 3, 2014

Getting project members motivated


One of the questions I hear the most from other Project Managers (PM) is how to get their project team members motivated to do the work they have been assigned. A PM usually works in a matrix organization, and that means that the PM’s project team is a mixture of resources across the organization who have their own “day jobs.”  So, it is important for the PM to set the proper expectations for the team. That does not mean that the PM should not hold team members accountable. So the fine line that the PM must walk is set even before the PM has resources assigned to the project. However, the question remains: How does the PM get project resources motivated?


Understand the balance needed by the resource
As I mentioned in my previous blog, when a PM has a resource assigned to the project, the PM must schedule the introduction with the team and then with the resources. The team meeting should be short and used for introductions. However, it is the precursor of the meeting for the building of the project schedule. The PM has to get buy-in from the project team members to commit to the schedule building meeting. To be clear, this meeting will most likely be more than an hour long. So, breaking up the meeting into two or three meetings over a week is strongly recommended. However, if the meetings extend over two weeks, the members may forget what they committed to, and that must be avoided at all costs. Once the members commit to the task(s), they must also commit to the duration of the task. Once that step is completed, putting dates to the task(s) is next, and this step is the hardest to get commitment from the members. This should be done in a team meeting, but if the PM has a team member that needs extra convincing, then a one-on-one meeting is suggested. Once the schedule is completed, it must be reviewed with the project sponsor and the team members. Once this is done, the commitment is public and the schedule must be in the organization's public domain.
There are some PMs who prefer to not place the name of the resource next to the task. I do not suggest that and am in favor of putting the resource's name next to their task. That way there is no ambiguity regarding who is responsible for the task.
Keep the resources informed and ensure there are no surprises
Once the project begins, a weekly status meeting is recommended. In my blog on how to keep the PM and the project team motivated, http://blog.bennythepm.com/2013/03/how-to-keep-project-manager-and-project.html, I suggest that a weekly team meeting is necessary, even if there are no deliverables. This is good for two reasons: one, to keep the project sponsor informed of the progress of the project, and two, to keep the project team members involved. If they become uninvolved, the project team members can become detached from the project. If that happens, it becomes hard for the PM to get the team members re-involved.
Also, a weekly meeting almost ensures that there are no surprises to any team member. Sure, there is always the risk that an anomaly can happen. But a weekly meeting can help the team members identify that risk and discuss how to mitigate it. 
Ensure that the resources know what is expected of them and when the task is due
Once again, the weekly meeting can help the PM keep the team focused on the next tasks and who is responsible for them. This is part of the “no surprises” philosophy that the PM should espouse and encourage among all project team members as well as the project sponsor.
The "no surprises" philosophy is not one to be taken lightly by anyone. We all know that the rate of failure in an IT project is over 75% and the main culprit is lack of communication. The PM has the authority to ensure good communication and must use that authority throughout the project. Even in the best-run projects, there will be times when project team members will have tough moments. The best way a PM can mitigate the possibility of the project team members becoming, shall we say, irritated with one another is to communicate often the next steps and the responsible parties. That way, a PM can develop good team members.
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, May 24, 2014

Developing the Plan

Many times when we discuss the “plan,” most people think of the Microsoft tool, MS Project. We have, incorrectly, called this the project plan. The project plan is an all-inclusive set of documents that includes the project schedule (the one we call the project plan), but is not limited to just that document. In my blog published on July 5, 2012, I commented on the project schedule (http://blog.bennythepm.com/2012/07/tools-of-communication-part-4-remaining.html ) as one of the important tools that a Project Manager (PM) uses to communicate the progress of a project. However, it is not the only communication document in the PM’s tool kit.


The Beginning
When a PM develops a plan, the PM begins with the Statement of Work (SOW) that includes the scope statement and scope of the project.  This document identifies the scope of the project, and especially what is out of scope for the project. The end of that sentence is most important and critical for the PM to understand. The common foe of any PM is scope creep, or additional tasks that get placed in the project that do not belong there. With this knowledge, the PM begins building the project. When I say build the project, I mean to assemble the building blocks of the project. That includes, but is not limited to, the communication plan, the resource plan, the budget, the risk and issue list, the status report, the project schedule, and other documents, depending on the type and complexity of the project. For example, you may need to include a telecom plan or a purchase order. With that said, those reports are the foundation of the project plan, not just the schedule. The communication plan should detail not only whom you communicate with, but when and how. The resource plan defines the type of resources you need, both human and hardware, and whether you need to purchase hardware (leading to a purchase order) or to hire consultants for specific technical needs. The budget of the plan speaks for itself. The risk and issues list may become the main communication tool for the project, along with the status report. The last document is the project schedule.
Executing the plan
A major misconception is that a project begins with the budget, but it really begins with the SOW. That then leads to the resource plan and budget plan. These are what I call the foundation documents to the project. Once these documents are begun to be populated the PM can then begin the project schedule. The schedule is developed at the planning phase of the project, but may change, depending on approved scope change, during the duration of the project. The schedule is built by the whole project team and is changed, when approval is received, by the whole project team. One common misconception is that the schedule is built by the PM. That is a recipe for disaster. The project team builds the schedule and the resources that commit to the task and the timeline own the task and the timeline. What the PM does with the schedule is manage and communicate with the team and ensure that the approved timeline is followed. The PM then becomes responsible for the approved schedule and the whole project plan, to be concise. 
Completing and Closing the Plan
Upon the completion of the project, the PM is responsible for delivering the closing documents and archiving them for reference.  Now, some may also consider having a small group celebration with refreshments. That is a good idea, and if there is leftover funding, then yes, the PM should do that. However, a simple face-to-face thank you goes a long way and I would suggest that as a very important gesture. If the project team members believe that a PM is grateful for their contributions and service, then they will want to work for the PM that appreciates them. THAT is how a PM or any manager leads.
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, April 26, 2014

Organizing the Project Team


Congratulations! You have a project team. Now what do you do?  

As a Project Manager (PM), you are tasked with being the leader of the project. Once you are assigned as the PM, you are now the mini-COO of that specific project. All eyes, especially those of senior management, will be on you.  So the first order of business once the project and project team has been assigned, is to organize the team. Now in my last blog post “How does a PM define Responsibilities” posted on March 23, 2014 (http://blog.bennythepm.com/2014/03/how-does-pm-define-responsibility.html)  I stated that the PM has to assign responsibility and keep the team members focused on their specific responsibilities. The PM must also organize the team and keep them organized so that the project goals are attained. That is not as easy as it sounds for many reasons. However, the goals of the project must be the goals of the project team and it is up to the PM to make sure that the goals are being met. 

Once the team is assigned, the PM begins the organization 

The first thing the PM must do is meet with the project sponsor to ensure the project goals are understood. Then the PM schedules the first project team meeting, and along with the project sponsor, the PM should begin organizing the team and their respective tasks. For example, just because the PM should be the “guardian” of the project repository, does not mean that the PM is the only person who makes updates to that repository. Assigning responsibility does not end with assigning tasks. Individuals should take turns being the “scribe” and someone should be assigned the keeper of the repository, with another team member as the close second (possibly the PM taking either role).  

As the PM bears the greatest responsibility for the delivery of the project, the PM should also bear the greatest authority. That does not mean autocratic authority, but it does mean that the final decision should be the PM's and the project sponsor's. 

Besides organizing the team, the PM should organize the project

As I indicated above, the PM should begin by organizing the project with the communication plan, the roles and responsibilities, and the status meetings. The PM should schedule one-on-one meetings with the individual project team members if necessary.  The PM should also schedule the delivery of the status report to the project sponsor and management and be the representative to the change control board (for any changes, if necessary). Now, the PM is not the sole voice of the project, so the PM must be able to organize the necessary team members if they are needed at the change control meetings, or if necessary, with management. Probably the hardest organizing task for the PM will be keeping the project sponsor up to date and informed of project issues. This task may be difficult because of the project sponsor’s schedule, as the project sponsor may be a senior manager and not have as much flexibility as the rest of the team.

It’s all about delivery

In the end, it is about delivery. Even if there are changes that go before the change board, the PM must be able to deliver and defend any changes. If the project team can deliver on the project, then the PM will be viewed as a successful PM that can deliver projects. But don’t forget the value of the project. In my blog http://blog.bennythepm.com/2012/09/the-value-of-delivered-project.html I comment that the value must be communicated as soon as the project starts and continuously until the project ends. The delivery of the project depends on the strategic value of the project and the alignment of the project to the organization's strategic goals. 

Even when the project is delivered, the value must be communicated to senior management and why the project was so very important to the organization in the first place.

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, March 23, 2014

How Does a PM Define Responsibility?

Recently, a colleague of mine asked me about the responsibilities of a Project Manager (PM) and the project team. Now, I must tell you that within a Project Management Office (PMO), defining responsibility may be a process unto itself. I have written about the fear of “process paralysis” that may come with an overly defined and micromanaged PMO. I have also written about the fear of an agile PMO becoming more ad hoc, which would lead to an out of control state. With those two statements, I have never addressed the initiation of a project. So when a PM is assigned to a project as the leader, not just the manager of the project, what steps should the PM take to define responsibility?

Can a PM Define the Responsibility of Other Project Team Members?
Yes. But as all short answers, there is a second part to the answer. The PM can and should request the authority to define responsibility and the authority to keep the project team members focused. That not only comes from the PM’s management, but with the cooperation of the project sponsor and the project team members’ management.
So when a PM receives a project, the PM must meet with the project sponsor and discuss the project team members and identify who is best suited for the project. Keeping in mind that sometimes the PM and the project sponsor do not always get the resources they believe would be best suited for the project, they must also pick a second person and think about what the plan B would be.  If the PM has been with the organization for some time, the PM should already have an idea of who will be best suited for the project tasks and who will be best suited for that specific responsibility. The project sponsor should be able to provide the PM with some guidance here also. If the project sponsor has had other projects in the organization, the sponsor will have valuable input on the project team members.
Once the team has been allocated and given to the PM, the PM should begin with team building by meeting with the team first and then meeting with the team members individually. At the team meeting, the PM should come with the project sponsor and discuss the goals of the project. Also, the PM should begin scheduling times to have project-building meetings to plan the project. At the individual meetings, the PM should come alone and be less formal, and discuss the expectations and responsibilities for that specific team member.

When the team meets for the first project-building meeting, everyone should build, acknowledge, and accept responsibility for their tasks. It is at that time that project scheduling should begin. In most organizations, the project team members are cross-functional, meaning they come from different divisions of the organization. For example, development, accounting, HR, and so on. So when building the plan and then the schedule, the PM and the whole project team must realize and accept that everyone on that team has their “full-time job” as well as being part of this project, especially the project sponsor.  
What is the PM’s Role in Defining Responsibility?
The PM must be the one source of knowledge and stability in the project. The PM is the one who keeps the whole project plan, not just the schedule, but the communication plan, the HR plan, and so on in a central repository that all of the project team members can access them.
Also, the PM should begin scheduling times to have project-building meetings to plan the project. At the individual meetings, the PM should come alone and be less formal, and discuss the expectations and responsibilities for that specific team member. When the team meets for the first project-building meeting, everyone should build, acknowledge, and accept responsibility for their tasks. It is at that time that project scheduling should begin. In most organizations, the project team members are cross-functional.
How the PM Keep Project Team Members Does Focused on Their Responsibilities?
In the project plan, the roles and responsibilities must be kept by the PM, who must ensure that the team members keep to the plan and their roles and responsibilities. Upon seeing that a project team member is underperforming, the PM must take action. The PM must also keep the team members motivated (see my blog on that topic at: http://blog.bennythepm.com/2013/03/how-to-keep-project-manager-and-project.html). The introductory meeting should set the tone, and along with the project sponsor, the PM should keep the teams’ eye on the goals of the project. However, if a team member is not “pulling their weight” the PM must address that as soon as possible. (I have written about that specifically in an earlier blog (http://blog.bennythepm.com/2013/02/how-to-deal-with-underperforming.html ).  
The PM is the mini COO as the project sponsor is the mini CEO. Those roles must not change and must be accepted by both the PM and the project sponsor.  However, both must never forget that they are the leaders, and that holds especially true for the PM.
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, February 28, 2014

How many projects can a PM handle at one time?

It is one of the most unanswerable questions in project management: how many projects should a project manager (PM) manage at one time? In this period of high unemployment and high employment costs, most organizations are requiring their employees to do more with less. That means a heavier project load and, with that, more resources to manage on each project. However, there does come a point of diminishing returns, or the PM’s effectiveness, when the PM has more projects than he or she can handle. 
Part of the responsibility lies with the PM to inform management of the heavy load and the possible issues associated with a heavy load. However, it is up to management to spread the projects effectively. So, how many projects can a PM handle?


Doesn’t it depend?
Yes and no. I know, not the answer you probably wanted, but it is an appropriate one. You see, the standard is from 4 to 8 projects per PM at one time. As great as that sounds, we all know that it really depends on the size and complexity of a project or projects. If the PM has 4 small projects (under 50 project hours per project), then it may be appropriate to assign additional projects that are larger in size and/or more complex. How many, you ask? Again, that depends on the size of the projects and how experienced the PM is. Assigning 2 larger projects may in fact overwhelm some PMs. However, there may be some senior PMs who, because of their experience and knowledge, can take on 2 or 3 additional projects that are larger and more complex.

What if the PM is a Senior PM?
I did begin to speak to this in the previous section. I will repeat my response: it depends. If the senior PM can handle more than 8 projects, and if the senior PM and management agree on expectations, then the answer is yes. However, even a senior PM has limits. The senior PM and senior management MUST review the PM’s workload and determine what is an acceptable workload and set expectations. Those expectations must be communicated to the project sponsors that the senior PM is going to be working with, as well as the project teams.

Should the complexity of a project factor into the decision?
Yes, there is no doubt about it. If a PM has more than 2 complex projects on his/her plate, and other smaller projects, even if it is only 2, the chances are that the PM will be overwhelmed. It is a matter of compounding the probability of risks and issues. Since we all know the PM’s job is about keeping expectations set on the original SOW AND controlling risk, the probability of risks occurring on 2 complex projects becomes greater. Let’s be honest here; just because a project is less complex does not exclude it from having its own set of risks. Since we all know that is true, what is the probability of the less complex projects becoming more complex because of issues that arise?

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, January 31, 2014

The Traveling PM: Conducting Multiple Projects on the Road


When a project manager (PM) is part of a Professional Services Organization (PSO) or a Project Management Office (PMO), there may be a project(s) where the PM needs to travel out of town or even out of the country. When that happens, the busy PM may have that gripping feeling of fear of what to do with all of the other projects the PM is responsible for.  Now, a good PM, when given this project, begins to plan immediately on how to provide the other projects with leadership in the PMs absence.


Your associates and peers should step up
It usually is no secret that you will be out of the office on business. You should be putting together a list of current projects that need support in your absence. Most likely, your associates know all the hot items on your projects since they have probably heard your updates at meetings. In the group meetings that follow, you have to begin laying the ground work and getting volunteers to manage your projects in your absence. Now, there may be one or two projects that in the launch stage. In that specific case, the Business Analyst (BA) or Subject Matter Expert (SME) may be the lead for that project. However, a  you as the PM may be needed to manage the process. So you will have to request help from other PMs who may not have a lot of time on their hands.

I would strongly suggest that the  you first discuss this with the PM’s immediate manager. You need the manager’s support on the plan you have come up with. The manager may know who is busy and who has the bandwidth to support you. With that information, and before the next group meeting, you should speak to the PMs that the you believe can best support your ongoing projects.

You must leave clear instructions in your absence
You must put all of the projects in flight in order of importance and execution. What I mean by that is you must communicate which project is of higher priority and why. Is one project close to signing off on their user acceptance test? Is one project in the beginning phases of execution? Is another project close to finalizing their training sessions? All of this must be documented with the BA and other project team members must be made aware that you are traveling. Also, you must identify the key stakeholders for the client/end-user.

With this documented, and with clear instructions, you can now petition the other PMs with the request of back up and support.


Ensure that you are kept informed
Before leaving for the business trip, leave clear instructions on how to contact you if there is an emergency. After the back-up PMs are identified, you must then communicate the plan to the in-flight project team members with documented communication plans that include contact information. Most likely, you will have contact via email during non-business hours and/or a smart phone. You must note that communication will not be immediate and will be only if necessary.
Once this are all established, then and only then is the PM ready to travel.


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, January 5, 2014

What is Important Outside of the PM Profession?


I am often asked, “What is important to the project manager (PM) outside the PM profession?” There can be multiple answers to this question and all of them would be correct. It depends on what a PM wants to accomplish professionally and personally. Do the two have to be perfectly in synch? The answer is no, but they should be somewhat complementary. So what is the balance for a PM? I can’t answer that question for you, but I can tell you how I do this myself.
Be Charitable with Your Time and Expertise
In this time of tight budgets, both organizationally and personally, be charitable with your time. You see the term “time is money” doesn’t end just with your profession. I belong to several networking groups, some of which are email only, some of which have monthly meetings. I do my best to attend at least six monthly meeting a year for each of the latter groups. I also am open to meeting with anyone one-on-one to network. This networking session can be done via a telephone call or at a coffee shop and the meeting can last from 15 minutes to an hour. It depends (there’s that term again) on the person requesting to network with me. We can share any number of things, from tips to contacts to a good job lead. I always consider the meetings to be two way. Just because I happen to be employed at the time does not mean that I don’t think the person I am networking with is without contacts that would be valuable to me.
Donate Your Time but Don’t Overextend Yourself
As PMs, we must be judicious with our free time. We not only have work to consider, but also our home lives that may include significant others and children. So we cannot overextend ourselves, or to put this in PM terms, allow scope creep in our personal lives where we are so busy we don’t focus on our own needs first. So pick one to three charities to commit your valuable time to. How much time really depends on how much time you have to commit. Considering that this would likely be during the evenings or weekends, once again, you must be judicious with your time.
Once a year I attend, along with some of my fellow Princeton Toastmasters, a session with the Special Olympics of NJ (SONJ) where we give athletes pointers on being better public speakers. This is usually a one-day session where we work with the athletes and then they give a short presentation. I can’t tell you how rewarding this is to me and my fellow Princeton Toastmasters. It really is a fulfilling day that leaves each and every one of us feeling as if we have just conquered Mt. Everest. I look forward to being part of this day every year, not because of what I can give in terms of communication skills, but in terms of what I can learn from the athletes and about myself.
My son Robert is an Eagle Scout, a laudable achievement of Boy Scouts. When he was starting out as a Cub Scout, I was his Cub Scout leader, as well leader for the other eight boys in his den. Now I make a monetary contribution to the local Boy Scout council. Contributing funds to worthy causes is important, however, contributing time is more valuable, in my humble opinion.
Additionally, I also participate in the National Multiple Sclerosis Society MS walk every year. That takes about four hours one day a year, where I raise money for a worthy cause. Also, on my blog, you will see the website for another worthy cause, Pennies in Action (www.penniesinaction.org). My wife Marie recently conquered breast cancer using a vaccine in combination with standard treatment and she is now involved with this charity to help bring the solution to all women. We recently attended a fundraising dinner for this cause.
Now, among these charities, I devote all of about three days of my time, which does not include my network groups. Considering what I get out of this it is without a doubt, a valuable investment of my time. You have to consider which charitable events you would like to contribute your time to and how much.
Be Consistent
Lastly, be consistent. When you commit, do so wholeheartedly. There has been one year each where I could not make the SONJ event or be in the MS Walk, but those were anomalies due to my work schedule. I have been consistent regarding whom I work with and which charities I contribute to. No matter which cause you support, be consistent with your time. And by all means, be judicious.
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.