It has been almost a year since I wrote on “Efficient Project Management”,[1] and so I decided to revisit the topic of project management, but with a different approach.  That September, 2011 article focused on a broad overview of project management, or the big picture.  This time, I will look at 2 (“two”) specific models – namely the Stage Gate Project Management Model (as ideally recommended for Information Technology-enabled projects), as set-out by the Treasury Board of Canada Secretariat, in 2010,[2] and the “DILIGENT” Project Management Model, as sometimes used by S’imprime-ça (Strategic IMPRIME Consulting & Advisory, Inc.).  I will attempt to show how these models follow parallel paths, or can be melded as or into one model.


Background on the Stage Gate Model:

The Office of the Auditor General of Canada had issued a November, 2006 Report that identified 3 (“three”) main reasons that had consistently contributed to the failure of large, IT-enabled projects.  These were (i) “Project conception that results in unwise approaches”; (ii) “Unsupportive project environments that contain barriers to success”; (iii) Project participants who lack the necessary qualifications or experience for IT-enabled projects”.[3]  These reasons are, in my opinion, equally applicable to non-IT-enabled projects;[4] and I addressed these three shortcomings, under different guises, in the September article at: Getting to Landmarks (covering these points i and ii, here), and at Optimizing Outcomes (covering these points ii and iii, here).  Motivation (Indoctrination) also has a key role in avoiding all 3 (“three”) of these shortcomings.

I must here state that I do not agree with overly-rigid analyses or typologies that find one stage finishing before another begins.  Everything overlaps due to the fluid nature of projects, later realizations of the need for changes after work on an element, section, or phase[5] was supposed to have been completed, whether for changed specifications from a project authority, new security requirements or last minute enhancements to intended functionality, unforeseen complications in the task (excess rain or ground that is too hard or too soft and requires shoring or heavier coring), or faults tracked to workmanship or source materials – all “Change Orders.”  This does not even encompass multiple re-writes of (apparently) Final Reports or discrete sections of Final Reports when budgets are depleted, or project staff ready to move-on/just moved, to the next opportunity.

There is always a potential, sometimes high and sometimes low, for major sectional overlap; with one gate half-open whilst another is half-closed! The “project steamship” has no such watertight compartments and so must be guided through the waters with great skill and diligence.



Additional reports and committee work led to the implementation of the Stage Gate model and independent reviews as a way to better and more consistently ensure proper project delivery.  Essentially, then, “[a] gating framework defines points during the life of a project, from the early concept to post-implementation phases, when executive management carefully considers the project status and grants approval to proceed to the next decision point or “gate.”  Early project examination is especially crucial.”[6]  In this way, gatekeepers retain firm project control.  In addition and as stated in the TBS guide: “Project gating is most successful when used hand-in-hand with independent project reviews.  These are critical assessments of a project conducted by experienced and qualified people who are at arm’s length from the project.  A defined gating process clarifies when reviews should be performed and which issues should be examined at those points in time, while still allowing flexibility for ad hoc or “health check” reviews.  Independent reviews are most helpful when they are timed to provide assessment immediately before a decision is required at a project gate, thereby supporting the gating process.”[7]


Essence of the “Stage Gate” Model:

This, then, is the rationale behind the gating process over a Project Life Cycle (PLC) or a Systems Development Life Cycle (SDLC), as applicable.[8]  In practice, there are 7 “virtual” such gates,[9] as follows:

Gate 1: (Strategic Assessment, and Concept);

-what is to be done, and why.

Gate 2: (Project approach);

-assessing plan feasibility and its fitness for the task.

Gate 3: (Business Case and general readiness);

-how it is to be done.

Gate 4: (Project Charter/Project Management Plan);

-clarify roles, oversight, approach, deliverables, and solutions for risks.

Gate 5: (Detailed project plan and functional specifications);

-RFP (Request for Proposals) issuance stage; contract award stage.[10]

Gate 6: (Construction, complete, and deployment readiness);

-deployment readiness, pilot deployment, full deployment

Gate 7: (Post-implementation review).[11]

-complete contractual obligations, deliver close-out report, assess lessons learned.


Essence of the “DILIGENT” Model:

The DILIGENT model, for its part, has 8 virtual phases, named by the first letter of the first word, of each line item.  These are:

  1. Determine objectives;
  2. Identify Project actors (both at the project authority and on the project);
  3. List roles;
  4. Impose priorities and timelines;
  5. Gather Team Leaders and meet; assign functions;
  6. Enact the project;
  7. Note and implement changes and adjustments in the above, as needed;
  8. Take stock of lessons learned; report on the project and on those lessons learned.[12]



In the Stage Gate model guide, the description of Gate 5 (Detailed project plan and functional specifications), refers to it as the RFP issuance stage, or the contract award stage.  This may seem odd to some, as appearing late in the sequence of only 7 Gates.  However, DILIGENT can also be read in a similar way, with the second “I” (impose priorities and timelines, or Stage 4 of 8), holding the same status.  In a very large or very complex project, a great deal of time and effort goes into setting the scope of the project, listing deliverables with great specificity, and stating the preferred bidder qualifications (both the mandatory and the desirable).  Once the project authority has received and evaluated the top “responsive” submissions (i.e. that hit all the right points), then they can make a decision based upon price, experience, or some other criteria or formulae.  With minimal additional negotiation needed, team leaders can meet with specific functions to be assigned (under the DILIGENT model) or the construction and installation or piloting of a solution, can commence (under the Stage Gate model), all being subject, of course, to such agreed-upon contractual checks and balances and additional reviews, as applicable.



Going back to the realization that the start and end of a stage on many a project is hardly fixed in time or place, we can meld or “de-conflict” these 2 models as follows.  I will refer to each model by Gate and by letter, for ease of reference and the avoidance of confusion.

The “D” (determine objectives), can actually be said to cover and capture Gates 1, 2, and 3 (Strategic assessment and concept; project approach; and business case and general readiness).

Whilst that first letter progresses, subsequent letters will start to come into play with the first “I” (identify project actors), “L” (list roles), and the second “I” (impose priorities and timelines), being spread-out to cover and capture Gates 3, 4, and 5 (with Gate 4 being the Project Charter/Project Management Plan, and Gate 5 being the Detailed project plan and functional specifications).  As stated under “Parallels”, the work can now begin on a larger or more complex project, at Gate 6 (construction complete and deployment readiness) or letter “G” (gather team leaders and meet; assign functions), as applicable.  In other and smaller or less complex projects, that work towards project deliverables will have already been well underway.

The “G” and “E” (Enact the project) essentially cover and capture Gate 4, 5, and 6.  We here include the Project Charter, Project Plan, and actual construction or deployment so as to account for those Change Orders that can both arise from and impact upon, any and all of these 3 Gates.

Similarly, “E”, “N” (note and implement changes and adjustments in the above, as needed), and “T” (Take stock of lessons learned; report on the project and on those lessons learned), cover and capture Gates 5, 6, and 7 (Post-implementation review).  The letters must all be taken, grouped, and treated together because both “N” and “T” are pertinent to “G” and “E”.

They are also together because of the need for clear, accurate, and consistent project documentation – in Change Orders and their rationales; in original and updated work specifications; in lessons learned; and in the project Final Report.  Where and when project documentation lacks these qualities, some important detail will almost inevitably be missed.



Simply put, the Stage Gate model is also the DILIGENT model, and just answers to both names.

The former has been task-built for large IT projects, but retains some flexibility, through lighter variants, for smaller and less complex projects.  The latter, applicable to projects of all sizes, parallels the former, and also specifically allows for the inevitable overlap in project stages as the pace ebbs and flows.  Both are useful, tried and tested, and effective approaches; but a project authority may always mandate one or the other, or any additional model they feel fits the mold.

En tout cas: to each their own!!



Ekundayo George is a sociologist and a lawyer, with experience in business law and counseling, diverse litigation, and regulatory practice.  He is licensed to practice law in Ontario, Canada, as well as in New York, New Jersey, and Washington, D.C., in the United States of America (U.S.A.).  See, for example:  An avid writer, blogger, and reader, Mr. George is a published author in Environmental Law and Policy (National Security aspects).

Mr. George is also an experienced strategic consultant; sourcing, managing, and delivering on large, high stakes, strategic projects with multiple stakeholders, large budgets, and multidisciplinary teams.  See, for example:

Hyperlinks to external sites are provided to readers of this blog as a courtesy and convenience, only, and no warranty is made or responsibility assumed by either or both of George Law Offices and Strategic IMPRIME Consulting & Advisory, Inc. (“S’imprime-ça”), in whole or in part for their content, or their accuracy, or their availability.

This article does not constitute legal advice or create any lawyer-client relationship.

[1] Ekundayo George. Efficient Project Management: There is an “I” in Team.   September 11, 2011.  Online: >><<

[2] Treasury Board of Canada Secretariat (TBS).  A Guide to Project Gating for IT-Enabled Projects.  2010. Online: >><<

[3] Id. TBS at page 2.

[4] Supra note 2, TBS at page 4.  “An IT-enabled project is a project that has an IT component that is critical to achieving the intended business outcomes.”  Examples include: (i) implementation or modernization of program delivery; (ii) implementation of systems and databases; and (iii) implementation of internal administrative processes and systems.

[5] Id. TBS at page 6.  “A project phase is a period of time during which a logical grouping of activities will be performed and deliverables completed and approved (deliverables are tangible, verifiable work products).

[6] See supra note 3.

[7] Treasury Board of Canada Secretariat (TBS).  A Guide to Project Gating for IT-Enabled Projects, at page 3.  2010. Online: >><<

[8] Id. at page 8.  Admittedly, a number of recommended best practice caveats accompany the gating process, namely that: (i) projects only be stopped where “there is little or no possibility of attaining intended outcomes with the current course”; and (ii) projects only be interrupted and restarted if “a fundamental change in approach is required”.  In addition, the Treasury Board of Canada Secretariat Guide does seemingly attempt to prevent micro-management and artificial delays by stating that “[c]are must be taken to ensure that routine project management decision making is not delayed pending the outcome of formal executive-level gate decision meetings.”

[9] Supra note 7 at page 13.  In addition to the full 7-gate model, an abbreviated version presents 3 gates (Business Case, Pre-Construction, and Post-Implementation); and an intermediate version presents 5 gates (Approach, Business Case, Pre-Construction, Pre-Deployment, and Post-Implementation).

[10] Supra note 7 at page 21.

[11] Supra note 7 at page 11.

[12] Courtesy of Strategic IMPRIME Consulting & Advisory, Inc.  online: >>;

%d bloggers like this: