« February 28, 2003 | Main | March 04, 2003 »
March 03, 2003
Meat Market Democracy (and HB 240)
If you've got some free time on Wednesday evening, go down to the Capitol and sit in on the House or Senate during the final few hours. They pass dozens of bills very quickly in an effort to get legislation enacted before they are constitutionally powerless on Thursday morning at 12:00:01 am. I call it "meat market democracy" because its raw and aimed at mass production. Its really a sight to see. Afterwards, everyone stands around shaking hands and pretending to like each other.
On a related note, this Salt Lake Tribute article declares HB 240 to be "all but approved" but don't let that lull you into a false sense of complacency. As of this afternoon, it is stuck in the Senate Rules committee. Without going into more detail than necessary, its possible for a bill to get stuck there and never get out.
Here's what you can do: write to a member of the Senate Rules committee and express your support for HB 240. Here are their names and email addresses. Its more effective if you live in their district, so if you do, say so.
- Lyle Hillyard, chair, District 25
- Curtis Bramble, District 16
- Chris Buttars, District 10
- David Gladwell, District 19
- Parley Hellewell, District 15
- Scott Jenkins, District 20
- Michael Waddoups, District 6
- Gene Davis, District 3
- Ed Mayne, District 5
If you're not sure which district you live in, here's a map of Senate districts. Its important to contact these Senators tomorrow morning early and get the bill out on Tuesday. If it makes it out of Rules on Wednesday, it may not get voted on before the end of the session on Wednesday night.
10:36 PM | Recommend This | Print This
Building Operational Excellence: An Exercise
I'm reading a book by Bruce Allen and Dale Kutnick called "Building Operational Excellence: IT People and Process Best Practices." Allen is a Vice President and Kutnick is CEO of the META group. I'm about one-third through this book and really enjoying it. I'll write a full review of the book later, but there was something that caught my eye in Chapter 2 that I thought was worth noting now.
Allen and Kutnick focus on processes which they define as sets of related tasks. They create a process maturity model (PMM) that is based on the Capability Maturity Model for software. Chapter 2 contains a table of common IT processes which I reproduce here.
| Application Optimization | Negotiation Management |
| Asset Management | Network Monitoring |
| Budget Management | Output Management |
| Business Continuity | Performance Management |
| Business Relationship Management | Physical Database Management |
| Capacity Management | Problem Management |
| Change Management | Production Acceptance |
| Configuration Management | Production Control |
| Contract Management | Quality Assurance |
| Contractor Management | Security Management |
| Cost Recovery Management | Service-Level Management |
| Database Administration (physical) | SLA Management |
| Disk Storage Management | Service Request Management |
| Facilities Management | Software Distribution |
| Hardware Support | Software Management |
| Infrastructure Planning | System Monitoring |
| Inventory Management | Tape Management |
| Job Scheduling | Test Lab Management |
| Middleware Management | Workload Monitoring |
The claim is not that this list is all inclusive or that all organizations will perform all of these processes. Still, most large IT organizations probably perform most of them. Here's the exercise: identify which of these processes (or any others) that your IT organization performs. Now, take one and identify the tasks that make up that process. Rank each task on a scale of 1 to 10 on how mature you think your organization is at performing it. There's a complete process catalog in the book which you can use to benchmark your answers.
Allen and Kutnick list ten attributes that they use to describe and classify processes. If you use these to describe your processes, you'll be able to easily compare them to the process catalog in the book. These include:
| Process Name | Automation Level |
| Stability | Purpose |
| Skills | Tasks |
| Staffing | Automation Technology |
| Best Practices | Metrics |
| Cross-Process Integration | Futures |
Some of these are merely textual descriptions and others are rankings on a 1 to 10 scale. They use these to form templates for processes that remind me in some ways of the standardized ways of defining software patterns.
01:55 PM | Recommend This | Print This
Profile of a Product Manager
Anyone who spends much time with me knows that I'm passionate about product management. I've got a white paper that describes some of my thoughts around what product managers do. Now, via Dave Winer, we can read the profile of a great product manager:
Chris Pirillo is a super-product manager. He's got so many great ideas that he is passionate about. His 29-year-old brain is racing at 150 mph. It's like an encyclopedia in there. A bunch of programmers work for him. He brings them Chinese takeout every night. Chris listens to the users during the day, uses the competitors products, and he tells the developers what to do. Of course they don't listen but he argues with them on behalf of users until they get tired of arguing and give him what he's asking for so he'll just shut up. When they give him what he wants he hits the ceiling and it isn't acting because he really loves this stuff.
I've worked with product managers like that before and its so exciting that you just want it to go on forever. Part of my beef with current software engineering curricula is that about half of what they teach is really product management, not software engineering at all. I've known developers who became good product managers, but often as not, they're not developers, just folks who are passionate about the changes that technology can make and anxious to understand the needs of their users.
08:58 AM | Recommend This | Print This
Public Service Tip No. 6: Laugh at the Jester
In ancient times, the
jester was a fellow who entertained the king and other nobles at
the court. The jester had another, more important, purpose, however.
The jester was one who was "without offense," meaning that they could
tell the King and Noblemen the truth and thus advise and critique them
where others could not. The catch was that they had to do it through
jokes. In that way they often wielded much more power than their
colorful costumes and humor would otherwise suggest.
In modern times, we don't have jesters, but we have a group of people who have a similar function: legislative staff. When most people think of their government, they picture their legislators up at night, studying issues and drafting legislation. In truth, legislators do very little of that. The legislative staff does most of this work and keeps things running.
How much power legislative staff wields depends largely on how involved legislators are in an issue. For example, if you have a lazy committee chair, then they largely turn the operation of the committee, including the tenor and tone of the business over to the staff. Other chairs take an active role and are clearly running the show. Since the chairs of committees are largely appointed based on politics, rather than skill or aptitude, this can happen fairly frequently. This whole problem is exacerbated by the fact that in most states the legislature is part time. Thus, the staff has considerable time to cause trouble while they're left without adult supervision.
Occasionally, despite their protestations to the contrary, a particular member of the staff will inject their personal biases into the process and work overtime to make sure their ideas on how things should work are the ones being heard. Legislative staff are in a particularly powerful position in this regard and if there is no legislator minding the store, they can wield considerable power.
In Utah, for example, there is one particular staff member who believes that he is the one true source of legislative intent on all matters related to information technology. He would constantly show up to meetings with his code book in hand and try to drive the meeting. He saw me as power hungry and reckless because I had a different interpretation of the statue and was trying to move IT in the direction the Governor wanted. He did everything he could to create roadblocks for any initiatives we'd undertake. He was very successful and the taxpayers of Utah are the losers.
The job of a public sector manager dealing with an overzealous legislative staff member is made especially difficult by the fact that you have a goal you're trying to accomplish. They have no real goals or objectives to accomplish other than the daily tasks that haunt their world: finish this piece of legislation or complete this budget. Very few of them have any management experience at all and they have little understanding of what it means to actually be responsible for making something work. This makes it difficult to get them to understand your goals and, especially your motivations.
If you can make friends with the legislative staff and get them to ally themselves with your agenda, then you're way ahead. If you can't, you have to insulate yourself from their effects by cozying up the legislature directly. This is harder to do, but quite effective when you succeed. I never did manage it.