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