I had dinner last night with a CIO who’s working on outsourcing a significant part of his development and testing. He suggested that any senior manager who’s not thinking about outsourcing and how to make it work is missing the boat. “When you’re in a fixed cost development situation, and people are most of […]
When I teach and discuss project management issues, I talk about project constraints and project requirements. Most people immediately think of the “iron triangle”: cost, schedule, and quality. But I don’t find that the iron triangle is sufficient when trying to discuss project tradeoffs. Project constraints and requirements have more than three sides. Project constraints
I think of development and test as partners. The developers create product and defects. The testers detect product and defects. They both need to understand what the product is supposed to be and how it’s supposed to work (the requirements). The more the developers explain the architecture and design, the better the testers can
Hal recently said, “Listening is one of the foundational skills of project managers.” I agree, and would add writers, tech support reps, people managers to that list. What about developers and testers? I think they need to listen also. Anyone working in an agile project needs to listen (including customers or product managers). Is there
In a recent blog post and comment, Hal Macomber said, “Listening is one of the foundational skills of project managers. Without a high level of competence at listenting projects are doomed to drift. Given the general characterization by wives that husbands don’t listen, anytime we have project managers who are men we have a potential
After my presentation last night at the Detroit PMI chapter, an attendee asked me, “Is context switching really as bad as you say it is?” Yes, it is. I believe Weinberg’s estimate of losing 10-20% of possible work-time every time you attempt to take on one more project. And, if you read Hal’s entry today,
Via Steve Norrie’s weblog, I found Kovitz’s “Hidden Skills that Support Phased and Agile Requirements Engineering”. In phased development, projects promise large feature sets to a customer for future delivery. In agile projects, the requirements are refined over numerous little conversations with the customer, day in, day out. Kovitz claims the skills required for agile
On the AYE conference wiki, Jerry Weinberg said this: “no iteration should be so big that you can’t afford to throw it away if it doesn’t come out right in the end.” The longer the iteration, the less likely you can recover the project (or re-steer it, or re-guide it to an appropriate direction).
Bloglet subscribers saw two posts from me Friday. They saw the post I published *and* the post I saved as a draft. Surprised me. Since I know about this feature, I’ll work around it, and compose future drafts somewhere else. This isn’t a big-deal problem for me. But it was a surprise, and a
In Sunday’s Boston Globe View from the Cube column, Lisa Liberty Becker claims “Telling the truth can be hazardous to your job”. She goes on to talk about her husband, a performance test engineer, whose manager buried his reports, because “they [the reports] reflect poorly on the job he’s done.” The result? Bad product performance,