Don’t Panic: Project Management and Continuous Change

I have been working in the field of web development for now 12 years. So it’s long been evident to me the pervasive tendency of the public to feel pressured to stay current with recent changes, without taking the time to understand the nature and purpose of new innovations. Unlike previous technological revolutions, the advent of the personal computer and the Internet involves a complexity of an underlying science that is usually far beyond the grasp of the average person. Busy with other concenrns, most people do not have the opportunity to spend additional time to understand the technology with more depth. This tends to make people feel embarrassed that they are falling behind, and they naively attempt to rectify the situation by jumping on the latest bandwagon.

That tendency has been succinctly illustrated in Garnter’s Hype Cycle chart. The trend is to greatly overreact with the promises of new innovations. When those exaggerated expectations don’t pan out, the pendulum swings heavily to the other end, causing a corresonpding depression of enthusiasm. However, as the affordances of the technology quietly reveal themselves, their adoption slowly seeps into our daily lives, settling on an eventual “plateau of productivity.”

Despite these warnings, the recurring mantra seems to be that constant “change” is our new reality, and we strive to adapt to it without first properly defining what that means. Despite several past disappointments, there is no lack of prognoses attempting to look ahead to further transformations. For example, Conway, Masters and Thorold (2017), observe that “We sit on the cusp of a fourth industrial revolution, with automation, robotics, machine learning and biotechnology promising to transform transport, medicine, social care, communication and more, and extend human capabilities in remarkable ways” (p. 5). Some some of these techonologies are already impacting our lives, but for the most part, their impending effect is largely conjecture.

Such conceptions of “change” not only impact the adoption of technology, but also appraches to managing such “change.” A prime example is the “agile development” methodology. A similar approach has been suggested for instructional design, known as “rapid prototyping” (Thomas,  2010, p. 192). The approach represents an attempt to adapt the ADDIE model which is supposedly not well-suited for rapid changes in technology. Because, again “change” is assumed to be “rapid” without defining what its potential impact might be. As I had discussed in a previous blog post, the process of ADDIE is not disrupted by rapid change, but is rather just accelerated. Instead, following on the agile development approach, an ever-elusive goal line is adapted to by continuously cycling through the process, instead of assuming that implementation means the project is complete.

It is possible that the advent of the agile methodology is due to the fact that the Agile Manifesto was written by developers, not project managers. In fact, agile project management is nothing new. According to the PMBOK (2013) of the Project Management instutute, projects whose scope are difficult to define are pursued with an interative scope defenition and project management approach known as “rolling wave” planning (p. 45). Effectively, what happens is that, by refusing to define scope in fine detail at the outset of a project, what the agile methodology does is offset risk in what the PMBOK call “sharing” risk (p. 346). This effectively forces the client to assume some of the risk of scope creep. The problem with that,  scope creep is not always the result of problems inherent in the project itself, but can ensue from shortcomings in the contractor’s methods, processes or competencies. It should not be the client’s responsibility to pay for those. Lastly, without detailed scope, it is difficult to define budgets, requiring clients to assume the risk of eating sunken costs if it happens that the project becomes eventually unafforable.

“Agile development” is now a popular buzzword across the industry, and one risks being perceived as behind the times if one doesn’t adopt the methodology. This is the nature of the challenge I’ve run into at work. The reality is that the agile approach was developed for the software industry, for brand new software projects, or applications that have never been created before. Clearly, in such cases, scope would be almost impossible to define, and by the nature of the technology, it would be necessary to be open to adapting the acceptance criteria as the project evolved over time.

I work as as Project Manager in a web development agency and recently acquired my PMP designation. Though, as is now common at most agencies, I was expected to implement an agile approach. Because it exists in a digital medium, it has been falsely assumed that web development must necessarly benefit from an agile approach as well. However, unlike new software applications, websites are a repeatable product, whose customizations are confined to a limited menu of features and funcationality. In effect, their scope is relatively easy to define.

As indicated by Drieghe (2017), agile was meant to be adaptive, and instead it is becoming prescriptive, involving an entire process, including scrums, standups, user stories, sprints and so on. These are now the orthodoxy of the agile approach, as opposed to it being a disposition of openness, where “Individuals and interactions,” are more valued “over processes and tools” (Agile Manifesto). As is so often the case in the era of cyber-utopianism that we are currently living in, there’s a rush to adopt the latest thing, as opposed to starting with assessing the nature of a current project, and selecting from the array of methods and processes, what approach is most appropriate at the time. It is important for leaders in the industry to recognize the widespread consequences of over-exhuberance, and take into consideration Gartner’s observation. Only then will we learn to adapt more successfully to real change.

 

References

Conway, R., Masters, J., & Thorold, J., (2017). From design thinking to systems change: How to invest in innovation for social impact. Royal Society of Arts, Action and Research Centre.

Drieghe, J. (2017, April 26). Being agile was never about the process. Medium.

Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition. Newton Square, Penn: Project Management Institute, Inc.

Thomas, P. Y. (2010). Learning and instructional systems design. In Towards developing a web-based blended learning environment at the University of Botswana. (Doctoral dissertation).