This is an evolving site.

This is the second attempt to fix the network installation process at MIT. Begun in mid-1999, the project team set out to understand what was going on and drew a picture like this:

A result of years of local optimizations, legacy technologies, resource constraints and re-organizations without process follow up. The technology, challenges, organizations and people are different than they were 10 years ago and as such the process needs to be re-aligned to reflect these changes. Needless to say, the work is cut out and we feel confident the complete picture is still not understood.

The goals driving process redesign are to develop clear lines of work accountability, minimize gratuitous hand-offs, and have one place where requests are made and tracked. A well-tuned and monitored process should reveal the underlying problems that cause dissatisfaction and stress. Today it always seems to be someone else's problem as the root causes go untreated.

The design principles are common sense.

stop doing stupid things:A lot of cumbersome rules can develop over a long period of time where the process participants have no idea why a rule was put in place and whether it is still applicable. These things need not only be hunted down but the process should maintain itself in such a way that silly things don't persist.

update technology where appropriate: There's no reason a simple installation request cannot be routed directly from customer to installer via an on-line request form. Plentry of on-line forms do in fact exist today. They deposit email into a myriad of mailing lists that result in manual routing and data entry.

place work accountability where work happens: It seems that for every bump in the road a new process tentacle was spawned from the existing process to make sure it didn't happen again, or for every resource constraint, a new layer of people were inserted in the path. It's difficult to tell who is accountable for what and there are too many cracks for things to fall into. The process should make sure the right things are done and the right resources are applied.

clarify what people do and why they do it: An array of people support the process by dealing with difficult problems or exception cases such as the need to acquire more backbone capacity or build new underground pathways. Often these process exception cases take circuitous routes and the people responsible for these activities not clearly identifiable. Escalations up the organization (in so far as there is a recognizable up or down in Information Systems) often come back down in another piece only to make repeated loops around again. The process is not going to solve the Institute's challenges in financial constraints, space constraints and the effort to build a common world class infrastructure across a diverse community. The process, however, should stop the fooling around.

What you'll find at this site are a couple of progress report presentations made to Information Systems staff and sponsors and a proposed design and implementation plan.