I was extremely fortunate in my choice of companies and work early in my career. I developed in assembly language and microcode and Fortran for a few years. Then, I moved to object oriented languages, primarily at Symbolics, using LISP. At Symbolics (I left in 1990), we practiced incremental development, iterative planning, and some […]
Many project managers (and senior management) still have the mindset of “How much can we fit into this project?” instead of “How little can we do?” How-much thinking carries these assumptions (even if your managers don’t agree): People are a scarce resource, and that we should put all of them to use immediately, working
I ended up in the hospital last weekend (facial cellulitis – yuck). On my floor, we had people who were not too sick, who needed a few days to recover from an acute problem. Everyone’s prognosis was good, and the average stay on the floor was 3 days. Recovering from an acute illness takes
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