Monday, November 26, 2018

Transitioning Into the Next Project

Transition. It is a word that can be both exciting and challenging at the same time and for the same reason. The definition of transition is “the process or a period of changing from one state or condition to another.” You see, the definition has that word “change” in it and that is what is challenging. We are creatures of habit who like consistency, not change. We basically eat the same foods on a daily basis, watch the same type of TV sitcoms, and associate with like-minded people. Some of us like variety, but most of us like consistency. However, a Project Manager (PM) must be a master of variety. We are hired to manage change, and like it or not, we are rated on how well we do it. So if change  makes us uncomfortable, how do we manage it? How can we practice to become better at transitioning?Let’s review:

Accept that transition is necessary

As a PM, your role is to manage the project, which includes transitioning from one state to another. The issue here is getting comfortable with change and transition. There is an old saying that“the only constant is change.” As PMs, we are agents of change and we are managers of transition. And may I add, not just for our projects. This must be a value that is part of the PM’s persona. If the PM is only an agent of change and transition in his/her projects and not their professional improvement, one can assume that the PM may be a bit of a hypocrite. Strong word, but we PMs must look in the mirror, and if we want to be considered the “go-to” PM, then growth is necessary. And with growth, professional improvement, change, and transition. It is how we personify our work and profession. Managing project transitions will help one manage transition from one company to another.

Accept that you may be uncomfortable managing transition

Even if the PM accepts the role of a change agent and understands that transition is part of life, the PM may not be entirely comfortable with this. This is understandable.However,a bit of discomfort can add to a PM’s professional growth. I believe that once a PM gets too comfortable doing the same thing the same way, that PM becomes obsolete. I would rather be uncomfortable learning something new than be too comfortable and facing the worst type of transition where I am forced to look for a new role. I have a good friend who says that being in transition (career wise) is the new constant. As a PM whohas experienced down-sizing, as uncomfortable as that is, I have usually bounced back because I have accepted that change and transition are now part of one’s professional career. It doesn’t mean I look forward to it, but I do understand that PMs must define themselves as the agent of change and transition.

                         Work to make others comfortable and you will become comfortable

One method I have found helpful is making others comfortable with the change and the looming transition that the project will bring. Whether it is the project team or the end-client, the PM will do a great service by making others comfortable. This can be done in multiple ways:
·       

  •            Schedule part of the weekly project meeting to discuss what the end-result will look like when the project implements the product or change.
  •       Discuss one-on-one with the most affected individuals their concerns about the change and what the transition will be like
  •       Work with the project team to incorporate others in the testing process even before the UAT phase of the product so their comfort level rises.
Once you establish these techniques, change and transition will be accepted with more ease and you will even become comfortable with the transition.


Change is never easy, but your team can make a transition easier for everyone involved, including yourself. 

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 20, 2018

Life Saving Methods that Project Managers should incorporate


I have read an eye-opening book titled “The Checklist Manifesto: How to get things right” by Atul Gawande.  This book was published in 2009 but still has relevance today mainly because of Gawande’s approach of not only getting things done but by getting them done right the first time. He was intrigued by a story he read of a child that fell into a frozen pond and was saved by a doctor that followed checklists. He was also moved to write when he researched about the airline industry and the way it discovered how to make a pilot’s job easier and making the pilot more efficient especially in critical situations. The movie Sully about the pilot Chesley Sullenburger is a good example of what Dr. Gawande  found in his research.

Dr. Gawande makes a distinction between errors of ignorance (mistakes that are made because there isn’t enough knowledge) and errors of ineptitude (mistakes that are made because of not properly using the knowledge we have). So as a Project Manager (PM), I read this with the mindset of how life-savings methods can make PMs better. I am not just speaking about PMs in the healthcare, medical and pharmaceutical fields, but all PMs in every field. So let’s take these two (2) distinctions one at a time.

Errors of Ignorance

Respectfully, this is not hard. For PMs, if we are a Project Management Professional (PMP), we must keep our certification by taking continuing education credits. If you are a PM that likes to challenge yourself, you will take the credits that updates your certification along with credits that stretch your limits, possibly by learning how to PM in another industry or field of study. By doing both, you keep current in fields like Artificial Intelligence (AI), Blockchain and other new technologies.

Errors of Ineptitude

Now, this is the hard part. It’s hard because we have all made these types of errors. Whether it’s because we are rushed due to a deadline or because of a mistake that should have not happened. You may ask, why do we need to consider a method of life-savings methods? Because being thorough and accurate is critical for any PM even if they are not working on life-saving projects. Using some of Dr. Gawande’s methods, here is what I suggest as a PM do the following:
·     
          Check and re-check your tasks and work.   Have a second and even a third set of eyes review your work and those on your project team

·        Bring your project team into this line of thinking and process by using it in your project meetings
·       Identify all possible risks, issues and errors
o   With risks, discuss with your project team how to avoid, mitigate, accept or  transfer each risk every time your team meets
o   With issues, discuss all possible ways to resolve them. Do not leave any possibility off the table and do not ignore any solution no matter what the cost
o   With errors, do not identify to point fingers but to resolve them and to avoid them in the future. The PM must ensure that the person(s) responsible for the error feel  comfortable enough to discuss why and how the error was made and how to avoid them in the future.
·     
          Ensure that any team member knows that they can approach you or any team member anytime to bring up any idea, possible risk or issue and most importantly, any error.
·        Once errors are identified, training on them may be needed on how to avoid them in the future. As the PM, ensure that your team members have all the training they need.
These are just some of the steps a PM can take to ensure the project has limited errors. Just like Six Sigma, we want to limit the errors before we get to UAT. The goal here is to make the process and the team better in a continuous fashion. That way, the team never stops innovating.

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.

Tuesday, September 25, 2018

Forward Thinking

As a Project Manager (PM), especially in Technology (IT) or in Professional Services (PS), we have to be forward thinkers. You may be thinking to yourself, don’t we all have to be forward thinking?  Of course we all do, but a PM has to be especially keen on forward thinking, not just about technology in general, but on each and every project. Sounds like a lot of work, doesn’t it? It will take extra effort, but it doesn’t have to be hard. Here are some suggestions:

  •     Every project has issues.Ask questions continuously about how to solve those issues.
  •      Link the questions to actions (similar to a Strength, Weakness, Opportunity, Threat or SWOT analysis).
  •      Rank those actions so that you can determine which one is most likely to be delivered as a solution and the impact of the solution.
  •      Implement the solution(s).

Let’s take these one at a time.

Ask questions

During your project meetings, you will be asking about issues and risks that come up. You will also be documenting them for management review. But  you should also be asking, what are the opportunities that arise from these issues and risks, and then listing them as solutions. In this phase you must not be concerned about ranking them.  Similar to a risk/cause analysis meeting, there are no foolish questions or answers and every response is reviewed equally. This is about solving the issues or risks and possibly improving the progress of the project. Also, this is not done during just one meeting.The PM must be vigilant and this process must be continuous.

Link the questions to actions

The PM must then lead the effort in linking the questions to possible actions. This is the second hardest part of the PM’s actions in this effort. Also, the PM cannot do this alone. This is done with the project team and there will be many opinions on what actions can be taken. The PM must be neutral in what he/she believes which actions are linked to which issue or risk. However,the PM may be the tie-breaker, and in this case, the PM must take the emotion out of the decision process and ask the question:Which action is the best for the specific issue or risk?

Rank the actions

Now comes the hardest part of the process. The PM and the project team have to come up with a ranking process for each of the solutions for the risks and issues.  It all comes down to which action has the best impact, not always the biggest impact, on the project. In this case, what is best for the end-customer and the project? Which action will resolve any issue or prevent any risk?Which action will improve the project? I am NOT suggesting gold-plating the project. Obviously, if the action is extra work, it must be presented to the customer for scope and possible changes. Then the PM and the project team have to determine the cost and the impact to the timeline and scope of the project. The importance of this phase cannot be overstated.  The impact and the possible changes to the timeline are critical and must be communicated thoroughly and consistently.

Implement the solutions


Once the change is accepted, the testing commences.Once this phase is completed, the change must be scheduled to be implemented.  Of all the processes I have mentioned above, this will be the most consistent (but not easier) phase. The PM and the project team must follow the same process as implementation of any product. The difference is that, most likely, the project will not be completed with the implementation of these improvements. Yes, this is a phased approach, much like the Agile method of implementing sprints. The PM must be able to communicate the successes of the implementation of the actions and prove the implementation improvements. The PM must show that the actions taken improved the project.  This is all done during the implementation of the whole project and must be done so as to improve the end-product. Once proven, the methodology I have described must be made part of the PMO/PS process.

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.