Project Management

Pro*Blog

by
Covering all things Pro: problems, products, progress, projects, process, programs, professions, proposals, provisioning, and more! Analysis and commentary on yesterday and today, and prognostications, prophesies, and projections for the future.

About this Blog

RSS

Recent Posts

Agile versus Waterfall in Software Projects

Collective Knowledge

Last Responsible Moments

Donald Rumsfeld and Project Management

Kaizen or Kaikaku?

Agile versus Waterfall in Software Projects

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. 

Posted on: January 26, 2019 11:14 AM | Permalink | Comments (10)

Collective Knowledge

Collective Knowledge  

By John Herman   PMP, CQE, MPM

Your company can be smarter than it is.  Your project, too. 

By drawing on resources both within and outside the company, your company’s knowledge base can be larger than the sum of its intellectual property and employee base.  Here are some sources of external knowledge that can be tapped, and should be considered when ideas or solutions are needed. 

  • Vendors:  The Agile Manifesto statement valuing partnership with vendors can be applied to advantage.  To keep your primary vendors honest, consult with their competitors, too.  Competitors are quick to point out the shortcomings of your primary vendors.
  • The Web:  While we all know that not everything published on the web is true, much of the info is real and trustworthy, especially from independent organizations such as universities.  Trade publications are more unbiased than company product brochures.
  • The World:  You can solicit ideas and solutions from the world.  From simple concepts like a suggestion box on a website to chat rooms and collaboration software, the world can be an oyster farm in your search for pearls of knowledge.  It does, however, require resources to evaluate the suggestions and ideas.  Offering financial rewards for good suggestions, solutions, and ideas can spread the word virally, which may further increase the number of both good and worthless thoughts.  There is also opportunity to recruit new employees from the pool of responders. 

How does this apply to Project Management?

Collective Knowledge can yield useful information from prior efforts for similar projects at other organizations, such as project schedules, cost info, risk management, and other aspects across the 10 PMBOK knowledge areas. 

Posted on: September 29, 2018 12:34 PM | Permalink | Comments (5)

Last Responsible Moments

Last Responsible Moments

By John Herman   PMP, CQE, MPM

Lean Software Development is an agile software approach based on the lean concepts of Value Streams, and the work of Taiichi Ohno, who is considered the father of the “Toyota Production System” and “Lean Manufacturing”.  Using the lean philosophy, Lean Software Development developed six best practices that continue to influence Agile methodology.  The six are:

  • Optimize the Whole
  • Defer Commitment
  • Deliver Fast
  • Eliminate Waste
  • Build Quality In
  • Empower Team Learning

No doubt today’s Agile methods have seen benefit from Lean Software Development, which originated in the early 2000’s.  The discussion of all six best practices is too much for a single blog posting, but I’d like to draw your attention to the second, “Defer Commitment” for a short lesson in agile risk management, and software project methodologies. 

In an earlier blog entry, I discussed Alexander’s Question, and Last Responsible Moments are generally based on those building blocks.  While Alexander’s Question encourages deferring decisions until certain critical information can be obtained or better understood, the Lean “Defer Commitment” states that the best possible solution can emerge by deferring design until the Last Responsible Moment.

The Last Responsible Moment occurs when any advantages of acquiring additional information are offset by potential risks of delaying a decision any longer. 

Note that there can be several such moments within any project or iteration, with aspects of the design and process in opposition to various risks, with overlap and feedback mechanisms also within consideration.  If it was easy, anyone could do it, right?

Thus the Last Responsible Moments, and the practice of Defer Commitment in general, are dependent on solid risk management.  This point is invaluable in any debate regarding the viability of agile methods when unknowns and risks are running rampant, and especially in defense of agile methods from those who are entrenched in Traditional Waterfall software development methods. 

I urge you to continue to evaluate each software project’s methodology based on the project itself, and without any preconceived notions regarding the best approach, until the Project Management team has gathered as much information about the project as it can.  Which is, of course, a Last Responsible Moment.

 

Posted on: January 24, 2017 03:52 PM | Permalink | Comments (5)

Kaizen or Kaikaku?

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.   

Posted on: November 25, 2015 03:14 PM | Permalink | Comments (11)
ADVERTISEMENTS

You can say any foolish thing to a dog, and the dog will give you a look that says, "My God, you're right! I never would've thought of that!

- Dave Barry

ADVERTISEMENT

Sponsors