S ince embarking on the discussion of project related leadership, I have found myself traveling through the collection of many interesting stories. One of the more salient conversations I’ve had recently is on the topic of organizational management. To contextualize this slightly, “digital disruption”, or “disruption” altogether seems — at a drone’s eye level — in need of leadership. With its funding models, social implications, and El Dorado-esque mythology of hitting it big with that one thing, it is a visceral and emotional response causing thrill. The dangerous evolution here is to chase disruption solely for the sake of disruption and make it your organization’s business model. To quote my colleague: “You can catch the vision, but what’s wrong with what we’re doing right now?”
This, generally, is where the need for “disruption” and “innovation” normally get tossed around. But do you disrupt to innovate? Or innovate to disrupt?
Fortunately, we have methods for this. One is the sidecar concept. A separate division is created inside the operational entity whose purpose is to determine where organizational weaknesses exist such that a competitor could capitalize on them thereby occupying your market share. Think murder boards, pivot analyses, threat-probability matrices, and big data dashboards.
The other technique came out of a Teresa Lawrence of International Deliverables PMXPO 2018 presentation. It represents greater prospects for creative pathways than rebranding or “just doing things differently.” S.C.A.M.P.E.R. is an engineering methodology, its permutations can bring to mind Rube Goldberg schematics, but it guides us to usable innovations (which can then disrupt.)
Substitute: What can be used instead?
Combine: Which elements/parts might be combined?
Adapt: What else is like this?
Modify: How can you change the meaning/shape/sound/color/frequency or subtract/shrink/streamline?
Put to other uses [self explanatory]
Eliminate: What can you remove/omit/do without?
Rearrange: What if you reversed patterns/assumptions? What can you interchange/transpose/reconnect?
Both techniques guide effectively through the innovation — disruption lifecycle: discovering where a problem exists, then discovering a fix. Once the cycle is complete, you likely need to run it again, and again… ad infinitum in a pattern PMPs recognize as “process optimization” while hewing closely to the business case. The business case argument that is inviolable here. ‘Innovating’ is a lot of fun as new products, protocols and professional titles may be invented. However, if you haven’t resolved the problems inspiring your adventure down this path, you may create a baker’s dozen of new widget styles, but those original problems are still not solved.
Optimization can yield leadership as organizations find efficiencies, serve their customer base more effectively, and produce greater stakeholder satisfaction. However, if an ‘innovation’ doesn’t solve the problems from the business case, can it be truly disruptive? Furthermore, if the project fails to meet its initial goals, that is the standard definition of a failed project. If it fails to innovate, it adds to the $2 Trillion worth of failed projects annually. To quote the PMBOK: “The astute Project Manager, recognizing the failure of the business case, moves immediately to project closure.” Sounds like a QA/QC process is required. Sounds like a great opportunity for a #PMPatWork.