Agile versus Waterfall in Software Projects
By John Herman PMP, CQE, MPM
A complete discussion of the pros, cons, and other aspects of using agile, waterfall, or hybrid approaches is too much for a blog column. Indeed, it might be worthy of a short book! What follows is a short recap of what I’ve had success with across the past decade. I’ll concentrate on Agile versus Waterfall and defer discussion of Hybrid methods for a future posting.
A fairly universal rule of thumb is that the Waterfall method works well when requirements are well defined. Agile thrives for projects where requirements are not well defined, are expected to change, or evolve based on each iteration such as with R&D activities.
Agile is usually very good for customer service or customer facing applications, where user feedback contributes to requirement changes, early and often. In addition, applications that interface with customers often need to rapidly incorporate innovations similar to those being used successfully by competing companies.
Agile is also great for marketing applications, another area of the business where change is common. Again, needs to respond flexibly and/or rapidly to changes in the economy and marketplace are a common factor in the marketing and sales functions of the business.
Waterfall is usually the best choice for compliance projects, where requirements are usually firmly based on laws, regulations, policies, or audit findings; both from internal and external sources. In addition, compliance activities are usually constrained by a date by which the compliance should be achieved.
Accounting and finance applications are also suitable for Waterfall. These business functions usually have exact requirements and face continuing efforts to meet standards for reporting to management, shareholders, and overseeing organizations.
It has generally been accepted that the choice of methodology for any particular project should be based on that project’s needs. That said, the above summary reflects some real-world experience with projects across companies of varying size with varied products and services.
Donald Rumsfeld and Project Management
By John Herman PMP, CQE, MPM
Donald Rumsfeld graduated from Princeton University and was an active participant at high levels in both corporate and government organizations. He was both the 13th (1975-77) and 21st (2001-06) Secretary of Defense of The United States. Today’s focus is on a statement he made at a Department of Defense news briefing on February 12, 2002.
“There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.”
This jumble of words actually has considerable worth during project planning. The “known knowns” are our scope and constraints. We plan for these aspects because they are known. The “known unknowns” are assumptions and risks. We know about these aspects, but we don’t know about their degree of truth (assumptions), or how likely they are to occur or their severity (risks). The “known unknowns” ties well to a previous entry in this blog titled “Alexander’s Question”.
But what about the “unknown unknowns”? Can we simply ignore what we don’t know? The answer is, of course, no. But how can we plan for what we don’t know? These “unknown unknowns” factor into the contingency buffers for scope, budget, and schedule. The experienced project manager incorporates budget and schedule contingency buffers (also known as management reserve) within the project to accommodate the unforeseen.
Rumsfeld’s quote, along with some other gems that he’s given us, show that planning and risk management have application even at the highest levels of corporations and governments. In closing, here’s another Rumsfeld quote that correlates well to measuring success, but we’ll have to save the discussion of this quote for another day.
“Congress, the press, and the bureaucracy too often focus on how much money or effort is spent, rather than whether the money or effort actually achieves the announced goal. “ - From "Rumsfeld's Rules", January 12, 1974
Kaizen or Kaikaku?
By John Herman PMP, CQE, MPM
Kaizen is a Japanese word that means improvement. When used in business or quality settings, it generally means continuous improvement, and is associated with cyclic activities like Deming’s Wheel (Plan-Do-Check-Act) and Six Sigma DMAIC.
Kaikaku is a Japanese word that means “radical change”. Kaikaku is associated with radical (innovative) change. So yes, recent discussions about kaizen and continuous improvement possibly acting as impediments to innovation have some truth to them.
Both Kaizen and Kaikaku are concepts associated with the “Lean” philosophy and strategy (www.lean.org). While Kaizen is evolutionary and focused on incremental improvements, Kaikaku is revolutionary and focused on radical improvements.
Kaizen and Kaikaku are both important processes. It’s interesting that the Lean/Quality/Six Sigma profession embraces Kaizen, which is a cyclic activity not greatly different from an Agile project management approach. Meanwhile, those same quality professionals are often suspicious of the sudden change of Kaikaku, which is similar to the “big bang” Waterfall approach to Project Management. In the PM field, the Waterfall approach has been stalwart across many decades, while Agile is just now catching up.
Both Kaizen/Kaikaku and Agile/Waterfall are important processes. There are situations and opportunities for each. In the Lean/Quality/Six Sigma profession, it is well recognized that when change is introduced by Kaikaku, it is important to follow up with several cycles of Kaizen to improve and refine the change. As PM’s, we should plan to have several Agile cycles shortly after the Go-Live of a Waterfall project, to fine-tune the results and capitalize on any improvement opportunities.
By John Herman PMP, CQE, MPM.
There are many excellent articles and templates for demonstrating Business Justification, but a root-cause analysis reveals a very basic lesson in business acumen. There are only four major reasons for undertaking any business process or project.
Increase revenue: Obviously, increased revenue is expected to lead to increased profits, and may also lead to increased market share, brand recognition, and other favorable results.
Reduce costs: Reducing costs will also impact the bottom line. However, costs can’t be reduced below zero, so there are more limitations associated with reducing costs than with increasing revenue.
Improve quality: Although sometimes difficult to measure, improvements in the quality of products and services impact customer satisfaction and growth of the brand.
Attain or maintain compliance: Government regulations must be addressed or the business could be forced to close, or suffer irreparable damage to the brand. Some aspects in the compliance area include taxes, safety, and privacy.
And, of course, projects can cross boundaries and have more than one business justification.
It’s always a good idea to inform the project team why any particular project is being done. Not only is it good top-down communication, it will improve the team’s business acumen.
By John Herman PMP, CQE, MPM
About 40 years ago, a new strain of flu hit in New Jersey. During the analysis of that flu outbreak, critical thinking took a big step forward via questions asked by Dr. Russell Alexander, although no one probably realized the impact at that time. Alexander’s Question, as a management tool, was probably refined and documented for the first time by Richard E. Neustadt and Ernest R. May in their book, “Thinking in Time: The Uses of History for Decision Makers”.
In a nutshell, Alexander’s Question can be summed up like this:
“What information, if we had it, would make us change our decision?”
Follow-up activities are focused on obtaining that information so that the decision can be based on better information, and thus likely have better results.
The goal of Alexander's Question is to uncover assumptions and perspectives that may be clouding one’s judgment. By asking what information would be needed to change your mind, faulty reasoning can be intercepted and the decision can be based on more objective data. Alexander’s Question can also identify which facts should be researched before committing to a course of action.
Another, more detailed variation of Alexander’s Question focuses on Project Management aspects like risk, schedule, and quality management :
What new information would change your estimation? When would you need this information? Why would it change your estimation?
Regardless of how Alexander’s Question is written, the underlying principle is the same: Identifying information that would make the decision more firmly rooted in facts, and less based on subjective opinions.