When I teach project management, I teach people to know what success means, and to know what done means (release criteria). One of my students recently emailed me: At work recently, we’ve come upon a scenario where we have no success criteria (or more accurately, success criteria that we can measure in any way). […]
I’m working with a group of people who are new to iterative development. They’re doing more of a staged delivery lifecycle than an agile lifecycle, but they are releasing about once a month. They don’t like it, because they say they’re releasing too frequently. The problem is that their planning and releasing take too
I teach a class called “Software Methodology” at The Gordon Institute. My goal is for the students to be able to recognize if a software project is not being managed properly, and to give them a feel for what a software project might be like. So, I have them organize themselves into teams and
One of my students emailed me recently, asking about how to assess project complexity. He said, “I think it would be pretty neat and also quite useful if you could define a project as say a .60 Apollos or what have you… I don’t imagine it would be at all easy to come up
In my project management class a few weeks ago, I did an activity on feedback. In my experience, many project managers are also functional managers, so they need to give feedback. And, in highly collaborative teams, the person called “manager” isn’t the only one to give and receive feedback. One team got stuck. One
Don has a great post on Single Point Requirements. You get one example of the requirements: “This product needs to do this. Just this.” Sure enough some months (or years) later, that single example is not sufficiently general to do everything you want the product to do. That’s ok, as long as you plan to
A couple of weeks ago (yes, I know I’m behind :-), Scott Berkun asked in Teaching programming / management the Harvard way“Anyone have examples of CASE or situation based courses for managers, designers and programmers? Undergraduate or graduate?” Yes, Scott, I do. When I teach program management and software methodology (at the graduate level
I had a discussion recently with a manager who was concerned about his developers meeting their milestones. “We have “Code Complete” as a milestone. The developers say they meet it, but that just means they wrote code until the milestone date. The code isn’t complete. I can’t even tell how complete it is.” Ah,
I met someone at the Software Development conference this week who told me he had too many people to meet with them all–even on a biweekly basis. I asked him how many people he managed. “30.” That’s not a typo; that’s the number between 29 and 31. I asked why he had so many
I gave a talk entitled “Predicting Project Completion” at the Central Mass chapter of the PMI last night. I had some suggestions about techniques to generate and discuss schedule estimates. Then, to practice a little, I asked the audience to become participants and practice a simulation. The simulation is to first estimate how long