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 – Change Management

The topic of change management has taken on a new meaning in many organizations.  The Agile framework mindset is very much a structured embodiment of a system that is foundationed on the dynamics of change.  The issue that I find is that the dynamics of change, in the proper sense, often don’t distinguish between the three main instigators of change being:

  1. Customer stakeholder(s) driven new or modified scope
  2. Internally stakeholder(s) driven new or modified scope
  3. Risk driven scope

On first review of the three instigators, one may conclude that risk driven change, that is to say, change that is captured on the project risk register, may identify customer and/or internal scope change as a risk.  Isn’t risk part of items 1 & 2?  My response to that is that future scope change driven by stakeholders falls into an unknown-unknown which should trigger an amendment to either or both of the Charter’s Statement Of Work (SOW) or certainly the identified and documented requirements for the project.   This is not a risk that can be quantified.   I’ll have more to say about risk management in a future blog post.  In short, a noted risk stating that the Customer or a Senior inter-company stakeholder may someday change the scope is not worthy of considering.  The risk driven change that would be considered are TBD’s in the requirements, optimistic estimates (threats), or pessimistic estimates (opportunities).

Agile framework organizations that have become obtuse via an abandonment of waterfall structured management tend not to formalize change management as it is thought to just be part of the job.  Often the formalization of requirements is thought to be either unnecessary or impossible (yes….I’ve actually had clients that have used this word) on the basis that the requirements are a result of the design; not the driver of the design.  Setting this notion aside for a moment, Agile Project Management must have cost and schedule budgets, well defined goals (i.e. scope), and well defined gating framework to adequately assess progress.  Change affects one or more of these cornerstone triple constraints which will hit the bottom line.  If Agile Project Management is ever to be confused with an environment of organized confusion, then change will most certainly be mis-managed if not entirely missed altogether.

A correctly executed Agile Project Management system will capture a change instigator upon the onset of a change and will document its occurrence, its source, and its circumstances for the purpose of tagging and tracking.  Some corporations use a formalized Change Request (CR) system, which is the first step towards adequate change management control.  The CR, as a standalone change identification is only a first step because it does not immediately identify which Work Breakdown Structure (WBS) elements that are impacted, and does not identify which requirements are added or impacted.  As the CR matures, the change in scope can rapidly infiltrate the working levels such to the extent that daily work scope can prematurely commence the process of incorporation prior to the project’s formal acceptance of the change.

If the CR is a type (1) change (i.e. Customer driven), then an assessment of the triple constraint must be immediately formalized in order to obtain stakeholder buy in.  This absolutely must precede the team undertaking the incorporation process into the tasking backlog or even worse being catapulted to an expedited task status.  The key takeaway here is that the PM must act quickly at the first sign of change to document, contain, assess, and approve or reject the change.

Once the CR is approved, the impact on cost, schedule, and scope must be formally captured.  The WBS must first be examined and adjusted depending upon the scope of the change and the contract type applied.  If the scope change alters the deliverable configuration, then the WBS must change.  If the contract type is Time & Materials (T&M) and the change is via a separate contract (i.e. not an amendment to the current contract’s Limit of Expenditure (LoE)), then the WBS must also change.  I’m always dumbfounded to come across a company’s business model that silo contracts for each incremental change, but it happens.  The PM must be able to organize the WBS to accommodate these situations while being fully cognizant of the ensuing impact that this WBS structure will have on the team performing the work.

In cases where multiple changes (CR)s are being incorporated at the same time, and cost traceability needs to be maintained for each, it may not be necessary to set up a brute force WBS element for each CR under each primary impacted deliverable.  In these cases, the PM can establish clear cost reconciliation by simply tracking low level task completion data and applying the metric time stamp for each completed task as proxy for timecard actuals would have been charged by each team member.  This, of course, will require tasking assignments to be traceable to each CR.  This really should not be a problem if the technical lead has done their planning correctly and is executing in a structured methodic fashion.  The team executes work to complete tasks that are pulled from a backlog created by the Technical Lead.  As far as the accuracy is concerned, the use of the metric time stamps in lieu of time card actuals can be factored based on earned value variances and/or cycle time tracking.  This can be very accurate.

Considering the alternate brute force WBS approach, the PM would have set up separate WBS elements for each CR under each impacted deliverable.  In order for this method to be successful, each team member would need to diligently charge their time to the correct charge number assigned to each CR for each performed task.  This would often result in inaccuracies due to juggling of charge numbers with the added artificial inflation due to rounding (many companies set 15 minute time tracking increments).  Just rounding alone can inflate daily time tracking by 45 to 120 minutes per day per person.

From a work standpoint, the executing team must first create a skeletal draft of the new or modified project requirements change such that all levels of the traceability hierarchy are clearly identified for impact.  Setting the skeleton will permit early start at all levels minimizing the serialization effect.  Each of the requirements are distilled into tasks and sub-tasks, each of which has a predetermined traceability to the CR that instigated the change.  The team can seamlessly accommodate the change traffic even in cases where the change is disruptive to current work in progress due to an alteration of a feature, physical attribute, or performance.  The PM must resist simply dumping a CR on the table and letting the team at it.  This approach is often confused with bureaucratic elimination.  This kind of Project Management is not Agile in any sense, and will likely lead to strong arm tactics like tear gas and rubber bullets to restore order.

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.

Agile Project Management – Earned Value Management

From a business enterprise and senior management standpoint, everything that moves and breaths bears a cost to the company.  Whether the shareholder structure is privately owned, co-cooperatively owned, or publicly traded, the basis of all metrics are monetized in order to be associated to shareholder value.  For projects conducted by the company, earned value (EV) is the metric that is used to demonstrate the value that the project bears to date, as well as the projection for costs based upon the performance to date.

Back in the day when all projects were managed employing a Gantt waterfall methodology, the project manager could easily set up a structured EV model using available tools, such as Microsoft Project, adhoc tools based upon customized spreadsheets, or a combination thereof.  Assuming all of the labor and other direct and material costs were included in the working schedule, then the time phased plan could be baselined, and the tracked actuals and any such execution changes could be updated thereby providing an accurate model of the project roll out.  This approach is still used in some industries, but what I have found is that this linear model system simply cannot accurately plan out a time phased precast detailed activity set over the full scope and duration of the project with any realistic chance of executing within reasonable and acceptable contingency both in cost and time.  Several factors such as ambiguity, overzealous risk adversity, and market dynamics are among the instigators.

Many factors in market, enterprise management, and general stakeholder expectation have changed the playing field so profoundly that the waterfall methodology can not accurately model the detailed activities in the same way that it had classically managed with such success in past generations.  The two things that have remained constant are project fiscal budgets, and market launch date expectations which tend to be fixed at an early stage and are expected to remain constant.

Agile Project Managers must still provide EV metrics using the classical formulas as are still taught and are the foundation of EV measurement as per the Project Management Institute (PMI).  We can still successfully apply linear EV formulas; however, we need to recognize, manage, and account for the dynamic work roll out which is best managed by employing an Agile framework.  What this means is that the EV calculation must adapt a Piece Wise Linear (PWL) model to wrap around the Agile framework.  The EV claim updates (i.e. the Physical % Complete) must be based on objective tangible work/cost performed; therefore, a defined relationship must be set between the task(s) that collect EV claims and the team execution.  Assuming the team is executing under an Agile framework, a translation can be established that will achieve accurate EV claims.  The team does not have to change the way they execute provided they are following a developed workflow and are tracking the assignment and progress of tasks.  There must also be a developed project road map, and a corporate New Product Introduction (NPI) framework setting clear stages and gate expectations upon which the PWL is modeled.   More on these latter two topics will be discussed in future posts.

Agile Project Management – The Product is King

The local Project Management Institute (PMI) chapter, to which I am a member, conducts a Peer-to-Peer Project Management Connect group (P2P PM Connect).  I serve as a co-Champion for PM Connect.  You can find this group on We hold monthly seminars covering a wide range of PM topics.  This month’s seminar topic was “How Product and Project Managers Work Together”.  You can check out the group on Meetup at this link  For this session, we had a joint meeting with the Product Management P2P organized as a slide deck presentation followed by a panel discussion.

One of the questions posed to the panel was “How does the execution model influence the relationship and delineation of responsibilities (i.e. Agile, Waterfall, Scrum-a-fall)?”.  One view presented to this question was that Agile framework, as an execution model, had a negative influence on the relationship because it complicated the roles and responsibilities. There wasn’t a great deal of talk on this particular issue, but my interpretation was that the Product Management panelist, who presented this view, and the ensuing audience comments suggested that Agile’s microcosmic nature provided non-sensible context which led the observers to draw conflicting conclusions.  If this conclusion was reached as a result of their own personal experience, then I can only surmise that their respective company’s Agile execution model is unstructured and open ended.  By this I mean that their work environment is a series of disconnected sprints that focus on the flavor of the moment; hence may or may not work to serve the product goals.

As a panelist for Project Management, I advocated Agile framework as a beneficial execution model. My thinking is that as a Project Manager, we need to motivate the team to visualize the product as King.  In order to empower the team to serve the King, all contributions must align with the product goal.  The product goal, as primarily set by the product owner (i.e. the Product Manager) is the deliverable that composites all discrete work product deliverables.  A well organized Agile model will have a defined traceability to the product goal by way of a documented hierarchy of Epics, Story’s, and Tasks.  Dependencies can not be explicitly visualized, but the daily work must always be traceable to the product goal.

If Agile framework is, in fact, complicating the influence and delineation of Product and Project Management decisions, then I would argue that the agile visualization is exactly what that company needs.  A good visualization shows you what you have done, what you are doing now, and where you are headed.  If Project and Product manager’s don’t like the view, then they need to fix what they see; not blame glasses.

Agile Project Management – Job Management Distortion Field

Picking up from last weeks post on Agile Project Management – Managing the Job, I’d like to focus on the concept of money becoming the central deliverable of the project.  I like to refer to this as the Job Management Distortion Field.  I didn’t really intend this to be a parable to Steve Jobs but, if we were to draw comparison, Mr. Jobs never made it about the money.  It was always about making the world better with his product creations.  The distortion field I’m referring to completely ignores product and market users.  Most importantly it ignores the work; the critical ingredient in the product.  Here are a few of the key signs and indicators that the project has fallen victim to the likes of the distortion field.

Long Term Infinitesimal Financial Detailed Planning

This is a prevalent practice in certain industries that have long New Product Introduction (NPI) cycles and are staunch waterfall centric planning advocates.  Here the level 1 schedules are typically 10,000 to 30,000 line items spanning up to five years.  Each task (some being a single day activity) is time phased and costed.  This is the kind of absurd management philosophy that has led to the complete abandonment of gantt based planning.  With such a plan cast at initial project kick-off, the baseline is set, and the financial time phased plans are imported into the Enterprise Requirements Planning (ERP) system.

Annualized Budget Alignment

With the multi-year planned down to ten to thirty thousand tasks, the job and financial expectations get extracted in a similar way that the media would extract incriminating phrases out of context.  This methodology perpetrates fairly rigid annul financial gates.  To jump back to the product and work world for a moment, will the dynamics of the work environment follow this detailed roll out?  Well, not to bloody likely!  The reality of late and changing requirements will almost immediately reshape the intermediate milestones which will most certainly change the annual financial targets and actuals.  This is the classic plan to fail mentality.  As much as it’s not being said, this is clearly setting money as the deliverable.

Scope Change without Re-Baselining

This is a favorite pet peeve of mine.  A scope change, by standard project definition, is a change outside the control of any Work Breakdown Structure (WBS) element.  For those projects being managed as described herein, management will acknowledge the need for change in the form of an approved growth to time and/or cost.  For change cause within the WBS overall structure, the project contingency absorbs the effect but, for cause outside the WBS the budget and timeline must be re-baselined.  This realignment is absolutely essential to apply earned value metrics to the work.  In my experience, the distortion field doesn’t recognize this impact thereby continuing to set financial expectations to the baseline.

Short Range Outlook Financial Management

This practice is one of my favorites.  Essentially Short Range Outlook (SRO) planning is likened to driving in the rear view mirror.  In these planning sessions, senior management will hedge bets on future spending based on past financial performance.  Considering that the baseline is completely out of step with the work (i.e. approved scope change without re-baseline), then SRO management exponentially distorts the project.  The hedging doesn’t consider scope change or work as it is focused solely on money as the deliverable.

Resource Fill Rate Management

Resource fill rate is a manpower tracking metric that is used in Job management to hit enterprise level targets.  It is obviously important for the enterprise to supply the project demand but the distortion field effect completely ignores the work execution which is synchronized to product deliverables; not money deliverables.  Organizations that focus only on the linear Job view the project as a static “turn the crank” mechanism.  The fill rate mis-alignment is a self fulfilling prophecy.


These are just five examples of how a project can be completely hijacked when the job financials become decoupled from the work.  As much as the financial metrics are true indicators, they are only accurate when the plan stays in sync with the work.  When the earned value metrics indicate a misalignment, the ONLY way to remedy the situation and get the project back on track is to manage the work scope and fix the work execution.  The financial numbers will snap in line.  Reversing the cause and effect results in Job Management taking on a form of fantasy management otherwise referred to as managing the optics.