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:
- Customer stakeholder(s) driven new or modified scope
- Internally stakeholder(s) driven new or modified scope
- 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.