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.