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.