Project Management

Facilities Management

Agile Project Management – Cost & Schedule Integration

It amazes me how corporate processes and general management methodologies can become so polarized considering that all corporations strive to achieve a common goal when it comes to Cost and Schedule.  I believe that it’s fair to say that hitting budgeted costs and staying on forecasted timelines is a holistic statement of truth….not some stereotypical generalization.  I’m not saying here that trade-offs between cost and schedule are in question; but rather that the management of cost and the management of schedule are either not connected at all, or are fragmented across multiple tracking tools and/or multiple departments each having their own systems and processes.  All would claim, hand on heart, that they’re collectively working to a common goal to control cost and schedule, yet are secular in retrospect regarding the interaction between cost and schedule.

The lens of cost management professes that good local performance equates to good program performance.  For those companies that maintain strict financial governess most often have their own independent systems in place that dictate processes and tracking tools that are pushed down to the Cost Account Managers (CAM)s.  These tracking tools don’t deal with nor care about inter-task dependencies, but rather focus on cost allocations that roll up to the correct Work Breakdown Structure (WBS) element.  The correlation to the schedule is either assumed to be coupled, or is loosely coupled via a manual human eye-balling or semi-automated month-over-month snapshot.

The lens of schedule management professes that good Critical Path Management (CPM) equates to good program performance.  For those companies that maintain strict milestone governess most often have their own independent systems in place that dictate processes and tracking tool that are pushed down to the CAMs.  These tracking tools don’t deal with nor care about cost, but rather focus on inter-task dependencies that form the critical path for the project.  The correlation to cost is either assumed to be coupled, or is loosely coupled via a manual human eye-balling or semi-automated month-over-month snapshot.

On a regular cadence, cost and schedule are updated.  Both cost and schedule are in flux as team performance and various change requests are adopted into the project’s deliverable cost and timeline.  Add to this variations in resource demand, and you have yourself a minimum of 4 balls in the air that you’re juggling to keep everything under control.  When cost and schedule management are not managed as a tightly integrated system, the Project Manager (PM) spends a considerable effort manually synchronizing the systems.  The following 10 items must be considered and managed as an integrated cost and schedule system:

Master Schedule Alignment

Whether you’re managing a project in a small or a large company, a master schedule is most often used for planning purposes.  Assuming that this planner is maintained, this schedule may be either a sprawling monster or a more wisely mapped sub-schedule aggregated rollup of all lower level projects or control accounts that comprise the portfolio.  If you’re dealing with the sprawling monster (i.e. 10,000 + line schedule), then you’re likely not entering resources or non-labor costs and only tracking activity To-Do’s.  This practice is not responsible governess as it only tracks the optics of looking busy.  Cost and resource alignment will be a continuous challenge.  Schedule updates must be funneled through one schedule owner who cannot keep up; hence, simply restricts the schedule to a Gantt view of activities.

Calendar Alignment

Corporate calendars can often deviate from the three globally recognized calendars such as Gregorian, Julian, Hindu.  Some companies develop their own to financially align fiscal months to weekend (Sat/Sun)  end dates.  This changes the working hours per month which changes the resource loading numbers. This will directly impact cost and resource demand, but will not translate into schedule planning when the systems are not integrated.  One way to ease this problem is to create a custom calendar so that your resource planning entered into the schedule will have an improved alignment to the costing world.

Resource Management

Corporate resources must be managed closely in order for a project to be successful.  When resource demand is tracked on its own separate from schedule, then miss-steps will almost certainly occur.  If this planning is separated from the schedule, then it is often driven by the derived cost tracking which cannot possibly supply the team dynamic demand.  Throughput management which is entirely managed on the schedule is underpinned by resource supply and demand. Any corporate process that separates resource management from schedule management is doomed.  This is fundamentally why CPM has been regarded as the nemesis of successful project management.  This has led to the incorrect conclusion that Gantt methodology cannot be applied to an Agile Project Management strategy.  This is an incorrect conclusion.  Gannt methodology depends upon cost and schedule integration.  Unfortunately CPM has classically not incorporated thorough resource visibility.  This is where Critical Chain Management (CCM) kicks in, and is a key ingredient to holistic Agile Project Management.

Daily Dynamic Management

Resource management is a key Segway into a complete and full understanding of dynamic management.  Dynamic management is much more about what needs to be done and in which order things need to be done.  Cost and Schedule management ensure that dependencies and resources at a tracked deliverable level are in place.  What the PM does with the resource(s) is not to be visualized on a project schedule; hence, the sprawling To-Do waterfall approach can only work if the PM’s crystal ball is perfect.  Unfortunately many organizations have abandoned cost and schedule management and replaced it with agile framework.  Agile Project Management cannot afford to be cost and schedule agnostic by simply advocating a propensity to an improved Getting Things Done (GTD) framework.

Change Management

Managing change is part of all projects.  Change always impacts the triple constraint in some shape or form.  Cost and schedule management never escape the wrath of change.  Driving change into a project without integrated cost and schedule will certainly become disheveled to the point that after a number of changes you won’t even recognize the project.  All changes must be captured in cost and schedule even if it is determined that a particular change can be absorbed.  In almost all cases, change does impact cost or schedule.  If, for example, schedule is changed and cost is absorbed, it still changes the cash flow.  When cost and schedule become decoupled, then the CAM or PM has two independent trackers to change.  This is not productive and will certainly lead to errors.

Actuals Reconciliation

The collection of actual costs is important in order to process how the project is proceeding.  If done correctly, the monetization of work effort is one data point that can provide the PM with an indication that claimed progress is making sense.  The more objective the reporting, the better these metrics will provide a good source of input.  In order for the CAM or PM to fully understand if they have the fuel to finish the job, the actuals reconciliation is important.  There will always be a variance; therefore, keeping track will keep the runway we planned for in check.  As we show variances, the runway either shrinks or grows.  Its also a great way to poke at the schedule performance.  This is important to determine the true amount of safety that was embedded into the estimates from the get go.

Cost Indexing

Cost indexing is the time cost of services due to inflation.  On long multi-year projects, the cost for the same level of service is higher in the future.  This being the case, schedule delays increase the cost of the services.  This is important because the delay of work to a later time period will increase the cost even if the scope of service is exactly the same.

Annualized Cost Management

As part of the fiscal responsibility, corporate governess will often lock down expenses within a given fiscal period.  In some cases, this may be micro-managed at a fiscal quarter.  This is a very difficult metric to maintain because project timeline changes will flow across these date lines.  If these reporting periods are very strict, the interim Estimate At Complete (EAC) must be maintained.  It’s clear that financial governess needs this data, but it is unreasonable to expect interim EAC data to be held firm.  There is no way to maintain a realistic timeline management model while pinning down interim fiscal EAC.  The only way I know of is to create time constrained cost buffers at the fiscal dates and simply balance the cumulative cost each reporting period.  This is totally unnecessary and poor use of a PM’s valuable time.  Knowing the fiscal cost is one thing; holding it constant is just fun with numbers.  Finance can adjust their net earnings reports which is a more truthful and responsible financial reporting.

Performance Tracking

Performance metrics at the management level are almost exclusively monetized earned value numbers.  Strictly speaking, these numbers can be managed independent of the project schedule because net present value time phased numbers are derived at the baseline, the performance is often subjective, and the actuals are collected through independent channels.  The intrinsic value of these metrics hinges on three things (1) the earned value model, (2) the degree of objectivity, and (3) that the baseline recognizes the current scope of the project.  As for the EV model, there are two recognized models being (a) %Complete and (b) %Physical Complete.  Model (a) is completely useless because it assumes that the Schedule Performance Index (SPI) is always = 1.0.  This is contrary to collecting metrics in the first place.  Objectivity is very important.  Agile Project Management must insist on only tabulating work product that is 100% complete.  Dynamic management must set a reasonably short cadence in order to stay on top of true performance.  Lastly…if the baseline doesn’t recognize approved change requests, then the earned value system is completely useless.

Enterprise data Continuity

At the enterprise level, the management of cost and resources are aggregated from all project inputs as submitted by CAMs and PMs.  The vehicle for submitting these updates is often what drives the corporate processes for tracking.  Various forms may be created that are either manually updated or are semi-automated with spreadsheets that are maintained by the PM.  This data is then processed, corporate reports are published, and Resource Managers review and/or adjust their staffing and logistics.  The schedule is often not processed at the enterprise level because it is thought to be a visualization of cost reporting.  This is flawed at many levels.  Reporting of performance metrics is a schedule dynamic that is often very subjective.  This being the case, it is no surprise that the realization of cost and schedule overrun is detected too late.  In larger projects, performance is only discussed at higher level rollups, therefore the underlying problems are not caught early enough to be proactively managed.

In conclusion, cost and schedule must be tightly integrated.  Scheduling tools such as Microsoft Project are designed to manage the holistic project including cost, resources, and deliverables.  In larger projects, the Integrated Master Schedule must be an aggregation of sub-projects.  This is true for many reasons.  All approved change requests must be incorporated and a new working baseline must be snapped.  Regardless of what enterprise cost and resource management system is in use, data can be exported from CAM and PM schedules which contain all of the data required to drive the enterprise.  This frees up valuable time for the PM to manage the job as opposed to manage the optics.

Agile Project Management – Task Collaboration

Our Product is Steel…Our Strength is Our People.  That’s a slogan coined by Defasco back in the 1970’s.  Since then, several corporations have developed a corporate focus in their respective mission statements  based on customized variants of this famous slogan.  It’s clear that “the people” form the fabric of any company; therefore, their ability to collaborate effectively underpins the mechanism by which individual contribution is summed up to form the value position of the company. It’d be fair to say that most folks would whole heartedly agree with this statement, and would endeavor to believe that simply putting the right people together will cinch this secret formulation to achieve greatness. When looking at corporate practices, this formulation is often thought to be solely based upon an individual’s core characteristic criteria.  Upon establishing the fundamental characteristics possessed by the individual, such as during the interview process, then a subsequent assessment of the chemistry that exists between individuals (i.e. those working together) form the bonds that produce the “Strength” formula as stated by Defasco in their slogan.

For many companies, the essential collaboration mechanism is thought to be the automatic result of good team member choice in the same way that a great culinary masterpiece is a mere product of the recipe’s ingredients.  This is not to say that a great leader is just another selection along the same lines. There’s no contest or debate on the importance of leadership; hence, the Project Manager’s (PM) role to lead the team successfully (as measured by one form or another of earned value) is highly dependent on the very strength of the people.  The fallacy that can and does trip up the PM is that task collaboration is automatic if the belief is that individual intelligence and interpersonal characteristic chemistry are the only two ingredients.

Collaboration is and has always been thought to be a result of assembling the team at the designated brick & mortar office location. Of course, if you believe in the formulation mentioned earlier, then you’d pretty much have to insist that a project team would have to be collocated in order to have any change of tapping into the strength formula.  The big mistake here is to think that the leadership direction will automatically blend into the team’s membership daily activities in exactly the right balance in order to achieve the desired output.  It has been my experience that collocated teams foster a foundation of tribal knowledge as the basis of their daily execution; hence, tend not to engage in any form of task formalization.  This loose form of collaboration is more of a hindrance when it circumvents the application of a structured framework. In my experience, it is often specific groups within organizations that resist structured collaboration.  These groups will also resist the recognition of task collaboration.  Agile, as a framework, is one of the systems being successfully implemented that augments the intelligence ingredient creating an even more powerful library of tribal knowledge.  When applied in conjunction with currently available technology, this powerful collaborative environment minimizes the collocation “curse” in that it enforces a much more succinct form of communications in the form of written comments in place of in situ conversation.  Having a permanent record provides all members of the engaged team the benefit of the conversation thread.

Agile Project Management is the management of the full suite of groups forming the wide project team.  Many companies are organized as matrix organizational structure of one type or another, with each functional group having their unique processes.  It is rare to find a case where the wide team contributors from Sales, Marketing, Finance, Manufacturing, Quality, Technical, etc are of a unified vision or mission in regards to the project.  Each of these groups will operate in their own circles using their own processes to collaborate amongst themselves. In larger organizations, these various group are often not collocated and have several ventures on the go at the same time.  As human resources to the project are essential, it is critical to ensure that task collaboration is managed across the entire project.  Task management must be proactive, which means that all contributors must primarily contribute by way of producing task results in the form of tangible deliverables. This must start by recognizing these deliverables on the Work Breakdown Structure (WBS).  Effective collaboration is both an open forum general communications as well as planned time correlated communications.  As a PM, a key ingredient for successful task collaboration is to structure the known issues (i.e. write them down in the form of Epics and Stories) and plan for the communications in a sensible coordinated fashion.  This is especially important for fractional team members because you likely will not have impromptu access to their undivided attention on an unstructured basis.

In conclusion, successful task collaboration must accommodate and take advantage of the strength of the people.  Considering that several distinctly different disciplines are involved in most projects, the PM must recognized that one size does not fit all.  A delicate balance of planning the high level “big rock” tasks (Epics and Stories) early in the project is the right thing to do.  Trying to sequence every last detail early in the project is not productive and almost always leads to contention and wasted effort.  Agile Project Management plans for the boundaries upon where the team can effectively operate, and plans for handling dynamics as opposed to predicting the specifics of the daily battle.


Agile Project Management – Project Kick-Off

Project Kick-Off is more often than not treated as a joyous announcement to the organization and the Stakeholders that a project is recognized from this day forward as official.  There might be a catered meeting call, and a few words of encouragement about the project goals or the diligence of the business team to sign an agreement with a key customer.  The intent and purpose of the event usually stops there often having been an adhoc impromptu announcement notice with little forethought or planning to actually get the project started.  A Kick-Off announcement is often thought of as a call to pull out the golden scissors to cut the ceremonial ribbon on a newly signed contract; hence, the event is actually denoting a completion of a phase as opposed to the beginning of a project.  The Project Manager (PM) often receives the meeting invite at the same time as the wide team and stakeholder’s; therefore, the PM is just an attendee and not the organizer of the Kick-Off of the project.

It is very important that the PM gets out in front of the Kick-Off event to ensure that the project is fully ready to go green.  This means that preparations are completed prior to the Kick-Off event to ensure that the following key metrics are clear and are underpinned by a specific plan:

  1. Team Assignments
  2. Recognized Stakeholder’s
  3. Project Deliverables
  4. Key Performance Indicators (KPIs)
  5. Key Milestones

These five metrics are not the complete list, but do represent a foundation for the announcements that are advertised at the Kick-Off event.  In order to publish “public domain” summaries for each of these metrics, a decent straw man plan must exist in order to build out the detail of the project.  The last thing that a PM needs is to attend a meeting like this to find that the Senior Management Team (SMT) or the designated Product Manager (PdM) makes statements about these metrics based on wishful data that they may have just pulled out of their ass.  The PM must get out in front of this by setting a clear standard for the kick-off.  The best way to do this, is to have a check list that is endorsed by the key stakeholders.  The artifacts prepared by the PM (and his designates in the case of a larger project) must be complete and agreed upon by the stakeholders in order to have a unified and clear goal, and that the expectations are in line and achievable.

From an Agile Project Management standpoint, the execution of the project must be clearly tied to the structure developed for the kick-off.  The short term team engagement in the project may be limited to assigned team leads and system planning in order to ensure that the requirements and expectations are derived into language that the team can understand at an execution level.  The Work Breakdown Structure (WBS) must be defined prior to the kick-off, and must be deliverable centric as opposed to a project organizational chart or an activity chart.  Item number 3 above is the high level presentation of the WBS.  This not to say that every last WBS element is finalized, but must be built out sufficiently to validate budgeted metrics.

Is the kick-off the all-call for the wide team to jump to action?  Absolutely not! The wide team cannot jump aboard the project as if it were a cruise ship leaving port because the plan will not be mature enough to direct the low level detail.  The team leads must first distill the straw man plan.  Even at the best of kick-off preparation intent, the detailed tasking backlog preparation will be performed immediately following the kick-off; not prior to kick-off.  The kick-off preparation must focus and limit the planning to a high level sufficient to structure execution detail laid in thereafter.  In short, the kick-off needs establish structure and does not need to be nor should ever be a detailed playbook for immediate execution.  The best way to gain a clear understanding of a project kick-off would be to document the expectations and to establish the check list so that the right level of detail is undertaken.

Agile Project Management-Requirements Management

Requirements Management is one of the most mistreated and misunderstood knowledge areas in Project Management.  In my professional practice, I experience the full spectrum of functional requirements management  styles and opinions.  In most cases, client’s will make their best attempt to extract some form of written requirements at the onset of a project to put some shape on the estimates for the job (for lack of a deeper purpose).  These written requirements are more often than not just published on a project wiki page, and are often open ended statements that are indistinguishable from a stakeholder expectations log.  This “publication” is often a onetime posting that is not maintained throughout the project cycle.  This practice is very prevalent among the clients that declare they are operationally “Agile”.  At the other end of the spectrum, clients who operate in industry sectors demanding regulated product assurance standards elaborate and formally release requirements documents, but fall short when it comes to adequately managing these requirements.  This practice is very prevalent among the clients that declare they are operationally “Certified” in accordance to their respective regulatory standards.

For many of the self-proclaimed Agile clients, they are really using the word (agile) to distinguish themselves from the other end of the spectrum.  They tend to refer to written requirements as the nemesis of dynamic creativity; hence to formally commit to such a written list would completely limit the final product.  This is a completely distorted view of agility and is completely misaligned to the practice of Agile Project Management.  The ability to be truly agile is to be open to change and to manage change in a structured fashion.  Requirements form the frame upon which the final deliverable(s) is structured.  Having these requirements documented in a way that facilitates a visual mapping breeds creativity.  This mapping, when correctly structured, forms the basis of the epics and stories which are the foundation of the agile framework.

As for the other end of the spectrum, documented and formally released requirements are more often than mismanaged because of the following reasons:

      1. Incorrectly or completely uncategorized listing of singular statements
      2. Buried or nonexistent traceability to lower tier requirements and specifications
      3. Loose or nonexistent relationship to ancillary applicable documents
      4. Loose or nonexistent relationship to derived requirements (orphans)
      5. Loose or nonexistent relationship to formalized change orders
      6. Loose or nonexistent relationship to deviations and waivers
      7. Loose or nonexistent management of TBD’s and TBC’s
      8. Loose or nonexistent relationship to stakeholder expectations
      9. Uncontrolled dissemination of requirements change to the wide team
      10. Incorrect connections to the Risk Register

Believe it or not, I see all of these key violations in the high reliability sector. I have listed the association to the Risk Register last because it is both a reason and a resulting case of collateral damage.  As I have mentioned in previous blog posts, risk adverse clients transfer these issues into risk, and proceed to claim hold harmless status thereafter.  This happens because the Requirements Management Plan does not address how to handle these issues.  The management of requirements is simply transferred to the Systems Management Plan, and the Project Manager completely lets go of this critical part of overall project leadership.  This is real mistake on many levels.  At the top of the list is the impact on Change Management.  I have yet to experience (going on 30 years in this business) a top level requirements document being “static” and not subject to change.  The requirements always change.

Agile Project Managers must take charge of Requirements Management.  There is a distinct segment of the defined responsibilities in the execution of requirements management that falls into the Systems Team’s scope of control.  Certainly capturing, clarification, and interpretation of customer requirements clearly falls into the Systems domain.  This must include clearly derived TBD’s in lieu of customer’s future clarifications.  In cases where the stated requirements are on the light side, (the “Agile” case I mentioned earlier) the Project Manager must endeavor to back fill these requirements with stakeholder expectations and derived requirements in order to set a clear and complete visualization for the team.  This must be defined and well-rounded prior to kicking off the project.  All work effort and non-labor spend during execution must clearly tie back to the requirements.  This definitely must be a section in the execution playbook because the requirements visualization is the hitchhiker’s guide to the galaxy®.  All successful teams rely on a strong playbook!


Agile Project Management – Risk Management

Risk Management tends to take on one of two states in most companies, and as you may suspect are polar opposites.  There are the risk adverse who are fear centric, and the risk oblivious who are….. well just oblivious.  Both of these operating states are very common in my experience.  Based on my own client experiences, I have only come across about 3 or 4 out of 10 clients that have a healthy view of risk in that they recognize the value of good risk management and actively engage all levels in the corporation in risk awareness.

Let’s start with a top down view of a project from the standpoint of metrics and look at how risk may impact each.  At the highest level, the triple constraint evaluates three cornerstone aspects which holistically defines a project and establishes a scalable interaction between the three constraints.  These constraints are:

  1. Scope
  2. Time
  3. Cost

Scope Identified Risk

Scope identified risks should be the easiest to define if the Program Management Plan has a well-defined Scope Management Plan section and a well-defined Scope Baseline.  The risk of a scope change can thereby be restricted to To Be Determined (TBD) or To Be Confirmed (TBC) requirements that were loosely defined at the onset of the project.  This statement may draw some rebuttal, but please read on.  It is understood that the Statement Of Work (SOW) will not reasonably capture all explicit requirements that clearly define all deliverables; however, the derived requirements that were defined by the proposal team form part of the project requirements.  These additional requirements must be clearly stated and captured as part of the official input to the Project.

Time Identified Risk

Risks captured to identify impact to timeline must distinguish a specific tie to schedule.  These are sometimes difficult to distinguish separately from cost, therefore are often combined.  In some cases, the risk may identify a third party service or deliverable that may drive out schedule.  Availability of key resources, or an underestimation of due process could also be fair game here.  Another example may involve a multi-prong development of design options in order to hit specific recurring cost targets.

Cost Identified Risk

Risks captured to identify cost can identify either/or specify costs to execute the project or cost targets for the deliverable in cases where either the expectations or requirements specify this parameter.

Define a Corporate Risk Register Template

When constructing a risk register, there are both guidelines and rules that must be applied in order to build a purposeful risk management process.  Developing a corporate risk register template is very important in order to develop consistency for effective and efficient collection of contributions, ongoing management, and portfolio comparison evaluation.  A risk register must provide a qualitative assessment of project risk.  Qualitative assessment involves two main metrics to establish the probability and impact of each stated risk.  These two main metrics influence cost and/or time against the deliverables defined in the Work Breakdown Structure (WBS).  Each risk will define an Unfactored Cost which sets a Rough Order of Magnitude (ROM) amount.  The Probability defines the likelihood, and sets the calculated Factored Cost amount.  The Impact is a scaled number to categorize the severity of change which usually plays out as a timeline and/or deliverable configuration change.  The risk register must capture a clear impact statement to define the WBS element that is impacted.  In the event that a given risk is realized on a project (i.e. the probability increases to 100% or a pre-set corporate threshold), then this risk is incorporated into the project baseline through a Project Change Request (PCR), and is thereby entirely or partially retired from the risk register.  It is very important that a well-defined identification tagging is established.  In short, here are the minimum recommended risk register fields that need to be identified:

  • Risk ID
  • Risk Title
  • Risk Description
  • Update Date
  • Estimated Start Date
  • Estimated Expiry Date
  • Owner
  • WBS Element Affected
  • Probability
  • Impact
  • Unfactored Cost
  • Impact Breakdown Definition
  • Risk Strategy (ex. Watch/Mitigate/Accept/Transfer etc)

Define Allowable Risk Rules

As far as rules are concerned, the most important rule is that all captured risks must be clearly outside the risk owner’s scope of control.  As a secondary caveat, the risk should also be approved by the Project Manager (PM) before it is officially logged on the risk register.  Another rule that must be established is regarding the category of risk allowable for the formal risk register.  There are three categories of risk as follows:

  1. Known-Known Risk
  2. Known-Unknown Risk
  3. Unknown-Unknown Risk

The first category entails risks that the team knows exist and also knows or has evidence of the existence of that risk.  An example of a Known-Known may be the availability of an internal resource that is conflicting with a known higher priority company project.  Another example may be a foundation development tool that has a known bug that affects the quality of the supplied results.  Known-Known risks are valid.

The second category is likely where most risks will be documented.  These risks will identify challenges in achieving the requirements as defined.  Likewise, the risk register also captures opportunities which would represent the converse situation for a given risk description.  Let’s say that a requirement states a specific performance parameter that is assessed by the project team as over-stated.  If the project is structured to meet operability, then an opportunity could be captured to allowably relax that requirement.  If the cost/time is tight, then it would be captured as a risk. Known-Unknown risks are also valid.

The third category of Unknown-Unknown risks must be avoided.  These types of risks are more often than not based solely on fear and are always situational circumstances that are above the proposer’s pay grade.  The PM must handle proposed risk that falls in this category delicately because team members that identify with these types of stated risks often lack confidence in general.

An important rule is required to set boundaries and thresholds for total risk and individual risk dollar amounts.  There must be an established total risk budget.  For risk adverse companies, the risk register can easily tally up a budget that can work itself to a high percentage of the overall originally estimated project cost.  Individual risk thresholds must be established to ensure the most appropriate strategy is applied.  For example, it should be unacceptable to carry a high value risk as a Watch strategy.  These must be Mitigated and should have a fully developed quantified plan in place that is invoked when the probability trips a pre-determined threshold.

The last rule to set is the cadence for Project Risk Review.  Depending upon the size of the project and the dynamics, the risks must be formally updated to ensure each are current, and that the dates and assessed metrics are correct.


In conclusion, a company must develop a Risk Management Plan that objectively sets a conforming standard by which the risk processes are executed. All too often companies fall into one of the two polar opposite regimes I mentioned at the beginning of this blog post.  Fear based risk management can provide the optics of risk management control, but are easily invalidated if the proposed rules are applied.  As for the risk oblivious, the definition of Agile Project Management may need to be evaluated.  Agility and Risk Management are two essential ingredients to any successful Project.

Agile Project Management-The Curse of Panic Driven Processes

Panic, mayhem, and anarchy are three of many terms that are often associated with Project Management.  Some corporations seem to perpetrate these traits as a statement of leading edge, customer responsive working environment accolades.  I have even seen job posting referring to these as adjective descriptive words in the running list of candidate qualifications.  What this says to me is that panic is the expected mode of operation, and that the Project Manager (PM) role is to primarily orchestrate and repackage this bundle of negative energy into something useful.

I have titled this article as Agile Project Management because this workflow framework is often thought to be a best fit to such a workplace that operates in a panic regime. I see Agile framework as more of a remedy to panic as opposed to being co-aligned to a development environment that is fueled by negative energy.  Waterfall framework managed projects are also afflicted with panic, and are likewise expected to incorporate the panic de jour with minimal (actually zero) impact on cost and delivery.  The point is that chosen framework is not the issue when dealing with panic.  Panic is an individual and organizational behavioral phenomenon that must be well understood and effectively managed in order to be successful as a PM.

The term Agile Project Management is much more than a framework and methodology associated with the logical structuring of a backlog of tasks into sprints tracked by metrics indicating progress.  The agility that a PM must possess are largely acquired soft skills to understand and eventually master individual and organizational psychology to calm and ultimately proactively manage panic.  The starting point is to realize and embrace the knowledge that reality is a physical manifestation of what an individual believes.  If the PM believes and more importantly dwells on panic, then panic, mayhem, and anarchy will certainly be their reality as this will very efficiently and effectively manifest.  From an organizational standpoint, this will spread like a viral agent affecting almost all that it touches.  A pandemic rapidly develops and can become the normal state of operation.  This can become chronic when the corporate mentality re-brands this into a distorted statement of a desirable mode of execution.

Here’s a simple technique that a PM can immediately implement to deal with a panic pandemic.  This technique is purported from a technical electronic signal noise management methodology.  When dealing with undesirable noise energy infiltrating a signal processor, there are three different management methods to consider:

  1. Avoid the noise source.
  2. Develop shielding from the noise source.
  3. Redirect the noise where it doesn’t harm the signal processor.

Let’s consider, for a moment, that the noise source is a key stakeholder, and the noise is a new or modified feature (i.e. scope creep).  Going down the list, we quickly see that option #1 can’t be applied in this case because of the stakeholder’s importance.  Option #2 is kind of like a quarantine method which means you (the PM) recognize and value the input, but are going to hold it in the backlog and deal with it later.  This may work, but if it happens to be made known to the team, and the team thinks it’s cool, then this technique won’t work very well.  Option #3 can be considered in cases where #1 and #2 don’t fit the situation.  The “redirection” is a workflow that you have defined to actively develop these kinds of adhoc additions.  By doing this you insulate the team from the diversion, and assign specific individuals that are separate from timeline critical workflow tasking. These would be team members who can effectively and confidently operate in this domain.

This is a simple example.  The point here is that building some techniques proactively completely change the individual psyche which ultimately projects cool confidence.  That’s what we want to spread across the team.  The bottom line is that individual behavior management is where it starts.  The PM needs to develop masterful skills on self before organizational behavior can be effectively managed.