Project Management Maturity: Where Do The 'Lone Wolves' Go Wrong?

When you have been in the business of "software project rescue" as long as I have, you begin to get a sense of deja vú: the realization that "you have been here before – many times." That the teams that you are tasked to "turn around," this time, are in more-or-less exactly the same situation that you faced last time. Therefore, I'd like to now share a few basic observations.

The Most Common Problem: "Project Management" Doesn't Exist

Okay, I said it. Nearly all the time I walk into a situation that grew out of a small set of "lone wolves" who probably had been working at their chosen place of business for a number of years – whether or not (probably not) they are still there. They probably crafted their "hand-crafted solutions" at the leading edge of the nascent "microcomputer revolution," when anything was better than nothing. As times moved on, they were the masters of "their" application(s), and nobody else did. They were "lone wolves," and they felt quite secure in their position.

Of course, in any business organization there must be "managers," but these managers generally took the easiest way out. Weekly status-meetings simply consisted of asking each "wolf" what they were doing, then concluding by telling each of them to "keep at it." The managers would of course talk to other managers about "manager questions," but they implicitly trusted their "wolves" and never seriously inquired about how the needs of the business would actually be handled by any of them – unless "a serious fire" actually started, which was unlikely.

Well, the problem here is that the so-called "manager" is actually just a "supervisor." (S)He is not at any point personally involved in what each "wolf" is doing, nor in how they are actually doing it. Each "wolf" is simply consigned into his-or-her own "silo," thereby eliminating any inter-project or inter-personal issues.

In short: "At this point, 'project management' does not exist."

This situation can actually exist, even thrive, "until."

"Aye, Here's the Rub ..." Until!!

At some fateful point, the business pressures upon this "lone-wolf non-pack" grow to the point where the "non-pack," lone-wolf" dynamics begin to crack. This is usually the point where the most-capable "wolves" simply turn in their two-week notices and scamper off to the next lonely field, leaving the manager with a serious conundrum. Up until this fateful moment, the "manager cum supervisor" has not had to become personally involved. Now, "the goose that laid the golden eggs" has just now flown the coop.

False-Step #1: "Scrum / Agile"

The usual "next step" beyond "this sheer-panicked realization" is to cling to a "manifesto." The supervisor/manager seeks to "re-organize" his (so-called ...) "team" by insisting that they internally re-organize their activities. They are to "gather around a white-board and attach sticky-notes to it" ... before departing back to their lone-wolf dens to continue their lone-wolf activities. They are to more formally describe their "lone-wolf daily tasks," instead of considering ways to share it. And, since "considering ways to share it" is strictly left to the individual in question, it should come as no surprise to anyone that nothing actually changes.

Serious-Step #1: "Planning is Everything"

At some point, the pivotal realization is finally made: "this is just too big for any one person."

At this point, both the manager/supervisor and the team begin to realize that the software-development tasks which each of them so-far had been "internalizing" must be formally separated:

• "Management of the 'Promises' made to the business." ("Project Owner.")
• High-Level Design of the Software, including formal exploration of its relation to other systems.
• Implementation-Level Design of the Software.
• Task-Wise Breakdown of the Implementation.
• Assignment of these tasks, and Communication between those responsible for each.
• Testing and Verification of the ostensibly-"completed" tasks.
• Regression Prevention – so that subsequent changes don't "break" something else.
• Deployment Process – so that "the customer never sees you sweat."
• Status-Reporting Process – so that this "suddenly-multiplexed process" can still be meaningfully reported.

When you, like me, as a "change agent," first step into this situation, you will be confronted by a set of very-earnest and highly-skilled team members who so far have conflated the issue of "what to do" with that of "why to do," because each of them have so-far been obliged to simultaneously confront the issues posed by the software with those that are posed by the business. Their point-of-view is automatically and necessarily determined by the software, and this entirely clouds their ability to properly see the business.

Project Management: "A Breath of Fresh Air"

When you first begin to breathe "project management" into a situation that previously has had none, your "breath of fresh air" has the following immediate effect: you begin to create, for the very first time, an actual team.