"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

grrrr. Archiving tags mysteriouly became corrupted! Too late to fix it tonight. ED

posted by Esther Derby at 10:31:00 PM  

|

I'm back from speaking at SD West, where I met several project managers who were promoted on the "Coder on Tuesday, Project Manager on Wednesday" program (similar to the "Coder on Monday, Manager on Tuesday" program). Expect to hear more about that from me and from Johanna Rothman.

In the meantime:

A friend of mine, who works in a large company, described how the Project Management Office in his organization is helping projects. The Project Management Office is chartered to ensure the company is receiving value from the projects it undertakes, and to make projects more predictable.

First, there is a rigorous process to initiate a project. This is a good thing. Projects that have no sponsor, no business case, and aren't solving a problem or creating an opportunity can be a drain on corporate resources.

Once the project is initiated, the project manager is required to project costs every month. Probably makes sense to keep an eye on spending and notice and investigate if spending is significantly off from what you expected.

And that's where the sense ends.

Navigating the corporate budget system and re-projecting takes, on average, one week a month. That's one week when the project manager wrestling with an unwieldy financial reporting systems and an equally unwieldy time tracking system. While the project manager is projecting, he is not managing the project.

Project managers are required (i.e., punished or rewarded) to manage their projects within 2% of their monthly budget projections. And what's the easiest way to do that? Manipulate the hours reported in the time tracking system.

My colleague has been instructed how many hours to report each week from now through mid-summer. He will be reporting 35 hours a week, whether he works 50, or 15.

What happens when some future project manager looks at the "actuals" captured in the project time tracking system?

Did that project really take 5,000 hours, or was it closer to 7,500. Or 10,000? Know one will know. Project work will become less predictable. Someone planning a project with similar scope will commit to an effort and cost estimate based on a fiction. And that project manager will fudge hours or miss schedule or work the team to the bone and slip quality.

It's frustrating to see a project manager walk into this very old trap. But the trap has been set with a poorly designed measure, and baited with a bonus.

posted by Esther Derby at 7:19:00 PM  

|

Two recent posts (Focus, Focus, Focus and Breakthrough Thinking on Worker Productivity) talk about the effects of multitasking and interruptions. Spread a person across 4-5 tasks and interrupt her with phone calls, drop-ins, emails, beeps, and meetings and pretty soon no real work is accomplished.

Some people – managers and technical staff – try to compensate by coming in early or staying late, when they hope for quite, uninterrupted time. Unfortunately, for the success of the stay-late-come-early strategy, people end up doing both: they come early and stay late. Some work from home or come in on weekends. This adds up to longer hours. And prolonged overtime is a killer. Tired people simply make more mistakes.

Many corporate cultures tacitly or explicitly encourage long hours.

How can we break out of the pattern?

Don’t spread people too thin. The TOC folks will tell you that projects using the same resources actually finish sooner when they aren’t run in parallel. If you have doubts, see the data on context-switching (March 21). Or look at this paper on Frank Patrick’s site.

Ban overtime. An occasional short stretch of 10-hour days won’t hurt anyone. Prolonged overtime has a high price. Work hard for 40 hours a week and then go home.

Establish a Meeting Free Day. Some groups agree that they will not schedule or attend meetings on a particular day of the week. The Meeting Free Day is for heads-down work, and heads-down work on.

If you can’t pull off a day, establish office hours. Let people know when you’ll be available and when your door will be closed. When people know that you’ll be available from 8-10 and 3-5, in most cases they can hold questions. You may want to let people know what the exceptions are, too: fire, emergency, system crash… you choose. This goes for management and technical staff.

Make meetings effective. I see many organizations where people are in meetings for 5 – 8 hours a day. Usually they report that not much is accomplished in these meeting. So when they meeting ends without a resolution, the group agrees to meet again. When do people get work done? Make sure your meetings are productive. Productive meetings have a purpose and an agenda. Only the people who must be present to achieve the purpose of the meeting attend the meeting. No hangers on. And unless there is a direct on-call responsibility, turn off beepers, pagers, and cell-phones when the meeting starts.

Get rid of status meetings. Try daily 15-minute stand-up meetings to report on progress, obstacles and plans for the day. Problem solving can happen as needed, with only the people needed after the stand-up meeting.

Now try it. Breath. Close your door (if you have one, otherwise put out your Do Not Disturb sign). Think.

posted by Esther Derby at 3:14:00 PM  

|

Bouncing off the evils of multitasking, C. Keith Ray (who just started his own blog) has this to say about how pair programming can counter some workplace interruptions:

Two effects pair programming has on tasking... in my experience...

It keeps the people focused on a single task (less likely to be distracted by emails, web-surfing, phone calls, people walking by, red herrings, trying the wrong design, bugs).

When one member of a pair does switch out of task to deal with a question or whatever, the other member can not only continue with the task, but also help the first one get back into the task, making switching (for a short period of time, like 5 or 10 minutes) less painful.

Still... I'd rather work on one project at a time, with the help of pair programming.

Other people report that people joining a project get up to speed much faster when pair programming, to the extent that "drop-in" programming is possible. In theory, this might allow some people to stay focused on one project (maintaining its continuity), and other people to switch projects frequently -- I don't know if this idea has been tested yet.

Keith makes a good point. It's not just the number of tasks that wreak havoc. Interruptions from calls, drop-ins, meetings, announcements, loud music, questions, pagers, beepers, the latest crisis -- can have the same effect on concentration and the same context-switching overhead.

Knowledge workers need periods of uninterrupted time to do their work -- thinking. If people can't find peace and quite in the cube farm, they'll find it by searching out a deserted conference room or an unused storage closet. And if they can't find a conference room or storage closet, they'll come in early, stay late, or work on company holidays, because it's the only time they can really achieve flow.

posted by Esther Derby at 8:11:00 PM  

|

I found a reference to this article in my morning stroll through blogland: Multitasking makes you stupid, studies say.

The article, by Sue Shellenbarger of the WSJ, points to evidence that multitasking doesn't really save time.

A growing body of scientific research shows that one of jugglers' favorite time-saving techniques, multitasking, can actually make you less efficient and, well, stupider. Trying to do two or three things at once or in quick succession can take longer overall than doing them one at a time, and may leave you with reduced brainpower to perform each task.

"There's scientific evidence that multitasking is extremely hard for somebody to do, and sometimes impossible," says David Meyer, a psychology professor at the University of Michigan. Chronic high-stress multitasking also is linked to short-term-memory loss.

Yet we're clearly engaged in a long-term trend toward doing more of it. Some 45 percent of U.S. workers feel they are asked or expected to work on too many tasks at once, says a study of 1,003 employees by the Families and Work Institute in New York.


The effect on knowledge workers is huge. Jerry Weinberg wrote on this topic in QSM 1, Systems Thinking (Dorset House, 1992).

# of tasks = 1 - Time spent on task = 100%
# of tasks = 2 - Time spent on task = 40%
# of tasks = 3 - Time spent on task = 20%
# of tasks = 4 - Time spent on task = 10%
# of tasks = 5 - Time spent on task = 5%
# of tasks = more than 5 - Time spent on task = random.

Notice that when someone is working on four tasks, he is spending 10% of his productive time on each task. That adds up to 40% of his time. Where does the other 60% go?

That missing 60% goes to:
--breaking concentration on the task A
--picking up task B
--organizing materials related to task B
--remembering where you were last time you worked on task B
--establishing concentration on task B
--overcoming emotional inertia
--recreating the train of thought that got you to the current point on task B....
and so forth and so on.

The cost can be higher if the level of tasks is different -- going from high-level design work, for example, to detail coding.

Here's what really surprised me about the current reporting on the cost of context-switching: it shows up in Work/Life balance pages. It should be on the business pages -- as breakthrough thinking on improving worker productivity and driving down costs!

posted by Esther Derby at 7:18:00 AM  

|

I'm working on getting the permalinks to work. I'm running into a few kinks. Bear with me, please.

ED (gnashing of teeth, tearing of hair)

posted by Esther Derby at 9:55:00 PM  

|

Yesterday after work, my spousal unit and I started our usual how-was-your-day ritual. He reported on a project he's just started and a meeting with a colleague from a previous job. I told him about the article I'm editing and a conversation I had with a colleague. I repeated an interesting statement made by a friend who works at the Department of Health: "The DOH is preparing for biological attacks," I said.

"Why?" my husband asked.

"Because they believe it's highly likely we'll be hit with biologicals in this country," I responded.

"Why?" my husband demanded.

"I guess they have evidence that convinces them an attack is likely," I said.

"Why?" my husband barked.

"How the hell would I know!" I snapped.

I don't have answers for all this biological threat stuff. I was annoyed.

And it's not just me: I noticed a long time ago that WHY? is one of those questions that sets people off.

If you really want to know why, WHY may not be the question to ask. So how do you ask WHY without asking WHY?

Ask HOW: How does this request fit with our other priorities? How will this directive affect our customers?

Ask WHAT: What was the thinking that went into this proposal? What scenarios were considered in adding this feature?

Ask WHO: Who will benefit from this decision? Who had input into this strategy?

Make a request:: Say more about that... Tell me more...

Admit you are puzzled or curious: I'm puzzled by what you just said... I'm curious about..... I don't understand....

I learn more about Why the less I use that question.

posted by Esther Derby at 1:42:00 PM  

|

Tim Van Tongeren gives an example of how posting project information publicly can open up communicaiton on the project team

This just won't happen if the plan is sitting in a scheduling tool (MS Project or your favorite flavor) on the project manager's computer. Not even when the plan is on a network.

When information about the project is visible, everyone on the team can see what's going on and everyone on the team becomes involved in solving problems.

Nice example of creating visibility so we can start seeing software.

posted by Esther Derby at 8:03:00 PM  

|

I found this on Joe Ely's weblog Learning About Lean:

Central to any Lean system is Management by Sight. An effective system is very visual. In less than two minutes, any associate must be able to assess if the system is in or out of compliance.

He tells a little story about a colleague looking out the window and seeing an activity gave him important information about a problem with their production process (the are in the buildings business).

How can we apply "Management by Sight" to software?

Create visibility into the product.

--Test first development. When the code passes the test you know it works.

--Technical reviews. People with the relevant technical expertise examine a product (a feature, a design, a spec...what ever) and assess whether the product will do the job it's intended to do. Make the review team's recommendation public information (but not the issues list, please).

--Satisfaction surveys. Send out a little survey that asks the designers (or developers or testers... whoever) how they rate the product. (Here's a short article on using surveys to "see" into
the product.)

--Unit tests. Run unit tests and post the results.

--Track defects. Make the information public.

Create visibility into the project.

--Create a Public Project Poster or Deliverable Map. Put it up on the wall and post review recommendations, status, estimated and actual effort and duration. Trouble cannot hide!

--Milestone reviews. Look at planned and actual progress. Look at what's changed, what assumptions have turned out to be correct and which have not; what risks have come home to roost.

--Track and display metrics. Defects, Fault Feedback Ratio, requirements changes, effort..... this list of possible choices is long. Pick a few key metrics and make them public (always in aggregate, metrics on individuals should stay private). Let your data tell a story.

--Hold a retrospective. Hold sprint retrospectives at frequent, short intervals. Ask the team: "How do you rate the product at this time? How do you rate our process at this time? How do you rate our teamwork at this time?" Use a 1-10 scale. Make a histogram. Figure out what it means. Choose what to change.

--Hold another retrospective at the end of the project or release. Recreate the timeline on a wall, a visual reconstruction of the project. It amazing what people will see about patterns of process and behavior when it's up there on the wall in black and white and color.

posted by Esther Derby at 3:17:00 PM  

|

Yesterday I was re-reading The Myth of Fungible Resources in Slack by Tom DeMarco.

Here's the definition of fungible that appears in the book (p.13):

Fun.gi.ble ....(especially of goods) being of such nature or kind as to be freely exchangeable or replaceable, in whole or in part, for another of like nature or kind.

Viewing people as fungible is the thinking that led to the staffing policies practiced at a multi-national company I once worked with:

All employees in IT or related functions were required to fill in a skills inventory. The skills inventory listed computer language skills (COBOL, C, C++, SQL, etc) and functional skills like requirements analysis, data modeling, data base design and project management. And it had a space to list level of proficiency, as evidenced by years of experience.

The global (everything was global at this company) skills inventory database was used to match employees all over the world to projects. A project manager anywhere in the world would fill out a form listing the skills needed on a project. A program would search through the database and produce a list of people who had the required skills and were available. Those people would be "deployed" as virtual team members to projects around the world! (Sounds so scientific, doesn't it?)

This scheme was intended to replace the process of internal hiring, which involved having humans apply for internal openings and having humans review applications, interview and select candidates, saving money and making efficient use of resources!

There are just a few problems with this sort of program (and the thinking behind it):

--It doesn't take non-technical skills and characteristics into account. What about traits like attention to detail, perseverance, able to see the big picture, encourages collaboration, works well with others? Personal characteristics and traits are just as important to the make up of a team as technical skills.

--It doesn't account for domain knowledge. Building an inventory tracking system in C++ is not the same as building a Monte Carlo simulation in C++. The time to learn the domain would certainly cancel out the "efficiency" of eliminating the messy, human application and selection process.

--It completely ignores the need for challenge and growth. What if someone has been programming in COBOL for years and is aching for a change or a new challenge? Deny people who want growth the chance to achieve it, and they'll usually move on.

Well, the Skills Inventory Database didn't work quite as planned. It was quitely dropped, but not until the company had spent hundreds of thousands of dollars and made a good sized dent in the store of employee goodwill.

This is an example in the large. People fall for the myth of fungible resources when job descriptions list only technical skills, resumes are scanned for languages, tools, and technical skills and hiring manager ignore the candidate's fit with the team and the culture.

But that's another story.

posted by Esther Derby at 8:06:00 AM  

|

I some times suggest journaling as a useful tool for people who want to become more effective leaders. I know journals are a useful tool because I have friends and colleagues who have journaled for years and swear by it.

But the truth is, I haven't used a journal consistently, at least not up until now. Sure, I've started lots of journals, but I ususally only last a few weeks.

The other day I was on the phone with Elisabeth Hendrickson and she asked me how I was using my journal..."eerrrr. I don't have one right now," I confessed. Elisabeth suggested I start a journal to try to figure out why I didn't have a journal. "Make a list of what's keeping you from keeping a journal," she suggested.

Here's the list I made:

--Keeping a journal isn't real work
--I'ts not part of my routine.
--I'll be embarrassed ten years from now when I look back at what I wrote.
--My handwriting is hard to read.
--My journal entries will be boring.
--My journal won't be pretty and artistic.
--I don't see how it's helping me.

Hmmm. As I look at this list, these seem like pretty lame reasons.

Then I went back and read some of my fits-and-starts journals. I found this entry in a journal I kept during a writing class:

Always remember the people you are writing for, and how you are helping them.

Well. As it happens, I've been struggling with a column I'm writing. And you know what? That little entry helped me.

Then I realized something else: Iv'e had this idea (who knows where it came from) that journals have to be prose. Not true! I can make a journal of lists if I want to. Or snippits, or words that catch my fancy, or doodles, or descriptions!

I've decided to make journal part of my day. It is real work, part of becoming more effective, what ever it is you do.

So what is keeping you from keeping a journal?
------
Bob Lee responds:

I tried journaling after reading Jerry's [Weinberg] Becoming a Technical Leader. I kept it up religiously about 3 weeks, then dropped out of journaling.

Reading your list of excuses led me to see another that I find:

- I hate to repeat myself. When what I have to say isn't new and unique, I find it feels awkward to put it on paper. I think this is a perfectionist rule or an MBTI type thing (INFP), but repeating feels like a no-no.

I too visualize my words being scrutinized by someone and feel that silence would be safer unless I have something clever to say.

Maybe I'll just convert to electronic media - my handwriting has grown so sloppy that I wince writing it out. Giving myself permission to be sloppy and unoriginal to capture the sequence of ideas, moods and context might do the trick. I'll see. March 12, 2003

posted by Esther Derby at 7:06:00 AM  

|

What's in a Name?

The name of this blog comes from the title of a column I wrote for STQE magazine (Management) Process Improvement a couple of years ago. The article talks about some of the fundamental things we can do to become more effective managers:

-- Learn about ourselves and how we respond in the world so we can better manage ourselves. If I can't manage myself, I can't manage anything or anyone else.

-- Learn from other expereinced managers so we can avoid making the same old mistakes. There's too much to learn to rely on only our own experience.

-- Learn from reading about new thinking and ideas. There are some new things under the sun... just filter out the fads and look for ideas that can make a difference in your context.

posted by Esther Derby at 7:21:00 AM  

|

Maintaining Quality
I stopped by HoloScan this morning to set up commeting on my blog and found this notice:

HaloScan.com - Weblog Commenting Signups closed temporarily

With the daily signups numbering in the hundreds and the support requests that come with the new registrations, it would be tougher to implement the changes and additions we have planned without compromising the overall quality of service. Therefore, in the best interests of existing and future members, we have decided to close signups temporarily till we roll out the planned changes and additions.

Wow! The folks at HoloScan have decided to hold off on more customers to maintain quality. I like it.

It reminded me of a very different response from a senior executive when his top managers told him the were understaffed and unequipped to handle the business volume from the latest new product release.

The executive said (quite loudly): "I don't care how many monkeys it takes to handle that business! I don't care if we have to hire temps from now until next Christmas to handle that business!" (It was January.)

It's easy to see the revenue coming in the door. It's harder to see the cost, especially the intangible one -- overtime for salaried employees supervising all those temps -- leading to fatiuge, errors, illness. What about the learning curve for the temps? They'll have to ask the experienced employees for help, which will take the experienced folk away from the work they were doing, leading to less progress. What about the effects on quality and service levels -- which will eventually effect customer satisfaction and customer retention?

I'm not saying "No more new customers for now" is a strategy that every company should follow, especially when revenue is involved. But is is worth considering some questions:

--What are the dangers and risks of a highly successful solution?
--What is the downside of more business?
--Can we provide the level of quality and support we have delivered in the past? What does that mean to us?

I'll check back with HoloScan in a bit to see if they're open again.... In the meanwhile, I think I'll just set up a mail to.

posted by Esther Derby at 9:30:00 AM  

|

Notice and Appreciate
Do you notice the people you work with?

I worked with a team this summer who had just completed a highly successful project. It was so successful, that the company gave each team member a significant cash reward $$$.

You'd think people would be happy, right? As I talked to members of the team, I heard something different. One after another, team members said, in a wistful sort of tone, "Yes, the cash bonus was nice. But I what I really want is for my contribution to be noticed."

Noticing and appreciating is different from rewarding, evaluating or saying " Atta boy! Thanks for a job well done." Noticing and appreciating talks to the person, not the task.

When I work with project teams in a retrospective, I teach them to give appreciations.

I put up a piece of flip chart paper that says "_______________, I appreciate you for _____________."

Most people are used to saying "good job." or "thank you," so this can feel a little awkward at first. One brave person will start and fill in the blanks: "Sara, I appreciate you for being patient with all my questions about the floozle design."

The other team members see the first one didn't die, so another will try it: "Jason, I appreciate you for keeping us on topic in all our team meetings. I didn't like it at first, but after awhile, I realized how much more we accomplished when you didn't let the dicscussion wander off track." Pretty soon it catches on!

Noticing and appreciating is a small thing that makes a big difference.
-------
Tom Van Vleck responds: Your blog entry about appreciation hit a chord. When I was managing , years back, I mentioned to another manager that I thought it was important to really care for one's employees -- to manage with love. The other manager snorted and said, "fear works a lot better. I kick butts until they deliver." (The project was a major failure.) March 5, 2003

posted by Esther Derby at 6:06:00 AM  

|

Too much to do
The other day I received an email from a colleague who is the QA/Test director for a mid-sized software company. Like many of us, she's busy--too busy. She feels like she’s running at 100 mph all day and barely has time to pause and think.

One of our most important jobs as managers is to step back and reflect on the big picture:
-- How is the team doing?
-- How is the work going?
-- Have priorities changed?
-- Has the context changed?
-- Are we still doing the right work?

If you can't find the way to the end of your work and are exhausted at the end of every day maybe it's time to see what you can take off the plate.

Try this experiment:

Write down the strategic goals of the function/group you manage.
Write down all the work you are doing.

Now answer these questions:

Does the work you're doing support the strategic goals?
Are you doing work that will prevent crises or dig your group out of crisis mode?

If you're doing too much tactical work or fighting fires, you won't have enough time to attend to strategic work or to attend to your team.

Look at the list of work you're doing again. What can you delegate or cross off?
---
Tom Van Vleck adds: Years ago I learned to ask myself "what are we trying to optimize?" every 30 minutes. Because otherwise, I'd waste the next 30 minutes. March 5, 2003

posted by Esther Derby at 6:21:00 AM  

|

Compared to What?
I just returned from my annual winter road trip. My trip included a visit to Chaco Canyon. I'd been warned about the bad roads. But I've been on some bad roads, and figured that with a four-wheel drive vehicle with plenty of clearance, we'd be ok.

As we made the turn down the unpaved road that covers the 20-miles from the highway to the archeological site, I looked at the road ahead of us: packed clay and gravel and wide enough for three cars.

I kept waiting for the road to deteriorate. It didn't. The posted speed limit was 45 and it was easy going the whole way. Sure, there are a couple of places where the road needs to be re-graded, but the road into Chaco Canyon is a *good* road.

Let me tell you what a bad road is like: two wheel tracks with ruts and barely enough room to get the truck between the trees. On a bad road, you creep along in granny gear at 5 miles an hour (tops).

And what does this have to do with software? It's a great example of the disconnect that happens when we make assumptions. In this case I made an assumption about the adjective "bad."

We use adjectives to be more descriptive. But adjectives can be subjective, and then they get us in trouble:

Think about a time someone asked for a system that was fast, or easy-to-use or secure. Chances are that your definition is different from the next guy's. Unless the person requesting and the person delivering calibrate their understanding of what "fast," "easy to use" or "secure" means, there's bound to be an expectation gap.

When you hear an adjective or adjective phrase without a comparison, ask questions to calibrate your understanding:

--Describe a system that is "easy to use."
--How would you know something is "easy to use"?
--What would make this software "easy to use"?

When you're doing the talking, be specific:

"The customer information screen needs to display in less than 1 second. That's 1/3 faster than the current screen return of 1.5 seconds."

"Our goal is to reduce the number of defects we ship by 25% compared to the number of known defects shipped in Release 2.1.4."

You're much more likely to see the result you want.

posted by Esther Derby at 6:29:00 PM  

|