Project Management


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


Recent Posts

Agile versus Waterfall in Software Projects

Collective Knowledge

Last Responsible Moments

Donald Rumsfeld and Project Management

Kaizen or Kaikaku?

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 (  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)

The QRD (Qualifying Requirements Document)

Every project needs requirements, and requirements need to be documented.  Many projects use a BRD, a Business Requirements Document.  Others use SRS, System Requirements Specification.  Some may use other document names, tools, and/or templates.  So what’s a QRD?

First, let’s make one thing clear - the QRD is just another name for a requirements document.   However, the QRD originates in a different manner than a typical requirements document, and that's why it has a different name.   The QRD is usually prepared by the project team, the people doing the work.   Let’s look at a few scenarios where a QRD might be appropriate. 

In some organizations, business users don’t have time to prepare a formal Requirements Document.  They gain support of upper management, who direct the PM or the PMO to do it.   At this point, you should consider a QRD.  Make sure to call it a QRD to distinguish it from the normal requirements building process.  

Many times, a QRD is based on a white-board JAD session with one or more key business folks, like a Product Owner or SME.   They might draw a process diagram, write down formulas, do high-level design, or even write pseudo-code.  Then, the representatives on the project team who attended the meeting use their meeting notes to prepare requirements, adding in other aspects to the project based on their expert knowledge.   Examples of expert knowledge include data management, infrastructure, technical specifications, security, compliance, legal, and other external interfaces and dependencies. 

The QRD is passed back to the business for their review and approval.  Like other requirements documents, this process could be iterative; the major difference is that the QRD is being driven by the Project Team (or PMO).  You need to be aware that the QRD may be automatically approved since the same people who say that they don’t have time to prepare the requirements document might also not have time to review the QRD.  Oh well, at least you'll have their sign-offs.  

However, if this project is important to the business, they should probably be able to find the time to review their requirements.   If a face-to-face meeting would have better acceptance, do the meeting instead of e-mailing a document.   If the origin of the QRD was a JAD session, then I recommend that the review of the QRD be done in a joint session as well.

In summary, a QRD is a different type of requirements document that is available to the PM and PMO.  The usual case is when the business doesn’t have time for a formal requirements gathering process, and ideas are strewn across a white board in a JRP or JAD session.   The Project Team or PMO prepares the QRD, which essentially says, “This is what we think you told us that you want” People with agile experience may relate to the QRD more easily than traditional project staff.  However, the QRD is not an agile process – it’s more like an ad-hoc process. 

Posted on: September 03, 2015 01:03 PM | Permalink | Comments (1)

"Would you tell me, please, which way I ought to go from here?" "That depends a good deal on where you want to get to."

- Lewis Carroll