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 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-Managing the Job

Last week, the topic of my blog post was an introduction to Agile Project Management, where I introduced the idea of duality between managing the “Job” and managing the “Work”.  Today, I’d like to look a little closer at the Job to examine the key distinctions that differentiate the two and how this aspect can take on a life of its own.

In a pure sense, the Job should be a small case version of a portfolio consisting of several work package elements.  The Project Manager (PM) fulfills the role of Task Master guiding the larger team, individually driven by Leads and Scrum Masters, towards a common goal.  Using a locomotive analogy, the project is a train consisting of a string of connected cars on the same track (ideally) heading to the same destination (a common goal).  The PM must effectively keep the train on schedule and on budget notwithstanding a few new cars and a couple of extra pick up’s (features) being added along the way.

The Job is always and only viewed through the lens of cost and time on a linear scale.  The belief is that all aspects of the project abide by these metrics; therefore the Work simply falls out (or feeds on) each of these two buckets (money and time).  This fact is the first of a potential series of collective fatal cuts that can cripple a project.  This view of the world makes the project about money and about time as if these completely describe the deliverables.  If the “plan” is reduced to this, then this underpins why plans are useless on the battle field. If money is a deliverable, and adding a feature will deliver more money, then we’d be silly not to do it….right?  Adding another car to the train isn’t as simple as stopping, hooking up, and hitting the gas pedal to get back up to speed.

The regular cadence of Job management aligns with regular senior management and customer reporting.  Here, the PM rationalizes the team performance using metrics based upon monetized work elements for the purpose of assessing earned value.  The PM processes these numbers as a bottom up conveyance of the Work in a way that makes sense to an audience that measures value in a different way than the team doing the work.  While the team is busy executing against the work plan, the key stakeholders are involved in other ventures on behalf of the corporation, market, customer ventures, etc.  Changes in these external events can and do influence the project, often without regard of the general health of the project commitments.  If we reverse the cause and effect relationship, changes in cash or cash flow (caused by some external event) may not be understood to have an impact on the work.  An example of this would be a resource group departmental drive to hit a cost reduction target for a given reporting fiscal quarter so that the high ranking manager can get a bonus.  In order to do this, all you’re being asked to do is rearrange your cash flow for the next couple of months until the new fiscal quarter.  This shouldn’t affect the work….should it??  Sure…if we don’t look at the tracked actuals… no problem.  Oh yes… and by the way the deliverables will stay on track to our customer expectations.

I suppose climbing the corporate ladder somehow impairs logical sensibility.  These types of occurrences are commonplace and must be navigated by the PM.  In order to keep this in check, the PM must be diligent in maintaining project requirements, risks, stakeholder expectations, and ensuing change orders because these aspects of the work are reasonably easy to convey in business speak.  The PM can successfully protect the project from these perils by way of effective communications that resonate with this particular audience.  Attempts to show burn down charts and cumulative flow diagrams will only result in the same indigestion as would earned value metrics to the team doing the work.