Category: Project Management

Back in the olden days, I was one of those people whose bedtime was established by end of the Johnny Carson monologue. Carson’s opening act often included an interchange where he would lead with the line “it’s hot/cold/smoggy and the audience would respond “how hot/etc. was it?” to set up the joke. To this day, when someone makes a statement “it’s whatever”, my mind responds with with the audience’s line. “How whatever is it?”

This time of year, I spend a fair amount of time trying to figure out “how bad is it”–not as a way of setting up a joke, but in trying to figure out what problems are important enough to solve “at the root” rather than just dealing with the symptoms. For example, we’ve opened a new building on campus and one of my staff members just spent about a third of last week dealing with issues have nothing to do with academic technology–she’s chasing down questions about wire molding, conduit, network connections, door locks and other stuff that clearly is not her responsibility. (I guess these things are technology related in some broad way–they all do have wires.) She gets the questions because she knows all faculty in the building and because there is no clear communication path established as to who really is responsible. When we try to figure out a way to deflect those questions so she can focus on things are clearly are her job she comes back to the relational question: “If not me, who?”.

In complex, decentralized, underfunded organizations, figuring out who actually does have the responsibility for even something (relatively) simple like coordinating all those building changes (and then documenting the process) may require hours of phone calls, meetings, memos, negotiations and communications–even staff training. Deciding whether or not to try to fix the root problem is a judgment call that we make dozens of times a day, and, more often than not, it’s easier to just spend extra time to solve the immediate problem rather than to try to dig down and fix the root. Our faculty are busy folks and they’re generally very appreciative when someone–whoever–helps them.

But I have to wonder what the long term cost is when “fixing the symptom and ignoring the cause” becomes ingrained in the organizational culture and it becomes the accepted way of doing business. In my real (non-William and Mary) life, I much prefer to deal with organizations where the simple things are simple. No matter how helpful, friendly, and courteous someone might be in helping me navigate the corporate run-around (think Cox or Comcast here), I much prefer not not to get embroiled in a mess in the beginning. I’m wondering if we’re as much a part of the problem as the solution?

Worth a Listen on IT Conversations Overcoming Bias.

We live in a world of cognitive biases and polarized opinions. We consider ourselves to be largely rational, yet we are often prone to systematic errors such as overconfidence, wishful thinking, and the attraction of strong opinions. This means decisions are often driven more by personalities and passions rather than technical merits. Economic theorist Robin Hanson explores common errors, and points to innovative tools such as prediction markets which can help overcome bias and promote truth.

George Mason economics professor Robin Hanson gave this short speech at the O’Reilly Open Source Conference last year about how cognitive biases get in the way of our accomplishing goals that would make our organizations function better. Bias is the a systematic tendency to produce errors in our judgment. (One way of defining the purpose of education is to help individuals understand these typical human errors and overcome them for the betterment of society.)

Most of know that intellectually. We know that our inability to accurately estimate project times and costs creates all kinds of wasted effort, and that it’s incredibly hard to get ideas accepted on many of our campuses because of our natural tendency to glamorize our own ideas and discount those not invent here. This tendency toward wishful thinking and over optimism is so pronounced, that managers of software developers really

Most of us are passionate about something–vegetarianism, open source, the Red Sox–but, in this talk, Hanson suggests that our greatest passion should be for doing the hard work to overcome biases to come to the truth. One key to betting better at reducing errors in our judgment is to invest some time in investigating our actual track records. Most organizations would be well served by spending some serious time analyzing both failed and successful projects to establish better estimating procedures.

After one of my academic advisors worked with me for a while, she came with what she called the half-it/double-it rule. She’s ask me when I might get her the next draft, and I’d tell her 20 pages, end of next week. She’d half-it (reduce the goal to ten pages) and double-it, (increase the time to two weeks). Having goals that were tied to the time it actually took me to write–rather than speed I wished I could write–made the whole project more manageable.

We’ve invested lots of time in the last few months cataloguing all the academic projects that we’re working on or could be working on if we had the time or money. The list of current projects is posted now on the TIP Community blog site, and we maintain a much longer list “awaiting evaluation”. (We define project as something that will take more than 10 hours, requires more than one person, and produces a “nonroutine” result.) The goal of our project management methodology is to keep the number of stealth projects to a minimum and to wring as much individual and collective learning out of the process as we can.

Moving to a more explicit project orientation has generated a few growing pains as we all try to form new habits. I’m sure we’ll learn more complex methods as we go along, but, for now, I still think one of the best guides is at Lifehack with 16 Steps to Project Management. The specific steps may differ from project to project, but there’s an underlying theme that is pretty clear. See if you can figure out what it is.

1. Determine the objective and specific desired outcome. Write it down.

4. Begin “brainstorming” and create scenarios on how to achieve the desired outcome (this may have be broken down into sub-tasks). Make a date when all this creative thinking will be finished and a written draft can be printed and shared.

6. Determine and identify the tools (capital, equipment, machinery), the people (administration, sales, suppliers, customers), and the time required to complete the objectives. Write this down.

12. The leader must follow-up on all dates and compromises. Make this information public to all others involved in the project. Communicate all deliveries of sub-tasks, or lack of delivery, with the group.

The consequences of poor communication have been well documented.