We're ramping up for some big training in IT this year. Everyone will go through CMMi training. We're all likely to get re-trained in the program life cycle (PLC, also known as the program/product life cycle). The goal is to reduce all big projects into smaller "chunks" of six months or less. We're not as efficient as we should be and we need to get better at estimating and hitting delivery dates. And having a common language to use for projects and deliverables would be helpful.
This all sounds fine, but it's not clear to me what problem we're trying to solve with CMMi. CMMi isn't a process, and it doesn't teach project management. Perhaps I'll learn better how this will help when I go through the training, but right now I can't really see the connection between the problems we're trying to fix and the actions we're taking. People at most corporations tend to like new things. CMMi is hardly new, but it's new in terms of embracing a way to manage and measure process in IT at Intel.
The PLC training makes sense, and I think most people in IT need to understand it. Despite what you hear about PLC being a planning framework, it's not. It's a series of steps required to get decisions and funding from your management. It basically says you need to do some research to get a clue, turn you clue into an idea, turn your idea into plan and explain why it adds value, then get it appropriately funded. It's really just a check-and-balances process. Once you start to look at it that way and follow the process, you'll start getting more decisions approved. Tip: be sure to use the PLC graphic in your presentations to show where you are in the process. There's and cool new graphic that's identical to the old one in every way except the graphics look more expensive. (They guys who revamped Intel's logo must have had some extra time on their hands.) Middle and senior managers in IT have a Pavlovian response to this diagram and you score points just for using it. And you get extra credit if you actually understand it, although it's not a requirement.
A few years ago in the eBusiness group things were going along fine strategically, but not so well tactically. Projects were missing delivery dates, quality was not good, resource and spending estimates were poor for most programs, and customers were generally not happy. I may get into the details of this in a later post, but for now just assume this is a fair assessment of how things were going. In the midst of what some might have viewed as a crisis the group's ability to meet customer expectations, deliver, the Sr. staff were focused on strategy. In particular they spent a lot of time working in succession planning - figuring out who in their groups could replace them, and who would replace those managers.
The VP had read a book called The Leadership Pipeline and was encouraging her staff to read it, and some of them encouraged their staff to do the same. It's a good enough book. But what I found funny (and a little sad) was the way some managers would leave this book out on their desks, or occasionally carry it with them from meeting to meeting. I sat through many meetings looking at copies of this book wondering why someone had brought it into the room. I never quite figured out why people carried their books around, but I decided that these were likely the same people who wore wore calculators on their belts in college to be easily recognized as one of the clan.
So what the heck is my point? In the middle of a situation where things were going badly, the VP decided that her staff should focus on something they were already doing pretty well. They didn't focus on project management, or estimation skills, or look at who was making program management mistakes and why. They didn't question how to react when resourcing came up short, because the answer was obvious. They didn't question much about the management aspects of delivering technology, just the leadership.
I don't think the IT is going down the same path with CMMi that eBusiness did by focusing on strategy rather than tactical issues. But I think they could be missing an opportunity to fill a knowledge gap in the organization, and to help solve many problems rather than just a few. But I'm going to make you wait for the answer until my next post. I'm guessing many of you know where I'm headed.
Monday, February 26, 2007
Little Black Book
Posted by Intel IT Guy at 11:54 PM 1 comments
Labels: leadership, results
Tuesday, February 20, 2007
Regular Song
Some of you are asking about my intentions with this blog given my diminished posting rate. And someone posted this comment to my lone January entry:
Excuse me, but why do you blog if you never actually blog? You actually have some interesting insights that others at Intel fail to share, but a monthly posting is about as effective as Paul having someone write his blog entries for him.
That's a fair enough question. I know that I won't keep readers without writing regularly. My intent is to post at least once per week - a goal I am clearly not meeting. It's largely a matter of time. I've been balancing some unexpected life events and some travel for work. I also spend a fair amount of time on these posts, and if don't finish one it could me many days before I can get back to it. Finding uninterrupted blocks of time to finish my posts has been a challenge.
But those are excuses. I'll do my best to write more regularly. I have plenty of topics started, but they don't always develop the way I'd like them to. During the recent lull I started a couple of posts that were intended just to get something out there, but I wasn't comfortable posting just to post.
Thanks for the interest. I'll try to keep up a more regular pace.
Posted by Intel IT Guy at 6:12 AM 7 comments
Labels: blogging
Thursday, February 15, 2007
Focalization #3
I'm getting a fair number of questions about the focal process this year. People aren't sure if it's very different, slightly different, or completely different from the previous process, or what this means to them. From am employee perspective focal is about the same. You should have recommend some names to your manager for 360 feedback. You should have done a self-assessment, and by now most of you have reviewed a summary worksheet or draft of your final review with your boss. Employees are now in the waiting period where their manager has likely completed ranking and rating, but they won't know anything until after April 1. For me the process as an employee was about the same this year. The only difference was that my boss wanted my to write my complete review rather than a worksheet.
For managers things are significantly different. Previously managers would go into a room and discuss every person in a rank group, usually between 8-20 people, but sometimes smaller, sometimes larger. Different rank managers used different processes for going through a session, but it was invariably a long, painful process. You needed to represent a years worth of accomplishments for am employee in 2-3 minutes. These sessions were a real power play, with managers negotiating, influencing, and doing a lot of acting to try and get their people ranked and rated fairly. Most managers tended to do a good job. There was usually some asshole in the room who thought his people were more deserving than everyone else's. But with a good rank manager and/or HR person in the room, things were usually kept in check. Depending on the size of your team and the number of rank groups they fell into, you could spend 1-5 days in R&R sessions. I usually spent at least 40-50 hours preparing worksheets, and other 30-40 hours writing reviews. Then there was additional time for figuring out pay increases, dealing with last minute budget or stock changes, and other stuff. It was not unusual for me to spend 3-4 weeks of time working on R&R.
Things could tend to break down in R&R sessions where there was an uneven distribution of power, influence, and bias in the room. I had one boss who insisted on being in all our R&R sessions as an "observer" so he could direct the outcome. It was similarly bad when the rank manager had some obvious bias and would help influence the result rather than just facilitate. The worst rank sessions were those in which the rank manager was representing their own employees. I was actually in one session where two of those happened: our boss was in the room to observe, the rank manager was representing his own people, and both of them had an obvious bias toward the rank manager's team. They were aligned on the result they wanted to see, and the rest of us were working hard to bring a sense of fairness to the session. This was an extreme case, but it's a good example of what's been wrong with the focal process: it often had more to do with a manager's political and influencing skills than the performance of their employees.
This year managers are ranking and rating people on their own. I ranked my team as an in-tact rank group. I had someone at the top and someone at the bottom. Some people are outstanding, some are not performing very well. We are being held to a distribution within our teams - I can't have an unlimited number of outstanding employees, or promotions. And I am expected to identify a percentage as poor performers. This is still a difficult task, especially for those with small teams. But it's far easier than spending days lock in conference rooms with other managers, influencing and arguing to try and get the right result.
We had one 3-hour meeting with my boss where we reviewed each other's results and and rolled up summary for the team. My boss needs to hit a distribution as well, and we didn't. So we had some conversation about who else could or should be given a poor performance message, and who really didn't deserve to get a promotion. Some of the old behavior came out, and some managers were overly defensive about their people. That's always going to happen. Doing this in 3 hours vs. 3 or more days was a huge improvement in process and efficiency, and yielded about the same result we would have gotten with the old process. And we still aren't quite done and will need to spend another hour or two working on our distribution. But considering what we used to go through, it's big improvement. Focal isn't perfect, and still takes up more time than I would like. I credit Paul with challenging the old process and for allowing these changes to take place.
Posted by Intel IT Guy at 6:04 AM 3 comments
Labels: focal