7 Tips for Working from Home

Thanks to the Corona Virus, many people are suddenly forced to work from home.  Here are some tips to make that transition smoother.

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.

Superman

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.   

21st Century Project Management

21^st century project management is fundamentally different from 20^th 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 21^st 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 20^th 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 21^st century is markedly different from the 20^th 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 20^th Century

Let’s consider some of the ways that the 21^st century business environment is different from the 20^th century business environment.  At the beginning of the 20^th 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 20^th Century

In the latter part of the 20^th 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 20^th 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.  

21^st Century

We are now well into the 21^st century and we can see further business transformation.  Big data and the internet of things is transforming business again.  In the 20^th 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 20^th 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 20^th 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 21^st 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 now resource alignment and empowered engagement across functional and organizational lines.    

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.    

Project Management Made Easy

People who are expert in an area love to discuss the intricacies and novel aspects of that area.  Project managers are no different.  But what that means is that many project management articles, books and posts are irrelevant to 99% of the people who are involved in projects.  Some people (like me) may enjoy debating when to use the SPI in calculating a forecast with Earned Value Management.  But sadly, I have discovered that is not a universal topic of conversation. 

Project management software has not made this any easier.  Many of the project management software applications tout how intuitive and simple they are.  But the reality is that they have automated some of the more difficult and obscure aspects of project management.  In order to really use the software, you already need to be adept at project management.  So for most people, the software either becomes a glorified chart-making tool or it is used as barriers to keep the “unwashed masses” out of the intricate mysteries of professional project management.

But in a nutshell, project management is just organizing who does what and when they do it so as to achieve a goal or objective.  When the work is very difficult, or there are many people, or there are some tight constraints around the objective; then the project management disciplines can help to identify and overcome unique issues.  But it still comes down to “who,” “what,” and “when” to  achieve the goal.

That is why I find that most of the time when I am working with an organization that is trying to embrace project management; I need to focus on how to keep things simple.  What I have found is that there are two very simple approaches to organizing the “who,” “what” and “when” that everyone can understand and work with.

Post-It Note Project Management

The first is to use “Post-it” notes and a storyboard.  In this case, every activity is listed on its own “Post-it” note.  I then add the name or names of who will do the activity and the start or end date.  

The “Post-It” notes are organized on the storyboard in whatever way makes the most sense to the team.  I have organized them in columns where each column represents a week or each column represents an individual on the team.  I have also organized them by grouping the tasks for a deliverable around each other in more of a mind-mapping approach. 

The great things about this approach are that it is quick, easy to understand, visual, and easy to maintain the status.  The way I manage status is that whenever a project activity is complete, I move the “Post-It” note to the lower right hand corner of the storyboard.  So it is easy to track what work is left to be done.  If another required activity is discovered, just add the “Post-it” note.  Updates and changes are easy to track.  

There are several limitations with this approach.  First, you need a co-located team so that everyone can see and track the storyboard.  Also, I have found that if there are too many activities it is difficult to fit them all on the storyboard and track progress.  My rule of thumb is that this approach is limited to 100 activities or less.  Finally, if there are many linkages between activities throughout the project, this approach does not capture that well and another tool or analysis is needed to track those linkages.  With that said, most of the organizations that have small ad hoc teams for conducting part-time projects can use this approach.

Spreadsheet Project Management

The next approach is to use a spreadsheet for planning and tracking the project activities.  Now I am not talking about using the advanced math functions of the spreadsheet, rather I am using it as a poor man’s database.  The reason I like to use a spreadsheet is because all most all mobile devices, laptops, tablets, and phones have a spreadsheet application.  If I put the project plan and status in a simple spreadsheet, I can share it with a distributed team and update it any time and from anywhere.

I set up my spreadsheet so that each row is a project task or activity and each column represents information about that task or activity.  So one column is the task, another column is the task completion criteria – or “definition of done” – for that task.  I also have a column for who is doing the work, the start date, end date, notes or comments, and current status.  Another thing I like to do with the spreadsheet is change the color of the row based upon status.  That way activities that are done are late or in work can pop out when your check the spreadsheet.

There are several advantages of this approach.   It can be easily shared with team members that are not co-located.  You can easily add hundreds of tasks (I have used it on projects with over 400 tasks and activities).  It is easy to sort the activities by date, by status or by who is doing the work.  And as I mentioned it is portable.  

There are several disadvantages.  One is that you can only see a few rows at a time on your screen.  Another is one that was mentioned with the Post-it notes; that is that it is difficult to track linkages between the tasks and activities.   When you have the complex linkages you should switch to a powerful project management software application.  And you probably need a professional project manager then because of the complexity and risk.

So keep it simple.  Use Post-it notes or spreadsheets where possible.    If you want to know more about using either of these approaches, check out my online course on the topic.   

Powerball Project Management

As I watch the frenzy growing over the Powerball lottery jackpot, I am reminded of the history of a failed innovation project that I have been analyzing for a company.  The project team kept trying one long shot idea after another, hoping that an idea might pay off.  As the project became further behind schedule, more and more resources were added chasing wilder and wilder ideas. 

This sounds a lot like what is happening in the Powerball lottery.  As the payout keeps growing (it is now estimated to be $1.3 billion dollars), I see more and more people spending money they can ill afford to spend on lottery tickets.  They then cross their fingers and hope they win; just like this project team kept hoping that one of the ideas they tried might work.

Risk and Reward

Ask any financial adviser and they will demonstrate that an individual will be far better off financially if they took the average amount of money the typical Americans spends each year on lottery tickets and invested that in a sound investment.  Yes, someone does eventually win the lottery and they receive a huge payout, but the vast majority of people who buy tickets are losers and the money is wasted.

Even many of the people now buying a lottery ticket will tell you that it is a stupid waste of money.  But they are doing it anyway because the payout has become so big.  The risk is the same – you are virtually guaranteed to lose your money.  But the reward has grown to the point where people are now willing to take the risk. 

The reason the reward has grown is because there have been no recent winners.  The longer the Powerball lottery goes without a winner, the larger the payout.  It was somewhat similar on the innovation project.  None of the earlier ideas had been feasible.  An idea that gave adequate product performance was too big, or not serviceable.  An idea that was the right size, couldn’t meet the specifications.  It was like having some of the winning numbers on the lottery ticket but not all of them.  The longer the project went without a viable solution, the more management focused on the project.  Whoever came up with the idea that would work would be big hero in the company and be well compensated for their idea.

So ideas kept coming.  In fact, the project team was growing.  People were working overtime.  There was a frenzy of activity – most of it wasted effort.  The project manager had no control over what was happening.  Configuration control of product designs was lost.  Testing was analysis was ad hoc and unfocused.  Different sub-teams responsible for different components were using incompatible approaches for subsystems that had to integrate with each other.  The project manager could no longer even report on project status because he had no idea what many of the people were doing.

Discipline of Project Management

The company had lost sight of the discipline of project management.  Just like disciplined investment of money will yield steady predictable growth in the value of a portfolio, disciplined project management will yield steady progress on a project.  Starting with a plan and doing regular risk reassessment and pulsing of the project will identify the problems and issues.  A disciplined problem solving approach will lead to an understanding of the nature of the problems and point to a solution strategy.  Planning the solution and implementing the solution plan keeps the project on track and moving to a successful conclusion.

Granted this isn’t the adrenaline rush of a “Eureka” moment when using disciplined project management on an innovation project.  Nor does it lead to the discovery of “heroes” in the business that suddenly emerge by creating the next mega-million jackpot product line.  But it will prevent the business from wasting tons of money on worthless ideas. It does provide a predictable approach to innovation and it keeps the project manager and senior management informed and involved.

Incidentally, which project disciplined project management approach you use is not critical.  What is most important is that you pick one and use it on your project.  Just like there are many financial strategies, there are many innovation project management methodologies.  You might prefer stage-gate over Agile.  You may be a fan of the PMBOK Guide®, or you may be an advocate of PRINCE2.  You may be able to use an industry specific methodology like APQP or IPPD.  You may prefer the rigor of Design for Six Sigma or the framework of the SDLC.  Pick the one that best fits you industry and culture – then actually use it. 

Disciplined project management does not mean nonsensical bureaucracy.  It does mean that you have a plan which is followed and updated periodically.  It does mean that you do regular risk assessment and variance analysis in order to make tweak the plan.  It does mean that you have regular status updates within the team and stakeholders to maintain alignment and integration.  These same principles apply to wise financial investing.

Powerball project management is a recipe for disaster.  Chasing ideas with no project plan, throwing resources at problems with no structured problem solving approach, and getting caught up in the frenzy of the moment won’t bring you success.  Keep in mind, the odds of winning the Powerball jackpot is 1 in 292 million.  The odds of Powerball project management leading to a successful innovation are about the same.      

The Logical Flaw with Project Management

One of the reasons that companies struggle with project management is that the approach they use has some basic logical flaws.  A company thinks it has some good project managers, and is disappointed when the results are poor. So the entire discipline of project management gets a bad name in that company.  But the problem was not with using project management. The problem was that the logic behind their project management approach was flawed.

This is the logic often used in appointing project managers:

Major Premise: The best project managers create project plans.

Minor Premise: Bob created a project plan.

Conclusion: Therefore, Bob is one of the best project managers.

But then Bob’s project becomes a train wreck and Bob and the project team are clueless as to why that happened or what should be done.  The problem was in the approach to project management. Let’s go back to the major premise that was used.

The best project managers create project plans. There are several flaws in this logic.  First, although it is true that the “best project managers” create project plans, there is no statement about what the “worst project managers” do.  In fact, many of the worst project managers also create project plans.  And some of those project plans use all of the latest forms, templates, software and are full of excruciating detail.   

Second, the “best project managers” do much more than just create project plans.  They execute their project plans.  They regularly do status checks and risk reviews.  They manage the stakeholder interactions and project teams wisely and well.  It is an ongoing continuous set of interactions that are not part of planning – but are necessary for success.

Project Plans

Project plans come in all levels of accuracy and completeness.  Project plans that are based upon incorrect assumptions about resource availability, technical capability, or stakeholder interactions are doomed from the start.  I have seen many books and courses on how to do project planning.  They often gloss over some of these points and instead focus on things like the format of the WBS or critical path calculations.  If the underlying assumptions about the project conditions are wrong, everything else in the plan is just a fantasy.

Project management gurus often talk about the need for upfront planning in a project.  The focus of that effort should not be just the technical planning activities; it should be identifying and testing the assumptions and constraints.  There are assumptions about business conditions and assumptions about project objectives.   There are constraints on resources and constraints on project options.  If any of these are missed, it can destroy the validity of the best formatted and calculated project plan.

Unfortunately, there isn’t a simple (or even complex) equation that can be applied to identify and test the assumptions and constraints.  Rather, the project manager must meet with the stakeholders and ask probing questions about goals and risks.  They need to determine how much support the stakeholders will really provide to the project – it is just cheering on from the side lines, or will they dedicate time and money.  The project manager needs to determine realistic resource capability and capacity, regardless of what is promised.  These activities require cross-functional and multi-level communication skills.  It is one of the hardest things to teach technical professionals.  One of the most challenging aspects of this activity is that you don’t know if you did it well until the project is over – which may be months or years later.   

Project Execution

A project plan is a necessary condition, but not a sufficient condition for excellent project management.  The plan must still be executed – or at least a variation on the plan must be executed.  Inevitably, something unexpected happens.  The project manager must be regularly pulsing the project to recognize the change and make the appropriate adjustment.  A project manager who blindly follows a project plan, even after a risk or issue has invalidated elements of the plan, can lead the project into disaster.

In addition to regular updates and adjustments to the plan, the project manager must interact with stakeholders and team members to ensure appropriate decisions and actions.  In many cases the project team members are matrixed onto the project team.  They still have other responsibilities, often simultaneously working on multiple projects.  The project manager must keep them engaged and focused.  This usually requires strong interpersonal skills and negotiating skills. 

The stakeholders who are involved in project decisions can delay and derail a project if they are not engaged regularly and kept informed of the project status and project risks.  Stakeholders often change during a project.  The project manager must bring the new stakeholders up to speed.  The stakeholders often are looking at the “big picture” in the business and the project manager is often focused on “immediate details.”  If the project manager is not careful, the project communication will actually confuse and irritate the stakeholders.  A good project manager is able to switch between the perspectives and effectively communicate and manage both “big picture” and “immediate details.”

The Real Logic of Project Management

So let’s review.  An organization that only focuses project managers on creating complete and intricate project plans will likely be disappointed in the actual project performance.  A good project plan is needed, but the most important aspect of planning is to understand and account for the assumptions and constraints – not just filling out forms and spreadsheets.  Then once the plan is in place, the project manager must stay flexible to modify the plan when appropriate.   And the plan is not enough; the project manager must engage the stakeholders and team members to keep things running smoothly and achieve project success.

This leads us to a new logical statement:

Major Premise 1: The best project managers create project plans based upon realistic project assumptions and constraints.

Major Premise 2: The best project managers adapt their plans throughout the project to reflect changing conditions.

Major Premise 3:  The best project managers interact with stakeholders and team members regularly to ensure alignment and appropriate actions and decisions.

Minor Premise: Jill creates project plans that are based upon realistic assumptions and constraints; she modifies them to reflect changing conditions; and she regularly interacts with stakeholders and team members to ensure alignment and appropriate actions and decisions.

Conclusion:   Jill is one of the best project managers.

The Problem with RACI

While the Project Management Body of Knowledge (PMBOK Guide®) may refer to it as a Responsibility Accountability Matrix, everyone I know calls it a RACI Matrix. It is supposed to clarify roles and responsibilities, yet it often creates more confusion that it clarifies.  So let’s look at this tool, the benefits and the pitfalls that create the problems.

Assigning responsibility for work is an age-old principle.  Even in early civilization, some people were designated to have certain responsibilities. The ancient kings had cupbearer, chariot drivers, shield-bearers, and ministers of all types.  These individuals had specific responsibilities and if they didn’t perform the punishment was often sharp and swift.  In more modern times, thanks to Fredrick Winslow Taylor and scientific management theory, everyone in business has a designated role or position and they are expected to become expert at the responsibilities associated with that role.

But projects are a little different.  They don’t always lend themselves to scientific management principles. Projects are temporary endeavours undertaken to create a unique result.  Individuals on the project team are temporarily assigned to work on project activities, and some of those activities may not be well defined.  Because of the unique nature of projects, a pattern may not already exist.  Roles, responsibilities, authority, and accountability need to be assigned to prevent duplication or work or missing work.  Which brings us to the RACI matrix.

RACI Matrix

The RACI matrix is the most common tool for assigning roles and responsibility to project team members.  The matrix is structured by placing the project tasks on one side of the matrix, normally the vertical axis; and the project team members on the other side of the matrix, normally the horizontal axis.  The role of each individual with respect to each task is then noted in the matrix as either R – Responsible, A – Accountable, C – Consulted, I –Informed, or left blank if the individual has no role.

The RACI matrix assigns a role to each individual, but it does not clarify what they are supposed to do.  And that is what leads to the confusion.  Who plans the task – the “Accountable” person or the “Responsible” person?  I have seen it explained both ways.  Does the “Consulted” person only participate when asked, or are they expected to engage and ensure their perspective is included?  Again I have heard it described both ways.  And then there is the question, “How can someone be accountable but not responsible, or responsible but not accountable?” 

Questions like these and others have led to a plethora of variations on the RACI matrix.  The fact that there are so many variations is an indication that there is a major flaw with the RACI approach.  If it was working well, people wouldn’t be trying so hard to improve it.   Let me list a few of the alternate approaches.

Alternate Responsibility Matrix Approaches

• ARCI – rearranging the letters because Accountable is more important than Responsible.
• RASI – Responsible, Accountable, Support, and Informed attempts to better define the original Consult role by now calling it Support.
• RACIQ – Responsible, Accountable, Consulted, Informed, Quality reviewer – this adds a role for review and approval.
• RACIO – Responsible, Accountable, Consulted, Informed, Omitted – this approach is meant to ensure that some individuals do not engage on a task and tamper with what is happening.
• RATSI – Responsibility, Authority, Task, Support, Informed – a slightly different segmentation of roles meant to clarify the differences as compared to the original RACI.
• RAPID – Recommend, Agree, Perform, Input, Decide – a variation that focuses on decision making authority rather than on the actual task activity.
• PACSI – Perform, Accountable, Control, Support and Informed – a variation that identifies some activities that must be done in addition to roles.
• DACI – Drivers, Approvers, Contributors, Informed – a variation that focuses on the type of activity that the person does rather than their role.
• CLAM – Contributes, Leads, Approves, Monitors – another variation that focuses on the type of activity rather than roles.

There are probably more, these are just the ones that I am aware of. 

The Problem

So what is the fundamental problem with RACI?  I believe it is that while defining roles, it does not clarify actions.  But clear actions are what a project needs.  As a retrospective tool to look back on a situation, RACI is effective.  It can determine who was responsible for success or failure?  Who was accountable for ensuring the task was completed?  Who was consulted along the way and how effective was their input?  And who was or was not informed and what impact did that have on the project?  Great questions when doing a post-mortem on a project; but not very helpful for proactive project management.

 When planning and executing a project, the project team members need to know who is doing what.  A matrix focused on actions associated with each task is much more beneficial to the team.  Who is planning the work?  Who will be helping on the task?  Who are the stakeholders that have to approve or sign off on the results of the task?  With these answers, the project leader and project team can manage their resources, coordinate the schedule, and ensure that risk mitigation plans are being executed in a proactive manner.  They don’t have to wait for success or failure and they try to understand what happened.

Recommendation: DACI or CLAM

For that reason, I recommend the use of either the DACI or CLAM approach.  These are activity-based matrices.  I have found that the level of confusion concerning who is doing what is significantly reduced when these are used in project planning and execution.  

VUCA Product Development

In most companies, developing new products is a critical component of strategy.  Many companies are finding this to be more and more difficult as their environment increases in VUCA.  The acronym VUCA stands for Volatility, Uncertainty, Complexity, and Ambiguity.  This acronym was created and gained recognition in the strategic planning circles of the US military during the past 15 years.  A body of knowledge is being developed around leadership in the VUCA world, with numerous articles and books published in the past few years.

Bob Johansen has proposed a leadership response to the VUCA environment which he titles VUCA Prime.  According to Johansen, volatility is countered by vision, uncertainty is countered by understanding, complexity is countered by clarity, and ambiguity is countered by agility. Let’s take a look at each of the elements of VUCA and VUCA Prime as they apply to product development.

Volatility

Volatile is defined as changeable – and often with an explosive or fleeting connotation.  Volatile situations are full of surprises.  Vision is the recommended leadership response.  Developing and articulating a clear vision will assist an organization through the volatility be reducing the disorientation that occurs when a volatile situation unfolds.  Even though there is rapid changes happening all around, the vision and direction stay constant; providing a basis for decision-making and action.

Product development involving innovative new technology, or a marketplace that is fast developing with new customers and competitors, can often be volatile.  The vision that is needed for the product development team is a clear product line strategy.  The strategy that has identified target markets and the characteristics of new products will guide the product development team through the technology, design, and business trade-offs that must be made when volatility strikes.  Without a clear product line strategy, the product development team often stalls as they start chasing options and waiting for decisions from stakeholders.

Uncertainty

Uncertain is defined as the state of being unpredictable and indeterminate.  There are numerous significant unknowns in the business situation.  The environment is novel to the point that past experience cannot be used as the measure for what should be done now.   However, in an uncertain environment, there are facts that could be discovered.   The recommended response to uncertainty is understanding.  This requires investigation, fact-finding, and analysis.  Rather than responding in a dogmatic manner using outdated principles, the response is to slow down and learn what is actually happening. 

Within the product development environment for innovative new products; there is normally uncertainty with respect to customer needs, product performance, and market response.  There are two approaches being used to create understanding within product development methodologies.  One approach is to do extensive upfront analysis using tools such as the Quality Function Deployment.  The other approach is to create a series of rapid prototypes of a minimally viable product to get “real-world” experience and feedback.  I have used both approaches and there are pros and cons for each.  The key takeaway for this discussion is that there is work that must be done to gain understanding.  And that work needs to be built into the development project plan.

Complexity

Complex is defined as intricate, often complicated, interconnected parts, processes, or organizations.  With complexity comes options and opportunities.  Some of these options and opportunities are very favourable and some are disastrous.  Navigating through the complexity requires numerous decisions.  The recommended response to complexity is clarity.  Clarity exposes the decision points and the options.  Clarity will also often provide a framework for understanding the implications of decisions.  Clarity exposes pathways through the complexity.

Product development of new innovative products will often involve complexity on several levels.  If the product is a system, there will be multiple components, possibly hardware and software, that must all work together.  And research shows that system integration and test is one of the most likely areas of a product development project to overrun both time and money.  In addition, there is often organizational complexity.  Marketing is developing requirements, engineering is creating designs, quality is establishing test and inspection methodologies, operations is setting up manufacturing and logistics processes and facilities, IT is bringing new databases online and possibly new systems for support.  All of these functions must work together and a change in one cascades through all the rest.  Establishing a stage-gate product development methodology with defined practices and decisions points will go a long way to creating clarity in product development.

Ambiguity

Ambiguous is defined as obscure, indistinct, and with numerous possible interpretations.  Unlike our definition for uncertain where facts are available but are not yet known; in an ambiguous environment there is normally no “right” or “wrong” answer.  Instead the answer is always, “it depends.”  The recommended response to ambiguity is agility.  This means that as the fluid situation continues to change, the decisions are revised and updated frequently.   Nothing is ever final; it is just the “current state,” with the expectation that change will soon be required.

In the global marketplace, industries are separating into those that are ambiguous and those that are rigid.  The highly regulated industries have a tendency to be very rigid and those that are not regulated are often ambiguous.  But regardless of the industry, the product development environment is ambiguous.  It follows that an ambiguous end market will create an ambiguous product development process.  As the target for product definition and performance is constantly changing, whatever product is developed will immediately need an upgrade or replacement product.   But even in rigid end markets, development is ambiguous.  The regulatory environment is often different in different countries or areas, and these regulations are frequently changing.  In addition, the regulatory agencies interpretations of regulations are often inconsistent.   Regardless of the industry, a rapid pulsing process is needed to determine the current state of the market and industry environment.  This must be coupled with a robust change management process for product development.   Finally, the product development metrics must be focused on business success or failure of the product, not on time and budget targets for the project.

If you are involved in product development today, you are probably experiencing VUCA.  You may reminisce about the “good old days” when things were calm and simple.  But don’t expect those days to return.  Instead embrace an approach to have vision, understanding, clarity and agility.

Learning Lessons from Lessons Learned

They go by many names including: Lessons Learned Sessions, After Action Reviews, Post-mortems, Post Project Evaluation, Learn and Grow, and Project Retrospective.  These sessions are the time when the project leader and project team look back over the project, or at least a portion of it, and attempt to learn from their experiences.  It is a practice that is called for in many project management methodologies, yet often neglected.  

When I ask people why they haven’t done one, I get many different reasons.  “Everyone is busy on other projects now.” ‘Why bother, we won’t change anything.” “Most of the team at the end of the project is different from the beginning team.  They didn’t participate in many of the decisions.”   In fact, often these are backwards looking, blame-focused sessions.  When that occurs, it is an indicator that the organization and project teams don’t understand how to use these sessions.

I would like to discuss five elements of effective reviews.  These are the purpose, the timing, the participants, the questions asked, and the follow-up.

Purpose

The purpose of these sessions is continuous improvement.  These are not meant to be final project reports or a history of what happened.  They are intended to improve the planning and execution of the current and future projects.  One of the implications of this purpose is that anything can be discussed.  There are no “sacred cows.”  Don’t avoid subjects because it many hurt someone’s feelings or it makes them uncomfortable.  The goal is to improve performance.  If we ignore some aspect of performance, it will not improve. 

Timing

A mistake often made when doing project reviews is that the review occurs long after the project is over and the review then considers the entire project.  A much better approach is to do a quick review after each phase or milestone with the project team so that they can immediately take action to improve the remainder of the project.  This type of review doesn’t need to be an all-day offsite meeting with formal facilitators and reports.  It can be a pizza lunch with post-it notes on a white board.

Let’s consider for a moment one of the best models of how to conduct one of these sessions, and that is the US Army’s After Action Review format.  First, note that it is not an “After War Review” with Monday morning quarterbacks looking back over years of history and trying to find the big lessons of the war.  It is a review that is immediately conducted following an action or event.  Everyone from the team is still there.  The events are fresh in everyone’s mind, and because it is focused on what the team just did; many of the recommendations are immediately actionable by the team.

Participants

This gets us to the participants in the review.  I recommend that it is the team, the whole team, and nothing but the team.  Well, you may want to have someone from the PMO or another project leader to help take notes and facilitate.  This is especially true if there were some leadership problems and the team might be uncomfortable discussing this in a meeting being run by the project leader.  There is no need for senior management in this meeting.  Their presence is likely to repress the conversation.  It is appropriate for the project leader to provide a summary of the results to senior management and the PMO.  But the discussion is likely to be much more open and honest if the meeting is just the team members.

Questions

The agenda for the meeting is very simple.  What is going right and what is going wrong.  The team may want to vent a little if there are problems or celebrate if things are going well.  Let them release a little emotion, but then focus them on these questions:

• What is going well that we want to continue?
• What is not going well that we need to change?
• What should we do differently as part of the change?
• What recommendations do you want to make to the organization to pass onto other teams?

Follow-up

Well, as you can see from the questions, we anticipate that we will want to make changes.  It is possible that the team may say that everything is going great and nothing should change.  When that is the case, the team should be making a recommendation to the organization so other teams can copy their result.  However, most of the time there will be some changes.  By conducting the review with the current project team, they can also decide what they will change – starting tomorrow.  I like to get very specific when I discuss the changes.  I go around the room and ask each person what they personally will be doing differently.  Doing this in the room among the team members will improve personal accountability among the team members.

Turning these reviews into forward looking change events instead of backward looking blame events will make them productive.  They really will drive continuous improvement.  

Project Kanban – Integrating Scope, Schedule, and Resources

One of the latest techniques in project management is to use a Kanban approach to project scheduling.  Those advocating for this scheduling tool highlight the characteristics of blending resource allocation with schedule and scope management.  Some even go so far as to say that it is more than a tool; it is a brand new methodology.  Let’s look at it in more detail.

This approach is often tied to Agile methodologies, but it has actually been around far longer.  I was using a modified Kanban project scheduling tool in the 1980’s.   The tool shows the relationship between scope schedule and resources.  Like the Gantt chart, it is very effective for managing the day-to-day status and tracking.  And also, like the Gantt chart, it is a tool that can be used with many different project management methodologies. 

This tool works best for those projects where many different deliverables go through similar steps or activities.  The Kanban schedule is set up as a matrix.  The vertical side of the matrix is the list of project deliverables.  The horizontal side is the steps or activities in the project.  Normally, at the top of the matrix, the level of resources available for each step is listed either in terms of the number of individuals or the number of deliverables that can be actively worked at one time.  See the diagram below.

Kanban Principles

Kanban scheduling relies on two important principles.  The first is that it is “pull” scheduling, not “push” scheduling.  This means that a deliverable does not move to the next step until there is a resource available to work on it.  As soon as the resource completes a deliverable, it pulls the next deliverable from the preceding step.  That way a step does not become glutted with many deliverables all hung up at a bottleneck.  

The second principle is that it is a “visual” scheduling tool.  The “pull” indicator is visual and the status of how many items being worked on at one time is also visual on the matrix.  In addition, I normally will change the cell color of the deliverable and the step to show what is being worked on and what is completed.   Visual control normally leads to improved project team communication because it is simple to understand.

Kanban Weaknesses

There are two weaknesses with using Kanban scheduling.  The first is that it is difficult to translate the schedule to a calendar.  The Kanban schedule is a matrix.  Often the matrix will have dates for each step of each deliverable, but it is difficult to take a table of dates and picture what is happening on a calendar.  That is why I normally will also use a calendar-based Milestone chart when using a Kanban schedule. 

The second weakness is that it is very difficult to track inter-relationships between deliverables.   If the deliverables are separable that is not a problem.  If there are numerous points of interaction between deliverables, the ability to pull can be confused.  In that case, the network diagram is a better scheduling tool because it shows those relationships and allows the project team to calculate a critical path.

Planning with Kanban

So let’s talk through how a project plan would be represented using a Kanban schedule.  First create the list of deliverables – this is usually derived from the scope statement or project contract.  Then determine the categories of activities that must be accomplished on each of the deliverables.  This is the same type of activity you would do when developing a work breakdown structure.  With these two pieces you can build the matrix.  Next, determine the resources capacity you have for each activity type.  Finally, estimate the amount of time required for each deliverable and estimate the dates when each activity will end for each deliverable.  Place that date in the appropriate cell of the matrix.  See the diagram below.

Managing Project Progress with Kanban

The Kanban tool is an excellent tool for managing day-to-day project activities.  Thanks to the visual control aspect, it is easy to see what is underway, what is complete, and what is coming up next.  Because I use cell colors to indicate activity status, the current project status is easy to see.  Also, problem deliverables or problem steps will quickly “jump out” from a review of the matrix. 

In the diagram below it, the present date is July 25.  It is easy to see that Deliverable #7 is behind schedule.  This is a major issue on the project and should be receiving the project manager’s focused attention.  In addition, the “Update/Debug” step is becoming a bottleneck.  There are five deliverables that could in process at that step, #3, #4, #6, #10, and #11.  However, the capacity is only to work on three, so deliverables #4 and #11 are not being worked on by anyone at this time.  So far it is not a major bottleneck, but deliverables #2, #8, #12, and #13 are in work in the previous activity and could be turned over to the update/debug queue soon.   

The Kanban schedule tool can be very useful for some types of projects.  It combines scope, schedule and resources into one easy to read visual display.  If this tool is not currently in your project management toolbox, you should consider adding it.

Channels, Navigational Beacons, and Project Management

When bringing a large ship up a river into a harbor, the captain and pilot must be careful that they don’t run aground.  There is a channel of deep water that they must follow.  By staying in the channel they avoid hazards such as rocks, reefs and sand bars.  There are often navigational beacons and buoys marking the channel to assist the captain and pilot.  If there are no navigational beacons, the captain must find a local experienced pilot, or proceed very slowly, taking soundings all along the way.  The local experienced pilot can still bring the ship safely into harbor because he or she knows the path of the channel and can tell where the safe path is by other landmarks.  The slow approach and soundings will tell the captain of dangers and allow the ship to maneuver to avoid them.

You are probably thinking, “What does this have to do with project management?”  Well, channels and navigational beacons are great metaphors for some important project management principles.

Every project is different, yet every project has some similarities.  Each project has a start and an end point.  There is an optimal path the project should follow for achieving the lowest cost or fastest time.  Depending upon the company and the project type, that path is unique.  Often when starting off on the project “voyage,” the water looks calm and smooth, but there are reefs, shoals, and shallow water that can cause the project to run aground.  The project manager, just like a captain or ship’s pilot, must navigate through the hazards and bring the project safely to its end point. 

To assist the project manager, many times an organization will create a project management methodology with templates, checklists, and reviews that are used to “chart” the path the project should follow.  The methodology defines a channel that has been determined to be the best path to navigate the risks and dangers of the project.  The reviews, checklists and templates are the navigational beacons and buoys that are used by the project managers to guide them through the channel.  The channel is still likely to have some sharp turns and dangerous eddies, but the templates, checklists, and reviews are there to guide the project manager through these dangers.

Without pushing the metaphor too far, we can see some of the problems and challenges that project managers and organizations face by considering some of the challenges associated with channels and navigational aids. 

• One problem is that the channel will often change over time.  Storms can shift sand bars and a channel can quickly be blocked.  In fact there may not be a navigable channel following a storm.  Within companies, re-organizations or new initiatives and systems can change how work is done. The original channel may no longer exist and a new channel must be found or dredged.


• Another problem is that the channel fills up with mud and sand over time so that it is no longer deep enough for the ships to come in.  When that occurs, the channel must be dredged to clean it out.  Within a company, a project management methodology often becomes cluttered over time.  A Lesson Learned on one project adds a new checklist or template.  The new checklist is added, but the old ineffective checklist is not removed.  A new management team wants to do project reviews in a different manner than before.  The new reviews are added, but the old reviews are not removed.  The organization needs to periodically review the “channel” in the project management methodology to ensure that it does not get cluttered up with unneeded or ineffective templates, checklists and reviews.


• A third problem is the use of the beacons.  Small boats can often scoot around the beacons and maneuver outside the channel because they have a very shallow draft.  As the captains of those boats are promoted to larger ships with deeper drafts, they can no longer safely navigate outside the channel.  Within companies, small projects can often be successful even though they did not use some of the templates, checklists and reviews because their scope or team is so small.  However, when these project managers are promoted to the large projects, that same behavior can lead to disaster.  The larger the project the more important it is to use the full project management methodology.  


• A fourth problem is that the captain and pilot must be able to see the navigational aids and understand what they mean.  This requires training.  In a river or harbor, the color, shape, and number of the navigational aid has a distinct meaning.  Within project management, checklists, templates and reviews also serve a distinct purpose.  Using the wrong checklist at the wrong time in a project can lead to bad decisions that create project disasters.  Project managers, project sponsors and key project team members need to learn the methodology.   Project management methodology training, tools and technique training, and periodic performance reviews are needed to ensure that project managers are effectively working with the project management methodology.

Whether your project is best represented by a super tanker, a catamaran yacht, or a two-person dingy, it is still important to know the channel and to understand the navigational beacons.  Using them appropriately will enable you to bring your project safely into the harbor.