To: jdb@MIT.EDU (James D. Bruce) Cc: itlt@MIT.EDU, mbarker@MIT.EDU Subject: Re: A different way of working In-Reply-To: Your message of "Mon, 17 Jul 1995 18:15:05 EDT." <9507172215.AA10861@MIT.EDU> Date: Mon, 24 Jul 1995 16:06:57 EDT From: Mike Barker Content-Length: 6034 -Mike ----- I like a lot of what you say but think one - thing is missing. Right now there are more -interesting things to be done than there are resources to do -them with. Some of the things to be done have a higher -priority -- say, for example, in the eyes of those providing -us our budget -- than others. - -How do we introduce the idea of priority into the concept -you outline? -.......................................................jim Sorry about the delay in responding. Let me suggest three points toward an approach. I consider the selection of which tasks to do and the negotiations around that to be one of the thorniest problems of getting a group to work together, and I am certain I don't know all the answers to how to do it. 1. Make sure everyone is "talking" the same language. One part of the problem is that there are many ways of selecting tasks, with various sets of jargon and methods to go with them. So, through training, practice, and (at first) fairly frequent peer review, build a set of priority ranking practices that we all know, understand, and use. 2. Provide individuals with information, help, and feedback, but trust them to do the right thing. Make consulting on task priorities a management task, but leave the selection to the individuals. Note that performance reviews, future individual planning, and other feedback should provide clear indications of how successful the individual was at balancing individual and group priorities. 3. Consider an "annual report" to the IT group? While we don't have the legal reporting requirements of a company, this is a fairly well-understood approach to reporting on the results of the last year and setting out directions for the next. We could include an annual "budget" (resources obtained, consumed, available) if we add training in how to read the balance sheet. Perhaps the quarterly projections being done now could also include such reporting. I guess most of what I'm suggesting could be characterized as "teach people how to handle it, then distribute the problem." I think the "right" place for task setting, prioritization, and regular reviews of progress in the new IT framework will probably be at the team level. Admittedly, this leaves the possibility of overloading an individual if they are on multiple teams, and both the competency group leaders and the process group leaders should watch for such "stretched" people and provide them with extra help in picking which things to do, what and how to refuse, and how to teach others to do some of the work (delegation, training, etc. development). An important task for the IT group may be collecting information about task estimation. I think there is a tendency for individuals to underestimate how much time and effort many tasks will consume, and collecting some realistic data to use in future planning can be very helpful. Lurking somewhere in the notion that managers should perform "prioritization of tasks" is the idea that people don't know what is important and, even if they did, they wouldn't necessarily do the right thing. As a result, the manager has to direct them, using carrots and whips as appropriate, into doing what needs to be done. (theory X?) Personally, I tend to think that given adequate information and the mental tools to deal with it, people are capable of prioritizing their own tasks. People in management need to make sure that they have the resources, feedback, and the backing to control their own performance. Admittedly, letting people decide on their own means they may make mistakes. The trick is to make sure there are "safety nets" in place to keep the mistakes from being too hazardous--and admit that 100 small mistakes may be easier to recover from risky than one big mistake. Frankly, having management try to do the prioritizing may lead to a bigger problem. For example, there are twenty demands for the same individual or resource, and it seems as if there isn't time for that person to do the "filtering" to determine which are important. So the manager offers to sort out the priorities. But then the manager gets overloaded with dealing with the multiple customers, and some people work out ways to circumvent the manager. The "buffering" fails, and the individual is left to deal with a set of demands selected mostly by how well they can bypass the system. It seems more sensible to me to start with training for the individual in how to handle competing demands, then provide backing for the decisions made plus alternatives for handling conflict (perhaps we need an "arbitration" system?). A rough cut at the "common methods" of prioritizing might be: a. Making goals real--taking a general concept and converting it into measurable, concrete, achievable goals. b. Goal oriented selection of tasks--if the task doesn't contribute to agreed upon goals, why would we consider spending resources on it? (including a simple planning tool--goal, steps to get there, expected and actual completion dates, and responsible person) c. Trade-off matrix--the simple "spreadsheet" of things vs. some set of measurements, payoffs, risks, and resource requirements d. Ranking sheet--I use a fast brainstorm method. List of things. now, rank from 1 to 5 the importance. then, rank from 1 to 5 the likelihood. Multiply and sort by the result. (Different ranking filters can be used, of course) e. Trade-off graph--x vs. y, with various lines showing various key methods. Often a very powerful tool. f. Perhaps some simulations--e.g., here's 100 dollars, here are the 25 goals that have been named, how do you allocate the dollars? Note: Some people seem to thrive on GANTT charts or PERT/CPM diagrams (more graphic). These and other methods can be introduced along with simple task lists, as long as people don't get too buried in the techniques.