Project Management

Facilities Management

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 – 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.

Summary

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.

Blending Waterfall and Agile Presentation

Blending Waterfall and Agile

In my role as Champion at our local Communitech PMI Chapter, I jointly planned our 2015 / 2016 season seminar topic series with my two co-Champ compadres.  The topic of blending Waterfall and Agile was the logical kick-off point given it addresses the needs of the holistic enterprise.  The follow up 8 presentations comprising our annual seminar series focused on visual management, corporate cultural change, work flow modelling, and stakeholder management.

There is a fair bit of momentum within the corporate culture at many organizations to adopt agility and lean practices  as they frantically strive to remain competitive.  This pursuit affects both large and small; mature and startup companies alike.  More often than not, what I experience is an emphatic disdain for the Waterfall planning and management model; hence, the immediate reaction is to completely replace it with an Agile framework.  I have also observed that the Agile model is perceived to eliminate the overbearing and wasteful planning allowing the team to get onto the “real” work sooner.

To quote Dwight Eisenhower “In preparing for battle, I have always found that plans are useless, but planning is indispensable”.  So…to translate into Job Speak, the sequential waterfall plan is not a view of the battle; its the map of how to win the war.  Last check….maps are still King!

I have attached the slide deck I prepared and presented at our chapter monthly seminar in October 2015.  In looking at the pursuit of a product or service delivery, from a holistic point of view, there are three corporate players each having their key indicators that underpin the mantra of their existence.   Of the key indicators, I have identified the critical indicators.  The central focus of this presentation is to align indicators to each of the Waterfall and Agile framework models to establish a best fit.

Please have a read through of the preso. I’d love to hear your feedback