Category Archives: Agile Project Management

Which Process Model is Best to Use In Software Product Development?

I recently saw a question on an internet discussion forum that asked “Which Process Model is Best to Use In Software Product Development?”.

Which Process Model is Best to Use In Software Product Development?

I’ve seen that kind of question come up over-and-over so it seemed like a good time to write a blog post to address it.

What’s Wrong With That Question?

There are at least a couple of things inherently wrong with that question to begin with:

    1. It implies that there is one process model that will work “best” in any possible software product development project

      If we just figure out which one is best, we can simply use that model for any software product development project you might imagine.  Wouldn’t that be wonderful if it were true?

      Unfortunately, software product development is not quite that simple.  You have to fit the methodology to the nature of the project  – you can’t just force-fit all software products to some universal development process.   And, that requires some good judgement, knowledge, and skill to know how to pick an appropriate model and adapt it as needed to fit a given project.  It isn’t as simple as having one universal model that works for all projects with a “cookbook style” checklist of what you need to do to make it work.

    2. It also implies that there is some way to easily make a determination that one model is inherently better than another.

      How would you make that judgement?  What would make one model “better” than another?  How can you make that determination objectively?

      There are many different factors that you might consider to determine which model is best but it certainly isn’t an easy determination to make.  It’s also difficult to create a side-by-side comparison of two models on the same project to really compare the performance objectively.

      That hasn’t stopped people from making a judgement that “Agile is better than Waterfall”. I’ve even seen studies that say that “Agile projects are statistically 2X more likely to succeed, and 1/3 less likely to fail than waterfall projects”.

      Reference to Standish Group 2018 Survey

      How do you make that determination?  How was “success” defined?  Was “success” really  defined the same way in both projects?

Which Process Model is Best to Use In Software Product Development?

So, what’s the real answer? Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”.  They both have advantages and disadvantages depending on the environment you’re in:

  • An Agile model tends to work best in projects where:
    • There is a relatively high level of uncertainty where a flexible and adaptive approach is needed to resolve the uncertainty as the project is in progress
    • Creativity and innovation are needed to maximize the business value of the solution
  • A traditional plan-driven model (what many people loosely call “Waterfall”)  tends to work best where:
    • There is a relatively low level of uncertainty, the solution is well-defined, and some level of planning and control are needed to maximize predictability of costs and schedules
    • The organization is not really  well-prepared to implement an Agile approach and/or the project team is not trained in Agile

The two factors that are making Agile so attractive in today’s environment are:

  1. A higher level of uncertainty in the environment
  2. Competitive pressures require more creativity and innnovation

However, that does not mean that there is no need for a traditional plan-driven model at all.  It would also be a mistake to think that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think.

You have to fit the approach to the nature of the project and to the business environment.

Fit the approach to the project

There are many ways to create a hybrid model that blends Agile and traditional plan-driven project management principles and practices in the right proportions to fit a given situation.  And, sometimes it is necessary to do that to fit the model to the nature of the project rather than trying to force-fit a project to some arbitrary, predefined model.

What Are the Key Attributes of Post-Agile Development? What Problems of Traditional Agile Does It Try To Solve?

I recently responded to a post with the question: “What are the key attributes of post-agile development? What problems of traditional agile does it try to solve?”  I think people are looking for a new “silver bullet”

>What is Post-Agile Development?

What is Post-Agile Development?

I don’t really believe that there is such a thing as “post-Agile development”.  That implies that Agile will become obsolete and something really different will replace it.  However, I do believe that the use of Agile methodologies will continue to evolve and mature.

Trends in Agile Development and Agile Project Management

Some of the trends that are evident to me are:

    1. Traditional plan-driven project management is beginning to converge with Agile. Agile started out as a revolution against traditional plan-driven project management practices (what many people loosely call “Waterfall”) and that pendulum is starting to swing back to the middle.  People are beginning to recognize that there isn’t really a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think. Rather than force-fitting a project to one of those extremes, a better solution is to fit the methodology to the nature of the problem which may require a blend of both approaches in the right proportions to fit the situation.
    2. Learning how to blend those approaches together requires understanding a broader range of methodologies (both plan-driven and Agile) and understanding them at a deeper level.Many people today do Agile somewhat mechanically “by the book” without really understanding the principles behind it. That results in a somewhat rigid approach to how to apply Agile which is exactly the opposite of the adaptive approach that is intended for Agile.
    3. A very big trend is that many companies and people are attempting to scaleAgile to larger and more complex, enterprise-level projects and that will accelerate both of the above trends.Agile was originally designed around small, simple, single-team projects and it can be difficult to scale without thinking about how to blend it with typical enterprise-level management practices including project/program management, project/product portfolio management, and overall business management.
    4. In some cases, an attempt has been made to force a whole company to be agile in order to adopt an Agile development approach and that just isn’t completely realistic or desirable in some cases. Becoming Agile is not necessarily a goal in itself – it has to be applied in the context of the company’s most critical business objectives – what problem will it solve and how will it solve it?

The “Program Du Jour” Effect

I’ve seen this pattern before – I call it the “Program Du Jour” effect.  Everyone is looking for a silver bullet that will magically solve all of their problems.  When one thing doesn’t work, they toss it out and try something else.

I saw that with Six Sigma in the early 2000’s.  When Six Sigma was hot, everything that came before it was obsolete and no longer relevant.  And, some companies made a fairly superficial attempt to apply Six Sigma, decided it didn’t work, and tossed it out waiting for the next “silver bullet” to come along.  Here’s a quote from my original book on Agile Project Management on that subject:

“Agile methodologies have the potential to have an enormous impact; however, like many other new and hot methodologies:”

  • “Consultants tend to swarm all over them and sell it as a cure for almost anything that ails you, and
  • Many companies and managers want to jump on this bandwagon and that further builds the hysteria in the market.”

“The result of this can be:

  • “Jumping into agile looking for a ‘quick fix’ without fully realizing that it takes a significant commitment to make it successful; resulting in superficial implementations that are likely to fail
  • Attempting to implement agile methodologies in a business environment or organizational culture that is inconsistent with an agile approach
  • Attempting to use agile methodologies for projects that they are inappropriate for or failing to blend a sufficient level of agility with the level of control that is needed”

If Agile is done correctly, it is a very broad, flexible, and adaptive approach for solving a number of different problems; however, it is not a “silver bullet” – it won’t solve any problem you might have.  I hope we’re getting past the “silver bullet” phase and starting to put the right amount of thought into applying Agile intelligently and continuously improving and refining it.

Is Agile Just a Development Process? Are Project Managers in Denial?

Is Agile just a development process?  There seem to be a lot of project managers who are in “denial” about the influence of Agile on the project management profession.  They continue to think that there is only one way to do project management and that is the traditional plan-driven approach that hasn’t changed significantly since the 1950’s and 1960’s.

Is Agile Just a Development Process?

Is Agile Just a Development Process?

One rationalization I hear often is that some project managers will claim that Agile is not really a project management process it’s just a development process.  That’s fairly narrow thinking about what “project management” is that goes back to the days when the project management process could be separated from the development process.  In those days:

  • A project manager might have been somewhat of a high-level administrator who planned and managed projects and may or may not have had any direct role in managing the development effort needed to fulfill the project requirements.
  • He/she might have been a “middle-man” between the business customer and the development team.  He/she might have worked with the business customer to define and document the requirements and then worked with the development organization to negotiate resource commitments as well as the cost and schedule for completing the effort.

In many cases, the project manager might have had little or no direct role in managing the development team – that level of management might have been done through a functional development manager.  And, in some cases, the project manager simply held the development organization responsible for fulfilling the commitments that they had made and monitored their overall progress in fulfilling those commitments.

What’s Wrong With That Picture?

There are several limitations inherent in that style of project management.  The traditional plan-driven approach to project management  is optimized around achieving predictability by emphasizing planning and control.  For many years, a project was deemed to be successful if it met its cost and schedule goals for a given set of defined requirements.   That is how “success” has been defined for a long time.   In today’s world:

  • Levels of Uncertainty – There’s a much higher level of uncertainty in the world which makes a traditional plan-driven approach to project management very difficult to implement.  It’s just not very adaptive to uncertain and rapidly-changing requirements.  It typically forces you to make a lot of assumptions to try to resolve the uncertainty; and, many times, those assumptions will be wrong.
  • Creativity and Innovation – Competitive pressures create a significant need for creativity and innovation.  An overemphasis on planning and control is not very consistent with an environment that is needed for optimizing creativity and innovation.  Breaking down a lot of overhead and creating empowered, self-organizing teams that are in direct contact with the business users  creates an environment that is much better suited for creativity and innovation.
  • Need for Efficiency – Efficiency is also very important.  There is a lot of overhead in a traditional plan-driven approach to project management and there is not much emphasis on efficiency.  As long as the project was completed on time and under budget, no one typically looked very hard to see if there might have been a more efficient way of accomplishing that result.

Where Does that Leave the Project Manager?

All of that can be very threatening to many project managers because it might easily put them out of a job.  In fact, there is typically no role for a project manager at the team level in an Agile project.

I personally believe that there continues to be a role for project managers but it may be a very different kind of role and it requires rethinking what “project management” is and developing some new skills.  Project Managers who continue to insist that traditional plan-driven project management is the only way to do project management and who attempt to force-fit all projects to that approach will have a difficult time in the not-too-distant future.

I am sincerely interested in helping people in the project management profession better understand this challenge and to develop a strategy for reinvigorating their careers.  To that end, I have developed a very short training course that is called “What Is the Future of Agile Project Management?”  This course is eligible for one PDU and I am offering it to any project manager who wants to take it for a token amount of only $5:

What Is the Future of Agile Project Management?

This course should help you develop a new, broader, and more modern vision of what a project manager int he future might look like and help you answer the question: “Is Agile Just a Development Process?”.

New Course – What Is the Future of Agile Project Management?

I’ve just launched a new course entitled “What Is the Future of Agile Project Management?”  This is a very confusing topic for many project managers because the role of an Agile Project Manager in the real-world is not well-defined:

What Is the Future of Agile Project Management?

I frequently see questions from project managers asking like:

  • What certification should I get?
  • Should I become a Scrum Master?

It’s understandable that there is a lot of confusion about this because there is no defined role for a project manager in a typical Agile project at the team level.  There are roles that a project manager can play in an Agile but:

  • It may not be the typical, team-level project manager role,
  • It does require a big shift in thinking for a project manager to adapt to an agile environment, and
  • It’s a very different kind of “project management” that emphasizes creativity and innovation to maximize the value of the solution as well as some level of planning and control to achieve predictability

To fill this role, an Agile Project Manager has to learn how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation and that is exactly what my training curriculum  is designed to do.

This particular course is designed to help project managers understand the impact of Agile and Lean on the Project Management profession and on their own career paths and to develop a strategy to adapt to this new environment.   The course is a little over an hour long and includes material on the impact of Agile and Lean on the future of project management as well as some real-world scenarios where an Agile Project Manager can provide a lot of value in an Agile/Scrum environment.  It is designed to help project managers  understand how toreinvigorate their careers into a very high-impact Agile Project Management role.

I am offering this course for only $5 to anyone who would like to take the course.  You can click on the link below to take advantage of this offer:

What Is the Future of Agile Project Management?

Why Should Project Managers Care About Agile? What Is the Impact?

Why Should Project Managers Care About Agile? There are many people in the project management profession who are in “denial” about the influence of Agile. Here are some of the common reasons for a project manager might ignore the influence of Agile:

  • Many people seem to think that there is a binary and mutually-exclusive choice between an “Agile” approach and a “Waterfall” approach and “Agile” really only applies to software
  • Some project managers don’t see Agile as a legitimate form of project management although PMI has slowly come around to recognizing that with PMBOK v6

The truth is that Agile is changing the very nature of “project management” and, as a result, “project management is taking on a much broader meaning.

Why Should Project Managers Care About Agile?

A Modern View of What “Project Management” Is

The table below shows how the very nature of project management is changing as a result of Agile:

Views of “Project Management”
Traditional, Narrow View Modern, Broader View
Traditional “Project Management” is heavily associated with planning and control The competitive environment today requires an emphasis on creativity and innovation in addition to planning and control.

Simply planning and controlling a project is no longer sufficient. Can you imagine a leading-edge, high-technology product like a new iPhone being developed with a traditional, plan-driven project management approach?

Success in project management is defined by delivering well-defined project requirements within an approved budgeted cost and schedule Today’s world has a much higher level of uncertainty which makes it difficult to always start a project with well-defined requirements.

Business value is what is important and costs and schedules are only one component of business value. There have been many projects that met their cost and schedule goals but failed to deliver an appropriate level of business value.

Project management is only done by someone who has the title of “Project Manager” In an Agile environment, there is actually a lot of “project management” going on although you may not find anyone with the title of “Project Manager”.

The project management functions that might normally be performed by someone with the title of “Project Manager” have been distributed among all the members of the team and its a different kind of “project management” with an emphasis on producing business value in an uncertain environment.

Many project managers have difficulty accepting this kind of change because it fundamentally changes the definition of what “project management” is which can be very unsettling. They want to hold on to traditional notions of what “project management” is that haven’t changed significantly since “project management” was first formalized as a profession in the 1950’s and 1960’s, but project managers who ignore this change run the risk of being left behind.   In the not-too-distant future, project managers who only know how to do a traditional, plan-driven approach to project management may have a limited future in a number of industries and application areas such as software development.

Similarity to Quality Management

I worked in the Quality Management with Motorola in the early 1990’s and that profession went through a similar gut-wrenching change at that time. The old approach to quality management was heavily-based on inspection and control.

  • Lots of QC inspectors were employed to find defects in products before they shipped and
  • The role of a Quality Manager was to control the quality of products that were shipped and enforce quality standards.

Companies began to realize that approach was very inefficient and resulted in a lot of unnecessary scrap and rework of defective products. A much more proactive approach was needed that involved eliminating defects at the source by designing processes that were inherently reliable.

Implementing that kind of change required a very different approach to quality management…instead of an emphasis on control and inspection, it required coaching and mentoring people to integrate an emphasis on quality into any job and process that had anything to do with producing products.  The results were enormously successful, it resulted in levels of quality that were unattainable with a typical quality control approach, and that was how Six Sigma was originally conceived.

In those days, my manager used to tell me that “Our job as a Quality Manager is to teach, coach, and audit” in that order. In other words, you had to be a missionary to spread an emphasis on producing quality throughout the whole company rather than attempting to be totally responsible for “quality” yourself.  That’s exactly what is happening today with the project management profession – instead of a Project Manager attempting to be in control of all of the project deliverables, he/she needs to teach and coach others to take some level of basic project management responsibility including functions such as:

  • Planning and estimating their own work,
  • Building quality into the product rather than relying on someone else to find defects later,
  • Integrating with the rest of the team as a whole to produce an overall solution, and
  • Reporting on progress

It’s essentially a distributed approach to project management that engages everyone in the project management process instead of one Project Manager attempting to control everything.  In a very uncertain and dynamic environment, that has got to be a much more flexible and adaptive approach.

Why Should Project Managers Care About Agile?

The impact of Agile on the role of many project managers is likely to be significant. On small, single-team Agile projects, you may not find someone called a “Project Manager” at all; however, there certainly is a need for someone to coach and mentor the team on Agile Project Management practices. There is also a need for project managers on larger and more complex enterprise-level projects but even at that level, some understanding of Agile is essential. This “raises the bar” for project managers significantly. It requires project managers to develop a fresh new perspective to see Agile and traditional, plan-driven project management approaches as complementary to each other rather than competitive and to learn how to blend the two approaches in whatever proportions are needed to fit any situation.

What’s Needed to Adapt to This Change?

I’ve given a lot of thought to this problem and I am very passionate about helping project managers adapt to this change. Here are a number of articles I’ve written on this subject that should help project managers understand the impact of this change and begin adapting to it:

 

Articles on Agile Project Management
Article Synopsis
What Does Physics Teach Us About Agile Project Management Training? There’s a lot of similarity between the way that the science of physics has evolved and how project management has evolved:

  • For many years until the late 1800’s and early 1900’s, physics was based on what is called “Classical Physics”
  • “By the end of the nineteenth century, most physicists were feeling quite smug. They seemed to have theories in place that would explain all physical phenomena.”
  • “Twenty-five years later, this complacency had been completely destroyed by the invention of three entirely new theories: special relativity, general relativity, and quantum mechanics.”

In other words, the universe turned out to be much more complex, more dynamic, and less predictable than people thought it was. Isn’t that exactly what has happened with the project management profession?

What Does PMBOK v6 Mean For the Future of Project Management?

What is the Purpose of the New PMI Agile Practice Guide?

With the introduction of PMBOK v6 and the new PMI Agile Practice Guide, PMI has taken a major step towards recognizing that there is a need to integrate an Agile approach with a traditional plan-driven approach to project management in the right proportions to fit a given situation.

Up until this time, “Agile” and traditional, plan-driven project management have been treated as separate and independent domains of knowledge with little or no integration between the two.

What Does PMBOK v6 Mean For the Future of Project Management?

What is the Purpose of the New PMI Agile Practice Guide?

With the introduction of PMBOK v6 and the new PMI Agile Practice Guide, PMI has taken a major step towards recognizing that there is a need to integrate an Agile approach with a traditional plan-driven approach to project management in the right proportions to fit a given situation.

The PMP certification, as we have known it for a long time has been the mark of a very professional and well-qualified project manager; however, up until March 2018, the PMP exam has been totally based on traditional plan-drive project management.

PMI has recognized this limitation and in March of 2018 will begin to incorporate more Agile content in the PMP exam.

Is Project Management Obsolete? What Do You Think? Talks about the need to rethink what project management is if it is to thrive in the future.
Learn the Truth About Agile versus Waterfall Helps to overcome some misconceptions about Agile and Waterfall to see these two approaches in a fresh new light as complementary rather than competitive.

What Does Physics Teach Us About Agile Project Management Training?

What does Physics teach us about Agile Project Management Training?   We can learn a lot from how the science of physics has evolved and how universities have developed Physics curricula.  I think there are a number of interesting similarities to an Agile Project Management training curriculum.

Agile Project Management Training

What is the Similarity of Agile Project Management Training To Physics?

For many years until the late 1800’s and early 1900’s, physics was based on what is called “Classical Physics”.

What is Classical Physics?

“Classical physics is the physics of everyday phenomena of nature, those we can observe with our unaided senses. It deals primarily with mass, force and motion. While its roots go back to the earliest times, to the Ancient Greeks such as Aristotle and Archimedes, it later developed into a cohesive system with the contributions of Galileo, Kepler and Newton. Classical physics achieved phenomental success, as the Calculus of Newton and Leibniz gave it the tools to tackle even even problems not imagined by its pioneers.”

“Around 1900, give or take a decade, surprising new experimental evidence, primarily about atoms and molecules, showed us that these small-scale phenomena behave in ways not anticipated by classical theory. This ushered in a new era called “modern” physics. New laws and methodology were developed to deal with the rapidly expanding experimental evidence. Relativity and quantum mechanics added new tools to the study of nature. These did not make classical physics “wrong”, for the old laws were working just as they always had, within their limited scope—which was the study of large objects (not atomic scale ones) moving relatively slowly (not near the speed of light). “

“So classical physics is still the starting point for learning about physics, and constitutes the bulk of the material in most introductory textbooks. It is the theory underlying the natural processes we observe everyday. It is the key to understanding the motion of pulleys, machines, projectiles and planets. It helps us understand geology, chemistry, astronomy, weather, tides and other natural phenomena”

Simanek, Donald E., What’s Physics All About?, https://www.lhup.edu/~dsimanek/ideas/allabout.htm

What Happened to Cause People to Rethink Classical Physics?

That notion of physics that was intended to define how the entire universe worked held together for a long time; however, serious weaknesses began to appear around the early 1900’s:

“By the end of the nineteenth century, most physicists were feeling quite smug. They seemed to have theories in place that would explain all physical phenomena. There was clearly a lot of cleaning up to do, but it looked like a fairly mechanical job: turn the crank on the calculator until the results come out. Apart from a few niggling problems like those lines in the light emitted by gas discharges, and the apparent dependence of the mass of high-speed electrons on their velocity”

“Twenty-five years later, this complacency had been completely destroyed by the invention of three entirely new theories: special relativity, general relativity, and quantum mechanics. The outstanding figure of this period was Albert Einstein. His name became a household word for his development, virtually single-handedly, of the theory of relativity, and he made a major contribution to the development of quantum mechanics in his explanation of the photoelectric effect. “

Slavin, Alan J., “A Brief History and Philosophy of Physics”, https://www.trentu.ca/physics/history_895.html

How is This Transformation Related to Project Management?

Classical Physics is analogous to traditional, plan-driven project management. Similar to the laws of classical physics,

  • The traditional, plan-driven project management approach has been widely accepted as the only way to do project management for a long time. and,
  • The way traditional, plan-driven project management is done hasn’t changed significantly since the 1950’s and 1960’s. It assumes a very predictable view of the world where it was possible to completely define a project plan with a fairly high level of certainty prior to the start of a project

That is similar to classical physicists who believed for a long time that a model of the universe could be completely predicted based on some relatively simple and well-defined laws of classical physics. In recent years; however, it is apparent that we are in a much more dynamic and more complex universe with much higher levels of uncertainty where that traditional, plan-driven approach to project management no longer works well at all.

What Can We Learn from This Similarity?

Traditional, plan-driven project management (just like Classical Physics) will never be totally obsolete and will continue to be a foundation for many areas of project management:

“…classical physics retains considerable utility as an excellent approximation in most situations of practical interest. Neither relativity nor quantum theory is required to build bridges or design cellphone antennas.”

The never-ending conundrums of classical physics, https://www.trentu.ca/physics/history_895.html

However, it is important to recognize and not ignore the limitations that are inherent in a traditional, plan-driven project management approach. Experienced physicists have learned to recognize the limitations of classical physics that it only works reliably in a certain range of situations as shown in the figure below:

modern-physics

“Classical Physics is usually concerned with everyday conditions: speeds much lower than the speed of light, and sizes much greater than that of atoms. Modern physics is usually concerned with high velocities and small distances.”

https://en.wikipedia.org/wiki/Modern_physics

Similarly, project managers also need to recognize that a traditional, plan-driven approach to project management only works reliably in a limited set of situations. In the project management world, this can be expressed with the Stacey Complexity Model:

stacey-complexity-model

In this model, there are two primary dimensions – one is requirements complexity and the other is technology complexity.

  • Traditional, plan-driven project management still works in areas of low complexity such as some construction projects but even in some of those areas, project managers have recognized a need for a somewhat more adaptive approach
  • As you get further out on either complexity axis, there is typically a need for more of an adaptive Agile approach that is better suited for dealing with uncertainty but this is not a binary and mutually-exclusive proposition. There is a need to blend both approaches in the right proportions to fit the situation

What’s the Impact on Project Managers?

Just as new theories about Physics have significantly extended the notion of what “Physics” is beyond the traditional world of Classical Physics, Agile will have a similar impact on project managers.  The way this will probably evolve is very likely similar to the way that Physics has evolved:

  • In today’s world, there are people who specialize in Classical Physics and people who specialize in the more esoteric areas of Modern Physics; however, neither one of those areas can ignore the existence of the other area and a truly broad-based Physicist has a fairly solid knowledge of both of those areas
  • I believe that a similar thing is likely to happen in Project Management.  There will be project managers who continue to specialize in a traditional plan-driven approach to project management and project managers who specialize in Agile; however, just as in Physics,  neither one of those areas can ignore the existence of the other area and a truly broad-based Agile Project Manager has a solid knowledge of both of those areas

An Agile Project Manager is not a project manager who only works in an Agile environment.  It is someone who has a broad-based knowledge of both Agile and traditional plan-driven project management and knows how to blend those two approaches in the right proportions to fit any given situation.  The online Agile Project Management Training in The Agile Project Management Academy is designed around exactly this need.

 

Is Project Management Obsolete – What Do You Think?

Is project management obsolete?  I don’t think that “project management” is obsolete but I do think that some traditional roles of a “Project Manager” are becoming obsolete in projects that require a more adaptive approach.  I also think that there’s a need to redefine what “project management” is if it is to continue to thrive in the future.  There is a need to:

  • Separate the functions of “project management” from some of the traditional roles that have been played by a “Project Manager”, and
  • For the project management profession to “reinvent” itself and develop a broader view of what “project management” is if it is going to continue to thrive and remain relevant in today’s world.

Is Project Management Obsolete

Examples of Companies and Professions Reinventing Themselves

Any company or profession that doesn’t change and adapt to changes in the world around them runs the risk of becoming stagnant and no longer relevant. Here are a couple of examples:

  • American Express – American Express is a company that has been around for more than 150 years and has had to reinvent itself a number of times over that time. American Express started out in 1850 shipping boxes on railway cars. That business went very well for a while:

    “For years it enjoyed a virtual monopoly on the movement of express shipments (goods, securities, currency, etc.) throughout New York State.” (Wikipedia)

    Can you imagine where American Express would be today if it still defined its business primarily around shipping boxes on railway cars?

    American Express has continued to reinvent itself over-and-over again to remain a vibrant and competitive company.  Here’s another example – At one time not too long ago, American Express had a fairly large area of business associated with providing travel services to companies.  They provided on-site travel agents to help companies plan travel, book travel reservations, and other related services. In recent years, that business has declined as newer internet-based services displaced the need for on-site travel agents.  That’s another significant adjustment that American Express has had to make to adapt to changes in technology and the marketplace.

  • Quality Management – In the early 1990’s I worked in the Quality Management profession with Motorola. Prior to that time, Quality Management was heavily based on a quality control approach that relied on inspectors to inspect products for defects.That process was very reactive and inefficient and companies like Motorola began implementing a much more proactive approach to quality management that was based on eliminating defects at the source rather than finding and fixing them later.  That’s how Six Sigma was created at Motorola at that time.That caused a major transformation in the Quality Management profession.  Instead of being in control of quality through quality control inspectors, Quality Managers had to learn to distribute some responsibility for quality to the people who designed and manufactured the product and play more of a consultative and influencing role.  When I worked for Motorola in the early 1990’s,  my manager used to tell me that:

    “Our job is to teach, coach, and audit – in that order”

    That turned out to be a much more effective approach but it was a gut-wrenching change for many people in the Quality Management profession who were used to being the ones who owned responsibility for quality and were in control of quality.

    I published my first book in 2003 which was called “From Quality to Business Excellence“.  That book was designed to help quality professionals understand this transition and I also gave numerous presentations at that time to ASQ (American Society for Quality) chapters to help them better understand and adapt to the transformation that was taking place.   At that time, there were a lot of people in the local ASQ chapters had difficulty adapting to that change and who were out of work.

How Does This Relate to Project Management?

For many years, the project management profession has been dominated by an approach that emphasized planning and control. A project was deemed to be successful if it delivered well-defined project requirements within an approved budget and schedule. That approach hasn’t changed significantly since the 1950’s and 1960’s but we live in a different world today. There are two major factors that are creating a need for a different approach in today’s world:

  • Levels of Uncertainty – There is a much higher level of uncertainty because problems and solutions tend to be much more complex.  This is particularly true of large software systems. With a high level of uncertainty; it is difficult, if not impossible, to define a detailed solution to the problem prior to the start of the project.   The example I use in my training is “finding a cure for cancer”.  Can you imagine attempting to develop a detailed project plan for that kind of effort?  There is just too much uncertainty.  Instead of getting bogged down in trying to develop a detailed project plan upfront, it would be much better to get started and use an iterative approach to attempt to converge on a solution as the project is in progress.
  • Increased Emphasis on Innovation – In many areas, competitive pressures require a significant level of innovation in new product development.  In these areas, creativity and innovation are much more important than planning and control.  For example, think of what a company like Apple has to do to develop a new iPhone.  Do you think that they start with a detailed plan based on some well-defined requirements?  I don’t think so.

An Agile project management approach is very well-suited for a project that:

  • Has a high level of uncertainty, or
  • Requires an emphasis on creativity and innovation rather than an emphasis on planning and control.

An Agile approach uses a very different approach to project management.  In an Agile project, you probably won’t find someone at the team level called a “Project Manager” but that doesn’t mean that there is no “project management” going on:

  1. It’s a different kind of project management that is focused on an adaptive approach to project management to optimize the business value the project produces rather than a plan-driven approach to project management that is oriented around simply meeting cost and schedule goals for defined requirements.
  2. The project management functions that might normally be performed by someone called a “Project Manager” have been distributed among the members of the Agile team:
    • Each member of the team is responsible for planning, managing, and reporting on their own tasks and working with other members of the team as necessary to integrate their efforts
    • The Scrum Master plays a facilitation role and is responsible for removing obstacles if necessary
    • The Product Owner plays an overall management role to provide direction and decisions related to the direction of the project and is ultimately responsible to the business sponsor for the overall success or failure of the project from a business perspective

What Needs to be Done to Adapt to This New Environment?

In today’s world:

  • There are many project managers who have been heavily indoctrinated in a traditional plan-driven approach to project management who might attempt to force-fit all projects to that kind of approach
  • There are also many project managers who are used to a project management approach that relies heavily on well-defined document templates and checklists to define how the project is managed

In my book, I use the analogy of a project manager as a “cook” versus a project manager as a “chef”:

  • “A good ‘cook’ may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook.”

  • “A ‘chef’, on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine.” (Cobb – The Project Manager’s Guide to Mastering Agile)

I think that analogy captures the challenge for the project management profession very well – In today’s world we need fewer “cooks” and more “chefs”:

  • Project managers need to learn how to blend an Agile (adaptive) approach with a traditional plan-driven approach in the right proportions to fit the nature of the problem.  Force-fitting all projects to a traditional plan-driven project management approach is not likely to be very successful
  • This new environment “raises the bar” considerably for project managers and requires a lot more skill.  It is not a simple matter of filling in the blanks in well-defined project templates and following project checklists based on PMBOK®.

What Has Been Done to Transform the Project Management Profession?

PMI® has begun to recognize the need to deal with this challenge and has made steps in that direction but much more needs to be done:

  1. The PMI-ACP® certification is a step in the right direction but it doesn’t go far enough in my opinion.  It recognizes the need for project managers to have an understanding of Agile and Lean but it is only a test of general Agile and Lean knowledge and doesn’t really address the big challenge that project managers have of figuring out how to blend those approaches with a traditional plan-driven approach to project management.
  2. PMI® still treats Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two. PMBOK® version 6 will have some added material on how the various sections of PMBOK® might be applied in an Agile environment but that also doesn’t go far enough in my opinion. The whole idea of PMBOK® is not very compatible with an Agile approach.
    • Agile requires a different way of thinking that is much more adaptive and you shouldn’t need a 500+ page document to give you detailed instructions on how to do Agile.
    • The whole idea of developing a knowledge base associated with Agile and only changing it every five years is difficult to imagine
  3. Much of the training that is available to project managers today on Agile only addresses the basics of Agile and Scrum.  You have to understand the principles behind Agile and Scrum at a much deeper level to understand how to successfully adapt those approaches to different kinds of projects.  You can’t just do Agile and Scrum mechanically.

We need to go beyond these steps and “reinvent” what “project management” is (just as American Express and other companies have had to reinvent the business that they are in).  Here’s how PMBOK® currently defines “project management:

“Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.  Project management is accomplished through the appropriate application and integration of the 47 logically grouped project management processes, which are categorized into five Process Groups.”  (PMBOK® version 5)

There are at least two major problems with that definition:

  1. The phrase  “to meet the project requirements” implies that a project is limited to meeting defined requirements.  In today’s world, a project manager should be capable of taking on a project with broadly-defined objectives, figure out what needs to be done to accomplish those objectives, and also figure out what methodology is best suited for managing that effort
  2. The phrase “application and integration of the 47 logically grouped project management processes” implies that there is a defined process approach for project management rather than an empirical approach that is used in an Agile environment

Summary – Is Project Management Obsolete

Project Management certainly isn’t obsolete but the “handwriting is on the wall” that change is definitely needed for the profession to continue to grow and thrive.  The need for change doesn’t always hit you in the face immediately. Many times it comes about subtly and it may not be that obvious at first but I can certainly see the early signs that a change is needed:

  • I gave a presentation at a PMI chapter in New York city this week and it was an excellent group of people but attendance was much lower than in the past. This presentation drew about 75 people and previous PMI chapter presentations I’ve given in New York City have drawn about 200-300 people.
  • I also met a number of people in that presentation who are out of work and looking for new opportunities

Those are obvious early warning signs to me that a transformation is needed to redefine and rejuvenate the project management profession.  It reminds me a lot of what I saw in the ASQ chapters I presented to about 15 years ago.

I am very passionate about helping the project management profession recognize the need for this transformation and helping project managers to develop the skills to successfully make this adaptation.  That’s the essence of the three books I’ve published on Agile Project Management and of the online Agile Project Management training I’ve developed.

What is Project Management? Is it Mutually-exclusive with Being Agile?

I recently participated in an online discussion where someone made the statement that “Project Management and Scrum have nothing to do with each other. In fact, they mutually exclude each other.” I want to share my response with you because I think there is an important issue about rethinking “What is Project Management?”

What is Project Management? – A Narrow View

That view of project management is based on a very popular and widely-held stereotype about what “project management” is:

  • “Project management” is something that is only done by a single person called a “Project Manager”
  • There is only one way to do “project management” and that is using a traditional plan-driven methodology (what many people loosely call “Waterfall”)
  • “Project management” is completely incompatible with an Agile approach because an Agile approach must be dynamic and adaptive and project management emphasizes control and is inflexible

That’s a very narrow view of what “project management” is; however, that view is widely-held by a lot of people and the project management community has not done enough to change that perception:

  • PMI still treats Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two
  • Many project managers are heavily indoctrinated in a traditional plan-driven project management approach and see that as the only way to do project management

If you look at the official PMBOK definition of “project management”, it is very consistent with that narrow view of what project management is:

“The application of knowledge, skills, tools and techniques to the project activities to meet project requirements” – (PMBOK version 5)

That definition implies that “project management” is mainly concerned with planning, organizing, and managing project activities to meet defined requirements. Which is exactly how a traditional plan-driven project works but it is not consistent with how an Agile/Scrum project works.

What is Project Management? – A Broader View

If you look at how an Agile/Scrum project works, there is actually a lot of “project management” going on but many people will not recognize it as “project management” because it doesn’t fit with the traditional stereotype of what “project management” is:

  • In an Agile/Scrum project you may not find anyone at the team level with the title of “Project Manager”
  • The project management functions that would normally be done by a single person called a “Project Manager” are distributed among all the members of the Agile team. For example:
    • Developers – All members of the project team are expected to take responsibility for planning and completing the tasks that they are responsible for to meet commitments that they have made. They are also expected to report progress and coordinate their work with other members of the team as necessary.
    • Scrum Master – The Scrum Master is expected to facilitate team meetings and take action to remove any obstacles if necessary
    • Product Owner – The Product Owner is expected to make any decisions or tradeoffs that might be needed to meet the project goals

    Those are all functions that would normally be performed by a project manager if there was one; they are simply distributed across a number of roles rather than being performed by a single person called a “Project Manager”.

  • It doesn’t use a traditional plan-driven approach to project management – the requirements may not be well-defined at the beginning of the project and it uses a more adaptive approach to further refine the requirements as the project is in progress

Does that mean that there is no “project management” going on?  I don’t think so – it’s just a different kind of “project management” that doesn’t fit the typical narrow stereotype that many people have of what “project management” is.

Here’s what I think a broader definition of “project management might look like:

“Project Management is the application of knowledge, skills, tools, and techniques to accomplish a meaningful objective and maximize the value that the project produces.”

What’s Different?

Here are a couple of key areas of difference that I believe are important:

  • My definition of project management doesn’t say anything about defined requirements.  It is based on a broader idea that a project manager should be able to be given a broadly-defined business objective and figure out what is needed to achieve that objective
  • The goal of a project manager should also be to produce business value, not just meet cost and schedule goals for delivering defined requirements.  There have been many traditional plan-driven projects that have met their cost and schedule goals but failed to deliver business value and they were still considered successful from a project management perspective

Why is this Important?

Many of the traditional notions of what “project management” is have their roots in the 1950’s and 1960’s and the fundamental nature of what “project management” is has not changed significantly since that time. We live in a different world today from what existed in the 1950’s and 1960’s:

  • Technology is rapidly changing
  • Solutions are much more complex
  • There is a much higher level of uncertainty in many projects
  • Time-to-market is extremely critical to keep pace with competition

Attempting to force-fit all projects to a traditional plan-driven model that hasn’t changed significantly since the 1950’s and 1960’s is probably not going to result in an optimal solution.  You have to fit the project management approach to the nature of the problem and that calls for a broader range of project management approaches not limited to traditional plan-driven project management.

The key message is that you need to fit the project management approach to the nature of the problem rather than force-fitting all projects to a single project management approach.

An Integrated and Dynamic Approach to Project Management

I think of this as an “integrated and dynamic” approach to project management:

  • It’s integrated because project management is fully integrated into the way the team works rather than being done by a single person called a “Project Manager”
  • It’s dynamic because the nature of the project management approach isn’t limited to a traditional plan-driven approach to project management.  It is expected that the project management approach will be adapted to fit the nature of the situation

I think you can see that if your objective is control, a traditional plan-driven approach to project management of putting one person called a project manager in control of a project might be a good approach; however, an emphasis on control can be inflexible and doesn’t work well in an uncertain environment that requires a more adaptive approach. We need to adapt the approach to fit the nature of the project and the level of uncertainty in the project is a major factor in choosing the right approach.

Transforming the Project Management Profession

Dealing with this challenge really requires a major transformation of the project management profession, in my opinion.

What is Project Management?

Here are some fundamental things that need to be done:

  1. We need to think of “project management” in broader terms than thinking that traditional plan-driven project management is the only way to do project management
  2. Project managers need to be trained in how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation
  3. We need to recognize that “project management” is a function, not a title, and the function of “project management” is not always exclusively performed by someone called a “Project Manager”

I’ve Been Here Before

There is a feeling of deja vu about this to me.  I’ve been here before.  In the early 1990’s, I worked in the Quality Management profession at Motorola.  Motorola was a leader at that time in developing a new approach to quality management.  The old approach to “quality management” was something like this:

  • There was a heavy emphasis on control.  Someone called a “Quality Manager” had responsibility for controlling the quality of the products being built.
  • The quality management approach relied heavily on  inspectors who enforced standards of quality through inspection of products before they shipped

The flaws in that approach should be obvious:

  • Relying heavily on inspection to find defects can result in a significant amount of rejects and rework – a far better approach is to go upstream in the process, remove the source of defects, and make the process that produces the products inherently reliable
  • Putting responsibility for quality in the hands of a single person or organization makes the employees who are responsible for producing the product feel that “quality is someone else’s responsibility”.  A far better approach is to engage everyone in the quality management functions so that everyone involved in producing a product feels that they are directly responsible for the quality of the products they produce

A similar thing could be said about project management today – putting all project management responsibility in the hands of someone called a “Project Manager” makes the workers feel like “project management” is someone else’s responsibility.  A far better approach in a complex and uncertain environment is to engage everyone in “project management” so that it is a shared responsibility among everyone on the team to make the project successful.

What are the Most Practical Ways to Do Project Planning?

I recently participated in an online discussion in response to a question that was asked on “What are the most practical ways to do project planning?” It’s a critical issue and it comes up a lot so I thought I would share some thoughts on this subject.

Factors to Consider

In my opinion, there are two very significant factors in determining what planning approach would make the most sense for a particular project:

  1. Uncertainty – The level of uncertainty in the project is probably the most important factor.  If there is a high level of uncertainty that cannot easily be resolved, it would probably be foolish to try to develop a highly-detailed, plan-driven approach.  An example would be attempting to find a cure for cancer.  It would probably be foolish to try to develop a detailed plan for that effort, there’s just way too much uncertainty.That doesn’t mean that you wouldn’t do any planning at all.  You would take stock of what you know and don’t know and try to develop at least a cursory plan based on that information and then continually revise the plan based on what you learn as the project is in progress.
  2. Customer Relationship – The second major factor is the relationship with the customer.   If you have a contractual relationship with the customer where the customer is expecting a firm set of deliverables for a given schedule and cost, you might be forced into a planning model to try to effectively manage and satisfy those customer expectations.  If there is more of a collaborative relationship with the customer, you probably have a lot more ability to optimize the approach based on the level of uncertainty in the project.

Planning Quadrants

Obviously, there may be a conflict between these two factors.  I’ve created a diagram below to show some of the possible combinations of these two factors:

What are the most practical ways to do project planning?

Lets look at each of these quadrants individually:

  1. Low Uncertainty, Contractual Relationship – This is the area that most project managers are most familiar with and it is the area that is most well-suited for a traditional plan-driven project management model.  In this area, the level of uncertainty may be low enough to permit developing a detailed plan that is consistent with managing customer expectations in a contractual relationship model.
  2. Low Uncertainty, Collaborative Relationship – If the level of uncertainty associated with a project is low, you might develop a more collaborative relationship with the customer but that might not be the most efficient way to do the project.  If the level of uncertainty is truly low and it is relatively easy to define the project requirements upfront, it may not make too much sense to engage the customer too heavily in a collaborative relationship to further define detailed direction for the project as it is in progress.
  3. High Uncertainty, Collaborative Relationship – This is the area where an Agile approach makes sense but the success of that effort will generally depend on a collaborative relationship with the customer to make it work.  In this area, instead of trying to develop a highly-detailed upfront plan prior to starting the project, you would probably:
    • Reach agreement with the customer on at least a vision for the project and at least some higher level objectives and requirements that the project must meet, and
    • Then further elaborate those requirements and the plan for meeting them as the project was in progress

    It’s easy to see how this kind of planning model may not work well unless there’s a collaborative spirit of trust and partnership with the customer since:

    • It may be almost impossible to accurately define the costs and schedule for completing the project prior to starting the effort; and
    • Further defining the plan as the project is in progress requires a close working relationship with the customer.
  4. High Uncertainty, Contractual Relationship – This area is the quadrant that is likely to be most problematic:
    • Attempting to do an Agile project with highly uncertain requirements without a collaborative relationship with the customer is not likely to work very well:
      • The customer may not be committed to actively engage in the project as it is in progress to help elaborate and resolve questions related to the requirements; and,
      • As a result, the project may either get stalled or go off in the wrong direction
    • Attempting to apply a contractual, plan-driven approach in this kind of environment is also likely to be problematic. There would likely be a very high risk associated with trying to develop a firm, plan-driven contractual relationship based on highly uncertain requirements. What is likely to happen is:
      • The project meets the defined requirements but the defined requirements were wrong, or
      • There are so many changes as the project is in progress that the scope of the project winds up being completely different from what the customer was expecting

    It’s easy to see how either of these scenarios might present a very high risk.

Of course, this is somewhat of an over-simplification and all projects don’t fall very neatly into one of these quadrants.  There is a very broad range of scenarios in the middle of this diagram that call for some kind of hybrid approach.

What are the Most Practical Ways to Do Project Planning?

There are a number of conclusions that I think we can draw from an from understanding of this model:

  1. There is not just one way to do project planning – Project Managers who have been heavily indoctrinated in a traditional, plan-driven model and attempt to force-fit all projects to that kind of planning model are likely to not have optimal results
  2. This is not a simple binary and mutually-exclusive choice between an Agile and traditional plan-driven planning model; it is much more complicated than that.  There’s a whole spectrum of different possible scenarios and it is a multi-dimensional problem
  3. The right approach is to fit the planning model to the nature of the problem based on the level of uncertainty and the relationship with the customer.  Attempting to use a single “one size fits all” planning model for all projects is not likely to work very well.

This creates a big challenge for project managers to learn how to blend an Agile and traditional plan-driven approach in the right proportions to fit a given situation.  And, that’s not an easy thing to do – PMI still treats these two areas as separate and independent domains of knowledge with little or no integration between the two.  This is exactly the challenge that my Agile Project Management training is designed to address.

Is Agile and Scrum Anti-Engineering?

I recently participated in an online discussion on the topic of “Is Agile and Scrum Anti-Engineering?”.  This question seems to be based on a number of popular stereotypes that people have about “Agile” and engineering design practices.  For example, a popular stereotype is that an Agile project consists of just a bunch of “cowboy software developers” who get together and start writing code without any plan and discipline about how it is done.

Is Agile and Scrum Anti-engineering?

If you have that view, it’s easy to come to the conclusion that Agile is not a very sound approach to engineering at all because it doesn’t necessarily follow a well-planned and systematic engineering design approach but it would be a mistake to draw that conclusion.  If it is well-executed, an Agile approach requires a considerable amount of discipline and skill and it’s not “anti-engineering” – it is just a different kind of engineering.

Importance of a Systematic Engineering Design Approach

Let’s step back and look at when and where a well-planned,  systematic engineering design approach really makes the most sense.  That kind of approach is most important for problems that have a high level of technical complexity and the aim is to find an optimum solution as quickly and efficiently as possible:

“A systematic engineering design process model aims at making it easier to find an optimal design for a product-to-be. To that end it is necessary to encompass the broadest range of solutions, that is, to search for solutions in a structured, systematic way. The breadth-first top-down strategy is adopted,  which means first finding the largest possible number of abstract solutions (breadth-first) and then more concrete ones (top-down)”
https://www.designsociety.org/download-publication/26782/a_review_of_the_fundamentals_of_systematic_engineering_design_process_models

A good example of that might be a very data-intensive application that might start with a high-level, conceptual design phase, proceed to a logical design phase, and then finally wind up with a detailed physical design of the solution.  To do that efficiently, you will want to stabilize the requirements as early as possible because each phase cascades into the next.  You don’t want to get all the way into the detailed physical design and discover some of the critical assumptions made in the previous phases were wrong because it could require a significant amount of rework of the whole design.

However, there are many people who believe that a well-planned and systematic approach to engineering is the only way to do engineering.  Here’s an example:

“The design of complex, complicated or a family of products is usually beyond the intuitive skills alone of a designer or design team. Gerhard Pahl and Wolfgang Beitz [1] have set out a strategy for the development of solutions which aims to increase the probability of technical and economic success of product design. This is done by creating a dependable approach which allows careful planning and systematic execution so that the whole design task reduces to a logical and comprehensible exercise and also allows recovery from inevitable errors. It also allocates a time schedule for the design stages which in turn leads to a predictable project timetable. Systematic design is general enough to be applied in any branch of engineering.”
http://theoriesaboutengineering.org/gerhard_pahl_and_wolfgang_beitz.html

When Does a Systematic Engineering Design Model Make Sense?

That well-planned, systematic approach to engineering design has been the predominant approach to engineering design for a long time. It has proven to be a reliable and efficient process for converging on a design solution where the requirements are relatively well-defined and the technology is also relatively stable as shown in the Stacey complexity model below:

The primary question that the design team must answer in this environment is:

“Is this solution the most optimum design solution to the requirements for this problem?”

It is primarily a pure engineering design decision.

Why Doesn’t That Approach Work in Many Areas Today?

The major problem with that approach is that we live in a much more complex world with much higher levels of uncertainty today.  In terms of the Stacey complexity model, both the requirements and the technology associated with the solution might be much more uncertain.  In that kind of environment,

  • It is no longer a simple question of “Is this solution the most optimum solution to the requirements for this problem?” and
  • Its no longer limited to relatively straightforward engineering design decisions because the requirements themselves might be wrong and the assumptions about the technology might also be wrong

In an uncertain environment, the approach needs to be much more adaptive and involve some amount of “discovery” to determine what the requirements for the solution should be.  The approach should not be limited to just implementation of a predefined  solution.  There is also typically a lot of tradeoffs between the requirements for the solution and the technical implementation that optimizes both.   Converging on a solution to those requirements without considering those tradeoffs might not yield an optimal solution.

When that kind of situation has arisen in the past, a typical approach has been to do some amount of upfront prototyping to try to converge on the requirements of a solution before actually starting on the full-scale design and development effort.  That approach works in some cases but it isn’t the most efficient or the most effective approach if there is a large amount of uncertainty in the requirements.  If there is a large amount of uncertainty in the requirements, it may take multiple iterations to converge on the requirements for the design; and, for larger and more complex projects, there may be a number of different areas of uncertainty that need to be resolved.

That’s why an Agile approach can make a lot of sense for projects with a high level of uncertainty.  It’s not really “anti-Engineering”:

  • It’s a different kind of engineering approach that is different from a typical, well-planned, systematic engineering design approach,
  • It is much more appropriate for areas that have high levels of uncertainty

It’s important to recognize that Agile is not “cowboy engineering” – if it is done correctly it requires a lot of discipline and skill.

What Does This Mean For Project Management?

Project Management is not just an administrative task – project management needs to be designed around the most sensible engineering design approach for a given problem. Traditionally, the project management approach has been heavily-based on well-accepted engineering design practices that emphasize a well-planned, systematic engineering approach. As we rethink the way that engineering is done, we also need to develop new project management models that are also better aligned with higher levels of uncertainty.

Summary of Key Points

Here’s a summary of some key points from this article:

  • There  is an intimate relationship between project management processes and engineering design processes.
  • Many people have forgotten about that relationship and think of  project management as primarily an administrative management function to manage the execution of what many people loosely call “Waterfall”.
  • Project management is more than just an administrative function – it should be geared to effectively manage an underlying engineering design process.  And, that underlying engineering design process should be geared to the nature of the problem.
  • The underlying engineering design approach that has been assumed to be well-established for so many years can no longer be taken for granted as the only way to do engineering design.  It does not provide a sufficient level of flexibility and adaptivity for a highly uncertain environment.
  • Project management must adapt as well – it is no longer viable to force-fit all projects to a project management that is based on an underlying engineering design approach that has serious weaknesses in an uncertain environment.

The challenge for project managers is learning how to blend an iterative and adaptive Agile approach with a more traditional plan-driven approach in the right proportions to fit the nature of the project and one of the biggest factors in choosing the right approach is the level of uncertainty in the project.