Even the most humble development effort in today’s environments implies multiple work streams. “Stand alone” and “desktop” are quickly leaving our collective IT vocabulary, delegated to proofs of concept at best. Connectivity isn’t everything, it’s the only thing. The PM needs to approach any development effort with a mind to assimilate all of the working parts into her universe. If the project is to create an app, where does the information come from and where does input go? What happens when I put down my phone and go to my computer to engage the application or solve the same business problem? What is feeding the app, what secures it from hackers, and how does the sponsoring corporation productively disseminate the fruits of their digitally transformed labors? That small, self-organizing scrum team, replete with cross-trained developers, testers, and a product owner, actually need to get with others before their creation is in the market. If they move swiftly and the supporting infrastructure and its requisite data stores don’t keep up, what happens then? Or, more to the point, who might get in trouble?
Assimilation presumes layers. The PM needs to assume that each layer, each contributing part, needs to be organized and managed so that they are stacked in a way a good cake is stacked; ready for the frosting, ready for market, ready for some return on investment to the sponsoring organization. The PM might be charged with managing the production of an app, but in today’s world, needs to become intimately familiar with all the parts of that app’s ecosystem (ugh, there, I said it, with sincere apologies to biologists and scientists everywhere).
Familiarize yourself with each work stream that together will compose the whole when that scrum team produces working, marketable software at the end of a three-week period. Diagram the work streams, noting who owns them, what tasks are done to have them ready to play, and what distinct outputs you’ll want to monitor. For example:
PMs create work breakdown structures as a matter of course. The “assimilate” output example above might be called a work stream breakdown structure. Understand the whats and the whos of your world, even if you don’t control all or most of the streams. Assimilate.
The next “8” would seem pretty logical. Unless the project is to build a bunch of silos, you need to know where and when the outputs of these work streams touch. “What” and “Who” need to dance with “Where” and “When.” You personally might not be able to control the outcomes of all the dependent efforts, but if that is the case, you had better know where, when, and how those dependent outputs control you (and objectives that you own). Even those silos, to stand and function successfully on your farm, will likely need contributions from more than one vendor if you want to ship in one truck or store in one barn. Integrate what you have assimilated.
So Assimilate and Integrate now march along like the proverbial horse and carriage. Out of what dark space might I have pulled “Mitigate” as a third component of said quartet? I’ll admit to cheating a bit here for effect, because there are other ways to address risk than to lessen its likelihood. But risk is really what all PMs need to manage. Mitigating risk is more often than not the treatment strategy, especially when the risk is around dependent work streams.
Everything on a RAID log is the spawn of risk. There’s risk that’s called risk (that’s the R). Assumptions are actually thinly veiled risks. We assume something to be true and state it so that we have currency to react and take action when it is not true. Issues, per PM 101, are realized risks or just plain stuff that flew through the air and landed in your project--that is, risks that you didn’t plan for. And dependencies are the nourishment of risk. In some textbooks it’s called “convergence” or “convergent” risk. In the programmatic sense, it’s dependencies that demand extra scrutiny and require mitigation so that someone or something won’t move your cheese into the other room.
Any time we depend on something outside of our circle of influence or control to achieve our objective, we put our objective at risk. The PM needs to assess all of the touch points and measure the burn, if only to be in a position to say, with all humility, “I told you that this might happen.” But more than that, the responsible PM will work to assure that all the “self-organizing” teams going about their business are traveling to the same destination. As the PM, you are the road smoother and the air traffic controller. Mitigate, mitigate, and mitigate again.
Murphy wasn’t the only one to be vulnerable to the inevitable, the worst case scenario. Actually, we should call it “Everyone’s Law” or maybe the second law of thermodynamics, the tendency to chaos. Stuff happens, and the fourth canto of the PM’s psalm is to escalate. What I mean is “get it out there” and institutionalize escalation so that it’s a fire drill executed, not a tragedy akin to running with bulls.
So what if something does go wrong? Of course we want to have a plan B, but even more importantly, we need a process to assure that everyone who needs to know will know that plan B is in effect. Escalate departs from the other three in that it’s not something we want to actually do. But we want to know how to do it when it’s necessary.
I perhaps could have gone with “illuminate” to emphasize the importance of transparency and full disclosure when things go awry, or even “communicate” to make my paradigm less jolting. “Illuminate” is a bit too allegorical for your average, anal-retentive PM, and “communicate” is just too damn pervasively self-evident, worth its own screed. As PMs, we can relate to escalate. We escalate every time we submit a change control. We escalate when we can’t make bad things go away through our own efforts, which is often. Escalate can refer to simply dealing with conflict. Escalation is not for the timid. The PM that delivers the bad news in a timely and actionable way is the PM you want to hire. I probably struggle with this 8 more than any of the others, but as I get better at this moving target called project and program management, I realize that I’ll need to do this verb more often in the future than I’ve done in the past.
Project managers need to be agile too, if only to dodge the flying debris and live to manage another project another day.
Don’t forget to leave your comments below.