I plan on about 6 hours of work in a regular day. That’s project work, not answering the phone, email, making arrangements for workshops or consulting or speaking, or invoicing, or any of the other things I do. Nope, that’s just project work.

The other half of that question is how many regular days do I have in a week? Either 3 or 4. I’ve had weeks with fewer “regular” days, where I could only accomplish 2 or 3 hours of work. This week, I’ve had 2 regular days (6 hours of work days) and 2 irregular days, where I accomplished maybe 3 hours of project work.

Since I make my own commitments, this usually works out. But not always. When it doesn’t work–when I don’t have enough project time in a week, I’ll work on the weekend. I hate to do that because I don’t have enough brain cells to work effectively the next week, making fewer regular days the following week.

If you know how much project time you have day-by-day, you have a much better chance of estimating your work on a project. So when you think about estimating your time for a given task, think about what you can accomplish in a regular day. And think about how many regular days you have in a week. If you only have one day a week where you can accomplish 6 hours of work, and the rest you can accomplish 4 hours, plan for the 4 hour every day. You won’t have less to do over time–you’ll have more.

Labels: estimation

Oh dear. I was not sufficiently articulate in my last post. Both Frank and David in their comments asked about capacity, the output of the organization over time. That will teach me to post when I’m tired. (Maybe.) Let me try this again.

In each of these projects, senior management wanted more features than they received. Unsurprisingly (to me at least), the more features requested and the longer the project, the less the development staff (developers, testers, writers) could deliver. (Longer projects have more requirements churn than shorter projects, if only because the world keeps changing.)

The feature requests aren’t real requirements, they’re ambiguous placeholders for the real requirements, such as “electronic signature” or “improve speed.” But that’s what the organization has available at the start of the project. By the end of the requirements/design phase, they have real requirements, counted in the way the organization counts. This number is the number management expects to get out of the release. But there’s one more problem: management has set the release date. In fact, management set the release date back at the beginning of the requirements/design phase, without any estimation input from the development staff. So now, management has fixed the number of people available to work on the project, the time for the project, and the number of features it wants. The project has only one clear degree of freedom: the number of defects the project will deliver along with its features.

But, there’s an implicit degree of freedom here, that of features. Even though management claims they want all the desired features, history proves they will accept fewer features. The development organization counts on that, because the release date is set before the requirements are defined. Without firm requirements, it’s impossible to estimate the time necessary. Without estimates, each project essentially throws the dice, to see if there’s any way the project can meet its desired commitments.

The problem the organization has is in the difference between the requirements desired and requirements implemented. During the implementation phase, the developers realize that they don’t have sufficient time to implement some of the requirements as they stand.

Management was convinced it was the testers who prevented them from obtaining all the features they wanted. A senior manager said, “If we shorten the testing time, we can spend more time in development and get the features we want.” As you can tell from the data, they could have done away with testing and still not been able to get the features unless they changed the requirements and design activities. The problem with all of these projects is the inability to adequately define requirements quickly and completely enough for the developers to implement the requirements and the testers to verify them.

There are tons of reasons why the requirements definition phase can take a long time. In his comment, Frank mentioned multi-projecting. Another reason is maintenance from a previous release can take away developer time from requirements definition work. Sometimes the product managers don’t agree with each other on what their feature requests mean. Sometimes the analysts and product managers aren’t able to unambiguously define the requirements, so the developers end up making decisions or changing the requirements during implementation.

In this case, optimizing the project so that the testers could finish faster was the wrong approach. They have at least these choices: making the projects shorter, so the requirements/design phase is shorter; changing the way they define requirements and design; use a different lifecycle so they can continuously produce mini-releases; using estimates based on the requirements to estimate release date. There are probably more options.

What is clear to me, is that as Frank and David pointed out in their comments, the issue is the organization’s capacity, not the capacity of one group. Management can try to ask for more than the development organization can deliver, but unless the development organization changes how it works, it can’t. Lopping off the testing (or for that matter requirements, or any other phase), or optimizing for one phase doesn’t change the organization’s capacity (output over time). The only thing that changes the organization’s capacity is changing how people work (their practices and lifecycle).

I appreciate Frank and David for asking me what the heck I was thinking :-) If I’m still not making sense, please let me know.

On the face of it, higher productivity looks like a Good Thing. More products for less time. Who wouldn’t want this? But I wonder about this search for higher productivity. What do managers really want?

If you want to understand about productivity for software organizations, read Putnam and Myers’ new book, Five Core Metrics: The Intelligence Behind Successful Software Management. Putnam and Myers discuss what productivity really means.

In the meantime, I think some managers want to release more products faster. But I think more managers want to release more suitable products faster. Since they don’t know how to define or fund “more suitable,” they want everything out faster.

I know of these ways to release more products faster:

• Shorten the projects (yes, you can timebox an entire project. Use a design-to-schedule lifecycle.)
• Start the projects faster
• Use agile techniques, especially short iterations, so you can end the project faster
• Ask how little the project can do, instead of how much

If you have more techniques, please do comment.

People can only think so fast. But with a little management thinking, management can help their technical staff use those brain cycles more effectively, increasing productivity. Much easier and more reasonable than asking people to work more hours or multi-task on several projects.

• Assign people to only one #1 priority task at a time
• Assign people to only one project at a time
• Create opportunities for people to work together, to build review into the product development process
• Ask about obstacles
• Clear those obstacles

I’m convinced that the reasons outsourcing works is that it forces organizations to document requirements and the outsourcers work on only one project at a time. The outsourcers’ management can then choose any number of useful product development practices that increase the outsourcers’ productivity. Management can’t change their minds and refocus the outsourced project(s) in the same way they feel free to refocus the internal projects.

Earlier, I made an off-hand comment, “The zeroth measure of productivity is showing up.” I now think showing up is necessary, but not sufficient. I’ve been thinking about what each of us produces individually, and thinking of ways to understand and possibly measure it:

1. How many hours per day do you stay focused on strategically important work? Sometimes, I keep a time log to make sure I’m working on appropriate things. Especially if my to-do list is very long. Like many other people, I can be distracted by things that are easy to do, but not as necessary as the work that may be harder to finish.
2. How many stupid mistakes do you make? When I was younger, I was so proud of myself. I would take myself home after making three stupid mistakes. ARGH. Three! Why did I have to make more than one stupid mistake??? I learned that three stupid mistakes is two mistakes too many. Now, if I make my mistake at 9am, then I can clean up email or my office for a few hours until my brain has a chance to think again. If I make another mistake, I take the rest of the day off (from hard-thinking work). There’s almost always something I can do that doesn’t require hard thinking.
3. How many of what did you accomplish in a week? How many times did you revisit that work? When I’m writing, sometimes it takes me too many drafts to find the right way to discuss the topic. Same for creating presentations. When I was a manager inside organizations, I noted how many decisions I had to re-open. When I was a tester or developer, I looked at the work to see how much rework I had to do. Finishing a piece of work the first time isn’t enough; the work isn’t complete until the people you hand the work off to agree that it’s complete.

So, my measure of personal productivity is how long I can stay focused on useful work, and how few times it takes for me to accomplish that work until the person I hand off to is satisfied.