Using contextual analysis to address project team problems

Sometimes, when I'm out reading apparently random things for no particular reason, I run across two quotes which click together. In this case, I found something while out reading about the structure of military thought immediately after going though my archived e-mail. The quotes are as follows:

Quote One

German General Kurt von Hammerstein-Equord in Truppenführung, 1933 wrote the following: "I divide my officers into four classes: the clever, the lazy, the industrious, and the stupid. Each officer possesses at least two of these qualities. Those who are clever and industrious are fitted for the highest staff appointments. Use can be made of those who are stupid and lazy. The man who is clever and lazy however is for the very highest command; he has the temperament and nerves to deal with all situations. But whoever is stupid and industrious is a menace and must be removed immediately!"

Quote Two

From an e-mail from a friend: “It's not whether or not we are stupid. It's what we are stupid about and when it comes up.”

Looking at this, where does it get us?

The second quote modifies the first, making Mr. Hammerstein-Equord's four classes conditional. It's not a question of whether we are clever, lazy, industrious, or stupid as a rule, but rather whether we display these attributes within a given context. Someone may well be both stupid and lazy on the job, while displaying cleverness and industriousness in the pursuit of his personal hobbies or some outside organization.

Taken in a more focused context, combining this matrix with the idea of contextual change allows us to quickly and easily identify possible resource failures within our team.


Assume for a moment that you have a team of six individuals. Three work as developers, one as a process analyst, one in project communications, and one in training. You fill in all of the other project roles yourself and farm out testing/deployment to other parts of the organization.

During the course of the project you notice that the process analyst spends most of his time working with the communications specialist. Meanwhile two of the developers flit in and out of the office at odd hours and miss their deadlines. The third developer manages though sheer force of effort to keep the project on-track, while the trainer goes out to the sites and causes trouble because he doesn't actually talk with anyone before declaring emergencies. The communications specialist sees to do an adequate but uninspired job.

If we were to take just a “classic” approach to this, we might divide our resources as follows:

    Process Analyst -- clever and industrious

    Developer One -- stupid and lazy

    Developer Two -- stupid and lazy

    Developer Three -- clever and industrious

    Communications Specialist -- stupid and lazy

    Trainer -- stupid and industrious

If we were to follow the good general's advice, the trainer would get the boot before he caused any more trouble. Developer three and the process analyst would both assume leadership roles while the other three were subjected to an appropriate regimen of management in order to manipulate their behavior.

Applying a bit more elaborate approach, we examine the context within which each individual works:

Our process analyst is an operations person from the lines of business. He really doesn't know anything about formal process analysis, but he does know everyone in the organization and has a track-record as a good project manager.

Our communications specialist comes from a marketing background. She just took this job to have something to do while waiting for her husband to finish up his medical degree.

Developers one and two spend a great deal of their time outside of work studying development techniques at a local community college. Although both are mid-career, this is their first real development job. They want it to work out and are deathly afraid that it is not.

Developer three is about to retire. He's worked on code for forty years. What he doesn't know about how to conserve time and effort on a project could fit in a three-page book.

The trainer is an operations person drawn from the organization. He knows IS, screws up all the time and doesn't know how to fix it. He also doesn't understand the system at all. He does, however, know a huge amount about how the business works. So, when he gets on site he spends a huge amount of time searching for flaws in the implementation in order to point them out before the product goes live.

In each of these cases, the person's classification only makes sense within our project analysis. In a IS context, what we see is this:

    Process Analyst -- stupid and industrious

    Developer One -- clever and industrious

    Developer Two -- clever and industrious

    Developer Three -- clever and lazy

    Communications Specialist -- stupid and lazy

    Trainer -- stupid and industrious (but highly misfocused)

If we were to pull back and look at the project from an operations point of view, we might see something else entirely:

    Process Analyst -- clever and lazy

    Developer One -- stupid and industrious

    Developer Two -- stupid and industrious

    Developer Three -- stupid and lazy

    Communications Specialist -- stupid and lazy

    Trainer -- clever and industrious

Not only does this approach help us to figure out what to do with our own resources, it can provide clues (via context switching) as to what our managers, their managers, and the business execs might see as they look down upon our work from on high.

I could probably whip this up in a spreadsheet or a database, but that sounds like work. I may go do it for my current project on 3x5 note cards, though.