Monday, February 20, 2017

Stakeholder Personas: Part 2 - Expert-Oriented

Stakeholder management is a major aspect of project management.  The Project Management Institute identifies it as one of the ten major knowledge areas of project management and has numerous tools and best practices for managing stakeholders.  But let’s face it.  You don’t manage the stakeholders.  In fact, it is much more likely that they are managing you.  So what you manage are your interactions with the stakeholders.   Now “interactions” implies that there are at least two individuals involved, you and the stakeholder.  In this series, I want to address the best practices for interacting with stakeholders based upon how they normally interact.  This is based upon what they consider to be compelling issues and their primary area of concern.  I have identified five personas that represent the types of stakeholders I have encountered over the years.  These are the action-oriented stakeholder, the expert-oriented stakeholder, the process-oriented stakeholder, the data-oriented stakeholder and finally the uninterested stakeholder.  In this post I will talk about interacting with the expert-oriented stakeholder.

The Stakeholder

The expert-oriented stakeholder puts their confidence in experience and track records of individuals.  Typically, these people are themselves an expert in their area.  They are personally self-confident within their area of expertise and they have developed a network of other experts that they rely upon.  For those inside their circle of experts, they will provide tremendous support and latitude.  For those outside the circle they; are far less trusting.  It is interesting that some expert-oriented stakeholders put an emphasis on schooling, degrees and certifications.  Others put an emphasis on the track-record of individuals on other projects.  But regardless how the stakeholder determines who is an expert, once their find one they lean on them and trust their judgement.  These individuals are quick to delegate authority to experts, and reluctant to delegate it to those whose expertise they doubt.  They definitely will “play favorites” and won’t hesitate to communicate outside the normal channels to talk to their network of experts.   

Interaction Style

The key to interaction with this stakeholder depends upon whether you are inside their circle of experts or not.  When inside the circle, quick high-level communication is often all that is needed.  If you are not inside the circle, your communication needs to carry the support of experts that the stakeholder trusts to be taken seriously. Whether you are providing a status update, a project review, or an issue report, they will want to know if what you are telling them has been reviewed and approved by the experts. Their typical questions from them will be:

  • “What is working with you on this?”
  • “Who else have you presented this too?  What did they say?”
  • “Have you talked with …… yet?”
They would prefer a presentation that leads with who is involved, the bottom line opinion or decision of those involved, and then if there are still questions to be resolved, who you would like to have work with you to resolve them.
If their circle of experts are supporting a position, it is almost certain they will support it also.  If the experts are against it, they will be against it.  If the other experts are mixed, they will study the issue with you.  If you can’t tell them where the other experts stand on the issue, they will send you back to do more homework.

Key Messages

When discussing your project always be ready to bring in your experts.  You do not need to know everything, but you do need to know when to rely on the experts on the team or in the organization.  If you are presenting a major decision or issue for resolution, invite other experts to the meeting, or have their comments and perspective ready to present as part of the support for your recommendation.  Let me also add that through-out your interactions with this stakeholder, if you are not already in their circle of experts, you should be aspiring to be.  Demonstrate your own expertise, not at the expense of others, but it is appropriate to acknowledge you experience and training if they are applicable to the issue being discussed.   The point is that you need to establish you own credibility if you want to move into that circle.

Good News and Bad News

For these individuals, they won’t believe any good news until it is verified by an expert they trust.  And they won’t get panic over any bad news if your communication of the bad news includes the experts you are bringing in to help.  The first question in their mind is always, “Who?” Who else has seen this news and what is their opinion?  That doesn’t mean you should delay your communication of bad news until you have experts lined up.  You can immediately notify the stakeholder of the bad news and ask for their help to get you an expert to assist with the problem resolution.

Final Thoughts

If you are inside the circle of experts, these are great stakeholders for your project.  They will let you do what you need to do and support you along the way.  I have had the privilege to work with several stakeholders who operated in this fashion.  Once I won their trust, my projects had priority in the organization and we achieved some fantastic results.  I have also had the misfortune to work for one stakeholder who operated in this style and whose trust I never won.  Every project of mine was challenged, delayed, and micro-managed.  

Monday, February 13, 2017

Stakeholder Personas: Part 1 – Action Oriented

Stakeholder management is a major aspect of project management.  The Project Management Institute identifies it as one of the ten major knowledge areas of project management and has numerous tools and best practices for managing stakeholders.  But let’s face it.  You don’t manage the stakeholders.  In fact, it is much more likely that they are managing you.  So what you manage are your interactions with the stakeholders.
Now “interactions” implies that there are at least two individuals involved, you and the stakeholder.  In this series, I want to address the best practices for interacting with stakeholders based upon how they normally interact.  This is based upon what they consider to be compelling issues and their primary area of concern.  I have identified five personas that represent the types of stakeholders I have encountered over the years.  These are the action-oriented stakeholder, the expert-oriented stakeholder, the process-oriented stakeholder, the data-oriented stakeholder and finally the uninterested stakeholder.  In this post I will talk about interacting with the action-oriented stakeholder.

The Stakeholder

The action-oriented stakeholder likes to see things happening.  They are very interested in making forward progress so their first concern is always the schedule.  They are addicted to adrenaline.  They love to be at the center of the action and are energized by the frenzy of activity.  Problems don’t disappoint them, they excite them because it is an opportunity to dive into a situation and make something happen.  When there isn’t obvious action on a project, they assume nothing is happening.   Typically, these individuals enjoy the spotlight and attention that goes with being in the middle of a crisis and working to resolve it.   The fact that a too quick reaction or over-reaction to a problem can make the problem even worse does not concern them.  These individuals can make great change agents or dynamic leaders in times of crisis.  But they can also exhaust an organization or team over time by creating unnecessary crises.

Interaction Style

The two key elements of any interaction with this stakeholder is immediacy and the next steps.  They want to know what is happening.  Always lead with the schedule when giving them a status update.  If there is a problem somewhere on your project, they want to know as soon as possible and they want to know what you are doing.  They don’t need a complete plan, but they want to know you are working on the problem.  Their typical questions will be:
  • “What is happening now?”
  • “What are you going to do next?”
  • “How can I help?”

Normally, they prefer frequent short crisp communications rather than in-depth analysis.  They would rather get a quick text or phone call giving them the current status than get a well rehearsed formal project presentation or detailed report providing background and options.   
They also are ready to make quick decisions.  Tell them what you want or need and expect an immediate response.  In fact, a way to encourage them to make a decision is to let them know that action on a project has stopped until the decision is made.

Key Messages

When discussing your project always have a schedule status.  Explain what has been accomplished and what is underway.  When presenting a project problem with this stakeholder, you don’t need to have all the answers.  They would rather interact many times through a series of short-term action plans, than to have one major interaction with a master plan that covers the entire project and options.  In particular, they want to know what you are doing and what they can do.  Expect them to make quick decisions and to offer help.  I recommend that you interact with frequent concise status updates of what is happening.  Remember, if they are not aware of any action, they assume nothing is happening. 

Good News and Bad News

For these stakeholders, both forward progress and crisis problems are good news.  A project that is in the midst of a long analysis or that is waiting for deliveries from suppliers or even worse, waiting on an approval from someone else before it can continue, is bad news.  A great way to communicate and interact with them is through a schedule chart that has at least one or two events or milestones every week.  Then it is easy to show progress and action.  They don’t consider unexpected events or deviations from plan to be bad news, but rather they are “opportunities.”  In fact, to them, a bad news message is when they didn’t find out about a problem as soon as it occurred.

Final Thoughts

I appreciate these stakeholders when running innovation, organizational change or crisis projects.  They are ready and willing to make decisions and keep things moving forward whenever the inevitable changes or roadblocks are identified.  However, they can be disruptive at times.  I was running a project a few years ago and one of the stakeholders was of this type.  He would often show up at project meetings and start giving directions to the project team, totally disrupting the plan and current activities.  In order to manage our project interactions, I eventually had to tell him he was not allowed to attend team meetings (an interesting discussion given that he was my boss’s boss).  What we agreed to do was for me to meet with him several times a week to provide status and let him know how he can help us move the project along.

Monday, May 16, 2016

The Value in Non-Value Added Activities

With the wide-spread acceptance of Lean Manufacturing and Lean Enterprise principles, the term “non-value added activities” has come into the business lexicon.  These are the activities that an organization performs that do not directly contribute to the generation of customer value.  Within the context of manufacturing, these activities are categorized as one of these types of waste.
  • Over-production, ahead of demand – wasted effort.
  • Waiting for the next process step – wasted time.
  • Unnecessary transport of product or goods – wasted effort.
  • Over-processing of product due to poor process design – wasted effort.
  • Inventories greater than necessary – wasted cost.
  • Unnecessary movement of employees (looking for tools, paperwork, help, etc.) – wasted effort.
  • Producing defective parts – wasted time, cost, and effort.

The Lean Value Stream Map categorized all of the activities in a business process into either value-added steps or non-value-added steps.  Even the value-added steps are further analysed and the time spent conducting that step is divided into value-added time and non-value-added time.

Implementing Lean has led to improvements in productivity and cycle time.  This has often transformed an operation; improving both customer satisfaction and profitability.  But sometimes, implementing Lean has not resulted in dramatic improvements for the business. 

Of course there are the Lean implementation failures, which seem to occur at least 50% of the time.  These are often due to poor management commitment and understanding, inadequate training, and the difficulty of culture change.  But I would like to discuss a different type of failure.  This is the failure to see improved customer satisfaction and the increase in sales and profitability after a “successful” Lean implementation.

This condition occurs when the company misunderstands the elements of value from a customer perspective.  Yes, there is value in the efficacy of the product.  The customer wants it to work to the expected level of fidelity and be reliable and durable enough to continue working through the expected life.  The Lean manufacturing definition of value-added activities will cover these elements of value. 

But many customers also want other aspects of value that are not directly tied to product performance.  These include brand affinity, ease of doing business, and a sense of personal engagement with the company. 

Let me give you an example.  Many companies have “Leaned” their customer service and help desk functions.  Now when a customer calls the company with a question or complaint, they are routed into an endless series of “push this number” and “select this number” until they finally are placed on a lengthy hold, waiting to talk to a live body.  Often that live body can’t answer any questions, but can only read from a script.  So while the company thinks it has “Leaned” customer service by eliminating non-value-added effort, the customer feels abandoned, belittled and unwanted.  Activities the company categorized as non-value-added because they did not support the manufacture of product, were activities that were very important to the customer.  The result is a customer who experiences a reduction in value, not an improvement in service.

An internal, product-centric view of “value” can lead a company to remove activities and functions that are important to overall customer satisfaction and that build a strong relationship with the customer.  A Lean initiative needs to start with a true understanding of what the customer values.  This should not be determined by the design engineers, manufacturing managers, or even the Lean consultants.  This needs to be determined through voice of the customer analysis. 

In many industries today, the new competitive advantage is creating and establishing a personal relationship between the company and the customer.  “Leaning” these customer interaction processes can destroy competitive advantage.  Strong positive relationships take time and numerous positive interactions.  Lean processes that minimize and eliminate interactions are eliminating value-added activities – even though the activities may have nothing to do with the product.

So let me propose, as an adjunct to the list of activities used in Lean analysis to define a waste, a list of activities that define value-add.
  • Activities that directly answer specific customer questions.
  • Activities that provide special privileges and offers to existing customers.
  • Activities that measure customer engagement and satisfaction with the company and its products and services.
  • Activities in the company’s operations that create or add to the functionality of products or services.
  • Activities that build customer confidence in the company’s brands, products and services.

I’m not suggesting that a company should abandon Lean or ignore the attributes of waste.  I am suggesting that a company should embrace the attributes of value.  Prepare a value stream map for the attributes of value and ensure that these value-adding processes are operating smoothly.

Monday, April 18, 2016

Pivoting Project Management Reviews

Entrepreneurs are using the terms “pivot” and “persevere” to identify strategies for decision-making.  When confronted with a situation that is not leading to the desired results, they must decide whether to gut it out and persevere on the current path, or pivot to a new direction and new approach. 
This decisions process can and should apply to many of our business and project management practices.  If your practices are not leading to the desired results, make a conscious decision to pivot or persevere. 

Let’s talk about the project management practice of project reviews by senior management.  Are the reviews leading to better project execution and performance?  Are the reviews leading to better project selection and planning?  Are the reviews leading to better project portfolio performance in terms of business impact?  If the answer is, “No,” and you have been doing the same types of reviews for years, it is probably time to pivot.

Project Management Reviews

Let me describe the typical project management review I see when I first visit a new client.  Senior management is reviewing project status on a regular basis – normally tied to the calendar.  For example, one client had a weekly review a summary of all open projects and a “deep dive” on two or three projects based upon which projects were perceived to be in the most trouble.  At the deep dive portion of the reviews, the emphasis was upon the status of the problems or issues that had occurred and what the team was doing about those issues.  The project team received lots of “help” to fix the current problem, but there was seldom any discussion about extrapolating from the current issue to foresee future issues or to share lessons learned from this situation with other project teams so that they could avoid the same problems.

My recommendation for a project management review pivot is to change from this backwards-looking, reactive project management reviews to a forward-looking preventive project review.  What do I mean?  The project review should be focused upon all the open and remaining risk threats on the project (not just the current crisis) and the resources and management actions needed to reduce or eliminate those threats.  And when you get that working well, add a discussion about the possible risk opportunities for the remainder of the project and the resources and management actions that will enable those opportunities to be realized.


The current approach leads to a “superman” mentality among project leaders.  They bounce from crisis to crisis, using their superpowers to overcome each one.  They don’t prevent problems, they just solve them.  The leaders get great credit and often rewards for their effort.  In fact they often take on “rock star” status within the organization.  While they may be good fire-fighters, I would not call them good project managers.

Let me relate a story from a client of mine.  His high-tech firm had two major development projects underway.  Both were developing new product lines using emerging technology.  Both projects were large be this company’s standards – they were planned for three to four years in duration, with a budget of over $20 million, and a large team located in multiple sites.  Both projects were managed by senior project leaders with strong technical, business and inter-personal skills. 

One project leader, we will call him Jack, was a fire-fighter.  His team faced many problems and challenges and he overcame all of them.  Granted it took late nights, weekends, and some creative solutions but with his charismatic personality he rallied the team and they come through. The project was a major market success.  However, the project finished more than a year late and several million dollars overrun.

The other project leader, we will call him Dave, was a risk manager.  Dave emphasized proactive risk management.  He had a well-developed plan with risk triggers and options that were used by the team.  His project did have several minor fires that had to be resolved, but nothing like the problems that occurred on Jack’s project.   Dave also had a major market success.  But Dave’s project was only two months late and came in on budget.

So now it is six months later and the business is going through a major restructuring due to some problems in a different division.  The business is downsizing and it only needs one senior project leader.  So Dave was laid off.  I asked the senior management why they laid off Dave instead of Jack.  Their response surprised me.  In their opinion, Jack was a superhero who could fix any problem, but they didn’t know if Dave could handle the stress of a major project in crisis.

I pulled together a summary of the two projects, including the major challenges that each had to overcome.  I identified the proactive risk approaches that Dave had used and the absence of those in Jack’s project.  Several of the senior managers told me they had never stopped to consider the risk management approach in the project reviews.  They never asked about risk avoidance and mitigation. They were just focused on the current crisis and what was being done to fix it.

The Pivot

So if you want to transform your project performance, I encourage you to consider pivoting your project management review approach.  When reviewing a project, I recommend the following topics.
  • Quick review of the Project Charter.  Remind everyone of the project’s purpose and goals.
  • Current status with respect to the project plan.  Make sure the team is reporting against the plan and don’t just give a list of the things that they have been doing.  If they aren’t working the plan find out why. 
  • Risk issues with their response or mitigation strategies that should be encountered or resolved within the near future.   Ensure the team has an adequate strategy and resources to resolve the risks.
  • New risk issues that have been discovered since the last review.  What changed to create these risk issues and what other impacts could those changes have on the project.
  • Critical milestones and decisions that will occur on the project in the near future.  These are potential risk points and senior management may want or need to engage with those activities.

Changing your project management reviews into risk reviews will pivot your project management approach from reactive to proactive.  I can assure you the project performance and business impact will improve.  But some of your superhero project leaders may resist the change.  They are fire-fighters and want a fire to fight.  Risk based project reviews will suppress fires and expose these leaders as the arsonists whose poor project management practices are what started the fires.   

Monday, April 11, 2016

Practical Idealism

Those two words are normally considered opposites.  I’ve heard for years that “idealists” aren’t “practical.”   “Practical” is grounded in reality.  “Idealism” is wishful thinking that can’t be achieved.  But by the same token, “idealists” challenge us to improve and go beyond our current performance, whereas “practical” approaches are stuck in the current paradigm.   If we could put them together, practical idealism could lead to an innovative approach that is transformational. 

This isn’t just hypothetical.  There is a real-life example right now in the sports world of what happens when practical idealism is implemented.  Have you heard of the University of Connecticut (UCONN) women’s basketball team?  Here are a few facts about them:
  • They just won their fourth straight national title – no women’s basketball team has ever done that.
  • They have won 75 straight games – all by double figures.
  • Their average margin of victory this season (including the NCAA tournament) was 39 points.
  • The program has a 100% graduation rate and over 80% of the players have a GPA of 3.0 or higher.
  • Their coach has won more national titles (11) than any other coach in college basketball – men or women.

Now this type of dominance does not mean that the sport of women’s college basketball is in decline or immature. The caliber of the competition and the quality of the players has been improving for years. There are tremendous women athletes in this sport. And between all of the other teams that play women’s college basketball, there is fierce competition. In my opinion, women’s college basketball exemplifies better team play than men’s college basketball – which is dominated by individual play. It is a tough, competitive, athletic sport. 

Yet UCONN performs at a level that is far above everyone else.  Why is that? Practical idealism. 

UCONN’s coach, Geno Auriemma, sets idealistic goals for the team and each individual.  Their goal as a team is not to be competitive, but rather to be dominant.  And their measure of performance is not only against the other team, it is against their previous performance.  The team is always striving to get even better.  But Auriemma also focuses on personal goals for each of his players.  That is why they have a 100% graduation rate and such high GPAs.  Any coach who lists these yearly goals for his team is an idealist:
  1. Go undefeated.
  2. Win the national championship.
  3. Beat opponents by an average of 40 points.
  4. Team members have a 3.0 or higher GPA.     

What makes UCONN different is that they have established a practical approach for achieving these idealistic goals.  The UCONN women’s basketball team works as hard as any college team in the nation.  Their practices are tough and exhausting.  They work on basic skills and on teamwork.  They are constantly seeking to improve.  Every turnover, every missed shot, every lost rebound from the previous game is scrutinized to understand what happened and prevent that from occurring again.   While the Auriemma shows genuine care and concern for each player, he also challenges and pushes them to be their best.  He refuses to accept complacency or mediocrity from any player in any aspect of her game.
Granted, UCONN is able to recruit from among the best high school women basketball players. But there is lots of talent to go around in women’s college basketball today. UCONN is only able to recruit 12 players for scholarships. They have talented team members, but so do many other programs. And UCONN does not limit their schedule to playing “powder puff” teams. In the final rankings of women’s college basketball for the 2015-2016 season, UCONN was number one and they played six of the remaining nine (beating all of them by double digits).    

Early this year, Auriemma quoted Julius Caesar as the team was preparing for a game, “Vini, Vidi, Vici” – we came, we saw, we conquered.  The attributes of dominance that were the hallmark of the Roman Legions 2,000 years ago were used to inspire his team this year.  “We came.”  They will go anywhere and play anybody.  In fact, they try to schedule the best teams in the nation.  “We saw.”  They study their opponents and prepare for them.  Some of the teams are bigger, some are great shooters, some play tenacious defense.   Doesn’t matter.  UCONN negates their strength, often by besting them at their own game.   “We conquered.”  UCONN teams hustle.  They are always working hard.  They dominate many aspect of the game.  And even when the “second string” enters the game – often early in the second half – they continue to dominate. 

So what are the lessons of “practical idealism” we can learn from UCONN?  
  • First, it is OK to be idealistic. Set big goals – seemingly impossible goals. 
  • Second, recruit talented people. Find the best people available and embed them into your team.
  • Third, work hard at the basics. There should be excellence in everything you do. Don’t accept mediocrity on any level.
  • Fourth, study your competition to understand their strengths and weaknesses. Then work to be as good or better than they are at their strengths and exploit their weaknesses.
  • Fifth, continuously improve. Set the standard of performance and then exceed your own standard.
  • Sixth, coach and encourage your people fulfill their personal goals and to be successful in all walks of life.
The UCONN story is inspiring.  Oh, and it is also excellent basketball.

Monday, March 21, 2016

21st Century Project Management

21st century project management is fundamentally different from 20th century project management.  Yes, there are still start and end dates, activities and deliverables, and budgets and project teams.  But the management of those project attributes is different.  And if you don’t understand those differences, your projects will struggle in the 21st century business environment.

Project Management Has Been Around for Ages

Now to be clear, project management has been around for thousands of years.  The pyramids in Egypt, the Roman aqueducts, and the Great Wall of China all had project managers who planned and organized the work.  They may not have had the title “Project Manager,” but someone was in charge.  As far as we know, none of them held the PMP credential.  Since Henry Gantt did not introduce the Gantt Chart until the beginning of the 20th century, that was not available to them.  And we are certain that none of them used either Microsoft Project or Primavera.  Nevertheless, the projects were successful. 

So if projects were successful thousands of years ago despite not having project managers with a PMP, Gantt Charts, or project management software, we can conclude that project management is more than just tools and certification.   There are components of the business and project environment that must also be considered.  So if the business environment of the 21st century is markedly different from the 20th century, it follows that project management must also adapt to the new reality.

Let’s start with a definition of project management.   I will cite the one used by the Project Management Institute, “Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”  This definition illustrates the point that was just made.  Project management relies on knowledge, skills, tools and techniques.  If these change in the business environment, the project management practices should also change.

Early 20th Century

Let’s consider some of the ways that the 21st century business environment is different from the 20th century business environment.  At the beginning of the 20th century, Fredrick Winslow Taylor and scientific management was all the rage.  This meant that activities were planned in detail and standardized.  Everything was planned and tracked.  Performance targets were set and measurements were seen as the key to good management.

This was a perfect environment for the introduction of the Gantt Chart and Work Breakdown Structure (WBS) to plan and control project activities.  Organizations were hierarchical and functions operated in separate “silos” that were managed for functional excellence.  Techniques like Critical Path were introduced to analyze and optimize project schedules.   Other techniques like Earned Value Management came along and provided strict accountability for cost and schedule on every aspect of the project.  Project management was now part of scientific management and all managers were expected to be able to use these techniques

Late 20th Century

In the latter part of the 20th century business was transformed by computers and revolutionary changes in communication and transportation technology.  These advances in science led to changes in how business systems operated.   Computers dramatically improved the performance of almost all products, processes and systems.  Communication and transportation changes resulted in almost all industries becoming global and operating 24/7.  With respect to projects, the speed of change and the decentralization of project teams compounded the effects of project complexity and urgency.  To address these issues, companies turned to project management certification and new project management tools and techniques that managed complexity. 

At the end of the 20th century, project management had reached a new level of professionalism.  It was now a recognized management discipline and career field.  Project managers had to manage complexity in a fast changing environment.  They were often required to operate both strategically and tactically.  Sophisticated project management software applications were used on large and small projects. 

In addition, an entire industry had sprung up around project management.  Many project management consultancies, training programs, books, journals, magazines, and certification programs abounded.  Researchers were analyzing projects to identify best practices and project management gurus were out on speaking tours.  Not to mention the numerous project management software applications which were on the market.  Project management was no longer an additional duty of operational managers; it was now a stand-alone management discipline.  

21st Century

We are now well into the 21st century and we can see further business transformation.  Big data and the internet of things is transforming business again.  In the 20th century it was impossible for a manager of a global business operation, or even a global project, to have all information about all activities instantly available.  Therefore, management disciplines focused on how to discern business performance and issues from summary information or how to infer it from a narrow slice of actual real-time data.  But that is all changing.

Companies can now get real-time data about all business processes, including what is happening at customers or suppliers, and make that information immediately available to managers.  Computers can be constantly sifting the data looking for special conditions or patterns that the managers specify.  And decision and actions can be implemented faster than most people can keep up with.  The role of the manager is changing.  The manager must now spend their time engaging with customers, suppliers, and employees to ensure alignment of activities and interests.  The arts of negotiation, motivation, conflict resolution and empowerment are the hallmarks of good management, not directing, controlling, and analyzing.

This is especially true for project managers.  The project management tools and systems can now do all of the analytical side of project management.  However, the diverse and decentralized project teams need a project manager who is focused on the team alignment and integration.  The project manager must build a relationship with team members to ensure they are appropriately engaged.

For those of us who started project management using the methods of the early 20th century (which in many cases were still the standard until the 1980’s) and have gone through the transition to the methods of the late 20th century, the thought of another transformation is daunting.  But that is the reality of our today’s business environment.  Will we still have certifications and project management software applications – of course.  But those will just be tools in the tool box, not a measure of project management acumen.  Project managers will be totally connected with technology  – but the technology will not be what is managed, rather the technology will be the enabler for the project manager to work with stakeholders and team members.  The more technically advanced we become, the more important the inter-personal relationships become.

So the new 21st century project manager is first and foremost a “people person.”  They are great communicators and motivators.  Yes, they are technically savvy with respect to the use of project management software and communication technology.  But these are just tools, the discipline of project management is not resource alignment and empowered engagement across functional and organizational lines.    

Monday, March 7, 2016

Proactive & Reactive Risk Management

I was recently working with a company who didn’t understand the difference between proactive and reactive risk management on product development projects.  Oh sure, they could explain the concept in a meeting, but their business practices told a different story. 

First, let’s acknowledge that we need both.  Proactive risk management can avoid and minimize risks.  But sometimes the unexpected happens and we need to respond to it when it does.   A strong risk management approach will periodically assess the project to identify risks and proactively take actions to avoid and mitigate negative risks while enhancing and leveraging positive risks.  And at the same time, the risk management approach will be constantly assessing progress and variances – both technical and project progress – to determine when unexpected conditions have occurred.  An analysis of those conditions will lead to appropriate corrective actions or responses.

Risk Events

Let’s look at the attributes of proactive and reactive risk management, at least as they apply to technology or product development project.  Risk is defined by the Project Management Institute as, “An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.”  There are three aspects I want to highlight.  First it is an uncertain event.  Second it can be both positive and negative.  And third, it effects on or more project objectives. 

Proactive risk management focuses on identifying the uncertain events and estimating the effects of the objectives.  Reactive risk management starts with the unexpected effects and attempts to determine the events that caused those effects.  In both cases, actions are taken to protect the project goals.  However, in proactive risk management, an action is taken to avoid or prevent a negative effect or to enable or enhance a positive effect.  In contrast, with reactive risk management an action is taken to recover or compensate for the already existing unexpected negative effect on the goal or an action is taken to lock in the benefits from an already existing unexpected positive effect on the goal.

Effective risk management needs to include both proactive and reactive elements. It is obvious that if you don’t do either, disaster is likely to strike your project.  But even if you do one, but not the other, disaster is still likely to strike.  Let me illustrate using the experiences of the company I mentioned earlier.    

Proactive without Reactive Risk Management

This company did proactive risk management for project risk events.  They conducted a risk analysis shortly after the project started where they considered a variety of project risk events that could affect the project.  These included schedule issues, resource issues, and some technical issues.  The risk analysis was captured in a risk register, proactive risk responses were identified and most were implemented.  And that was the last time that project risk was discussed on the project until the accumulating disasters caused the project to be cancelled two years later.

Proactive risk management was done and the actions taken were good ones.  But the company and project team did not regularly assess project performance with respect to cost and schedule goals.  They just kept changing the schedule and throwing resources at problems.   There were ample signs that other unexpected events had occurred and that the project plan and project approach was not working.  However, the project team did not stop to assess what was going on and analyse the project to determine the root cause or causes of the risk events.  Therefore they never took appropriate corrective actions.  Finally two years into the project, they were approximately 18 months behind to the original schedule and the spending was nearly double the original budget. 

Reactive without Proactive Risk Management

While the company did proactive risk management with respect to project goals, they did not do any proactive risk management with respect to technical goals.  This was a development project using emerging technology and it was pushing that technology to an order of magnitude improvement in several of the key technical performance characteristics.  In addition, the product was evolving from a complex mechanical product to a system involving complex mechanical elements, electronics, software, and systems integration with other customer systems.  The project team did not do any proactive technical risk assessment.  In fact technical risk was never discussed in their project reviews – just technical problems. 

The technical problems were addressed using a reasonable and effective reactive risk management approach.  As a problem was identified, a root cause analysis was performed and a solution was created to solve that problem.  But since no proactive risk management was done, the solutions often then created even more technical problems.  And when a technical problem was finally solved, it would just unmask the next technical problem.  The project went through a continuous set of technical problems and issues, with the result that despite dozens of systems being constructed, none of them was ever fully compliant with the specifications.  Finally, after two years of work, the design team reported to management that the current design approach was not robust enough to ever meet the customer’s use requirements.   If the company wanted a product that would be satisfactory to the customer, they would need to restart the development project with an entirely new concept.

Combining Proactive and Reactive Risk Management

If the company had effectively combined both proactive and reactive risk management approaches around either the project or technical goals, the situation would have been recognized much sooner and the project could have been salvaged.  The proactive project risk management made some good project enhancements.  If it had continued to monitor for risk, it would have identified that something wasn’t right with the technical approach and corrective actions could have been taken.  The reactive technical risk management continually fixed one problem after another, but a proactive analysis would have identified that the fundamental concept was too risky and a different approach would have been used.

The lesson for project managers is to do proactive risk management early in the project.  And then monitor performance, identify variances and do effective root cause analysis as the project progresses.  These complementary approaches should lead to project success.