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?

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)

Donald Rumsfeld and Project Management

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

Posted on: January 07, 2016 11:53 AM | Permalink | Comments (7)

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)

"If God had meant for us to be naked, we'd have been born that way."

- Mark Twain