The past few weeks have been a world wind.  Going from being really optimistic about a project and feeling good about the amount of planning and risk mitigation seemed to spell success early on.  We even restructured the timing and resources to accommodate the needs of the project on the fly with stunning success.  After looking at the risk plan and the projected final milestone, I saw something really bad in the way.  The need for untested and invalidated software to make the entire project successful.  I thought I had the resources to mitigate this risk.  I though the project had the visibility to make proactive changes in code when required.  I was wrong!!  Not only did I fail to get validation on the fix in the lab, I relied on a senior architects word that he has resolved this for other customers in a way that is within our scope of work.  The interesting part was the resource going silent during the project and making requests of his schedule early on placing the project at risk.  Why didn’t I ask for Proof?  Why did I not ask for references?  I guess I trusted the source and that was the risk I should have identified.  Even more, I relied on a host of individuals that happened to disappear once the project became critical and needed their update.  It could suggest one or two things.

• The experts where feeding me incorrect information and really did not understand the project.  I immediately dismissed that claim due to several meetings with detail explanation of the problem and needed outcomes.
• The played the white night.  That is a term I used to identify people that want to come in and save the project.  They also want to make sure they are the resource choosing for the project.   At first I dismissed that thought, but had o consider it after some continued research into the problem.    What do you do when failure is an option?

I considered folding and allowing he project to just fail.  That sounds bad, but sometimes there are no logical work abounds that are immediately viable.  In addition, we rely heavily on the product group to define a roadmap inclusive of these changes to benefit these types of changes.  I was in a real pickle.  The status report had a red maker on the key milestone.  My risk plan was now front and center.  It showed the theoretical failure as a real potential.

After some more searches, I found a ray of light.  What if the risk of failure was in the plan and it caused us to redirect efforts toward an alternative.  Luckily for me, this approach allowed me more time to research additional experts in this field.  It also allowed me to meet with product engineers who actually had a release coming.  I was fortunate to find an outcome supporting the actual risk that was defined in the plan.  I was also willing to allow the project to fail which seems incorrect.  Sometimes failure is needed to reach the ultimate solution.  It worked this time, but it was part of assumed experimentation that allowed me to take this road.  If this was a more aggressive project around a current product, I believe this would not have been appropriate.  Have you let a project fail?

 

Have you considered what skills are needed for project manager today?  In discussions with many Project Managers and Program Managers, this seems to be the new problem in an ever evolving world of Digital Technology.  In discussing these challenges with David Lipien (A Manager with considerable PM experience), I have come to a new level of understanding of the new needs and challenges for Project Managers in this ever changing digital world.  David provided this presentation to help direct me (http://www.slideshare.net/lipien/21st-century-skills-12723591).

Some of the feedback really provides these 7 levels of key skills everyone should have if they want to be a project manager during this age of transformation.  My contact starts by visually showing some of the issues today.  One key concern is understanding the heterogeneous concerns of a project.  It is a central requirement for future project managers.   Having and developing long term learning and skill may represent the new vision for PM’s. Some of those skills Include:

Business Skills, Systems Integration, Enterprise technology, Technical Basics, Familiarity with legacy Systems, Global Collaboration/Out Sourcing and Project Management.

Project managers need some level of knowledge and proficiency in a host of categories to be effective in many instances.  They are required to deliver alignment and quality to a project.  Coming out of our current recession, the project managers skill is also required in understanding the business, cost ramifications and impact.  In many cases, this requires the project manager to work within key roles that offer maturity in the business and technology to meet those goals.

One central theme to the role which cannot be learned is relationships building.  While all other skills can be learned over time, a Project Manager must have the people centric skills that provide engagement and the ability to deal with objections.

In conclusion, project management skill requirements are changing to provide more engagement, understanding and experienced.  While many documents and books focus on PM skills alone, this qualitative view has shown that nurturing skills across a multitude of areas will provide the most skilled PM during this age of Digital Transformation.

 

How difficult is it to tie mission, to assigned resources and align to senior management deliverables?  After working in a PMO office, this can be a killer of projects especially when their is a failure in the conceptual understanding of the Mission between the PM Lead and the Project SME.  Given the new complexity or projects, it is assumed that project resources have real world knowledge of the service, tool or process.   In two occasions, the “learning on the job” mentality is used in organizations with cultures that assume PM expertise will translate to project success.  Because the initial phase where project members, vendors and senior leaders align is not fully understood, project impacts can grow due to the lack of leadership.  As an example, one of my former employers wanted to deliver an Asset Management project in order to reduce the cost of employees onboarding from 5 days down to 1 day (3 hours).  In this time, they wanted their ID, Computer and Applications available.  The PM did not have any experience in Asset Management, Tools and Procedures.  In addition, the PM was not familiar with the environment (network or systems) which created problems when trying to align the mission, charter and resources to the overall outcome.  Initiation (envisioning) must be considered as a crucial part of team alignment to goals.  It is also an opportunity to switch resources that have little or no depth in the topic.  Due to the misinformation communicated by the project manager in this case, senior leaders cancelled the project.  The strategic value in terms of hard cost associated with idle employees and soft cost associated with early system access was lost.  The operational value and capability was introduced in a project managed by a vendor that provided an end to end system that worked throughout the environment which fed asset inventory tools.    The fact that the PM focused solely on a reporting tool meant the project would never proceed.