Nothing to See Here

What are Your Management Priorities?

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Mon, 08 Jun 2009 13:54:00 +0000

In my last post, I described 10 priorities for successful service delivery. It is a list of priorities that I find helpful when deciding where to focus my efforts. I have used it in the past to develop a five-year strategic plan. I have also used it as the outline for sole-source purchase justifications. However, you have to understand what it is and what it is not to have it be useful. The right tool for the right job is as important in management as it is in carpentry.

Despite their appearance in a numbered list, they are not a sequence of steps. You should not attempt to complete these items in order before introducing a service. If you get nothing else out of this post, get this: These are not steps for you to execute in sequence. These are priorities.

In addition, this is not a checklist. Just as it is not a list of steps for you to execute in sequence, it is also not a list of steps for you to execute in parallel. These are priorities. You do not have to complete all of these items before introducing a service.

What are Priorities? Priorities are items for you to consider when planning what to do next. They are guides when you are trying to develop guidance.

Consider the first three priorities from my list: Function, Capacity, and Reliability.

Say you are currently idle — hypothetically. You have completed all of your work. You are trying to decide what to do next. You could do anything but the institution hired you to do something. Think about your function first in deciding what to do. A jack-of-all-trades is master of none. If you focus on what you do, the institution will be better off than if you are trying to perform many unrelated functions.

Now say that you have decided to do something. Hurray! Doing something is better than doing nothing. Someone benefits where nobody benefited before. This is a start. If you had waited until you had the rest of the priorities covered, nobody would benefit now. That is interesting because, in addressing the “Function” priority first, you probably did something cheap, easy, and quick. That means you probably also addressed the “Budget,” “Parity,” and “Timeliness” priorities.

You have been doing your something for a while. Enough time has passed that you can tell the need for the function is real and you are planning what to do next. Now think about capacity. Is there enough of the function to go around? How much do you need and where do your users need it most? Is it simply a question of more, or does it have to be different? What changes do you need to make? Consider these issues and make your plans.

As you went through this stage of planning, your solution probably was not in the “cheap, easy, and quick” category any more. You had to consider its cost, and when you spend money, you thought about where you were spending the money. In considering potential solutions, you considered what other similar institutions had done before you. That means you addressed the “Budget,” “Welfare,” and “Standing” priorities.

Time passes, you implement your plans, and you now provide a useful function with enough capacity to service your intended audience. Where you focus your efforts next is on making it more reliable. The questions you ask yourself are similar to the ones you asked while increasing your capacity. Is it reliable enough? How much reliability does it need and where do users need it most? Is more enough or does it have to be different? What changes do you need to make? Consider these and make your plans.

So you see that the crux of these priorities is this: Something, More, Better. Do something. Then work on doing more. When you have enough, focus on doing better.

These priorities are a tool to help guide your thoughts as you plan what you will do next in service of the institution.

10 Priorities for Successful Service Delivery

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Wed, 03 Jun 2009 17:18:00 +0000

Several years ago, I moved from for-profit industry to academia. It has taken me a while to come to grips that profit is not a motivator here — let alone, the primary motivator. I have come to the conclusion that there are ten priorities for successful service delivery at a state-related higher education institution.

Function — This is really a placeholder for whatever it is you do. No matter how well or how badly you do your function, you are there for a reason. This is your primary motivator. For me, my primary function is packet transport — I do national, state, and some campus networks.
Capacity — Once you do something, you have to do enough of it. Whether it is producing enough handouts or having enough web servers, after basic functionality you have to have sufficient capacity. For me, that means that the network has to have enough bandwidth to carry the traffic customers produce and consume. It also means that you have the tools to know what your capacity needs are and that you use them to know when you need to increase or when you can decrease your capacity.
Reliability — So, you do something and you do enough of it. Now you need to be able to do it when your customers expect it. If you only have one person to hand out leaflets and they have enough leaflets, it does you no good if they are out on sick leave the day you need them handed out. You need to provide a reliable service. For me, while there are many approaches, this generally leads to discussions of redundant delivery mechanisms. Though it also involves questions of maintenance, upgrades, support, repair, and replacement and the associated staff and tools.
Standing — So you provide a reliable function with sufficient capacity. That is impressive. Now you can think about paying it forward. How does what you do contribute to the standing of the institution in the Higher Education community? In my case, we participate in national research and education networking organizations. We give presentations on what we have done and listen to and question others on what they have done. We provide input and seek feedback from standards bodies. We work with other institutions to solve common problems and work towards common goals and make sure that our service delivery decisions build on and support those efforts. We work cooperatively with other institutions to seek better group pricing than an individual institution could achieve.
Welfare — While the funding we receive from the state is a small part of our overall funding, we do care deeply about the welfare of our state. Our institution has a tremendous economic impact on the state and we see this as a specific part of our mission. Whenever possible, we try to make spending decisions in a way that benefits the state economy. Whenever possible, we try to provide our services in a way that benefits the state residents.
Budget — You knew we would get here eventually. We are still not a for-profit industry, but we need money to do almost any thing and that money has a finite supply. Remember though, we are not in this to make money. You have a given amount of money in your budget to provide the planned service. If you manage to be able to spend less on one part of your function you should not think of it as saving money. You should think of it as having money to do more or better. You are here to provide a function with enough capacity and reliability — trust me on this — you are probably not going to have extra cash laying around. If you do, you should use it to invest in providing a better service. If you consistently have extra cash laying around, you should reduce your planned budget in the future. There are others who need it.
Parity — Your service cannot discriminate on customers based on their campus location. Everyone has to have the same opportunity. That does not mean you have to build out to every potential customer, but you have to be willing to build out for the first customer that wants your service at a campus you do not currently serve.
Equity — If parity is about providing service, equity is about paying for service. We all have a funding model. The money that goes in our budget came from somewhere — tuition, fees, grants, or customer charges. They also come with some expectation of delivery. That means your customers expect something for their money. The problem is that you also have to account for free riders. While your service may — and probably does — expect some level of free riders, you cannot let that impact the level of service you promised by accepting the money in your budget. The old saw goes, “You cannot rob Peter to pay Paul.”
Transparency — Providing services in a higher education institution is rarely something you can do without help. Perhaps you rely on the service of some external membership organization that the institution is a part. Perhaps you buy part of the service from an external provider. In either case, transparency is key. While we understand that we may work with for-profit organizations, we want to understand what our budget dollars are paying for. We want visibility into the providers future plans and directions and we want the ability to influence them. The same holds for member organizations. We want some level of control in the governance of the organization.
Timeliness — Given everything you have done so far, this one seems hard to remember, but a service is best when it is available when needed. Unfortunately sometimes this means you have to say, “That sounds like a good idea for next year.”

Hoping People Will Do the Right Thing

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Wed, 03 Jun 2009 12:58:00 +0000

In order for a person to do the right thing, a event sequence has to occur.

Someone has to recognize that an action needs to occur.
They need to decide that they are the one that needs to make it occur.
They need to know what the right thing is so they can make it occur.
They need to know how to make the right thing occur.
They need to feel empowered to make the right thing occur.
They need to have the time to make the right thing occur.
They need to have sufficient internal motivation to make the right thing occur.

Now let's say we have really good people. Let's assume they were all “A” students and that nine times out of ten, they have what it takes to do the job.

With those assumptions, if we hope people will do the right thing, how often will it actually happen?

What we have here is an exercise in probability. The probability that our hypothetical worker bee will complete any event in the sequence is 0.9. The probability of completing all of the events in the sequence, and hence doing the right thing, is the product of the individual probabilities. That is 0.9 × 0.9 × 0.9 × 0.9 × 0.9 × 0.9 × 0.9 = 0.478. That means that left to her own devices, our “A” student that recognizes that something needs to be done and that she is the one to do it, knows what the right thing is and also how to do it, feels empowered and has the time and internal motivation to do it will — a little less than half the time — do the right thing.

If instead you assume that we are working with “C” students (0.7) the probability that hoping people will do the right thing only pays off 8% of the time.

So, as a management tool, hoping people will do the right thing is an exercise in futility. It is only interesting to the mathematically challenged.

Seriously, just stop it. Stop it now. Really.

Multiverse Planning Haiku

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 02 Jun 2009 20:51:00 +0000

Look at the future
See the possibilities
Choose your path forward

com.Oracle.Oracle Calendar[3866] set a breakpoint in malloc_error_break to debug

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Thu, 30 Apr 2009 12:57:00 +0000

What a piece of ©®@℗!

4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803009d0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803009c0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300990: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300950: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300930: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803009d0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803008f0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300660: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300620: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300600: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803005c0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803005a0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300560: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300540: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300500: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803004e0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803004a0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300480: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x80300440: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] LaunchCFMApp(3866,0x8025d720) malloc: *** error for object 0x803001b0: incorrect checksum for freed object - object was probably modified after being freed. 
4/30/09 8:48:58 AM [0x0-0x158158].com.Oracle.Oracle Calendar[3866] *** set a breakpoint in malloc_error_break to debug

Cautious Reflection About “How” We Change

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 27 Jan 2009 16:20:00 +0000

As George Santayana is often quoted, “Those who cannot remember the past are condemned to repeat it.” Since I believe that is true, it is worth looking back at another, less often quoted individual — Melvin Conway. He was a programmer in the 1960s. He wrote an assembler for the Burroughs 220, he wrote a paper on coroutines, but the reason we know him at all, is that he is credited with coining Conway’s Law. Unlike other, so-called “Laws,” Conway’s Law was not intended as a joke, but rather as a valid observation of how real organizations make things.

In 1968, Conway wrote a paper called “How Do Committees Invent?” In it, he wrote:

…organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.

This is more commonly quoted as, “Any development project reflects the organizational structure that produced it.”

As we move forward in an environment of change, it is important that we keep this in mind.

To see how this manifests itself in the real world, please read this blog entry from one of the Vista programmers on how they developed a particular feature for which he was responsible. While you are reading, see if you find any of what he says familiar. If you do, consider that we may need to address those issues ourselves as we try to move forward.

Another Oracle Calendar Peeve

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 21 Oct 2008 17:47:00 +0000

Oracle Calendar brings up an alert box in front of the application that I am working in to tell me to switch to Oracle Calendar so it can show me an alert box. That's good. Interrupt me twice.

Oracle, nobody like an attention whore.

Notes from Today’s Tuesday Reading: How Well Do You Delegate? - Discover how to improve

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 07 Oct 2008 14:11:00 +0000

What and When to Delegate

Assuming you have accepted work, do it yourself when it is:

Due in less time than it would take a delegate to accomplish
Directly related to your own objectives and priorities
Critical to the success of a project
Confidential or sensitive in nature
Incompatible with the skills and expertise of your potential delegates

Otherwise, delegate.

To Whom to Delegate

Delegate large projects to teams of people with appropriate responsibility and clearly defined authority for decision-making
Delegate to the most qualified person
Delegate to people as a means of developing their skills
Delegate to people who report to you

How to Delegate

Explain clearly, what you expect the delegate to do and why it is important
Agree to an end-point and checkpoints along the way
Talk openly about the consequences of missing and the benefits of meeting deadlines and expectations
Let delegates know that you expect them to come to you with solutions to problems they encounter, instead of simply asking for more instructions.

How Well Do You Delegate? - Discover how to improve.

I Need Some Feedback

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Mon, 29 Sep 2008 19:44:00 +0000

(Or “When is talking to each other not communicating?”)

I have a recurring nightmare that as a child, I learned all the same words that everyone else did, but somehow I ended up learning a different language. I was in a meeting last week where this seemed to be coming true. I made a statement trying to clarify a “big picture” issue.

Here is a snippet.

Me: “There is no feedback built into our workflows.”

Another Meeting Attendee: “Yes, there is. I send an email back to the person before me in the workflow every time I get a request.”

I hate it when that happens. I deliver an opening line, somebody says something true, and it throws me completely off track. It took me almost a week to get back on track and figure out what went wrong and how to explain it. I eventually realized we were not talking about the same thing.

I am an old-time engineer, and I think about everything like this, I apologize, but bear with me.

The other person was talking about what I would call a handshake. A handshake is useful in communication systems with an unreliable medium. If you have used the Internet, you have probably done this without knowing it. The transmission control protocol (TCP) incorporates a handshake to ensure that the devices between two hosts on the Internet actually deliver the packets from the sender to the receiver. When the receiver gets the senders information, it sends back a message that it got it. If the sender does not hear back from the receiver, it tries again.

That is how a handshake works. That is how it manifests itself in our workflows. We send a work order to the next queue in line. The receiver sends back an email saying they got it. Is that feedback? Yes, technically it is. Unfortunately, it was not my point. It just took me a week to realize it. Sorry. I am a little slow.

So, if a handshake is a kind of feedback but not the one I meant, what did I mean? That is the problem. I do not think it has a name. Just “feedback.”

The feedback I am talking about is the kind I learned about in Circuits 101, where you connect the output of an amplifier back to its input to allow the amplifier to change its behavior based on what is happening at the output.

Geeky. I know.

Let me give a more relevant example in the form of a conversation with an anthropomorphic freezer that uses a handshake, but not “feedback” in the sense I am using it.

User: “Honey, I’m going to put this steak in the freezer.”

Controller: “Cool the freezer compartment.”

Chiller: “Cooling away!” ←Handshake

…time passes…

User: “Hey! The freezer is a big block of ice. Where’s my steak?”

Controller: “What’s going on?”

Chiller: “Just doing what you asked.”

Controller: “So you’re saying this is my fault?”

Chiller: “If the shoe fits…”

Controller: “Want to step outside and say that?”

Chiller: “You and what army?”

User: “Hey, guys. What about my steak?”

Chiller: “Get lost. This is an internal issue.”

Controller: “Yeah. If you knew anything about refrigeration, you wouldn’t need us in the first place.”

User: “Honey? I’m going to Big Box for a new freezer. This one’s broken!”

It turns out that the new freezer includes the type of feedback I mean. Here is the new exchange.

User: “Okay, I got my steak moved to the new freezer.”

Controller: “Cool the freezer compartment.”

Chiller: “Cooling away!”

…time passes…

Chiller: “It is cold enough.” ←Feedback

Controller: “Okay. Stop cooling.” ←Corrected output

Chiller: “Stopped.”

…time passes…

Chiller: “It is getting warm in here.”

Cooler: “Okay. Start cooling.”

Chiller: “Cooling.”

…time passes…

Chiller: “Frost is starting to build up.”

Cooler: “Okay. Start heating.”

Chiller: “Heating.”

…time passes…

Chiller: “It is getting warm in here.”

Cooler: “Is the frost gone?”

Chiller: “Yes.”

Cooler: “Okay. Start cooling.”

Chiller: “Cooling.”

…time passes…

User: “Honey? There’s a steak in the freezer. Could you get it out so we can grill tonight?”

That is what I meant when I said “feedback.” The system gets information about how close its actual results match its desired results.

How does that fit with our group working together?

Suppose we have a big system to install for a particularly visible application, but the vendor of the equipment has made a change that makes it so it cannot work.

Designer: “Here’s a work order for the big design.”

Installer: “Got it.”

…time passes…

Installer: (to himself) “This doesn’t work.”

…time passes…

User: “This doesn’t work.”

…time passes…

Installer: (at bi-weekly meeting) “The vendor of the equipment we used in the big system installed two weeks ago made a change and now it doesn’t work.”

Middle Managers: “What are you talking about?”

In defense of the installers, they brought it to the only forum they had available: the bi-weekly meeting. The drawback is that those people are out of the loop. In fact, that is the problem. There is no loop to be “in.” Our workflows always go forward. There is no way to send that message back to provide input to the designer so they can change the design to more closely match what was wanted.

Here is what I would like to see happen.

Designer: “Here’s a work order for the big design.”

Installer: “Got it.”

…time passes…

Installer: “The vendor made a change and it does not work like that any more.” ←Feedback

Designer: “Okay. Try this instead.” ←Corrected output

Installer: “Got it.”

…time passes…

Installer: “That worked.”

…time passes…

User: “I like working here.”

How do we make that happen? How do we make it so the folks actually doing the work can work issues out amongst themselves rather than having to have big meetings with a lot of middle managers who do not know what is going on in the first place? How can we do it before our users get a new freezer?

Fall Member Meeting to Feature Outstanding Program

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Fri, 19 Sep 2008 17:37:00 +0000

Penn State is an Internet2 member organization. That makes everybody at Penn State an Internet2 member. Twice a year, Internet2 has a member meeting with presentions for, by, and about members and what they are doing with Internet2. You might be interested. Here is part of a recent announcement for the upcoming meeting in October.

The program for the Fall 2008 Internet2 Member Meeting will feature many highlights, including 70 track session presentations of innovative uses of advanced networking for research and teaching, as well as the development and evolution of high-performance network infrastructures in support of local to global cyberinfrastructure. In addition, 11 applications demonstrations are planned, which will showcase uses of advanced networking to provide telehealth and telemedicine services, weather forecasting and numerical modeling, and innovative approaches to delivering content and video, among others.

General session presentations will include a live peek behind the scenes at the Large Hadron Collider using advanced iHDTV technology, developed by the ResearchChannel and the University of Washington, to provide a first hand view of the biggest science device on the planet. Scientists and networking experts at CERN will engage in a live discussion on the importance of the community’s investment in cyberinfrastructure to this work and in future research and discovery, with Q&A opportunities for the audience. Ed Seidel, Director of the NSF Office of Cyberinfrastructure, will present on the “The Importance of Cyberinfrastructure for Higher Education.”

General sessions will also feature Scott Cowen, President of Tulane University, who will describe the Tulane experience before, during, and after Hurricane Katrina, and Robert Browning, who will provide a live demonstration the C-SPAN Archives. A live videoconference using dynamic circuit networking and UltraGrid HD technologies will highlight collaboration between Louisiana State University professor Thomas Sterling and students in the Czech Republic, and the Internet2 Strategic Planning Execution Committee will lead a discussion on next steps in the strategic planning process and implementation.

There is still time to register and make plans to join your advanced network colleagues in New Orleans. Please also make your reservations at the Sheraton New Orleans before 5:00pm CDT on 23 September to take advantage of our special meeting room rates.

Shorter "SOTU"

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Fri, 19 Sep 2008 14:52:00 +0000

One university…

…geographically dispersed…

…for the future.

Inspired.

Proud.

Motivated.

We are…

…Penn State

Watch it. Watch it now!

You will be, too!

Shorter “Leadership lessons from my daughter”

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 16 Sep 2008 14:28:00 +0000

Yelling never has a positive outcome
Formal authority rarely works
Give permission to make mistakes
Communication is key
Get the basics right
You can criticize ideas, but not people
Foster the joy of success rather than the fear of failure
Delegate responsibility, but emphasize accountability
Respect innovation
Accept independence

— Opinion: Leadership lessons from my daughter

More Generalized “Build One to Throw Away”

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 26 Aug 2008 15:25:00 +0000

I am a big fan of Fred Brooks, by the way…

ongoing - Build One to Throw Away: “Given that, what hope is there for waterfall development? Or for any approach that doesn’t leave space for going back and building things right once you’ve learned what ‘right’ is by building things once? Well, none.

“…Because there’s this terrible glaring conflict between what sensible managers want and what sensible [developers] know. Managers, good managers, want a plan; they want to lock in design constraints so that work can be dealt out and progress tracked and promises kept. [Developers], good [developers], know that they’re not smart enough to get the core design choices right until they’ve built something that works.

“The various techniques and disciplines gathered around the banner of ‘agile’ are on balance more honest at facing up to this unavoidable tension. But there’s still lots more work to be done.

“And the most important thing is, we all have to remind ourselves, all the time, that we’re not smart enough to get anything important right the first time.”

Save Little Suzie!

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Fri, 22 Aug 2008 16:41:00 +0000

Security {Versus|Plus} Privacy

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Thu, 21 Aug 2008 17:11:00 +0000

Here is an interesting short article at wired.com. It makes an interesting point for us in IT to consider:

"Too many wrongly characterize the debate as 'security versus privacy.' The real choice is liberty versus control. Tyranny, whether it arises under threat of foreign physical attack or under constant domestic authoritative scrutiny, is still tyranny. Liberty requires security without intrusion, security plus privacy."

That would be a lot easier to swallow.

Managing Access Bandwidth

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Wed, 06 Aug 2008 19:07:00 +0000

Since Penn State has both volume caps and prioritized packets, I am curious what anybody else thinks about this post on the Google Public Policy Blog?

Change is not a New Concept

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Thu, 17 Jul 2008 15:27:00 +0000

“Time is a river of passing events, and strong is its current; no sooner is a thing brought to sight than it is swept by and another takes its place, and this too will be swept away.” —Marcus Aurelius

Another Look at Change

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Wed, 16 Jul 2008 14:58:00 +0000

Change means doing new things, but it also means letting go of old ones:

“We all cling to our projects, our directives, especially if they are the bulk of what defines our position, or a whole department’s identity. But what if that directive, like Mr. Smith’s, was outdated, was in the way of progress, or harmful? Would you continue on course or would you question it?” — Nikki Massaro Kauffman

John Gruber on Jamis Buck on Estimating

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Wed, 16 Jul 2008 10:50:00 +0000

Imaginary work is always easier to do than real work. It is much more attractive (being more quickly done) and once you see the imaginary work, it can be very difficult to identify the real work it masks. People estimating imaginary work often assume they have all the facts in hand when making their estimates, which assumption leads them to believe that there is no “big technical hurdle” preventing its implementation. — Jamis Buck

These users are inevitable, and they never cease to annoy. But no product team will ever be successful without the confidence to know when to ignore them. What these users want is everything, and if you try to do everything, you will fail. — John Gruber

Dan Moren's iPhone Wish List

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 15 Jul 2008 18:17:00 +0000

Macworld: "Personally, I still want cut-and-paste support on my iPhone. And, heck, turn-by-turn GPS would be nice. Oh, and also, when you get around to it, I would like a pony. Thanks."

Change, Flexibility, Recognition

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 15 Jul 2008 14:18:00 +0000

I just listened to a news story on the radio about General Motors. They have established brands and methods for producing those brands. Unfortunately for them, their marketplace is in a period of change. Their customers have changed their needs and GM has to adapt to the new conditions. This is not the first time this has happened. In the past, when companies have successfully adapted to a changing marketplace, it was because of flexibility. I hear many people saying that we need to be more flexible, too.

The news has a funny way of focusing on the bad. My memory of this type of story is that they follow this line: a series of plant closings; followed by business closure; followed by persecution of management in the media and the courtroom; followed by second-guessing on what could have been done from people peripherally involved who could have done something but didn’t. Rather than repeat that cycle, let us jump to the end and try to learn from it.

After the fact, everyone recognizes that the cause of the failure was a lack of flexibility. The company should have made smaller (bigger) cars. The company should have made more fuel-efficient (powerful) cars. The company should have made more family-oriented (sporty) cars. The company should have made what the market wanted when the market wanted it.

To their credit, most companies are in business today because, through serendipity or generally good business acumen, they made what the market wanted when the market wanted it. The trick to longevity is recognizing when the market has changed its mind and being flexible enough to change to producing what the market wants.

As an organization, we have talked about change. We have talked about how we need to be flexible. We need to let go of what our customers no longer need so we can target our energies on what they will need next. Letting go is hard, but we can all work together to accept it (denial, anger, depression, bargaining, acceptance). Wait a moment, though. Look back at the last sentence in the last paragraph. We are working backwards through it. There were three concepts that made up the “trick” in that sentence (in reverse order): change, flexibility, and recognition. We already talked about change and flexibility. They are hard things because we live with habits and like to have others tell us what to do. But, what about recognition? That is the key to the trick, but we have not talked about it.

Recognition for an organization starts when the individuals who make up the organization are in touch with and aware of the needs and wants of their customers and then they communicate those customer needs and wants freely, openly, and honestly to the largest possible audience. Share what you know, learn what you don’t.

How does all that happen? That is the easy part. All you have to do is ask.

Are you interested in weight lifting? There was just another successful Lift for Life. Go introduce yourself to one of the people involved and ask them about it. Learn about what they do and ask yourself if what we do helps or hurts their efforts, or is completely irrelevant. Communicate what you learn.

Interested in fine art? Go find one of the people involved in research on digital systems for detecting forgeries. Ask them about their research and ask yourself how we might make a positive contribution. Communicate what you learn.

Interested in earthquakes? There is a group of people studying the recent earthquake in China. Go talk to them about what they do. Ask yourself how they could benefit from what we can do. Communicate what you learn.

Find a faculty member, researcher, or administrator. Find a student organization that might be of interest. Introduce yourself and ask them about what they do. You do not have to sell them anything. You are trying to get in touch with our customers and become aware of what they do. That is the mission of the University. When we say we support the University that is what we mean. It is not support as in “Hello, this is Microsoft Technical Support.” It is “With the support of all of us, we can do what each of us cannot do alone.”

Get out of your office. Bump into someone you do not know and say, “Do you have a moment? Can you tell me what you do at the University?” Recognition, flexibility, and change all start with you.

draft.blogger.com

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Wed, 09 Jul 2008 16:32:00 +0000

I am posting this from draft.blogger.com. This is the ~~beta~~ (guess they don't call them that any more) draft of the new post editor. It actually seems to work in Safari! It includes image uploading, but that might have some issues.

You'll Never Believe This

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 08 Jul 2008 18:55:00 +0000

I have this crazy idea. I want to form a committee. I know… but I really do. I have this idea for a service that the University should have. (Notice I didn’t say who should provide it or even what “it” is.) I’m thinking this service has a transport component, so TNS should be involved, but I don’t want to make it a TNS committee. I’m also thinking that there will be an authentication component, so AIT should be involved, and of course there is a security component, so SOS should be involved, and yet I don’t want to make it an ITS committee. I’m thinking this will have a distributed IT component — you know that IT at Penn State is bigger than ITS, don’t you? But I don’t want to make it a Penn State IT committee, either. This service has a huge end user component. After all, what is the mission of IT at Penn State if not to support the University’s teaching, research, and service missions? And, what are those if not the embodiment of our faculty, staff, students, researchers, and so on — the users of our services.

You begin to see why I don’t want to narrow the focus of the committee too much. I have this crazy idea that a service should be formed with input from all of the stakeholders. It should address real users’ needs and wants, rather than the imagined ones of a middle manager on the IT staff (wherever he or she may be ). Certainly, they are stakeholders, as well, as I’ve already mentioned, but not the primary ones.

I’d go into the particular service, but it is not pertinent. You can see that this is a general problem. How do you get input from 107,000 people in any kind of useful, constructive way?

There are some things I’d like to accomplish in this committee:

Convince the stakeholders that they have a stake in its success
Identify how the group can work together
Do an affinity analysis to help define the user needs
Identify and define use cases
Establish a desired future state
Determine functional and non-functional requirements
Identify and prioritize essential, desirable, and optional features
Do a gap analysis

Out of this would come enough information for the appropriate people to go off and decide whether the service is feasible, and how to provide it. Of course, given a sufficient mandate, appropriate people would then go on to develop it in an agile way, providing early access to core functionality and features. Adding more features based on the original specification and feedback from users, administrators, and the committee.

So… Does anybody have any idea how to go about this? What has worked for you?

Retreat

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Tue, 08 Jul 2008 18:30:00 +0000

I spent (most of) the morning at Mountain Acres Lodge. Actually, I spent the first hour and a half driving around George’s Valley, which is directly across the ridge from Decker Valley, which is where Mountain Acres Lodge is, but let’s ignore that. As a result, I managed to miss Kevin’s talk in which he apparently answered a question I asked him in the last IT Leader’s Brown Bag lunch. If nothing else, at least I can provide fodder for further conversation.

Anyway, this was session 19 in the Brown Bag series and it was graciously hosted by AIS. Thank you very much!

As always, the event was wonderful. The conversation insightful and stimulating, and I already have ideas about how I can use what we talked about. Many light bulb moments today.

I think there is a core of people who really get it, who have integrated these themes not just into their daily lives, but into the way they think. Like learning a foreign language, it is the difference between being able to translate into the language you know and being able to think in the foreign language so that no translation is necessary. We are beginning to speak the language. Half a dozen people sat in a circle with me in our discussion group and had a single conversation. Ideas starting in one voice and flowing to the next. Being picked up by another and carried on by the rest. Without hesitation. Not rote repetition, but new answers to new questions — pertinent questions.

On a side note, I saw something in some meetings yesterday, as well. For a long time, I’ve been wondering how to influence the glacial pace of change in our organization. It has been extremely frustrating for me. I guess I was in a bit of a mood and I had a moment like Howard Beale (Peter Finch) in Network, where he says, “I’m mad as hell, and I’m not going to take this anymore!” That wasn’t what I said, but it was how I felt. The funny thing is, like in Network, the reaction was to hear the same thing from just about everyone around the table. It wasn’t just me any more. The people that I thought were the glacier had changed my mind. I was looking at it wrong. Not a glacier, but an iceberg. And the iceberg was breaking up before my eyes.

Things are changing. Now in visible ways.

Shorter “Should Links Open In New Windows?”

noreply@blogger.com (Mark (the Brush Valley Brewer)) — Wed, 02 Jul 2008 21:27:00 +0000

No, they shouldn’t.