NotificationNEW - Check out our new evening training classes! Click here to find out more!
×
Menu

Authority, Leadership, and Connection

Published on

 

Authority, Leadership, and Connection

Just because an executive has authority over their employees doesn’t mean their employees will follow them. I have seen a CIO’s direct reports fire him by deciding as a team they would not follow him. This particular CIO was left with no way to report on critical activities and no way to influence the outcome of his direct reports critical endeavors. This quickly became obvious to the CIO’s boss, and he was relieved of his contract.

In this situation, the CIO could have used his authority to fire his direct reports, but the business leaders and his boss held them in high esteem. In all cases, this CIO’s direct reports did their jobs well for the sake of their success, not for the success of their supposed leader.

The point of sharing this extreme case of mutiny is to illustrate the two distinctly different ways for an executive to influence outcomes, with authority or leadership.

Leadership is exponentially more powerful than authority because it involves choice. When your team members choose to follow you, they are doing so because they feel positively connected to your vision, or because they simply feel connected to you. When this positive connection is in place, your team members will start consciously succeeding for you, their leader.

This subtle shift from their minds to their hearts means that your team members will begin intentionally incorporating the things they believe will ensure your success with their approach to ensuring their success. This will result in much closer alignment between their actions, your vision and the direction you hoped their efforts would take the company.

Connection is the key to leadership. And… There are only two ways for human beings to connect with each other; through physical intimacy or by actively listening. Since employing physical intimacy as a leader would be a disaster, I am going to focus on listening.

Fostering connecting with your team members requires active listening vs. listening to respond. Human nature being what it is, most of us are listening to come up with a smart response or to give the right answer. Most of us have a ton of competing demands and are in a hurry to solve the problem. Unfortunately, without taking the time to listen and truly understand our solutions are never as effective as we would like.

Active listening is about listening to understand how your team members are feeling, how they are anchored to a topic and what they are thinking. Connection is about feeling understood, and feeling cared for. When a leader takes the time to really listen; listen as a gift to the person speaking, you will understand them. And… You will care for them. It’s impossible to know someone truly and not feel some connection to them. The depth of understanding you develop for your team members will be evident in how you lead them. And… The time you spend listening will always be perceived as caring for them and will give you the perspective you need to truly SPEAK to them. To get through to them… To Lead them.

Deliberately Developmental Leadership

Published on

Better Leader

In their Harvard Business Review article titled “Making Business Personal”, Robert Kegan, Lisa Lahey, Andy Fleming, and Matthew Miller describe the Deliberately Developmental Organization (DDO). The basic premise of their article is that the DDO structures their business practices on the assumption that people can grow. That mistakes are not vulnerabilities, but prime opportunities for personal growth. And… when their team members grow, there is a significant and positive impact to the DDO’s bottom line.

This is particularly important for the improvement of Leadership in an organization. If the expectation of our leaders is that they SHOULDN’T make any mistakes, people in those positions are less likely to acknowledge and work on their mistakes. They are more likely to spend time covering them up than they are to acknowledge them for the sake of deliberately developing their leadership skills.

The notions that people learn the most from mistakes and that innovation requires risk taking are not new. If asked, my CEO clients would scoff at the mere suggestion that their leadership team SHOULDN’T make mistakes. In fact, my clients frequently tell me that they want innovators and entrepreneurs on their teams.

Then, the first thing their organization does when a problem occurs is find someone to blame…

The most important enabler of leadership development is an organizational culture that “in action”, not only embraces mistakes, is a culture that creates frequent, reoccurring and public forums that are safe to explore those mistakes. The first step to creating this type of forum is to understand the Kolb Experiential Learning Model, otherwise known as the Adult Learning Model.

Kolb Model

Kolb found that for an adult to learn or grow we need to stop and intentionally reflect on what we learned in a training session, or from the outcome of our own actions. Taking time to reflect on the recent past for the sake of improvement, then conceptualizing how we can apply what we learned or can improve upon our results. Once you have an idea of what improvement looks like, decide on a future approach and seek opportunities to experiment with that approach.

A simple and low cost way to begin Deliberately Developing your Leadership is to have your team members begin publishing a weekly Leadership Performance Journal (pJournal). The pJournal is a simple tool developed by the Stagen Leadership Academy that employs the adult learning model and the cultural components necessary to maximize the opportunities associated with mistakes. For the pJournal to be effective, they need to be completed by everyone including the executives and publicly available to everyone on your team.

The pJournal format

Mental Replay of a “Concrete Experience”

  1. The Situation – Describe what happened:
  2. Results – Describe the results, consequences, implications:

Reflection “Reflective Observation”

  1. My Thoughts – What I was thinking:
  2. My Behavior – What I did and said:
  3. My Inner State – What I was feeling:

Self-Authoring “Abstract Conceptualization”

  1. Key Insights – Describe your triggers, habits, patterns:
  2. Desired Outcome – What do I really want?:
  3. Action – My next step is or Next time I will:

Criteria for a Good pJournal

  1. Identify a leadership mistake you made. A situation that you wish you handled better with other people in the room, on a call or via email. Ultimately the premise of the exercise is to identify situations that you DID NOT influence, and where you failed to attain the result you were hoping for from other people.
  2. Remember that you are the only thing in this world you have complete control over. Your insights in the journal and “Actions – next steps” should be yours. Do not list next steps that involve other people’s actions.
  3. The main outcome of this exercise is to take the time to work through the situation, evaluate your actions/results and COMMIT to how you will handle the next similar situation. When you are done with the exercise each week, you will have a road map to experiment for the purpose of refining your ability to influence people and improve your leadership skills.
  4. Last… Publishing to the team allows others to provide you with input on possible solutions or empathize. SOLUTIONS that are created by several minds measured by the end RESULT are always better than a solution created by a single mind.

Ultimately, the pJournal allows leaders to publicly acknowledge their mistakes, lessons learned and make a public commitment toward improvement with tangible next steps. Public commitments are much more likely to be kept which helps create velocity toward improvement and gives other team members the ability to lend support. When team members are aware of the areas you are actively working to improve, their very nature will be to support your efforts and…

In the book titled “The Speed of Trust”, Steven Covey makes the point that when you demonstrate publicly that you are willing to acknowledge your mistakes and then keep your commitments toward improvement, people will naturally trust and cooperate with you. People want to work with authentic, capable people that they can rely on.

The pJournal exercise creates velocity toward leadership improvement by maximizing the opportunities associated with mistakes and supercharges the performance of the entire team by fostering trust and cooperation.

Leadership Performance Journal Example #1

Mental Replay of a “Concrete Experience”

The Situation – Describe what happened: In an ongoing attempt to continue to refine business practices at 120VC, I asked my leadership team to begin providing weekly forecasts for billable hours. I asked them to start by having team members take a look at the coming 1 weeks workload and forecast the number of hours they would spend on billable work for that week. I explained that this is a first step toward quarterly forecasting that will be used to make investment decisions, hiring decisions, swap team members across accounts, etc… Essentially, we could be more efficient about how we are allocating our current billable workforce.

My team asked for a month to work this out and they set a deadline to begin providing me this reporting. Last week, I was in a leadership team meeting going over reports and it occurred to me that the deadline had passed, and the data I had requested was not in the report.

I asked why I didn’t have the data and they pointed fingers at each other. The next few questions resulted in excuses and I got mad. I said… “This is bullshit! Someone should have told me… Instead I had to discover that it hadn’t been done by noticing the information was missing from the report? This is totally not cool.”

And then I gave them 10 minutes to come up with a solution and a near term completion date. I left the meeting and returned 10 minutes later to a plan and commitment.

Results – Describe the results, consequences, implications: The immediate result was that I was given “another” plan and completion date. The consequence is that we didn’t work as a team to figure out the root cause of the failure and therefore I had no confidence in the new plan or the date. My team didn’t learn anything that would impact their future decisions… We made no progress as a team and learned nothing from the failure. We essentially fixed the symptom without addressing the root cause.

Reflection “Reflective Observation”

My Thoughts – What I was thinking: What else isn’t happening that I don’t know about? Cuz apparently if I don’t log it in the risk log and micro manage, I can’t trust that they won’t just blow things off.

My Behavior – What I did and said: I threw a tantrum. In a very professional way I might add…

My Inner State – What I was feeling: I was furious that these super highly paid professionals that essentially run 120VC were like… Oh ya, we did say we would get that done (paraphrase in the tone of stoned surfer dude). I felt really let down and was hurt that they left me hanging.

Self-Authoring “Abstract Conceptualization”

Key Insights – Describe your triggers, habits, patterns: I felt left out. Like their last priority. Like… My contribution is not important to them, even though history shows that my contribution is uber valuable. Uber = Super in Southern Californian speak.

Desired Outcome – What do I really want?: I want my leadership team to do what they say they are going to do, when they say they are going to do it, or… Circle back and let me weigh in. To either disagree with me or tell me they don’t understand so we can develop a go forward plan together.

Action – My next step is or Next time I will: The next time something like this happens (and it will), I will remember that they don’t want to disappoint me. In fact, I believe that the last thing on the planet my leadership wants is to let me down. I believe they care about me. Next time I will remember our core value and make the failure safe so we can get at the root cause.

We have had several meetings on the topic since and as it turns out, they didn’t understand what I was trying to accomplish. They needed my help and didn’t ask for it. If I had made it safe, we would have worked it out in that meeting and we would have avoided the drama I caused by getting frustrated. As a leader I can chose to be right or I can chose to be effective. No one in the universe would say that I didn’t have a basis for being angry. However, I would rather have made progress that day with my team by showing them exemplary leadership.

Leadership Performance Journal Example #2

Mental Replay of a “Concrete Experience”

The Situation – Describe what happened:  This week I hosted the first tele-conference for the Project Management Leadership Academy (PMLA) Picasso cohort. I planned to help my team review their posts from the first weeks assignment and assess their mindsets as either “Knower” or “Learner” for the sake of value creation.  I also introduced a new piece of technology for the conference call that I thought I had thoroughly tested.  And…  This technology was supposed to help by giving my team some private time in small groups to work through the topic of Knower vs. Learner…  When the technology failed… or I failed to use the technology correctly, I was really embarrassed.

Results – Describe the results, consequences, implications:  When the PMLAers appeared to challenged my motives by pushing back on the exercise as “asking them to be judgmental of each other”, I was already off my game and I felt “accused”.  Instead of playing for them by acknowledging their points of view I justified the lesson, or I justified my motives.  Let’s be clear, I did the latter.  Instead of helping them connect with the value of working as a team to recognize when the knower is manifesting and help guide each other back to learner, I feel like I made them feel judged.  Critique for the sake of value creation is a really hard topic because the only distinction between constructive criticism and judgment is motive.  Essentially, where the messengers heart is…

Reflection “Reflective Observation”

My Thoughts – What I was thinking:  This team is really important to me.  I know that I can contribute positively to their Project Management and Leadership journey, and I look like an idiot with this technology.  They are going to think I didn’t test it.  I did test it between me and Steve.  Clearly that wasn’t enough and tantamount to no testing at all.  They are right, I let them down.

My Behavior – What I did and said:  I defended myself instead of doing my job.  I was supposed to be the leader on this journey.

My Inner State – What I was feeling:  Shame

Self-Authoring “Abstract Conceptualization”

Key Insights – Describe your triggers, habits, patterns: I don’t like to look incompetent in front of people I respect.

Desired Outcome – What do I really want?:  I want to do a great job for this cohort.  I want them to have an amazing experience in the PMLA and I want their leadership to recognize that their efforts in the Program contributed to significantly improving their (already awesome) ability to inspire their projects teams to greatness, and complete Projects on time and on budget.

Action – My next step is or Next time I will:  The next time I make a mistake in front of the Picasso team, I am going to acknowledge it out loud and ask them for a moment to reset.  I will remember that we are all on the same team and that I will never be perfect (just damn good).  I will then recommit to my role which is to serve them.

What Does Leadership Actually Look Like?

Published on

Leader

Whenever I get the opportunity I ask people to close their eyes and tell me what they see when I say the word “leadership” or “leader”. Almost everyone imagines a superhero type looking off into the distance with a bunch of people standing behind ready to follow. Ironically, that is not at all what leadership actually looks like. Leadership… is what took place before all of those people lined up to follow.

Communication is our only leadership tool… We lead with words, voice, tone modulation and body language. That’s it! Leaders get people connected to an idea and excited about building something, or doing something.

Leaders need to have vision, clarity and the ability to crisply and energetically communicate that vision. Great leaders understand that communication isn’t just a leadership tool, it’s also a “followership tool”.

When a leader delivers instructions, receives acceptance and watches their followership march off on a mission, they won’t know if they succeeded as a leader until they measure the outcome. This is a lag measure.

Great leaders measure their “leadership effectiveness” in the moment, without having to wait for the outcome. The most effective leadership is a two-way conversation. The leader shares their vision and their follower communicates what they heard and how they feel about it. In this exchange the leader has the opportunity to adjust until both the leader and the follower share the same vision. This is a lead measure… The feedback you receive from the follower is predictive of the outcome.

So… when someone says “follow me”, they mean listen to me. When someone says “I don’t understand”, they mean… I’m not following you.

In summary, leadership looks a lot like a two-way conversation.

Dealing with Stress in the Team Dynamic

Published on

Stress

The 120VC leadership team has had to tackle many complex business problems over the years; some that were make it or break it.  Needless to say, I have seen my team stressed-out.  What I have noticed is that stress is infectious, but calm is not.  The stressed-out team members will cause the anxiety levels of others to rise, not the other way around.

Shawn Achor, the author of The Happiness Advantage writes about the statistical impact of stress on the brain.  His research finds that our brain at positive performs significantly better than at negative, neutral or stressed. At positive our intelligence rises, our creativity rises, our energy levels rise. Our brain at positive is 31% more productive than our brain at negative, neutral or stressed. We are 37% better at sales and Doctors are 19% faster, more accurate at coming up with the correct diagnosis when positive instead of negative, neutral or stressed.

Bruch and Ghoshal’s (Harvard Business Review – Beware the Busy Manager) Focus-Energy Matrix identifies four types of behavior: disengagement, procrastination, distraction, and purposefulness.  Their research states that a mere 10% of managers are purposeful, that is, both highly energetic and highly focused.  They use their time effectively by carefully choosing goals and then taking deliberate actions to reach them. Managers that fall into the other groups, by contrast, are usually just spinning their wheels. Some managers procrastinate, others feel no emotional connection to their work, and still others are easily distracted from the task at hand.  Although they look busy, they lack either the focus or the energy required for making any sort of meaningful change.

It is important to consider Bruch and Ghoshal’s four behavior types when addressing the stress dynamic on a team.  In my experience it is rare that any individual exhibit a single behavior 100% of the time.  Even the 10% that are naturally purposeful will fluctuate to another behavior type occasionally.  When members of a team are stressed-out, any member’s actions that are less than optimal will create more stress for the entire team. Unfortunately, the results of stress make the negative consequences of disengagement, procrastination and distraction worse, and may even shake the productivity of the purposeful; this is called a stress loop.

To address stress and break the stress loop, it is critical that the leader acknowledge it’s presence and make it safe for the other team members to do the same.  It is important to pause and allow everyone on the team to talk about how they are feeling about the pressure.  Once the team has acknowledged that stress is impacting productivity, you can work together to solve it.  Reducing the stress will take time and must be achieved as a team.  The exercise should emphasize how the effectiveness of each individual impacts the stress level of the other team members.

Reducing the teams stress level requires that everyone on the team make an intentional effort to:

  • Reduce the number of activities they are working on to ensure they are highly focused on those that will create the necessary transformational outcomes.
  • Be conscious of how their individual preparation and performance impacts the confidence and stress level of other team member’s. In other words, those that drop the ball increase the stress level of those that don’t…

And that everyone on the team make an intentional effort NOT to:

  • Focus on reducing their individual stress without consideration for how their approach impacts the other team members, and…
  • Use their stress or workload as an excuse for dropping the ball. Stress / workload is not an excuse for doing a bad job. If the expectations are reasonable, this team member needs to step up or ride the bench.

The success of a team is not measured by how it performs in good times, it is measured by how it deals with hard times.  A high performing team is one that knows how to deal with stress together!  When things get tough and the teams stress level is high, you are only as effective as your Most Stressed-out Player (MSP)!

The Reasons You Want Veterans On Your Team

Published on

winner

Where are you going to find fearless professionals that welcome challenges, have proven leadership maturity to build cohesive teams, and leverage collective talent to deliver projects?

Most veteran joined the military out of conviction for a greater purpose, a desire to serve others. Their purpose quells fear of the unknown and fuels their will to overcome the daily challenge preventing them from completing their objectives. What could your company/practice achieve with a group of professionals driven by your mission and purpose?

From day one, service members as young as 18 are taught the importance of teamwork and leadership. They gladly accept and understand the responsibility of leading people and finding solutions to accomplish tasks in an unpredictable environment and with limited resources. They learn and understand the Team’s collective talents and strengths and build collaborative solutions. They understand the value of people! They learn by doing, trying new methods, failing, reflecting and trying again. What if your company/practice were full of leaders that already possessed the ability to build real-time capability for changing market/business priorities?

In the military, mission accomplishment is the only focus. Military leaders are accountable to their team members and the completion of the mission. Continuous refinement in a dynamic environment and team flexibly is a daily occurrence. The service member is both trained and practiced in this environment. Delivering the product, project, goods or resources must be done. They measure their success against the company mission & vision and not by individual achievements. What could you do with a group of professionals that thrived in this space?

The talent is out there ready to adopt your purpose, to help you build your teams and accomplish all your missions with the same drive, spirit and vigor as they did for this Nation…

Think about the possibilities…

– Steve Soika, 120VC Stakeholder Champion

Hierarchy of Success

Published on

Leadership Support

The difference between a leader and a tyrant is that a leader works hard for the sake of everyone else, while a tyrant makes others work hard for them. Project Managers need to possess strong leadership skills because we have no formal authority.

  • We are responsible for ensuring the success of our “clients” via their projects.
  • We are 100% responsible for leading the project team to the greatest possible success, and…
  • We are responsible for making our clients dreams come true!

From my experience the concept of leadership is widely misunderstood. There is a huge difference between a leader and an authority. Project Managers are leaders but are rarely the decision maker, and therefore lack official authority. Our clients decide what they want built, and the project contributors decide how it will get built. The Project Managers’ role is to lead them to do this in the most effective and cost efficient way, essentially enabling them to reach their greatest potential.

People in authority have the power to wield the proverbial carrot or stick in an effort to manipulate an outcome. Most people that yield the carrot and stick are perceived as exploiting the project team members to ensure their own personal success. These folks can choose to be leaders by inspiring an outcome or can simply wield their authority.

Inspiring an outcome requires remembering that as a leader you are not “in charge”, but that you have a responsibility to those “in your charge”.

  • Leaders don’t dictate an outcome; they help their team members focus on what can be done vs. what can’t be done.
  • Leaders help their team members prioritize their workload and run interference when anything threatens to distract them.
  • Leaders sincerely care about the success of their team members and focus on solutions, leadership style, coaching and mentoring in ways that enable their team member’s success.

Leaders understand that when their team members succeed, the project will succeed and they in turn will be successful. People will naturally give their “All” to the leader they believe cares about their success over their own. People will generally give only the minimal effort required to the authority. Authority has nothing to do with leadership and in my opinion is an antiquated paradigm. Official authority or not, you can achieve more with strong leadership skills than with authority.

The “Hierarchy of Success” is simple:

  1. Work to ensure your project stakeholders are as successful as possible. Make sure that every decision and every action you take serves this purpose.
  2. When your project stakeholders are successful, the project will be a success, and…
  3. In the end you will be successful, and a leader that inspires people to their greatest potential.

Issues, Risks, Impediments, Problems and Landmines

Published on

stop wasting tim

The project management community and their consumers waste countless hours debating about whether the obstacles to completing a project on time and budget are risks or issues.  The Agile community won’t acknowledge either term and strictly employs the term “impediment”.  Simple folks would call anything impacting their ability to get something done “a problem” and when I was in the Navy, we called them landmines.

I have seen several Vice Presidents in a Fortune 100 company on many different occasions consume an entire hour long meeting debating whether the “problem” impacting their project was an issue or a risk.  Since the mission of project management is to move the project forward as aggressively as possible, leaving no time or money on the table, allowing this debate to continue seriously impacts this mission.

In the end, project managers monitor the impact of progress and lack of progress with respect to how it could impact the Project end date and cost.  Things are either ahead, on track or behind.  When something starts to fall behind, there is an obstacle that the project manager needs to address to move the project forward as aggressively as possible.

Since the word impediment is a clearly understandable synonym for obstacle, we have adopted it in lieu of any other term.  This has been done to focus people’s attention on the obstacle / impediment that needs to be solved, instead of debating terminology.  Since 120VC employs the use of slack and late date to prioritize our impediments, it really doesn’t matter what we call them.  We will always focus the project team’s efforts on the obstacle / impediment that will begin negatively impacting the project end date and cost first.

Agile, Waterfall, Scrum & Enterprise Project Management

Published on

With the velocity being created by the Agile movement it is important that we take a moment to clarify a few things. First, Agile is not a standard of any sort. It is a movement that consists of a 73 word manifesto and 12 principals. The manifesto and its principals as written can only truly be applied for the optimization of software development Projects. That said, the spirit of both can be applied more broadly and have been honored in the 120VC Project Management Standard.

Waterfall was invented by a computer scientist named Winston Royce in the 1970’s when he wrote a paper called “Managing the Development of Large Software Systems”. The approach was specifically designed to optimize the development of Software Systems given the technology that was available at the time. In a nutshell, the article outlined how software development should be completed in phases and that no work in a subsequent phase could be completed until all of the work in the current phase was done.

At no time was the Waterfall methodology adopted by the Enterprise Project Management community as it would be the least efficient way to complete a large scale Project with multiple matrix, cross disciplined teams and external vendors.

We define Enterprise Projects as those that require multiple matrix, cross disciplined teams and sometimes external vendors to complete. Enterprise Projects require that communication, and cross organization dependencies be managed tightly to ensure that contributors on one team are ready to start work as soon as the dependent work is completed by a member of another team. Enterprise Projects cannot be completed by a single group of fully dedicated people with a single discipline.

Traditionally, the critical path method has been used on Enterprise Projects. The concept of critical path assumes that there are multiple work streams being executed in parallel on every project; and that given the cost and schedule constraints of most organizations, the schedule of each of those work streams has been compressed or “crashed” to ensure that no time or money is being left on the table.

In the waterfall model, there would only be a single work stream and all of the work would be on the critical path.

Therefore, when people talk about Agile or Waterfall they are talking about frameworks, not step by step standards; and neither of these frameworks have anything to do with traditional Project Management outside the realm of software development.

Scrum is a software development standard that has many well documented step-by-step best practices that can truly optimize an organizations ability to frequently deliver working software. I personally recommend “Agile Project Management for Dummies®” written by Mark C. Layton and published by John Wiley & Sons, Inc. It is a well-documented, easy to follow approach to Agile software development.

Scrum best practices create velocity by requiring a dedicated development team that defines tasks no longer than 1 day in duration, and meets daily to assess progress. With a dedicated team and work broken down into single day increments, it becomes very easy to see where changes need to be made to increase the productivity of the team.

Enterprise Project Management works with matrix teams, breaks tasks down into a maximum of 12 hour increments, and uses the critical path to forecast the impact of progress, lack of progress and risks to make data driven decisions. This approach enables the closest possible delivery of the project to the planned end date and cost.

In my humble opinion, Scrum is the most efficient way to develop working software. When a development organization is truly optimized using Scrum best practices they are not leaving any time or money on the table. The only downside to Scrum is that it completely ignores a companies need to allocate funds and resources from Projects with surplus to Projects in need in a Program or Portfolio. In addition, it doesn’t account for or support the cross organizational dependencies on an Enterprise Project.

With that said… 120VC recognizes that Scrum is the hands down winner when it comes to software development and that the Agile principals can be used to optimize any Project Management Standard. Therefore, the 120VC Project Management Standard has been optimized to leverage each of the Agile Principals in the context of an Enterprise Project and we are working on an Agile Addendum. The addendum is a Standard that allows outputs from a Scrum Project to be used as input into an Enterprise Project to achieve three things:

  1. To overcome Scrums inability to support Program & Portfolio needs.
  2. To allow Scrum outputs to be used to efficiently manage cross organizational dependencies, and…
  3. To allow for the allocation of funds and resources from Scrum Projects with surplus to those in need.

ninjaWisdom Comes with Experience…

Of the many very valuable Scrum best practices, there are only two that can’t be adopted by Enterprise Project Management. The first is the practice of having dedicated teams and the second is the practice of “just in time” planning.

Enterprise Projects will always use matrix resources or “non-dedicated” resources. Consider this… If you have a Portfolio with 200 projects that need to be completed in a given year, let’s assume that at least 100 of them are Enterprise Projects and each will take 1 year to complete.

In this scenario there are only 20 people available to work on your projects across the functional teams, therefore each will be assigned to work on 5 projects at a time. If you were to staff each of these projects with dedicated teams you would need to add 80 people for a total of 100. Dedicating resources would allow you to complete all 100 projects in 1/5th the time or in approximately 2.5 months. This would increase the rate of change across an Enterprise by 5X. This amount of change is not sustainable and would leave your organization with two unrealistic options:

  1. You would have 80 employees with no work for the remainder of the year that you could keep to retain your domain knowledge or lay them off.
  2. You could increase the number of projects you deliver from 100 to 500 in a year, but first ask yourself how well the change associated with 100 is being digested.

Enterprise Projects actually do employ the use of “just in time” planning. The difference is that “just in time” has a different meaning on a development Project with no cross organization dependencies and a dedicated team vs. an Enterprise Project.

Agile projects identify the requirements at the beginning of each Project, but wait to plan out the tasks associated with their users stories at the beginning of each sprint. This can be done because the resources are dedicated and available to work on whatever is decided in each sprint planning meeting.

Enterprise Projects compete for matrix or “un-dedicated” resources. If you don’t book them in advance based on a timeline developed with predecessor successor relationships, they will NOT be available when you need them to start. Therefore, “just in time” planning on an Enterprise Project is at the beginning.

Last note here… Another Agile principal is “Responding to change over following a plan”. This principal can be adhered to even if you create your entire plan at the beginning of a Project. On Enterprise Projects change is driven by two things:

  1. Risks, and…
  2. Requests.

When a Risk arises that can only be overcome by changing the scope, we change the scope! When a request comes in to change the scope… We change the scope!

This is one of the areas that the Agile best practice “Inspect and Adapt” comes into play. If there is an obstacle to completing the Project that can only be overcome by changing the scope, then “good customer service” dictates we do this. If either a Project Owner (Enterprise Project) or a Product Owner (Agile Project) wants to change the scope, they are making this decision because they feel it will benefit their customers or Project beneficiaries.

The only difference between the Change Management Process on an Enterprise Project and an Agile Project is that once the change is requested, whether it is due to a Risk or a Request, the Project Manager assesses its impact to the overall Project Cost and Schedule. This doesn’t impact the Project team’s productivity at all because they continue to complete the tasks committed while the assessment is completed. In addition, there is an Enterprise Project best practice that requires this assessment takes no longer than 10 days.

Once the assessment is completed the impact (if any) is presented to the Project Owner or Product Owner so they can make an informed decision. This is done because all changes are perceived to be great ideas, and all changes are requested without any data on how those changes would impact Project Cost and Schedule. All the “Change Assessment” process does to ensure Project and Product Owners are making COMPLETELY informed decisions.

Program Management Effectiveness: Managing Program Risk

Published on

Program Managers spend their days working with their Project Managers to mitigate the Risks that surface on their projects.  This article will focus on two simple Program Risk Management Tools.  The first tool is the “Late Finish Date”.  The Late Finish Date is the latest date that a Risk can be solved before it begins impacting the Project finish date and cost.  The Late Finish Date or Late Date is calculated automatically by most Project Management Tools and can be added to any Work Plan simply by adding the field to your view.

As most Projects have at least one Risk on any given day, a Program Manager can become overwhelmed trying to decide which Escalation they should take ownership of and which they should allow their Project Managers to continue to solve on their own.  The “Project Manager that screams the loudest” approach to prioritization isn’t always the best way to ensure a Program Manager is working to mitigate the highest Risk in their Program.

The Late Date makes it easy…  For example:  If a Program Manager had 5 Risks across their Program:  One with 5 days to solve before it began impacting its Project’s End Date and Cost, another with 10, another with 20, another with 30, and the last one with 6 months to solve, the Risk with 5 days to solve before it begins impacting the Project end date is obviously their highest priority.

Integrating the Late Date into a Program Manager’s tool kit is as simple as requiring their Project Managers to ALWAYS communicate the Late Date with the description of the Risk and the solution they are proposing. When a Late Date is not provided, the Program Manager should request one be provided before attempting to prioritize the Risk being escalated.

The second super simple tool will eliminate almost 100% of a Program’s “Avoidable Risks”.  We define Avoidable Risks as things like poor resource loading across a Program or Organizational Politics.  We define “Unavoidable Risks” as those that could not be foreseen due to the complexity or uniqueness of a Project.

Most Project Contributors are assigned to several Projects at a time and have daily operational responsibilities. Therefore, most Contributors generally have more work than can be completed in a 60 hour week with competing priorities.  Program Managers should require that their Project Managers manage to their critical path by educating their contributors on the slack associated with each task assignment.  Contributors should be taught that tasks with little or no slack CAN NOT finish late without causing the Project to end late.  Providing this information to contributors will allow them to effectively prioritize their weekly task assignments by prioritizing those tasks with little or no slack above all else.

Who would intentionally deprioritize a task that will turn a Project Yellow or Red?

Requiring Project Managers to manage to the critical path and enforcing it is simple! First, have your Project Managers add the “Total Slack” to the view in their Work Plan.  Then, just be sure to ask the Project Contributors with whom you interact while mitigating Project Risks if they were informed that their task was on the critical path during their last weekly status meeting.  As the Contributors start to realize they can use slack to prioritize their workload, they will start asking their Project Managers to provide them with this information at the time the task assignment is made.

This approach to managing to the critical path will eliminate almost 100% of the “Avoidable Risks” and free a Program Manager to focus on the top priority Risks as determined by the Late Date.

ninjaWisdom Comes with Experience…

Intuition does not come to an untrained mind.  It is important to note that Program Management Tools will never replace the need for a Program Manager to think critically and Lead effectively.  They are meant to give the Program Manager additional data that can be used to increase the effectiveness of their critical thinking and leadership efforts. Without data, intuition is bankrupt.

When introducing the “Late Finish Date” and “Management to the Critical Path Using Slack” to your organization, remember that 80% of education provided by corporations to their team members is lost.  Behavioral change must be championed regularly by Senior Leadership and reinforced daily by managers.  Our tip to successfully implementing these simple tools is to take a top down approach by follow the next three steps:

  1. Share the benefits with Senior Leadership and get their buy-in.
  2. Work with Senior Leadership to train and get buy-in from the Program Management Team.
  3. Train your Project Managers and Contributors on the benefits and expectations. Be sure to follow the steps in the article above to hold them accountable.

We DO NOT recommend the alternative, taking a bottom up approach. A bottom up approach where you start with the Project Managers and Contributors will likely result in a training session that gets every Project Manager talking about the critical path, but not actually employing it to minimize the avoidable risks.  Essentially, it will result in a rebranding exercise with no real change.
Special thanks to Susan Black, Chris Baker, and the 120VC Program Management Steering Committee for their contribution to this article!  You guys rock!

Program Management Effectiveness: A Case Study on Rapport

Published on

When you boil it down…  The PURPOSE of a Program Manager is to ensure all of the Projects in their Program are completed and that the budget allocated to the Program is not exceeded. To succeed at this, Program Managers need to accept that, regardless of how thoroughly each of their Projects are Planned, Risks will occur on each of the Projects in their Program every day.

A Program Manager’s job is to ensure the Risks that are occurring are not due to a Project Manager’s lack of competence; that their Project Managers are actively identifying all Risks and driving mitigating strategies that move their Projects closer to completion as aggressively as possible. Typically, there are 3 categories of competence that a Project Manager will fall into:

Type 1: Performing.

Type 2: Lacks the experience to make the most aggressive decisions, but takes directions and learns quickly.

Type 3: Lacks the Aptitude or Attitude and is a Risk to the Project.

Program Managers are also responsible for performing Program analysis to identify opportunities to allocate funds and resources from Projects in their Program with surplus to Projects in need.  This is done to ensure that all of Projects in their Program can be completed as scheduled, and that the funds originally allocated to the Program are not exceeded. Essentially, a Program Manager:

  1. Assesses and eliminates any Risk to the Projects in their Program associated with Project Manager Competence.
  2. Quality assures their Project Managers’ work to ensure that their reporting can be effectively used to perform the required Program Analysis, that Risks are being mitigated, and that each of their Projects are moving closer to completion as aggressively as possible.
  3. Completes weekly Program Analysis to identify opportunities to allocate funds and resources across their Projects to ensure each completes according to schedule, and to mitigate any Risk to the Program budget as aggressively as possible.

During a study of Project Managers at 120VC, we found that there were two distinct reasons a Project Manager would end up categorized as a Type 3, Attitude or Aptitude. In some cases Project Managers were perceived to have the Aptitude to control the cost and schedule of their Projects; they just chose not to do the work!

First, we assessed the Type 3 cases related to Aptitude and found ways to eliminate the Risk associated with identifying them after being assigned to a Project. The following measures were taken to reduce the number of Aptitude cases to almost zero.

  1. We improved our screening and interview procedures to focus on Aptitude in addition to past experience, qualifications and references. We found that past experience, qualifications and success are all subjective qualifications that ALL candidates view and present in a positive light.  However, Aptitude can be objectively measured with very little room for error. And…
  2. We educated our employees and customers on our Zero Trade Off policy.  In essence, when our clients have a need to start a Project they are being pressured by their organization to provide a Project Manager YESTERDAY, and to begin their initiative immediately. Under the pressure to satisfy a customer’s immediate need, our Account Teams have occasionally assigned a Project Manager that was less than qualified. Sometimes knowingly and other times due to a rushed qualification process.  In all cases, Trade-Offs where consciously made.

The client, in a rush to start their initiative would accept the less than qualified candidate; again, sometimes knowingly and other times due to a rushed qualification process. Essentially, The Trade-Offs created a Type 3 – Aptitude, and put the Project Manager, the Client and 120VC in a position to fail.

To address the Trade-Offs, we created a culture through education that made our Account Managers and Program Managers comfortable passing on an opportunity, rather than rushing the qualification process and assigning a Project Manager that didn’t have the Aptitude to be successful. 

We educated our clients to ensure they understood our rationale for passing on opportunities or being slow to produce qualified candidates. 120VC will not take on an engagement unless we have, or can find, a qualified Project Manager to assign and create a WIN, WIN, WIN scenario; a WIN for the Project Manager, the Client and 120VC.

While assessing the Type 3 due to Attitude, we found that almost no one shows up to an interview with a bad attitude, or shows up to the first day on the job with a bad attitude.  However, everyone is capable of developing a bad attitude. So there was no way to identify a Type 3 – Attitude before assigning them to a Project.

In further analysis we found that in almost every case where there was a Type 3 – Attitude, the Project Manager had more rapport with the Client, Project Owner or Sponsor than the Program Manager had with them. Essentially, the Project Manager was confident in their ability to control the narrative with the client, and was certainly not representing themselves as a Risk.

In each of these cases, the Program Manager was working behind the scenes or attempting to insulate the client from the Risks being created by the Type 3.  The Program Manager was not partnering with the client, keeping them abreast of the Risks being created by the Project Manager, the steps being taken to eliminate them, or taking the time to build rapport. The imbalance of rapport eliminated the Program Manager’s ability to manage the Type 3.

This led us to analyze the Client / Program Manager relationships associated with Type 1 & 2 Project Managers.  In each case the Program Manager had “Good to Excellent” rapport with their client. We found that Program Managers with “Good to Excellent” client relationships rarely encountered a Type 3, and when they did it was usually a Type 3 – Aptitude.

In addition, the Program Managers that had “Good to Excellent” rapport with their clients had fewer challenges with Type 3 – Attitude due to over-allocation.  This is because their clients were following the 120VC Work Intake process and working through the Program Manager to assign work to 120VC personnel.  In scenarios where the Program Manager had less than adequate rapport with their clients, the Project Managers were generally over-allocated. 

In these cases, the client would approach the Project Manager with new work assignments due to their rapport and the Project Manager would accept the work due to their rapport. The lack of Program Manager rapport caused a breakdown in the Work Intake process and led to Trade-Offs that impacted the Project Manager, Client and 120VC.

In summary, our study showed that in order for a Program Manager to ensure all of the Projects in their Program are completed, and that the budget allocated to the Program is not exceeded, they need to employ the “Rapport Tool”. The Program Manager will also need to be effective at identifying Risk, Analyzing the Portfolio, etc… However, unless the Program Manager has “Good to Excellent” rapport with their client, they will not be able to effectively do their job.

How to Avoid the Roadblocks Created by Methodology & Complete Planning ASAP!

Published on

As a Project Management Professional, I learned long ago that our clients have little tolerance for the planning involved when they engage a Project Manager, and all anyone associated with a Project really wants to do is start the work. They believe that the sooner they start the work, the sooner they will finish the Project.

In addition, most clients have an abundance of standard deliverables outlined by their methodology that are lightly documented and may or may not be required on every Project. The lack of clearly documented and subjective deliverables creates DRAG, and results in Risk to completing planning as soon as possible. 

Recognizing that our client’s methodologies are intended to control portfolio pipeline, support financial allocation, resource staffing / allocation, and provide data to facilitate executive stakeholder decisions, the identification and execution of their processes and associated deliverables is just as critical as the actual Project work.

In summary… 

– A Project Manager needs to complete Planning as soon as possible.

– Identify and execute all of the standard deliverables required by their client’s methodology.

– Eliminate any DRAG associated with standard client deliverables that are lightly documented and subjective.

– Eliminate the Risk associated with late-breaking requirements and avoid spending time each week debating about which standard client deliverables and Project Management Best Practices are required, and…

– Prevent Project Team members from asserting mid-planning process requirements to avoid task assignments.

To do this, the Project Manager must identify the standard client deliverables during the First Week of the Project and incorporate them into their Planning Schedule. Then the Project Manager must obtain consensus from the Project Owner and Executive Stakeholders on which are required for each Project.  Once consensus is obtained the Project Manager can escalate any process disagreements to the Project Owner for resolution, and keep the team focused on completing Planning as soon as possible.

To do this we recommend, and take the following steps during the Planning Schedule Approval Meeting:

1. Walk the Project Owner and Executive Stakeholders through the Planning Schedule task by task.

2. Review the standard client deliverables the Project Owner feels are unnecessary, the reasons for their durations, their PURPOSE and VALUE.

3. If the Project Owner feels any of the standard client deliverables are unnecessary after the review, remove them.

4. If after review and removal of the unnecessary standard client deliverables the Project Owner feels the duration for planning is too long, review the reason for the durations of all of the tasks, their PURPOSE and VALUE.

5. If the Project Owner feels the durations for any of them should be reduced, reduce them.

Wisdom comes with experience…

If the Project Owner insists on an unrealistic completion date for Planning after going through all of the steps above there is a reason.  DO NOT ARGUE THE POINT, “zip it” and AGREE!  You will simply manage to the dates, keep the Project Owner informed of progress, Risks, and their solutions to achieve the fastest possible result. If you push hard, communicate effectively, and focus on developing and driving solutions to Risks, you will be perceived as having done everything possible to complete planning by the due date, and the Project Owner will be more than satisfied with your performance – even if you miss the date!

Remember, effectively LEADING the Project Owner is an essential element of creating a platform for success!

Management of the Project Budget – Are you getting what you’re paying for?

Published on

Effective management of a project’s budget begins by managing and accounting for the Projects spending, and establishing a Baseline Budget once the Planning Documents have been established. When a Project Manager is assigned to a Project, two things are generally true.

1. Someone has created an estimated budget for the Project and communicated that fabricated number all the way up the food chain.  And…

2. Just like project work generally begins before the Project Manager is assigned; funds are also spent.  At a minimum the cost of the Project Manager begins accruing on the first day and must be tracked and reported to the Project Owner weekly.

As we all know, there is a huge emphasis in the Project Management Community about the management of Project Budgets.  In fact, some of our basic principles like the “Triple Constraint” teach us to assess Risk in association with Cost, Schedule and Scope.

Unfortunately, most organizations that I encounter want the Project Manager to rely on the reports produced by their Finance Departments.  Given the inherent limitations of these departments ability to gather accurate, project specific data, there is no real way for the Project Manager to use these reports to identify Issues or Risk associated with the Project Budget.

The reports provided from the Finance Department only reflect the spending associated with invoices received by their organization.  They do not reflect the Project funds that have been committed to vendors for goods shipped or services rendered but not yet invoiced.  They certainly don’t reflect the lost invoices, the invoices sent to the wrong email address or the invoices sitting on the desk of Mr. “I Haven’t Had Time”!

Simply put, without knowing exactly what has been Spent and Committed, there is no way for a Project, Program or Portfolio Manager to identify Issues, assess Risk or make informed decisions to ensure they don’t go over budget.

In my experience most Project Owners don’t care about impact to Scope if there is no impact to Cost.  Sometimes there is concern about impact to the schedule even though there is no corollary impact to cost, but, if you want to see someone lose their mind… tell them you are going to go over budget!

In addition to closely tracking what is spent on a Project, it is important for the Project Manager to develop a Baseline Budget after the project has been planned.  This is done to verify the accuracy of the original budget estimate.  Without this step there is no way to know if what was planned can be completed for the amount that has been set aside.

By developing a Baseline Budget, the Project Manager can provide the Project Owner with the information necessary to stay within the original estimate by cutting scope or to obtain the funds necessary by using the Project Plan to substantiate the actual cost.

Without this step, there is no way to know if the decisions you are making about how to spend your funds will prevent you from going over budget because the estimated budget you would be tracking against could be wrong!  Essentially, the decision to skip the establishment of a Baseline Budget and rely on someone other than the Project Manager to track your spending, will severely limit your ability to Manage the Project Budget.

The Role of the PMO – Are you achieving the value?

Published on

I believe we are in agreement as a community that the role of the PMO is to ensure the consistent application of an organization’s methodology and processes across the portfolio. What I don’t hear anyone talking about is why… Organizations launch PMO’s because the CIO and the CFO want to be able to make data driven decisions about how to allocate funds and resources across their portfolios to achieve the greatest return for their investment. Essentially, a project portfolio is no different to them than a financial portfolio.

Ideally, both the CIO and CFO would receive a weekly or monthly fact based report from the PMO that lists each project in the portfolio with a summary of their health in relation to the project end date and cost. This information would then be used to make decisions for the reallocation of funds to projects over budget from projects under budget as well as the allocation of resources from projects ahead of schedule to projects behind schedule. Just like an investor would make buy / sell decisions based on the report provided by the finance manager.

PMO’s have turned to implementing PPM systems at significant cost and impact on the organization in an effort to provide reports. The problem is the consumers of these reports don’t trust the data! This is evidenced by the weekly or monthly status meetings that every Project Manager has to attend to talk about their projects with executives who have already received the report. This meeting takes place because the executives are attempting to validate the data in the report before making any decisions because they don’t trust that Red is Red or Green is Green! Often, they require very detailed financial reports for each of their projects in order to perform their own financial analysis before making decisions. This type of work does not make “O” level executives happy or build their confidence in the PMO.

We have now come full circle to the role of the PMO… The reason PMO leaders need to ensure the consistent application of their methodology is so their CIO and CFO don’t need a secret decoder card, 10 meetings per month and a private detective to get the data they need to make decisions.

Today, PMO leaders spend most of their time implementing or refining their methodologies because their CIO and CFO are unhappy with their ability to achieve the ultimate goal of the PMO; Consistency of Project Management approach, assessment of risk / project health, financial analysis and status reporting. Each new change or refinement made by the PMO requires training and adoption during which most Project Managers are not consistently adhering to the set standard. This cycle of constant change is the number one contributor to the lack of consistent application of an organization’s methodology across their portfolio.

The second major contributor to a lack of consistency in Project Management approach across projects is that Project Managers do not need to adhere to a standard methodology to get a project done and be successful in the eyes of the stakeholders. Furthermore, their customer is generally the person in the line of business, IT, or the home owner that is looking forward to having the project done, not the CIO or CFO. Roughly translated, the chaos created by the constantly changing, rarely documented methodologies, that aren’t really tools to help the Project Manager succeed in completing their projects, are generally viewed by Project Managers as unnecessary overhead.

There is good news… The solution to this problem is simple and cost effective. Find a company that is in the business of Project Management and that has successfully developed and uses a methodology or tool kit for your type of projects. Adopt it. Don’t create overhead for yourself by changing it. Train your teams and then spend your time quality assuring their work instead of constantly reinventing project management. The focus on quality assurance will provide you with the consistency you need to provide reliable data to your CIO and CFO. It will also eliminate the cost of methodology maintenance, offset the cost of training vendors and establish a partnership with a company that can provide you with staff augmentation that doesn’t need to be trained in your Project Management methodology.

In other words, buy a car that runs and drive it. Only a masochist purchases a car that needs constant maintenance and that will not serve its primary purpose: to and fro.

If you care to share your perspectives on this topic or if you have a different point of view, please contact me directly. I would love to discuss this topic with you further.

Rebranding vs. Adopting – A Dangerous Trend

Published on

As Project Managers we talk a lot about Methodologies and Standards. As leaders of Project Management organizations we spend a lot of time developing inter-organizational project management centers of excellence. All of this activity is indicative of two things. The first is a perceived need for organizations to improve their ability to control cost, schedule and produce a ROI; the second is the belief that Project Management disciplines are the way to accomplish this.

The fact is the Project Management trade as a whole is floundering at a CMM Level 1¡ at best. Most organizations’ Project Management Methods are lightly documented, if at all, and in a state of dynamic change, tending to be driven in an ad hoc and reactive manner. In addition, most organizations approach project management differently. Experienced, previously successful Project Managers are hired and asked to re-learn their trade according to their new employer’s point of view.

Management approaches come and go like shiny new objects. I believe that Project Management is here to stay simply because there have been pockets of large scale success that organizational leaders cannot turn their backs on. It is proven that thorough planning provides the ability to forecast impact of progress, lack of progress and issues to project end date and cost. Forecasting allows the quantification, prioritization and the development of appropriate responses to risk so project executives can make informed decisions.

In order for organizations, and the Project Management trade as a whole, to achieve the successes that have been proven to result from disciplined Project Management techniques, we need to take the time and put in the effort to actually adopt them. Today’s trend in the development of Project Management centers of excellence is identifying the latest shiny new object (SCRUM, LEAN, PMBOK) and then completely customizing it to fit the organization. What generally results is a re-branded version of what the organization was already doing. When the organization fails to realize a ROI from the Project Management discipline that was not actually adopted, the failure is blamed on the standard and another shiny new object is identified.

Real change takes discipline and time. There are no short cuts to quality, and customization has proven to give us more of what we already had. There is a reason our Project Management standards exist. It is because they have yielded results. The adoption of external standards in their entirety would eliminate the re-education of Project Managers each time they take a new job. Not only would organizations finally yield the proven results from Project Management and move our trade up the CMM ladder, they would be able to hire professional Project Managers who can accomplish this from any source.

In the end, customization is about our comfort level. Real change is not comfortable, but necessary if there is a real need to improve. Rebranding is not adopting.

If you care to share your perspectives on this topic– or if you have a different point of view – please contact me directly. I would love to discuss the topic with you further.

http://en.wikipedia.org/wiki/Capability_Maturity_Model

Project Management – Leaders vs. Note Takers

Published on Leave a comment

As Project Managers we learn how to facilitate the definition of the project scope while working with the Executive Stakeholders.  We also learn that in order to properly plan a project we must work with subject matter experts as facilitators while they identify the necessary project tasks.

Essentially our job is to identify what the Executive Stakeholders would like delivered and then work with the subject matter experts to have them identify the tasks necessary to give the stakeholders what they want. Once the work is started we gather and report status. 

What is often overlooked is the leadership aspect of those exercises.  Simply documenting Executive Stakeholder requests without questioning until you truly understand their stake, the benefits / impacts to their organization, and their concerns will eliminate your ability to identify conflicts between stakeholders, obtain buy-in from each and develop a unified defensible understanding of what you need to deliver.

At the end of this exercise the Executive Stakeholders should have bought in to a single mission and the Project Manager should possess a level of clarity that will allow him to judge the best approach and the appropriate tasks when provided by the subject matter experts. 

As the Project Manager facilitates the identification of Project tasks, the same level of diligence described above should be taken to ensure he develops a thorough understanding of each task, its predecessors, successors and breadth.  Though each task must be identified by the appropriate subject matter expert, the Project Manager must judge its applicability to the completion of the defined scope. 

Subject Matter Experts are better suited to identify the tasks they will be responsible for completing than the Project Manager, and it is much easier to hold someone accountable for the completion of something they identified as necessary.  However, simply documenting each task provided without gathering the appropriate information to judge its applicability will eliminate the Project Managers ability to support and defend the final approach and schedule to stakeholders; to identify and prioritize the resolution of issues, to develop risk mitigation strategies and judge the impact of scope changes during the course of the project.

In summary, the Project Manager who simply documents stakeholder requests, contributor recommendations and status without due diligence will not have the understanding or credibility necessary to “lead” their stakeholders and contributors to success.

If you care to share your perspectives on this topic with me – or if you have a different point of view – please contact me directly.  I would love to discuss the topic with you further.

Communication Skills – A Means To An End

Published on

When interviewing Project Management candidates, I often ask what three attributes a Project Manager should possess.  In response, one of the three attributes is almost always “strong communication”.  This answer surprises me since communication is simply a means to an end.  Communication is the vehicle in which we deploy all of our attributes or skills, but it is not our final destination.

When analyzing this response I realize that our Project Management community emphasizes strong communication as the most important attribute a Project Manager can possess.  I believe the question that needs to be answered is: Why do we need strong communication skills?

As Project Managers we communicate to accomplish a singular goal; to complete our projects and achieve the highest degree of success possible for our stakeholders. In order to do this we must develop relationships and lead. We accomplish this by communicating.  We can’t lead or build relationships silently.

Many of us have encountered “the project that never ends”.  This problem occurs when the project team and stakeholders are completely focused on the “means” rather than achieving results.  It is the Project Manager’s job to move the team forward by encouraging them to make decisions and then holding them accountable to the results.

Likewise, to improve our success as Project Managers it is important to focus our development and education on the attributes that will ensure our success; up, down, and across leadership and relationship building.  We must focus on the “end” rather than the “means”.

I agree with Ralph Waldo Emerson who said “life is a journey, not a destination”. However, Project Management is about the results, not the journey.

In summary, we communicate so we can lead.

If you care to share your perspectives on this topic with me – or if you have a different point of view – please contact me directly.  I would love to discuss the topic with you further.

Project Management Methodologies – The Brands, The Myths, The Legends

Published on

As the CEO of a project management consultancy, I am in the business of providing project management expertise to those who don’t have it.  During the process of planning and completing projects we also act as emissaries for our trade, raising awareness and educating our customers so they can obtain the greatest value from their investment in project management.

Educating our customers also helps them avoid the costly mistake of investing in training, products, vendors, or individuals that will not improve their ability to control costs and complete projects on time. While carrying out this mission my team and I have found that there is quite a bit of confusion with respect to “what is” and “what is not” a project management methodology.

The most popular training and certification program we see today is the ScrumMaster certification.  Though we endorse it as a very productive and highly adaptive way to develop software, it has no more to do with project management than choosing to use the Waterfall or for Dummies approach to software development.  All three “approaches” can be planned and executed by a Project Manager utilizing an effective project management methodology.

Asking a Project Manager to obtain his ScrumMaster certification is like asking a developer to obtain his scuba certification or pilot’s license.  Though both would be great to have, neither is necessary to expertly perform their development duties.

Another very popular certification is the Six Sigma Black Belt.  Again, Six Sigma is a very effective business management strategy for quality assurance and constant improvement, but it is not a project management methodology. As with the iterative approach to software development, the Six Sigma paradigms can be employed as project requirements when defining a project, but like most project requirements they have nothing to do with project management.

ITIL, an acronym that stands for “Information Technology Infrastructure Library,” is a set of concepts and practices for managing information technology services, development, and operations but not for managing IT projects.

Now that Webster, Wiki, and I have set the record straight, I would like to offer a few points to consider when evaluating how to invest your project management training dollars.  Though it is easy to get caught up in the “latest and greatest,” a little internet research goes a long way.  A good project management training and certification program will focus on leadership, relationship building, and executive communication as the foundational skills necessary to lead projects successfully as well as on planning and measuring project progress to control project costs and schedules. 

Project Managers are leaders and should focus their training on learning how to leverage the subject matter expertise of their project teams.  Accordingly, training or certification programs that focus on specific IT or business subject matter should be avoided.  Lastly, project management software is only effective in the hands of a trained Project Manager.  Providing training in the use of a Project Management software tool to an individual who doesn’t have a solid foundation in project management techniques will not improve his ability to plan and deliver a project.

If you care to share your perspectives on this topic with me – or if you have a different point of view – please contact me directly as I would love to discuss the topic with you further.

PPM Tools: Garbage In, Garbage Out

Published on

More and more executives are realizing that tightly managed projects are mission critical and are seeking to improve their project success rate. Effective project planning and management provide executives with the information they need to make informed decisions with respect to the success of each of their projects. Similarly, portfolio management provides executives with critical information across their entire project portfolio to make informed decisions and improve their overall project success rate.

Project Portfolio Management (PPM) tools provide executives with a central repository for status and health reporting.  PPM tools also provide the functionality to assess and plan for organizational resource needs, ensure proper resource allocation across all projects, and forecast the impact of progress, lack of progress, and issues associated with individual projects across an entire project portfolio.

Unfortunately a PPM tool only allows an organization to improve from “good” to “great.”  If your organization’s internal project management is poor, it will still be poor after the implementation of a PPM tool.  The first step to improving a poor project success rate is to invest in the development of your organization’s project management center of excellence. 

By investing in and providing your project management team with a project management standard and training, your organization will realize immediate improvements in its project success rate.  Many of the companies that provide professional project management also license their project management standards and provide training and certification in their use.  Licensing a project management standard and sending your team to training as opposed to developing a proprietary standard is the fastest way to see immediate improvements in the success of your projects.

Investing in the design, development, and implementation of a PPM tool is often costly and requires the allocation of valuable resources and months to deliver.  If your organization hasn’t first ensured that it has the internal project management expertise to deliver projects with a high rate of success, the information in the PPM tool will be of little value as it will have been deployed on a foundation of failure.  The implementation of a project management center of excellence will yield immediate results and provide the foundation for the successful launch of a PPM tool. 

First improve the success of your projects…  Then you can improve your portfolio’s success rate.

Project Issues Aren’t Just for Special Occasions

Published on

Project Managers are hired to perform two basic functions: plan and then manage projects. Once the monumental task of planning is done all that remains is the project’s management. Management requires that the Project Manager attempt to keep the project moving according to the plan. However, if every project were to go according to plan, even the largest project could be “managed” by gathering status once a week… 

Collecting status on projects that are on target doesn’t take much time and certainly doesn’t require any real management. We all know that true “management” of a project is predominantly the daily mitigation of issues that arise and get in the way of completing planned work on time or in the way that was envisioned.

As Theodore Rubin famously said, “The problem is not that there are problems. The problem is expecting otherwise and thinking that having problems is a problem.”

Executives intrinsically understand this premise but sometimes in the course of a hectic week, hearing about project issues just isn’t on their agenda. However, in spite of careful project planning, problems do arise and each one threatens to derail the project from the plan. The process of identifying and implementing solutions often means informing executives that issues exist and obtaining their buy-in on the solutions. It may also be necessary for Project Managers to remind these executives that the occurrence of issues is natural and the primary reason that they are on point.

When a Project Manager brings an issue and proposed solutions to an executive, the conversation can get bogged down if the executive forgets that the real work of the Project Manager is overcoming challenges. Good executives remember that the role of a Project Manager is to engage them in ongoing communication about what those challenges are and to present them with the best, most cost-effective solutions.

Executives who understand that project management is about problem-solving and who encourage open communication with their Project Managers are also the ones best prepared to answer tough questions at the boardroom conference table. Executives who internalize the concept that a Project Manager’s role is to keep them informed about issues – rather than shield them – maintain a much more positive and productive level of communication and enjoy higher levels of project success.

The First Rule of Project Management Communication

Published on

The first rule of project management communication is that we don’t communicate with executives and stakeholders in Project Management mumbo jumbo. 

We Project Managers are highly skilled practitioners of a trade and use a lot of complex tools, theory, and vocabulary that is specific to our field.  Given that Project Management is a nascent and growing occupation, it isn’t surprising that we want to talk about the field’s intricacies and speak in its language. 

Effective communication with executives is critical to a Project Manager’s and a project’s success. Unfortunately, when a Project Manager attempts to teach Project Management theory and vocabulary to executives, he winds up creating barriers to his own success.  Executives do not have the time nor are they interested in learning how to be Project Managers.  Rather, they employ Project Managers to plan and manage projects, identify risk, plan mitigations, and then to communicate the essentials in terms they can understand so they can make informed decisions.

Communication breaks down when Project Managers don’t take the time to translate from Project Management mumbo jumbo to simple business terms.  To provide unnecessary detail is a bit like a doctor describing the intricate biochemistry involved in a bone marrow transplant to his patient.  The patient doesn’t want to know nor does he have the education to understand all of the complexities and would simply end up confused and scared; he just wants to know if it will make him well, how soon, and when treatment will begin.

Likewise, an executive faced with a project issue does not want to be schooled in Project Management. When issues arise, the Project Manager must be smart about how he communicates because these are opportunities to increase the executive’s confidence in him and to demonstrate his skill and value.

The proper role of the Project Manager is to help the executive understand the issue by describing it using plain, pertinent English.  And it is vital that he answer the basic questions the executive will have about the issue:  What’s the problem?  What impact does it have on the end date and project cost?  What are you doing about it?

In summary, in addition to learning to use all of the complex Project Management tools, theory, and vocabulary, Project Managers need to learn how to communicate using the language of their clients.  Speak in plain business terms with your executives about the impact that progress, lack of progress, and issues are having on your project.  The age-old axiom of 3-B’s in speaking applies here: be brief, be brilliant and be gone.  A smart and effective Project Manager understands project issues in terms of theory and can easily identify impact using state-of-the-art tools, but he also knows that to be truly effective, he must communicate with his stakeholders in terms that they can understand.

An Alternative to Proprietary or Highly Customized

Published on

Regardless of the economic times, companies must closely manage project time-to-market and cost to realize project benefits and yield a return on their investments, and naturally, that need is even greater when funds are tight.  In the face of this, many companies conclude that they must develop an internal Project Management Center of Excellence to allow them to manage their projects effectively. 

To achieve this, companies spend enormous energy, time, and money developing and launching their own proprietary Project Management standards.  Unfortunately for companies that are not in the business of providing Project Management as a consumer product, often the high cost and redundant resources required to implement and maintain standards together with the high rate of turnover in the Project Management field result in Centers of Excellence that begin a steady march towards extinction shortly after their launch.

In the past companies had no alternative to developing their own Project Management standards, but now there is an approach to achieving long term success for a fraction of the cost.

The average launch of a proprietary Project Management standard begins with a commitment of dollars and the launch of a project.  Often an organization specializing in Project Management is hired to develop a custom Project Management standard under the guidance of the client’s leadership team.  Once the standard has been developed, training is provided and adherence is monitored during an adoption period.  And then the project is closed.  

In the days that follow the launch of the Project Management standard, the Project Managers, Project Management Leadership, and, if properly staffed, the training team are left to maintain the new standard.  But several factors cause the standard to begin unraveling almost immediately.

The primary factor is the high degree of Project Management turnover industry-wide.  As there are few companies that provide Project Management as a consumer product, the career path for most Project Managers is very horizontal.  Before a company can promote anyone in the organization, the Manager of the Project Office must take another position or leave the company.  Additionally, in the interests of efficiency, companies often assign their Project Managers to the same types of projects over and over so the Project Managers do not gain the exposure to diverse projects that is required to develop their Project Management skills.  As a consequence, they are rarely seen as capable of leading a Project Office or managing other types of projects, and external candidates are often chosen over internal Project Managers. 

This cycle leads to enormous turnover in the Project Management community, and the constant need to train new project managers on the use of their custom Project Management standard severely affects an organization’s productivity.  The demands on training teams are further compounded by the need most organizations have to augment their internal Project Management staff with contractors who must also be trained in the use of the custom Project Management standard.  As a result, organizations must maintain a large staff of full-time trainers and they must pay their Project Management contractors for the time they spend attending training and learning how to use the custom Project Management standard.

The remaining factors in the demise of most custom Project Management standards are all related to a lack of available external support.  Because the Project Management standard is proprietary, there aren’t any vendors who can provide appropriate trainers or training when the training team begins to turn over or demand forces augmentation.  And a vendor certainly can’t provide Project Managers who are already trained and certified in the use of the customer’s Project Management standard.

The result of the turnover and lack of external support is that, no matter how well conceived the standard was at the outset, an organization’s Center of Excellence will degrade over time as the maintenance of the standard moves it further and further from the concept and intent of its originators.  Inevitably, team members who know nothing about the established standard will be hired and they will be trained by people who weren’t part of the development and launch and know little more. 

The alternative is simple…  There are a handful of organizations today that provide Project Management as their core competency, as a consumer product.  They are the same organizations that you would hire to create a custom Project Management standard.  These organizations have proven Project Management standards, which are based on the PMI’s framework, that have been used successfully without customization across industries and diverse companies.  Because it is their core competency, they can justify the expense of maintaining a Project Management standard, training materials, certification program, and training team.  

Simply employing one of these standards without modification will ensure a sustainable standard while taking advantage of the vendor’s economies of scale.  No development time will be required as the method already exists and has already been proven.  And many of these vendors have readily available training materials and training, dramatically reducing the time required to launch your organization’s Project Management Center of Excellence and significantly decreasing the cost of maintaining the standard. 

Because your standard will be the same as the vendor’s, the vendor will be able to provide Project Managers to augment your team who can deliver according to your standard without the investment of time and money to train them.  This allows you to size your internal project team without the expense of maintaining a bench model and to still be able to handle the fluctuations in yearly project workload.

Lastly, as most of these vendors also have certification programs, you won’t get locked into a single vendor for staff augmentation.  More importantly you can put the cost of training back on the vendors supplying the resources by demanding that their resources maintain the vendor certification associated with the Project Management standard you are employing.

Essentially, there is no good reason – financial or otherwise – for a company to develop and maintain its own proprietary Project Management standard when there are organizations that can readily provide a flexible internal Center of Excellence for a fraction of the cost.  Your company will reap the benefits of having a Center of Excellence that is scalable, flexible, and cost effective without the cost and effort associated with its development and maintenance – and without the certainty of its degradation over time.

Avoiding the High Cost of Project Management Turnover

Published on

At 120VC, we recruit and place Project Managers every day to perform the project management services we provide.  When we do so, one of the key concerns we hear from clients is whether the assigned Project Manager will see a project through from start to finish.

This is a reasonable concern because lack of project management continuity is a key cause of schedule delays, cost overruns, and even project collapse.  Many of our oldest clients first came to us when a Project Manager bailed before finishing their assignment.  We have retained these clients because we advocate and deliver a holistic approach to project management that builds systemic continuity and reduces dependence on any individual Project Manager.

The key to our ability to provide project management continuity is our exclusive 120VC Quality Assurance model.  The three key components of the QA model are project standards, education, and project audits.

The project management community unanimously agrees that standards are mission critical and spends much of its time in their creation and maintenance.  However, there is very little discussion in our community about the goal of these standards.  Unfortunately this lack of focus on the goal has prevented most standards from being effective and serving their purpose.

The primary goal of standards is to ensure the consistency of project management deliverables, but not merely for consistency’s sake.  More importantly, consistency provides the foundation for preventing the costly effects of project management turnover.  Additionally, the lack of focus on the goal of mitigating the impact of turnover has also inhibited the recognition that standards alone will not achieve it.  To effectively mitigate the impact of project management turnover, standards must be combined with education and project audits.

In my experience, the skills of project management must be taught.  Like a second language, the project management skill set is complex and is not gained through osmosis but through education.  At 120VC we assess the knowledge level of each of our Project Managers and then teach them how to work with clients regardless of environment or project subject matter.  This enables them to create a Project Plan that can be used to forecast the impact of progress, lack of progress, and issues on the project end date and cost.  Our clients expect that Project Managers will use this education along with our project management standards to effectively plan and move their projects forward.

Frequently organizations focus on the completion of templates and forms instead of the quality of their content and how they are being used as tools on a project.  Unfortunately, simply publishing a set of standards and even ensuring that forms are filled out is not sufficient to guarantee continuity when a project has lost its Project Manager.  Once standards have been created and Project Managers have the education and skill to effectively plan and manage projects, achieving continuity requires one final and critical component:  daily and weekly project audits… 

While the project auditor role isn’t new to project management, the auditor’s function in our Quality Assurance model has revolutionized project management for our clients.  Our audit system validates fidelity to our project standards, ensures the quality of both the Project Managers daily work and the quality of each of their project management deliverables.  Our system also facilitates the Project Manager’s education and most importantly, because the deliverables are all consistent with a proven standard, our audit system ensures that the auditor – who is also a qualified project manager – is familiar enough with the project details, environment, and client politics to step in and take over the project without any rework that would result in schedule delays or cost impact. 

Utilizing our Quality Assurance model ensures optimal continuity because the audits ensure all deliverables are meaningful in content, standard in form and execution, immediately actionable, and ensure that the auditor has requisite knowledge of the project details, environment, and client politics to drive the project forward. The combination of standards, education and audits has been proven to minimize the effects of project management turnover.

Effective project management is my passion, and I can demonstrate that rigorous Quality Assurance is the key to continuity.  When using our Quality Assurance model, our clients are less dependent on individual Project Managers and much more secure that continuity will be maintained regardless of project management turnover, saving them time and money and guaranteeing project success.